• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

RocketMQ核心原理与最佳实践笔记

互联网 diligentman 3天前 5次浏览
1.消息类型
普通消息 :单机性能可达10w级TPS
顺序消息:
分区有序消息,发送消息时制定队列,根据发送顺序,队列内先进先出
全局有序消息,Topic的分区数设置为1,单分区所有消息FIFO
单向消息:只管发送过程,不管发送结果,主要用于日志传输等消息允许丢失的场景
批量消息:提高发送效率,提升系统吞吐量
消息最好小于1M;同一批的Topic/waitStoreMsgOK必须一致;不支持延迟消息
延迟消息:先将消息发送到延时TOPIC,根据延迟级别初始化多个定时投递任务,每秒执行,如果消息满足时间条件,就将消息投递到原始TOPIC中
事务消息:先将Half消息保存到消费者不可见的TOPIC,生产者本地事务处理成功后,发送一个commit消息到Broker,然后再投递到原始TOPIC中;如果本地事务处理失败,会通知Broker删除之前的Half消息;Broker会定期回查生产者,确认生产者本地事务的执行状态再决定处理Half消息
2.
生产者发送消息高可用
a)生产者:
同步重试:见下面生产者总结
异步重试:见下面生产者总结
选择发送延迟级别较低的Broker发送消息:开启sendLatencyFaultEnable开关
b)broker:
生产中建议至少部署2个Master和2个Slave
同步复制:金融等高可靠性场景使用
异步复制 1个master挂掉或者1个slave挂掉或者2个slave挂掉或者一组master和slave挂掉都不影响生产
同步刷盘
异步刷盘:定时;实时
过期文件删除:
1.到达删除时间
2.磁盘空间超过85%
c)消费者
集群消费模式:异步、削峰等对消息没有顺序要求的场景;消费进度保存在Broker端,即使应用崩溃,消息进度也不会出错
广播消费模式:适合消费者实例都需要通知的场景,消费进度在客户端机器中,消费进度可能会丢失
消费的可靠性保证:
重试-死信机制:重试队列、死信队列(处理需要人工介入);补偿之前消费失败的死信数据
Rebalance机制:根据服务器架构变化,自动感知并调整
消费服务方式
并行消费
顺序消费:如果顺序消息消费失败,会再次投递给消费者消费,直到消费成功
消费进度保存机制
消费幂等性
3.
生产者总结
消息类型:
RocketMQ核心原理与最佳实践笔记
发送方法:
RocketMQ核心原理与最佳实践笔记
4..架构
RocketMQ Console
Namesrv:推荐一个集群部署2个节点
Broker:多master多slave同步复制最可靠
异步刷盘异步复制适用于大部分应用场景,个别意外情况可通过其他手段达到最终一致
服务正常停用不会造成数据丢失
服务异常停用会造成少量数据丢失
读写分离在提供高吞吐量的同时会增加数据不一致的风险,生产环境慎用
5.实践
1.衍生产品:rocketmq-connect-es/rocketmq-flink/rocketmq-hbase
2.严禁开放自动创建Topic和消费者组,需要通过API进行统一管理,推荐Rocketmq-console管理平台
3.重置消费位点,回放消息发送时间和实际消息的发送时间及顺序不同,重置时间最多不超过commitlog保存时间
4.如果业务消费代码出错,可以暂停消费者消费
5.因为业务代码出错导致失败而重试的消息会进入重试Topic,如果出现消费慢而堆积的问题,可以增加重试Topic的队列数
6.如果出现消息堆积,需要增加消费吞吐量的方法
优化消费业务代码,加快消费
增加单个消费者的消费线程数
增加消费者实例数(一个Topic队列只能被一个消费者实例消费)
7.监控
RocketMQ Exporter+Prometheus+Grafana
8.迁移
搭建新集群
迁移Topic等配置信息
禁写原集群
新旧集群双消费
确认原集群没有任何流量后,关闭报警,下线
9.测试环境,开发环境
方案一:不同环境建立不同RocketMq集群
方案二:同一个集群,不同环境建立不同订阅关系
 
{{o.name}}


{{m.name}}


喜欢 (0)