Kafka笔记

1.为何使用消息系统

• 解耦  两边都要实现这一接口，所以能独立地修改两边的处理过程。
• 冗余  会存储这些数据，以防数据处理失败而丢失。很多消息队列采用“插入-获取-删除”的范式。
• 扩展性  因为消息队列解耦了处理过程，所以增大消息入队和处理的频率很容易。
• 突发处理能力  对突增的流量可以从容地应对，使关键组件顶住。
• 可恢复性  当系统某一组件失效时，不会影响整个系统
• 顺序保证  保证消息的有序性
• 缓冲  使写入队列的处理尽可能地快速
• 异步通信  不一定需要立即处理消息，允许用户把消息放入队列但不立即处理它。

2.消息队列的点对点和发布订阅

• 点对点

　　生产者发送一条消息到Queue，只有一个消费者能收到。Queue实现了负载均衡，一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有 一个可用的消费者，一个Queue可以有很多消费者，他们之间实现了负载均衡， 所以Queue实现了一个可靠的负载均衡。

• 发布订阅

　　topic实现了发布和订阅，当你发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到一个消息的拷贝， 只有在消息代理收到消息时有一个有效订阅时的订阅者才能得到这个消息的拷贝。

• 消息队列模型比较

RabbitMQ

RabbitMQ实现了AQMP协议，AQMP协议定义了消息路由规则和方式。生产端通过路由规则发送消息到不同queue，消费端根据queue名称消费消息。此外RabbitMQ是向消费端推送消息，订阅关系和消费状态保存在服务端。

生产端发送一条消息通过路由投递到Queue，只有一个消费者能消费到。

当RabbitMQ需要支持多订阅时，发布者发送的消息通过路由同时写到多个Queue，不同订阅组消费此消息。
RabbitMQ既支持内存队列也支持持久化队列，消费端为推模型，消费状态和订阅关系由服务端负责维护，消息消费完后立即删除，不保留历史消息。所以支持多订阅时，消息会多个拷贝。

 

Kafka

Kafka只支持消息持久化，消费端为拉模型，消费状态和订阅关系由客户端端负责维护，消息消费完后不会立即删除，会保留历史消息。因此支持多订阅时，消息只会存储一份就可以了。

同一个订阅组会消费topic所有消息，每条消息只会被同一个订阅组的一个消费节点消费，同一个订阅组内不同消费节点会消费不同消息。