to be continue。。。
kafka是通過一個提交日誌記錄的方式來存儲消息記錄，採用拉模式，而RabbitMQ則採用隊列的方式，屬於推模式。
由於kafka是通過提交日誌記錄的方式，消息的狀態在消費端維護，因而當需要多訂閱時，完全沒必要建立多個partition，所有消費端對應同一個partition。但當kafka需要實現負載均衡時，就需要在一個topic下建立多個partition，此時，partition和消費端之間是多對一的關係。消息通過負載均衡分配到不同的partition。
RabbitMQ通過隊列的方式實現，當需要實現多訂閱時，就在一個topic下建立多個隊列，隊列之間的消息完全一樣。但某個隊列如果需要實現負載均衡，就比較簡單，只需要由每個隊列來實現負載均衡就可以了。
所以對比起來，kafka和rabbitMQ實現負載均衡的地方不一樣，前者是在消息保存進partition的時候，進行負載，後者是在消息進行消費的時候進行負載。多個partiton的目的是爲了負載均衡，而多個隊列的目的是爲了實現多訂閱。kafka提交日誌的方式不需要考慮多訂閱，但需要考慮負載均衡；rabbitMQ的方式需要考慮多訂閱。相比之下，rabbitMQ進行負載均衡時比kafka更容易。
另外，實際上，推模式和拉模式都是消費端主動去和消息中間件建立連接（輪詢也好，長連接也罷），然後將消息拉回消費端。因而個人認爲，推拉模式的本質差異是：消費頻率和消息狀態的保存位置，負載均衡實現端等的不同，即如果是在客戶端保存和實現則爲拉模式，反之則爲推模式。而並非很多博客中說的推是服務端推送給消費端，拉是消費端去服務端拉，也不是一些博客中說的輪詢是拉模式，長連接（長輪詢）是推模式。實際上，如果消息狀態存儲在消費端，即使使用長輪詢也算是拉模式；相反，如果消息存儲在服務端，即使使用輪詢，也算推模式。
參考博客：
1、https://blog.csdn.net/pi9nc/article/details/27714745 消息系統該Push/Pull模式分析
2、https://www.cnblogs.com/charlesblc/p/6045238.html 消息隊列-推/拉模式學習 & ActiveMQ及JMS學習
3、https://blogread.cn//it/article/5883#original 實現一個簡單的服務端推方案
4、https://www.cnblogs.com/charlesblc/p/6045238.html 消息隊列-推/拉模式學習 & ActiveMQ及JMS學習
5、https://jack-vanlightly.com/blog/2017/12/4/rabbitmq-vs-kafka-part-1-messaging-topologies