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