kafka 最初考慮的問題是，customer 應該從brokes 拉取訊息還是brokers 將消
息推送到consumer，也就是pull 還push。在這方面，kafka 遵循了一種大部分
訊息系統共同的傳統的設計：producer 將訊息推送到broker，consumer 從
broker 拉取訊息。
一些訊息系統比如scribe 和apache flume 採用了push 模式，將訊息推送到下
遊的consumer。這樣做有好處也有壞處：由broker 決定訊息推送的速率，對於
不同消費速率的consumer 就不太好處理了。訊息系統都致力於讓consumer 以
最大的速率最快速的消費訊息，但不幸的是，push 模式下，當broker 推送的速
率遠大於consumer 消費的速率時，consumer 恐怕就要崩潰了。最終kafka 還
是選取了傳統的pull 模式。
pull 模式的另外乙個好處是consumer 可以自主決定是否批量的從broker 拉取數
據。push 模式必須在不知道下游consumer 消費能力和消費策略的情況下決定是
立即推送每條訊息還是快取之後批量推送。如果為了避免consumer 崩潰而採用
較低的推送速率，將可能導致一次只推送較少的訊息而造成浪費。pull 模式下，
consumer 就可以根據自己的消費能力去決定這些策略。
pull 有個缺點是，如果broker 沒有可供消費的訊息，將導致consumer 不斷在循
環中輪詢，直到新訊息到t 達。為了避免這點，kafka 有個引數可以讓consumer
阻塞知道新訊息到達(當然也可以阻塞知道訊息的數量達到某個特定的量這樣就可
以批量傳送)。
訊息中介軟體 推還是拉
訊息系統內有兩個角色 消費者和生產者 需求是生產者產生了乙個業務內容，需要給消費者，這裡可以引入兩種方式來處理 1.生產者直接推內容給消費者 代表 apache flume 1 優點 i.開發方便。2 缺點 i.生產者決定內容推送速率，不同消費速率的消費者不好處理。ii.如果生產者推送內容速度大於消...
狀態同步，究竟是推還是拉？
好友狀態的同步 有群友狀態的同步 有的需要實時同步，有的能夠容忍延時。結合具體場景來看下，狀態同步，究竟是推還是拉。不同的狀態，對於不同的業務處理流程可能不同 例如對於訊息的處理 服務端狀態離線，直接儲存離線訊息，等使用者下一次登入拉取 登入時，會修改使用者的服務端狀態為。登出 時，會修改使用者的服...
狀態同步，究竟是推還是拉
任何脫離業務的架構設計都是耍流氓。狀態同步，有好友狀態的同步，有群友狀態的同步，有的需要實時同步，有的能夠容忍延時。結合具體場景來看下，狀態同步，究竟是推還是拉。什麼是服務端狀態？服務端狀態離線，直接儲存離線訊息，等使用者下一次登入拉取 如何實時更新服務端狀態？使用者uid a登出時，會修改使用者的...