消費者獲取消息主要有push和pull兩種模式算法
push模式： 由消息隊列主動向 Consumer 推送消息服務器
pull模式： 由 Consumer 主動從消息隊列 獲取消息併發
push模式最大的缺點就是：服務器不清楚consumer的消費速度，若是consumer中執行的操做又是比較耗時的，那麼consumer可能會不堪重負,而性能好的consumer可能處於閒置狀態，形成負荷·不均。異步
pull模式最大的缺點應該就是： 當部分consumer異常致使 Producer 速度遠大於consumer速度時，大量消息會堆積在消息隊列中。至於說影響實時性的問題，實際上是能夠經過實現的方式進行解決。性能
對比兩種方式，通常的消息隊列都會採用pull模式，他有一下優勢：spa
一、consumer根據自身能力進行獲取任務，按照多勞多得的原則，能夠解決多個服務器之間負荷不均的問題。隊列
二、消息有消息隊列統一管理，能夠作消息備份，保證消息不丟失。路由
consumer採用pull模式的實現方案kafka
一、consumer啓動後向消息隊列發送準備就緒，而後異步等待任務消息隊列
二、consumer定時向消息隊列發送心跳包
三、消息隊列收到心跳包後更新consumer的有效性，消費者一段時間未更新則移除，防止consumer異常退出後，繼續下發任務。
四、 消息隊列接受到任務後採用最近最少使用算法路由（LRU模式） 將任務轉發給consumer
五、現實中consumer處理任務不會是處理完一個再接下一個，所以，能夠採用多通道模式，即準備就緒信號攜帶通道id，這樣一來能夠經過控制通道數就能夠控制任務處理的併發數。
這裏還有一個問題就是，當consumer異常結束時，未處理完成的消息要如何處理，這裏就要看是由消息隊列維護狀態信息仍是由consumer來維護狀態信息，好比kafka就採用的由consume維護狀態信息，consume記錄消息的偏移量，異常重啓後能夠重寫獲取消息。若是是由消息隊列維護隊列狀態，那麼能夠將正在執行的任務進行記錄，若是檢測到consumer異常退出，就能夠將任務回收進行重發，但這裏並不能肯定consumer全部待處理的消息是否須要重發，所以這裏須要更加實際業務進行處理。