基础
消息队列的作用
- 削峰
- 解耦
- 异步
常用消息队列的比较
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
|---|---|---|---|---|
| 吞吐量 | 万级 | 万级 | 十万级 | 十万级 |
| topic数量对吞吐量的影响 | - | - | topic达千量级时，吞吐量较少幅度下降 | topic达百量级时，吞吐量下降明显 |
| 时效性 | 毫秒 | 微秒 | 毫秒 | 毫秒 |
| 可用性 | 主从 | 主从 | 分布式 | 分布式 |
| 消息可靠性 | 极小概率丢失 | - | 参数优化后可保证0丢失 | 参数优化后可保证0丢失 |
| 功能支持 | 完备 | 完备 | 完备 | 简单 |
| 劣势 | 可靠性低 | erlang语言开发 | 社区活跃度一般 | topic数量过多时导致的吞吐量下降，存在消息重复消费 |
| 突出优势 | - | 极小时延，社区活跃 | 消息事务，阿里出品 | 吞吐量极高，社区活跃 |
关于Kafka
kafka高吞吐量的原因
- 顺序读写
- 零拷贝
- 分区
- 批量发送+数据压缩
kafka角色说明
假如topic有N个partition，集群有(N+M)个broker，某个topic有N个partition，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。各角色说明如下：
- broker，服务器节点
- topic，主题，每条发布到Kafka集群的消息都有一个主题
- partition，分区，topic中的数据分割为一个或多个partition，每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序
- Replication，副本，Kafka支持以Partition为单位对Message进行冗余备份，每个Partition都可以配置至少1个Replication(当仅1个Replication时即仅该Partition本身)
- leader，主，每个Replication集合中的Partition都会选出一个唯一的Leader，所有的读写请求都由Leader处理。其他Replicas从Leader处把数据更新同步到本地
- ISR(In-Sync Replica)：是Replicas的一个子集，表示目前Alive且与Leader能够“Catch-up”的Replicas集合
kafka的高可用框架
image.png
kafka的消息可靠性
- request.required.acks设置为1 ，即ISR集合中的副本都同步后才算发送成功
- min.insync.replicas设置ISR最小副本数
kafka的副本复制机制
- 既不是完全的同步复制也不是单纯的异步机制。
- HW，一个分区的最后一条消息的offset
- LEO，一个分区副本最后一条消息的offset
- 当一个失败的副本重启的时候，它首先恢复磁盘中记录的HW，然后将它的消息truncate到HW这个offset。这是因为HW之后的消息不能保证已经commit了（也许leader上并没有HW之后的消息）
kafka消息的可靠性
消息不丢失
- 生产端，事务发送
- 中间件，acks配置设置为-1和ISR最小副本数
- 消费端，
重复消费 - 生产端，
- 中间件，
- 消费端，幂等防重
Zookeeper的作用
Kafka 使用 ZooKeeper 存放集群元数据、成员管理、Controller 选举，以及其他一些管理类任务，但新版本已经将zookeeper取代了。
领导者副本(Leader Replica)和追随者副本 (Follower Replica)
就是传统意义上的主从，主负责读写，从负责备份，也能提供读能力
kafka的顺序消费
单线程指定partition发送，单线程指定partition消费
RocketMQ
rocketMq事务消息原理
RocketMQ事务消息原理
持久化方式
- 同步刷盘，牺牲性能
- 异步刷盘，可能导致消息丢失
主从消息同步方式
- 同步复制，
- 异步复制，不影响可靠性，主节点从宕机中恢复时会重新复制
主要角色说明
- Broker，生产者生产消息到 Broker，消费者从 Broker 拉取消息并消费，一个 Topic 分布在多个 Broker 上，一个 Broker 可以配置多个 Topic，它们是多对多的关系。
- NameServer，Broker 管理和路由信息管理。Broker 会将自己的信息注册到 NameServer 中
- Producer，生产者
-
Consumer，消费者
RocketMQ角色关系图
消费模式
- 集群消费，一条消息只能被同一个group的一个Consumer消费
- 广播模式，消息将对一 个Consumer Group 下的各个 Consumer 实例都消费一遍
如何保证有序
- 发消息时指定发送到同一个topic的同一个queue（通过重写MessageQueueSelector）
- 收消息时指定从同一个topic的同一个queue中获取
零拷贝
- mmap+write
- sendfile
mmap+write的理解
通过虚拟内存，将文件映射到内核缓冲区，同时，用户空间可以共享内核空间的数据。这样，在进行网络传输时，就可以减少内核空间到用户空间的拷贝次数。
mmap+write
关于零拷贝
sendfile的理解
数据根本不经过用户态，直接从内核缓冲区进入到 Socket Buffer，同时，由于和用户态完全无关，就减少了两次上下文切换
sendfile
linux2.4改进版本零拷贝的理解
Linux 在 2.4 版本中，做了一些修改，避免了从内核缓冲区拷贝到 Socket buffer 的操作，直接拷贝到协议栈，从而再一次减少了数据拷贝。
gether
零拷贝方法使用场景
- mmap 适合小数据量读写，sendFile 适合大文件传输。
- mmap 需要 4 次上下文切换，3 次数据拷贝；sendFile 需要 两次 次上下文切换，最少 2 次数据拷贝。
- rocketMQ、java中的FileChannel+MapperByteBuffer，kafka的索引层采用mmap方式，kafka的传输层采用sendfile方式
