多个mq如何选型

  • RocketMQ

    • Java开发
    • 集群化，效率高，每秒可解决几十万条音讯
    • 有音讯查问界面
    • 音讯可靠性高

  • Kafka

    • Scala开发
    • 效率高
    • 音讯失落概率大，适宜做日志收集、埋点上报等业务

  • RabbitMQ

    • erlang开发
    • 对音讯沉积反对不敌对

  • ActiveMQ

    • Java开发，简略、稳固，效率不高

MQ的作用

  • 解耦

    • 上游发mq，上游订阅，上游不须要关怀有哪些上游零碎，不须要与上游间接交互

  • 异步

    • 不须要同步执行的业务逻辑，异步解决，缩小响应工夫

  • 削峰

    • 后端Service能够放弃固定速率生产，甚至进行生产，保证系统不被压垮

RocketMQ从生产发送到生产的执行流程

  1. Producer发送音讯到Broker，负载平衡策略默认随机
  2. Broker接管音讯，写入PageCage，返回胜利
  3. Broker刷盘，音讯存储Consumer queue、commit log
  4. Consumer从Broker拉取音讯，拉取形式长轮询pull
  5. Consumer生产音讯，解决业务逻辑
  6. Consumer返回ACK，更新Broker offset
  7. 生产失败，音讯转入失败队列
  8. Broker的ScheduleService从重试队列拉取音讯，重放这个音讯
  9. 重试16次如果还是失败，音讯进入死信队列
  10. 通过RocketMQ操作面板监控死信队列，手动解决

RocketMQ如何做负载平衡

Topic在Broker集群中分布式存储

Producer端：轮询
Consumer端：平均分配策略，一个队列最多被一个生产组的一个Consumer生产，一个Consumer能够生产多个队列

RocketMQ如何保障音讯不失落

1、Producer端

  • 采取send()同步发消息，发送后果是同步感知的。
  • 发送失败后能够重试，设置重试次数。默认3次。
producer.setRetryTimesWhenSendFailed(10);
  • 集群部署，比方发送失败了的起因可能是以后Broker宕机了，重试的时候会发送到其余Broker上。

2、Broker端

  • 批改刷盘策略为同步刷盘
  • 批改主从复制策略为同步复制

3、Consumer端

  • 生产胜利后会返回ACK，更新Broker的offset

音讯失落的场景

  1. 异步刷盘，Broker宕机，未实现刷盘
  2. 异步复制，主Broker宕机，未实现复制

反复生产问题

1、造成反复生产的起因

  • Consumer生产完，宕机，未返回ACK
  • Consumer生产完，返回ACK，网络断开，Broker未收到
  • 主Broker更新ACK，副Broker未复制，主Broker宕机

2、解决
业务方管制幂等

  • 定义业务幂等字段，数据库定义为惟一键

怎么发送程序音讯

  • 将音讯发送到同一个队列中
  • 通过重写MessageQueueSelector接口，将不同的音讯发送到指定的队列
  • Consumer生产的时候如果是多线程，须要先应用synchronize获取锁
  • 一条音讯生产失败，将阻塞整个队列，所以个别不必

RocketMQ效率高的起因

  • 分区并行。每个Topic能够设置多个MessageQueue（Partition），能够对应多个消费者实现并行处理
  • 程序写磁盘。对commit log采纳追加写的形式，新音讯被追加到文件的末端
  • 利用页缓存PageCache。Broker收到数据后，写入PageCache即算胜利，由操作系统本人管制刷盘
  • 零拷贝。消费者能够间接从PageCache读取数据，缩小了数据复制次数，防止了用户态与内核态之间的切换
  • 应用Netty框架实现高性能的网络传输

RocketMQ与Kafka的异同

1、定位

  • Kafka定位高吞吐，对音讯反复、失落没严格要求，实用数据量超大的日志收集、埋点数据收集等常见
  • RocketMQ思路源于Kafka，提供了更牢靠的音讯传输，具备高吞吐、高可用个性，实用大规模分布式系统利用

2、单机反对队列数

  • Kafka队列数超过64个性能会降落，对多个Partition文件的程序写在操作系统层面变成了随机写
  • RocketMQ队列数增多效率无显著降落，因为数据存储在一个commit log

3、数据可靠性

  • Kafka应用异步刷盘，异步主从复制，Producer只反对异步发送音讯，且会积攒一批音讯一起发
  • RocketMQ反对同步刷盘，同步主从复制，Producer发送音讯反对同步、异步、单向三种模式

4、过后音讯

  • Kafka不反对
  • RocketMQ反对level级别的定时音讯

5、音讯失败重试

  • Kafka不反对
  • RocketMQ反对工夫level级别的重试

以下RocketMQ反对，Kafka不反对：

6、分布式事务音讯
7、程序音讯
8、音讯查问
9、音讯回溯

RocketMQ音讯底层存储模型

  • CommitLog存储真正的音讯体
  • ConsumerQueue是CommitLog的索引文件，存储音讯在CommitLog的物理偏移量，音讯大小，tag的hashCode
  • IndexFile是面板查问的索引文件

定时音讯实现原理

  1. 提早级别大于0示意提早音讯，将音讯转存到SCHEDULE_TOPIC_XXX队列
  2. ScheduleService定时工作拉取延时队列中的音讯（未到延时工夫则提早100毫秒再拉）
  3. 依据偏移量从CommitLog拉取音讯体
  4. 复原成原来的音讯主题，将音讯投递到原主题队列

音讯沉积如何解决

1、减少Consumer，减少MessageQueue，减少Consumer线程数
2、新建一个Topic，先生产将音讯搬运到另外一个Topic，后用新Consumer生产解决

分布式事务音讯实现原理

Half Message：预处理音讯，当broker收到此类音讯后，会存储到RMQ_SYS_TRANS_HALF_TOPIC的音讯生产队列中

查看事务状态：Broker会开启一个定时工作，生产RMQ_SYS_TRANS_HALF_TOPIC队列中的音讯，每次执行工作会向音讯发送者确认事务执行状态（提交、回滚、未知），如果是未知，Broker会定时去回调在从新查看。

超时：如果超过回查次数，默认回滚音讯。

也就是他并未真正进入Topic的queue，而是用了长期queue来放所谓的half message，等提交事务后才会真正的将half message转移到topic下的queue。

其余

RocketMQ生产模式有几种？

生产模型由Consumer决定，生产维度为Topic。

  • 集群生产
1.一条音讯只会被同Group中的一个Consumer生产

2.多个Group同时生产一个Topic时，每个Group都会有一个Consumer生产到数据

  • 播送生产
音讯将对一 个Consumer Group 下的各个 Consumer 实例都生产一遍。即即便这些 Consumer 属于同一个Consumer Group ，音讯也会被 Consumer Group 中的每个 Consumer 都生产一次。

如果让你来入手实现一个分布式消息中间件，整体架构你会如何设计实现?

  • 反对集群，反对疾速扩容
  • 音讯存储模型
  • 高性能
  • 高可用性
  • 数据0失落的思考