1、语言
?????? Kafka：采用目前比较主流的Java语言开发，运行依赖于JDK，比较适合Java开发者做源码深入或者加入其开源社区成为一个committee。
?????? Rabbitmq：采用erlang语言开发，一种广泛应用在电信通信行业的语言。
2、通信协议
????????Kafka：自己基于TCP实现的专有协议，Kafka的专有通信协议不包含Schema，内容简短，同时多条消息压缩的batch处理方式，减少了网络和CPU处理的压力，也是kafka吞吐量大的原因之一。
????????Rabbitmq：AMQP协议，一种专为消息队列而生的协议。
3、设计初衷
?????? Kafka：最初是领英为了解决生产日志存储处理而打造的一款产品。
?????? Rabbitmq：为了消息队列而生的中间件。
4、对zk的依赖
?????? Kafka：在早期版本中把topic分区、消费者生产者等元数据保存在了zk，中期版本把元数据保存在了各个broker中，逐步脱离对zk的依赖，但是controller的选举还依赖于zk，最新版本2.8.0中彻底放弃了对zk的依赖，当分区数量过多的情况下，这个过程对性能的影响比较大，去除这个依赖后，可以支持百万级别的分区，对于kafka的发展来说无疑是一个好消息，但目前不建议在生产环境中使用。
?????? Rabbitmq：一直对zk强依赖。
5、架构设计
Kafka：
????????生产者，消费者，消费者组，broker，topic和分区
????????生产者和消费组无需过多的描述，懂的都懂。
????????消费者组：指定有同一group的消费者，组内消费者数<=topic的分区数，大于没有意义，因为一个分区数只能由组内的一个消费者对应，一个消费者可以对应多个分区，这也是kafka扩展性和负载均衡体现点。
????????Broker：kafka server实例。
????????topic和分区：topic订阅主题，逻辑概念；创建主题为会其指定分区数，分区是实际存储主题消息的物理概念，分布在各个broker实例上。分区又有主分区和副本节点，每个主分区存放的数据是不一样的，也就是生产发送过来的数据会均衡写入到各个分区中，分区副本会同步主节点的数据。
????????生产者发送消息先经过序列化器序列化消息，然后再经过分区器选择把消息写入的最终分区，这时候如果消费者的消费是紧跟着生产者写入的，那么消息无需经过磁盘，会直接给到消费者。分区中会维持着消费者的消费偏移量，消费者可以选择从头消费，也可以选择从已确认的偏移量处开始消费，消费者的偏移量是可以重置的，可以指定移到指定偏移量处，当生产故障的时候可以使用该方式。
Rabbitmq：
?????? 主要有生产者、消费者、交换器、队列四种角色，交换器定义了消息路由策略，队列则是消息在中间件实际存放的地方。建立连接后，生产者通过 channel通道发送消息，消息先来到交换器，交换器根据策略和消息的 routing key 把消息再分发到对应的队列，消费者最后消费队列中的消息。
6、消息保留策略
????????Kafka：消息是会写入分区的磁盘文件的,两种历史数据保留策略，一种是保存过去多长时间的数据，一种是保证文件的固定大小，两种机制可以同时使用。提供了历史消息回溯的能力。
????????Rabbitmg: 消息被消费者处理完成后，就会删掉。
7、消息路由
????????Kafka：不提供任务的路由过滤机制，消费者订阅对应主题则会收到该主题上所有的消息。
????????Rabbitmg: 不同的交换器类型有着不同的队列分发策略，可以根据需要灵活地结合交换器和 routing key 值来在中间件层实现消息路由。
8、消息顺序
????????Kafka：在同一 topic，单一分区，单个消费者情况下，能保证消息能够按照发送的顺序达到消费者端（如果消费者使用的多线程来处理的话，这里不能保证消息被处理的顺序）但是这种情况下根本无法发挥 kafka 吞吐量大的特点。多分区、多消费者、消费者组的情况下，没法保证消息的顺序性，虽然分区是有序的，但是没法保证分区对应消费者的处理能力，实际情况是没法控制的，一个分区被处理完了，另一个分区还存在大量的消息积压，顺序自然没法保证了。
????????Rabbitmg：正常情况下能够保证消息顺序到达消费者处，但是如果发生异常，消息没有得到成功处理，那么会回到队列中，这时候消息顺序性没法保证。
9、扩展能力
????????Kafka：具有良好的横向扩展能力,通过增加分区数和消费者数提高系统处理能力。
????????Rabbitmg:更便于纵向扩展。
10、可靠性保证
????????两种在生产者和消费者上都提供了一些机制来确保消息的可靠性,比如失败重发,消息确认 ack 等机制,但是完全可靠还是得需要业务来做一些保证,比如失败重发都失败了,业务应用层面需不需要记录该失败信息。
11、适合场景
?????? Kafka：更适合大数据场景下的技术选型，在吞吐量、流处理支持上更好。
?????? Rabbitmq：适合真正意义上的消息队列，适合对可靠性要求较高的场合。
建议通过书籍系统性学习
《kafka权威指南》
《深入rabbitmq》