消息队列相关问题

1. RabbitMQ

2. RocketMQ
   可靠事务消息

3. Kafka
   分布式的，可实时快速处理大量数据
   Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。
   没有主从，通过zookepper 完成协调

4. ActiveMQ
   吞吐量较低

消息队列适合哪些场景

消息队列：它主要用来暂存生产者生产的消息，供后续其他消费者来消费。
它的功能主要有两个：a.暂存(存储)、b.队列(有序：先进先出)。

1. 异步处理数据：允许用户把一个消息放入队列，但并不立即处理它
2. 系统应用解耦：
3. 业务流量削峰：

RabbitMQ

处理来自客户端的异步消息。
服务端将要发送的消息放入到队列池中。接收端可以根据RabbitMQ配置的转发机制接收服务端发来的消息。
RabbitMQ依据指定的转发规则进行消息的转发、缓冲和持久化操作，主要用在多服务器间或单服务器的子系统间进行通信，是分布式系统标准的配置。

主要架构

1. broker：每个节点运行的服务程序，功能为维护该节点的队列的增删以及转发队列操作请求。

2. master queue：每个队列都分为一个主队列和若干个镜像队列。

3. mirror queue：镜像队列，作为master queue的备份。在master queue所在节点挂掉之后，系统把mirror queue提升为master queue，负责处理客户端队列操作请求。注意，mirror queue只做镜像，设计目的不是为了承担客户端读写压力。

1. 应用

服务间异步通信，顺序消费，定时任务，请求削峰

2. 工作模式

1. 简单模式：一个生产者一个消费者
2. 工作模式work：一个生产者，多个消费者；
   多个消费者同时监听同一个队列时会共同争抢当前消息队列的内容
3. 订阅者模式：群发
4. 路由模式routing：匹配对应关键字
5. 主题模式topic：交换机个根据通配符模糊匹配对应队列，由队列的监听消费者接收消息消费

3 问题

消息如何路由？

消息提供方–> 路由 —>一个至多个队列消息发布到交换器时，
消息将有一个路由键，在消息创建时设定；
通过队列路由键，可把队列绑定到交换器上；
消息到达交换器后，RabbitMQ会将消息的路由键与队列的路由键进行对应路由机制的匹配
fanout：交换器收到消息，将会广播到所有绑定队列
direct：路由键匹配，则把消息发送到相应队列
topic：可使用通配符模糊匹配

如何保证消息不被重复消费？（如何保证消息消费时的幂等性）

为什么会被重复消费？

正常来说消费者在消费完消息时，会发送一个确认消息给消息队列，队列得知该消息被消费就会将该消息从消息队列删除，
但有网络故障时，确认消息没有传到消息队列，导致消息队列不知道该消息已经被消费，会再次将该消息分发给其他的消费者

解决

保证消息的唯一性
在写入消息队列的数据做唯一标识，消息消费时，根据唯一标识判断是否消费过

例如有一个系统，消费一条消息后就往数据库插入一条数据，一个消息重复两次的话就会出错，应在插入数据库时根据唯一标识自己判断一下是否已经消费过，若消费过，直接丢掉，从而保证了数据的正确性

如何保证RabbitMQ消息的可靠传输？

消息

Kafka

实时快速处理大量数据
Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。

没有主从，通过zookepper 完成协调

问题

kafka中的broker 是干什么的?

broker 是消息的代理，Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉取指定Topic的消息，然后进行业务处理，broker在中间起到一个代理保存消息的中转站。

kafka中的 zookeeper 起到什么作用，可以不用zookeeper么

zookeeper 是一个分布式的协调组件，早期版本的kafka用zk做meta信息存储，consumer的消费状态，group的管理以及 offset的值。考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖，
但是broker依然依赖于ZK，zookeeper 在kafka中还用来选举controller 和 检测broker是否存活等等。

kafka 为什么那么快?

1. 顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。
   硬盘的每次读写都会 寻址–>写入 ,采用顺序读写极大的提升速度
   Kafka的message是不断追加到本地磁盘文件末尾的，而不是随机的写入
2. Cache Filesystem Cache PageCache缓存
   利用了操作系统本身的内存
   通过操作系统的Page Cache，Kafka的读写操作基本上是基于内存的，读写速度得到了极大的提升。
3. Zero-copy 零拷技术减少拷贝次数
   允许操作系统将数据从Page Cache 直接发送到网络，只需要最后一步的copy操作将数据复制到 NIC 缓冲区， 这样避免重新复制数据
4. 分区,分段,索引
   Kafka的message是按topic分类存储的，topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。每个partition对应了操作系统上的一个文件夹
5. Batching of Messages 批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。
6. Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符

kafka producer如何优化打入速度

增加线程
提高 batch.size
增加更多 producer 实例
增加 partition 数
设置 acks=-1 时，如果延迟增大：可以增大 num.replica.fetchers（follower 同步数据的线程数）来调解；
跨数据中心的传输：增加 socket 缓冲区设置以及 OS tcp 缓冲区设置。

整体架构：

zookeeper :分布式协调服务，协调kafka应用
broker：kafka的节点
producer：生产者生产数据
consumer：消费者
consumer group：消费者组，组内的消费者默认是不能重复消费
topic：主题，是消息的归类
partition：分区
replicas：副本，数据冗余储存
segment：文件段，文件按照1G大小进行拆分，主要包括两个文件，.index索引和.log（如何查找，二分）

消费者语义

1. exactly at once：精准消费一次，主要的是要保存好消费的偏移量，比如存储到redis或hbase中
2. at least once：至少消费一次，重复消费
3. at most once：至多消费一次，数据丢失

数据的不丢失

1. broker：通过副本机制，保证数据的不丢失
2. producer：ack机制
   1）0：不管broker是否保存好数据，都一直发送数据
   2）1：至少leader节点保证存储好数据
   3）-1：leader和follower 都保存好数据，再发送下一条数据
3. consumer：保存好offset
4. flume整合kafka
   关键点：设置好flume中的sink，到kafka