Rocketmq知识图谱

优点

缺点

总结

优点

缺点

总结

优点

缺点

总结

通过tcp与name server建立长连接，定时拉取broker元数据

元数据信息包括：Topic路由信息、messagequeue在哪些broker中

每30s自动和name server进行一次数据获取&更新

通过tcp与name server建立长连接，定时拉取broker元数据

用于管理broker server，类似于zookeeper的功能

本身是无状态的，所有的数据是存放在内存当中

支持集群部署，用来规避单节点风险，各节点间数据是不做同步的

部署架构模式

Broker Server需要向每个Name Server进行注册

master和slave节点都需要注册

Broker 和Name Server之间是TCP的长连接

Broker 向Name Server每30s发送一次心跳

Name Server有线程每10s对Broker Server进行一次探活

120s内没有接到Broker心跳确认，认为Broker宕机

Producer向Name Server拉取Broker信息

主从同步：Slave节点向Master节点拉取数据

Consumer节点消费Broker中数据

Rocketmq的读写分离，slave节点的度并不是人为可以控制的，也并不是传统意义上的读写分离

是否从slave节点读取消息，受限于两个条件

slave节点挂掉，对整体集群影响不大

master挂掉需要运维工程师手动调整配置，把slave切换成master，不支持自动主备切换

master-slave不是彻底的高可用，无法实现自动主备切换，version 4.5后，引入了Dledger，实现了高可用自动切换

一个Topic可以有上百万甚至更多的数据

消息的分布式存储，实际上是分散在各个Broker当中

Topic可以设置多个message queue做了一个逻辑分割，让数据分布式存储

这种概念，相当于kafka的partition，分散在各个broker中

Producer

样例： 接到消息

可以是很多log文件，默认每个文件限制1GB大小

采用PageCache写入+OS异步刷盘+磁盘顺序写的策略，
提升性能，基本和使用内存差不多（为什么性能高的问题）

对应MessageQueue Topic下的每个MessageQueue都会有一系列的ConsumeQueue文件

ConsumeQueue同样是基于OS cache的

集群模式

广播模式

Push

Pull

由客户端发起pull请求，服务端接收到客户端请求后，如果发现队列中没有消息，并不立即返回，而是持有该请求一段时间，在此期间，服务端不断轮询队列中是否有新消息

如果有，则用现在连接将消息返回给客户端，如果一段时间内还是没有消息，则返回空

好处在于，其本质还是pull，所以消息处理的主动权还是在客户端手里，客户端可以根据自己的能力去做消息处理
而服务端持有请求一段时间的机制由很大程度避免了空拉取，减少资源浪费

但是这种机制也有一定的问题，当客户端数量过多时，服务端可能在某个时间段内需要持有过多的连接，服务端压力比较大
不过一般来说，消息队列的承压能力还是比较可靠的，再加上集群的保障，基本不用担心这个问题。

3台及以上

3台

2台

2台

Prometheus 利用exporter进行监控

可以采用JMX进行监控

用Rocketmq-Console Dashboard进行监控管理

Prometheus

Zabbix

vm.overcommit_memory=1

vm.swappiness=10

vm.max_max_count=655360

ulimit=1000000

大体就是优化jvm相关参数，rocketmq默认是g1回收器

sendMessageThreadPoolNums=10

即MQ的TPS和机器的资源和负载之间取得一个平衡

RocketMQ的tps和消息延时

cpu负载情况

内存使用率

jvm gc频率

磁盘io负载

网卡流量

这种模式就是只管发送，不管MQ是否收到消息

类似于Kafka中的ACK=0的时候

produce.SendOneWay(msg);

默认是采用了同步刷盘策略

Producer发送给Broker之后，会等待Broker响应（超时时间默认为5分钟）

SendResult send = produce.send(msg)

默认采用的是异步刷盘策略

Producer发送给Broker之后，不会同步等待Broker响应（超时时间默认为5分钟）

可以调整失败重试次数

produce.send(msg, new SendCallBack(){
    @Override
     public void onSuccess(){

     }
     @Override
     public void onException(Throwable e){
     
     }
})

发送方式     优点                             缺点                                                          使用场景
同步发送     可靠性高，简单易用     延迟较高，吞吐量受限                                订单系统、金融交易、重要的消息通知等
异步发送     非阻塞，延迟较低        实现复杂度高，可靠性相对降低                   实时数据处理、日志采集、消费信息的推送等
单向发送     高效，延迟最低           无法确认消息是否成功发送，可靠性最低      日志收集、监控数据上报等

电商场景下，下订单15min未付款则关闭订单

多个consume消费消息，导致消息消费无序

取模选择对应messageQueue+批量等待机制

首先要保证消息是有序进入MQ的

消息放入MQ之前，对id等关键字进行取模，放入指定messageQueue

consume消费消息失败时，不能返回reconsume——later，这样会导致乱序
应该返回suspend_current_queue_a_moment,意思是先等一会，一会儿再处理这批消息，而不是放到重试队列里

consume.subscribe("TopicOrderDbData","Table A || Table B")
consume.subscribe("TopicOrderDbData",MessageSelector.bySql("a > 5 and b = 'abc'"))

1.数值比较，比如：>,>=,<,<=, BETWEEN, =;
2.字符比较，比如：=，<>, IN;
3.IS NULL或IS NOT NULL;
4.逻辑符号AND, OR, NOT;
5.数值， 比如：123，3.1415；
6.字符， 比如：'abc'，必须用单引号包裹起来；
7.NULL，特殊的常量
8.布尔值，TRUE或者FALSE

系统间调用的重复机制
A->B，B系统处理慢导致超时，A系统重新发送请求导致重复

上述B系统后有个将消息放入MQ的操作
手动提交offset未完成

消费者成功消费完消息，未返回consume_commit时，系统重启|系统宕机，
MQ重新发送消息到同消息组其他消费者机器，导致消息重复

重试机制导致的问题
消息成功发送到MQ中，但MQ因网络原因未能成功返回，导致重试机制重试机制重复发送到MQ

producer

consumer

生产者发送失败重试

消费者消费失败重试

网络问题导致的重发

16次重试失败，则放入死信队列

事务消息机制->half-commit

同步发送+不断重试机制

默认异步刷盘->同步刷盘

手动提交offset+自动故障转移

TCP长连接

长连接发送消息

正常IO读取数据会经过两次内核态切换，两次数据拷贝

mmap内存映射技术，映射用户私有进程地址和磁盘数据地址到pageCache不需要从OS cache拷贝至用户私有进程

写入同理，直接进入pageCache，然后异步刷盘

除此之外，还有内存预映射机制，文件预热来优化性能

避免因此种情况导致MQ集群挂掉

启动broker时，会自动创建一个名为rmq_sys_trace_topic的topic存放消息轨迹记录