承德网站制作方案,织梦本地做的网站内网访问不,关于幼儿建设网站ppt,优化关键词步骤简介#xff1a; 我们在几年前决定引入 MQ 时#xff0c;市场上已经有不少成熟的解决方案#xff0c;比如 RabbitMQ , ActiveMQ#xff0c;NSQ#xff0c;Kafka 等。考虑到稳定性、维护成本、公司技术栈等因素#xff0c;我们选择了 RocketMQ。 背景介绍
为何选择 R…简介 我们在几年前决定引入 MQ 时市场上已经有不少成熟的解决方案比如 RabbitMQ , ActiveMQNSQKafka 等。考虑到稳定性、维护成本、公司技术栈等因素我们选择了 RocketMQ。 背景介绍
为何选择 RocketMQ
我们在几年前决定引入 MQ 时市场上已经有不少成熟的解决方案比如 RabbitMQ , ActiveMQNSQKafka 等。考虑到稳定性、维护成本、公司技术栈等因素我们选择了 RocketMQ
纯 Java 开发无依赖使用简单出现问题能 hold 经过阿里双十一考验性能、稳定性可以保障功能实用发送端同步、异步、单边、延时发送消费端消息重置重试队列死信队列社区活跃出问题能及时沟通解决。
使用情况
主要用于削峰、解耦、异步处理已在火车票、机票、酒店等核心业务广泛使用扛住巨大的微信入口流量在支付、订单、出票、数据同步等核心流程广泛使用每天 1000 亿条消息周转。
下图是 MQ 接入框架图
由于公司技术栈原因client sdk 我们提供了 java sdk 对于其他语言收敛到 http proxy 屏蔽语言细节节约维护成本。按照各大业务线对后端存储节点进行了隔离相互不影响。
MQ 双中心改造
之前单机房出现过网络故障对业务影响较大。为保障业务高可用同城双中心改造提上了日程。
为何做双中心
单机房故障业务可用保证数据可靠若所有数据都在一个机房一旦机房故障数据有丢失风险横向扩容单机房容量有限多机房可分担流量。
双中心方案
做双中心之前对同城双中心方案作了些调研主要有冷热备份、双活两种。当时社区 Dledger 版本还没出现Dledger 版本完全可做为双中心的一种可选方案。
1同城冷热备份
两个独立的 MQ 集群, 用户流量写到一个主集群数据实时同步到备用集群社区有成熟的 RocketMQ Replicator 方案需要定期同步元数据比如主题消费组消费进度等。 2同城双活
两个独立 MQ 集群用户流量写到各自机房的 MQ 集群数据相互不同步。
平时业务写入各自机房的 MQ 集群若一个机房挂了可以将用户请求流量全部切到另一个机房消息也会生产到另一个机房。
对于双活方案需要解决 MQ 集群域名。
1若两个集群用一个域名域名可以动态解析到各自机房。此方式要求生产、消费必须在同一个机房。假如生产在 idc1 消费在 idc2 这样生产、消费各自连接一个集群没法消费数据。
2若一个集群一个域名业务方改动较大我们之前对外服务的集群是单中心部署的业务方已经大量接入此方案推广较困难。
为尽可能减少业务方改动域名只能继续使用之前的域名最终我们采用一个 Global MQ 集群跨双机房无论业务是单中心部署还是双中心部署都不影响而且只要升级客户端即可无需改动任何代码。
双中心诉求
就近原则生产者在 A 机房生产的消息存于 A 机房 broker 消费者在 A 机房消费的消息来自 A 机房 broker 。单机房故障生产正常消息不丢。broker 主节点故障自动选主。
就近原则
简单说就是确定两件事
节点客户端节点服务端节点如何判断自己在哪个 idc客户端节点如何判断服务端节点在哪个 idc。
如何判断自己在哪个 idc?
1) ip 查询 节点启动时可以获取自身 ip 通过公司内部的组件查询所在的机房。
2环境感知 需要与运维同学一起配合在节点装机时将自身的一些元数据比如机房信息等写入本地配置文件启动时直接读写配置文件即可。
我们采用了第二个方案无组件依赖配置文件中 logicIdcUK 的值为机房标志。 客户端节点如何识别在同一个机房的服务端节点
客户端节点可以拿到服务端节点的 ip 以及 broker 名称的因此
ip 查询通过公司内部组件查询 ip 所在机房信息broker 名称增加机房信息在配置文件中将机房信息添加到 broker 名称上协议层增加机房标识服务端节点向元数据系统注册时将自身的机房信息一起注册。
相对于前两者实现起来略复杂改动了协议层 我们采用了第二种与第三种结合的方式。
就近生产
基于上述分析就近生产思路很清晰默认优先本机房就近生产
若本机房的服务节点不可用可以尝试扩机房生产业务可以根据实际需要具体配置。
就近消费
优先本机房消费默认情况下又要保证所有消息能被消费。
队列分配算法采用按机房分配队列
每个机房消息平均分给此机房消费端此机房没消费端平分给其他机房消费端。
伪代码如下
MapString, Set mqs classifyMQByIdc(mqAll);
MapString, Set cids classifyCidByIdc(cidAll);
Set result new HashSet;
for(element in mqs){result.add(allocateMQAveragely(element, cids, cid)); //cid为当前客户端
}
消费场景主要是消费端单边部署与双边部署。
单边部署时消费端默认会拉取每个机房的所有消息。 双边部署时消费端只会消费自己所在机房的消息要注意每个机房的实际生产量与消费端的数量防止出现某一个机房消费端过少。
单机房故障
每组 broker 配置
一主两从一主一从在一机房一从在另一机房某一从同步完消息消息即发送成功。
单机房故障
消息生产跨机房未消费消息在另一机房继续被消费。
故障切主
在某一组 broker 主节点出现故障时为保障整个集群的可用性需要在 slave 中选主并切换。要做到这一点首先得有个broker 主故障的仲裁系统即 nameserver以下简称 ns 元数据系统类似于 redis 中的哨兵。
ns 元数据系统中的节点位于三个机房有一个第三方的云机房在云上部署 ns 节点元数据量不大延时可以接受三个机房的 ns 节点通过 raft 协议选一个leaderbroker 节点会将元数据同步给 leader, leader 在将元数据同步给 follower 。
客户端节点获取元数据时, 从 leaderfollower 中均可读取数据。
切主流程
若 nameserver leader 监控到 broker 主节点异常, 并要求其他 follower 确认半数 follower 认为 broker 节点异常则 leader 通知在 broker 从节点中选主同步进度大的从节点选为主;新选举的 broker 主节点执行切换动作并注册到元数据系统生产端无法向旧 broker 主节点发送消息。
流程图如下 切中心演练
用户请求负载到双中心下面的操作先将流量切到二中心---回归双中心---切到一中心。确保每个中心均可承担全量用户请求。
先将用户流量全部切到二中心 流量回归双中心并切到一中心 回顾
全局 Global 集群就近原则一主二从写过半消息即及写入成功元数据系统 raft 选主broker 主节点故障自动选主
MQ 平台治理
即使系统高性能、高可用倘若随便使用或使用不规范也会带来各种各样的问题增加了不必要的维护成本因此必要的治理手段不可或缺。
目的
让系统更稳定
及时告警快速定位、止损
治理哪些方面
主题/消费组治理
申请使用
生产环境 MQ 集群我们关闭了自动创建主题与消费组使用前需要先申请并记录主题与消费组的项目标识与使用人。一旦出现问题我们能够立即找到主题与消费组的负责人了解相关情况。若存在测试灰度生产等多套环境可以一次申请多个集群同时生效的方式避免逐个集群申请的麻烦。
生产速度
为避免业务疏忽发送大量无用的消息有必要在服务端对主题生产速度进行流控避免这个主题挤占其他主题的处理资源。
消息积压
对消息堆积敏感的消费组使用方可设置消息堆积数量的阈值以及报警方式超过这个阈值立即通知使用方亦可设置消息堆积时间的阈值超过一段时间没被消费立即通知使用方。
消费节点掉线
消费节点下线或一段时间无响应需要通知给使用方。
客户端治理
发送、消费耗时检测
监控发送/消费一条消息的耗时检测出性能过低的应用通知使用方着手改造以提升性能同时监控消息体大小对消息体大小平均超过 10 KB 的项目推动项目启用压缩或消息重构将消息体控制在 10 KB 以内。
消息链路追踪
一条消息由哪个 ip 、在哪个时间点发送又由哪些 ip 、在哪个时间点消费再加上服务端统计的消息接收、消息推送的信息构成了一条简单的消息链路追踪将消息的生命周期串联起来使用方可通过查询msgId或事先设置的 key 查看消息、排查问题。
过低或有隐患版本检测
随着功能的不断迭代sdk 版本也会升级并可能引入风险。定时上报 sdk 版本推动使用方升级有问题或过低的版本。
服务端治理
集群健康巡检
如何判断一个集群是健康的定时检测集群中节点数量、集群写入 tps 、消费 tps 并模拟用户生产、消费消息。
集群性能巡检
性能指标最终反映在处理消息生产与消费的时间上。服务端统计处理每个生产、消费请求的时间一个统计周期内若存在一定比例的消息处理时间过长则认为这个节点性能有问题引起性能问题的原因主要是系统物理瓶颈比如磁盘 io util 使用率过高cpu load 高等这些硬件指标通过夜鹰监控系统自动报警。
集群高可用
高可用主要针对 broker 中 master 节点由于软硬件故障无法正常工作slave 节点自动被切换为 master 适合消息顺序、集群完整性有要求的场景。
部分后台操作展示
主题与消费组申请 生产消费堆积实时统计 集群监控 踩过的坑
社区对 MQ 系统经历了长时间的改进与沉淀我们在使用过程中也到过一些问题要求我们能从深入了解源码做到出现问题心不慌快速止损。
新老消费端并存时我们实现的队列分配算法不兼容做到兼容即可主题、消费组数量多注册耗时过长内存 oom 通过压缩缩短注册时间社区已修复topic 长度判断不一致导致重启丢消息社区已修复centos 6.6 版本中broker 进程假死升级 os 版本即可。
MQ 未来展望
目前消息保留时间较短不方便对问题排查以及数据预测我们接下来将对历史消息进行归档以及基于此的数据预测。
历史数据归档底层存储剥离计算与存储分离基于历史数据完成更多数据预测服务端升级到 Dledger 确保消息的严格一致
原文链接 本文为阿里云原创内容未经允许不得转载。
