介紹隊列服務訂閱推送功能的使用。
在訂閱推送可以持續(xù)地將就緒的數據立即推送到客戶端手中，避免通過Get API進行輪詢造成的時延和通過隊列服務的內部機制進行查詢，可以最大程度地降低處理時延和隊列服務的負載。但是在使用上，由于有較多額外的概念，訂閱推送具有一定的復雜性。文本將介紹訂閱推送場景下的這些概念。
消費者
消費者是指從隊列服務中訂閱數據的客戶端程序，當客戶端使用Watch API進行數據調用時，會在隊列服務中生成消費者對象。您在API中增加的參數，比如Window的大小、Tags，將作為消費者的屬性。您可以通過Attribute API看到隊列服務中的消費者狀態(tài)，格式化的示例如下：
[OK] Attributes:
consumers.list.[0] : Id: default_group.u1, Index: 0, Pending: 0, Status: Complete, Idle: 2.091s, Window: 0, Slots: 0, AutoCommit: true
consumers.list.[1] : Id: default_group.u2, Index: 0, Pending: 0, Status: Complete, Idle: 1.124s, Window: 0, Slots: 0, AutoCommit: true
consumers.stats.total : 2其中：consumers.stats.total消費者的總數量。consumers.list是消費者列表，各個列的說明如下：
參數 | 說明 |
Id | 為消費者的ID全稱，格式是 |
Index | 為當前消費者正在消費的數據index。 |
Pending | 指示當前消費者正在處理，但沒有進行Commit的數據數量。 |
Status | 消費者的狀態(tài)，主要的狀態(tài)有：
|
Window | 消費者窗口大小，即允許的最大數據推送數量。 |
Slots | 窗口空閑數量，如果Slots為0，則窗口已經占滿。 |
AutoCommit | 是否在數據發(fā)出后，自動Commit數據。 |
Tags | 該消費者的tags過濾條件。 說明 當您使用帶有tags的watch API時，需要確保同消費者組的消費者使用的tags都是相同的。 |
如果您在使用Watch API時，執(zhí)行了數據的tag，則還會看到一個額外的Tags列，比如：
consumers.list.[0] : Id: ..., Pending: 0, ..., Window: ..., Tags: tags[foo=bar]表示該consumer關注的數據tags，只有當數據滿足該條件時，數據才會送達該消費者。
消費者組
消費者組是以相同過濾條件訂閱隊列服務的消費者的集合，不同組內的消費者可以同名，同組內的消費者不可以同名。
在同一個消費者組內，數據將會均衡地分發(fā)給各個消費者；在不同的消費者組間，數據會并列地推送給每一個存在的消費者，舉例來看：
如果您的多個消費者在同一個組內，您可以觀察到數據會在這些消費者之間進行均衡地分發(fā)，消費者會收到不同的數據。
如果您的多個消費者在多個不同的組內，您可以觀察到不同組的消費者收到了相同的數據。
如果數據已經被某個消費者通過API刪除，該數據會被立即刪除，其它組內的消費者將無法收到該數據。
您可以通過Attribute API看到隊列服務中的消費者狀態(tài)，格式化的示例如下：
groups.list.[0] : Id: default_group, Index: 0, Pending: 0, Delivered: 0, Consumers: 1
groups.list.[1] : Id: group, Index: 0, Pending: 0, Delivered: 1, Consumers: 0groups.list是消費者列表，各個列的說明如下：
參數 | 說明 |
Id | 為消費者組的ID。 |
Index | 為當前消費者組正在消費的Index，為所有組內消費者最大的Index。 |
Pending | 指示當前消費者組正在處理，但沒有進行Commit的數據數量。 |
Delivered | 以及推送出去的消息數量。 |
Consumers | 消費者組內的消費數量。 |
可以創(chuàng)建的消費者組數量沒有上限，但值得注意的是消費者組不會被自動清理，創(chuàng)建之后其狀態(tài)會一直保留。
消費者與消費者組的使用
您可以在Watch API調用中通過HTTP Header聲明所使用的消費者與消費者組，或者在各個語言的SDK中，在client初始化時進行聲明。相關HTTP Header的key也可以通過Attributes API進行查看。
meta.header.group : X-EAS-QueueService-Gid
meta.header.user : X-EAS-QueueService-Uid通過X-EAS-QueueService-Uid，X-EAS-QueueService-Gid分別聲明使用的消費者ID和加入的消費者組ID。
Commit與Negative
隊列服務支持Commit與Negative兩種消費方式，其操作對象都是數據的Index，但是兩種方式的語意完全不同。
Commit為完成提交，表示該消費者已經收到了這批數據并且處理完畢，可以推送下一批數據。
Negative為否定提交，表示消費者已經收到了數據但是因為某些原因無法處理，隊列服務根據錯誤Code決定是否推送下一批數據。可以在Negative的同時以文本方式聲明原因與錯誤Code，該數據會被推送給其他消費者。下列的表格規(guī)定了隊列服務能夠處理的特殊錯誤Code：
Code
說明
Shutdown
表明該消費者正在執(zhí)行退出，隊列服務不會繼續(xù)推送數據。
數據重平衡
在很多場景下，消費者無法進行數據Commit，比如：
正在進行預測服務的滾動更新，一些消費者正在處理數據但是被終止，正在處理的數據無法被Commit。
消費者遇到了某些內部錯誤導致崩潰。
消費者無法處理收到的數據而執(zhí)行Negative Commit。
這些無法處理的數據會被隊列服務重新推送給其他消費者，這種機制稱為數據重平衡。數據重平衡會在以下時間點發(fā)生：
任一消費者進入Exit狀態(tài)。
消費者在Windows有空閑的情況下沒有收到新的數據推送。
隊列服務為每一條數據都維護了投遞的計數器，每次數據執(zhí)行重平衡并且被分發(fā)出去之后，都會使得該計數器加一。當在重平衡過程中，發(fā)現某數據的投遞計數器已經超過了最大投遞次數，該數據被為作為死信進行處理。隊列服務會執(zhí)行您配置的死信策略，默認情況下會將數據投遞到尾隊列。
尾隊列
尾隊列是輔助性質的隊列，主要用于存放不推送給消費者的數據，比如死信或者您自定義的控制數據。尾隊列也是隊列服務內的一個隊列實例，具有相同的API。輸入隊列和輸出隊列均各自配備了一個尾隊列。
注意：尾隊列和普通隊列實例共享最大隊列長度，即如果隊列實例最大長度是10，而普通隊列長度為6，則尾隊列最大長度只能為4。此時，若尾隊列達到4時，如果繼續(xù)嘗試寫入數據，會返回隊列過長的錯誤。因此尾隊列需要定期觀察和清理。
您可以在API調用時增加額外的HTTP Header來聲明訪問尾隊列，增加的HTTP Header如下：
X-EAS-QueueService-Access-Rear: true