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
6、https://jack-vanlightly.com/blog/2017/12/15/rabbitmq-vs-kafka-part-4-message-delivery-semantics-and-guarantees
