RabbitMQ
保证消息不丢失
生产者确认机制: 消息发送到 MQ 后会返回一个结果给发送者, 表示消息是否处理成功.
消息失败后处理方法:
- 回调方法即时重发
- 记录日志
- 保存到数据库然后定时重发, 成功发送后即时删除表中的数据
消息持久化, 默认内存存储消息, 开启持久化确保缓存在 mq 中的消息不丢失:
- 交换机持久化
- 队列持久化
- 消息持久化, SpringAMQP 中的消息默认时持久的, 可以通过
MessageProperties中的DeliveryMode指定
消费者确认: 消费者处理消息后向 mq 发送 ack, mq 接受到 ack 后才会删除该消息, SpringAMQP 有三种确认模式:
- manual: 手动 ack, 业务代码结束后调用 api 发送 ack
- auto: 自动 ack, 由 spring 检测 listen 代码是否出现异常, 没有异常返回 ack, 否则返回 nack
- none: 关闭 ack, mq 假定消费者获取消息后会成功处理, 消息投递后立即被删除
利用重试机制, 消费者出现异常时重试. 达到重试次数后, 如果依然失败则将消息投递到异常交换机, 人工介入处理.
消息重复消费
- 每条消息设置一个唯一标识 id
- 加锁: 分布式锁, 数据库锁
延迟队列
延迟队列 = TTL + 死信交换机
消息成为死信的条件:
- 消费者使用
basic.reject或者basic.nack声明消费失败, 并且消息的requeue设为false
- 消息时一个过期消息, 超时无人消费
- 要投递的队列消息堆积满了, 最早的消息可能成为死信
队列配置了dead-letter-exchange属性, 制定了一个交换机, 则队列中的死信就会投递到这个交换机种, 这个交换机被称为死信交换机 (DLX)
ttl: 一个队列中的消息 ttl 结束仍未消费, 则会变为死信, ttl 超时的两种情况:
- 消息所在队列设置了存活时间
- 消息本身设置了存活时间
或者安装延迟队列插件使用延迟队列
消息堆积解决
三种方案:
- 增加更多消费者, 提高消费速度
- 在消费者内开启线程池加快消息处理速度
- 扩大队列容积, 提高堆积上限, 使用惰性队列
惰性队列:
- 接收到消息后直接存入到磁盘中而非内存
- 消费者要消费消息时才会从磁盘中读取并加载到内存
- 支持数百万条的消息存储
高可用机制
普通集群
标准集群, 会在集群的各个节点之间共享部分数据, 包括: 交换机, 队列元信息. 不包含队列中的消息.
- 当访问集群中某节点时, 如果队列不在该节点, 会从数据所在节点传递到当前节点并返回.
- 队列所在节点宕机, 队列中的消息就会丢失.
一个节点宕机就不可用, 没有高可用
镜像集群
主从模式:
- 交换机, 队列, 队列中的消息会在各个 mq 镜像节点之间同步备份
- 创捷队列的节点被称为该队列的主节点, 备份到的其他节点叫做该队列的镜像节点
- 一个队列的主节点可能是另一个队列的镜像节点
- 所有操作都是在主节点完成, 然后同步给镜像节点
- 主节点宕机后, 镜像节点会代替成为新的主节点
同步期间宕机会丢失数据
仲裁队列
用来代替镜像队列:
- 与镜像队列一样, 主从模式, 支持主从数据同步
- 主从同步基于 Raft 协议, 强一致性
Kafka
保证消息不丢失
生产者发送消息到 broker 丢失:
消息在 broker 中存储丢失:
-
发送确认机制 acks
消费者从 broker 接收消息丢失:
kafka 分区机制: 将每个主题划分为多个分区 (partition)
topic 分区中的消息只能由消费者组中的唯一一个消费者处理, 不同分区分配给同一消费者组的不同消费者
关闭自动提交, 使用手动提交避免消息没有消费/重复消费:
同步+异步提交:
保证消费顺序性
一个 topic 有多个分区, 多个分区无法保证顺序性, 但是分区内偏移量顺序递增, 所以可以:
- 发送消息时指定分区号
- 发送消息时按照相同的业务设置相同的 key, kafka 会对 key 哈希来指定分区号
高可用机制
集群: 多个 broker 组成一个 kafka 集群
复制机制:
- 一个 topic 有多个分区, 每个分区有多个副本, 一个 leader, 其余都是 follower, 副本存储在不同的 broker 中
- 所有分区副本内容相同, leader 故障时会将一个 follower 提升为 leader
- follower 有 ISR(in-sync replica, 同步复制) 和普通副本 (异步复制), 优先从 ISR 中选取副本作为 leader
数据清理机制
存储结构:
- topic 数据存储在分区上, 分区文件过大就会分段存储
- 每个分段都在磁盘上以索引（xxx.index）和日志文件（xxx.log）形式存储
分段好处:
- 减少单个文件内容大小，查找数据方便
- 便于 Kafka 进行日志清理
日志清理策略：
- 根据消息的保留时间，消息保存时间超过指定时间（默认 168 小时）就会触发清理
- 根据 topic 存储的数据大小，当日志文件大于阈值则会开始删除最久的消息（默认关闭）
高性能设计
- 消息分区：存储不受单台服务器限制，处理更多数据
- 顺序读写：磁盘顺序读写，提高读写效率
- 页缓存：把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问
- 零拷贝：减少上下文切换以及数据拷贝
- 消息压缩：减少磁盘 IO 和网络 IO
- 分批发送：将消息打包批量发送，减少网络开销
减少了 页缓存 -> Kafka -> socket 缓存 -> 网卡 的过程
