RabbitMQ开发基础
- 学习了解MQ的AMOP基本原理 AMQP是一个异步消息传递所使用的应用层协议规范,AMQP客户端能够无视消息来源任意发送和接受消息,Broker提供消息的路由、队列等功能。Broker主要由Exchange和Queue组成:Exchange负责接收消息、转发消息到绑定的队列;Queue存储消息,提供持久化、队列等功能。AMQP客户端通过Channel与Broker通信,Channel是多路复用连接中的一条独立的双向数据流通道。
设计规范
-
选择RabbitMQ
**规则目标:**什么业务设计场景应该选择RabbitMQ?
规则要求:
a、微服务(系统)间交互场景是联机交易需要实时返回,不能选消息队列而选RPC。
b、微服务(系统)间交互场景被调用方可以异步延时处理,选择RabbitMQ来做解耦。解耦的好处:
i、解耦降低复杂度:调用方(发送方)不关心被调用方(消费方)的处理结果,只保证发送到MQ服务器。异步消息队列是一种弱依赖设计,相对同步RPC是强依赖设计。
ii、削峰:上下游处理能力不一致情况下,下游的处理性能不影响上游。
规则示例:
a、股票交易过程中,下达订单,交易微服务调用风控微服务,需要实时返回风控判断结果,风控通过才能进行交易,否则不允许交易。这种场景选择同步RPC。 b、股票交易过程中,订单已经成交,交易微服务调用风控微服务,不需要风控微服务实时处理,可以异步处理。这种场景选择异步消息队列RabbitMQ。
-
【
强制
】Topic的命名规范。**规则目标:**主题含义清晰不会误用,同时不会和其他系统冲突,能适应一体化的场景。
**规则要求:**按照微服务命名规范,平台名.系统名.服务名.功能名。
规则示例:“hsfund.ips.otc.deposit_insdirect 资管投资公共场外存款指令下达”。
-
【
建议
】Exchange的命名规范**规则目标:**队列含义清晰不会误用,逻辑上做一下划分。
**规则要求:**按照微服务来设计,“exchange.平台名.系统名”,同一技术产品用一个(没法约束共用)。
规则示例:“exchange.hsfund. o45”、“exchange.hsfund. am4”、“exchange.cop COP”。
-
【
建议
】Queue的命名规范。**规则目标:**队列含义清晰不会误用,不会和其他模块冲突,同时内部有合理的业务划分。
**规则要求:**按照微服务命名规范,“平台名.系统名.服务名.内部业务划分”,这里的服务名指消费方,如果消费处理多个业务分类,内部也可以考虑分开不同队列处理。
规则示例:“hsfund.ips.basic.usercenter IPS基础订阅操作员中心队列”。
-
【
强制
】连接和断连**规则目标:**考虑网络异常,避免没连接上或没有断开导致处理异常。
**规则要求:**自动重连、超时自动断连 Jres和Cres框架包装实现。 优雅关闭Jres默认封装无需业务实现,
Cres需要业务实现优雅关闭
(Cres框架下业务来操作这些指针,包括释放)。 -
【
强制
】订阅和取消订阅**规则目标:**业务设计变更可能导致不再需要,无效部分需要取消订阅,避免造成流量浪费或引起处理异常。
**规则要求:**Jres配置需要的主题即可(框架自动取消不需要的主题订阅)。Cres新增配置方法,业务按照框架要求配置即可(框架自动取消不需要的主题订阅)。
-
【
强制
】可靠发送**规则目标:**业务提交保证发送到MQ服务器,除非行情这类业务上允许丢失。
**规则要求:**Java调用Jres框架的可靠发送API,非极速Cres调用框架的可靠发送API (业务处理和框架写待发送一个数据库事务);UFT部分参照业务设计方案,业务上做待发送消息的持久化和重试。
-
【
强制
】可靠消费-手工ACK**规则目标:**确保消费成功,避免消息丢失未消费。
**规则要求:**消费处理成功再ACK让服务器删除消息,除非消息处理不成功没有影响。
-
【
强制
】可靠消费-避免消息乱序**规则目标:**消息发送和消费通过网络没法保证严格顺序,需要业务设计来保证一致性,达到业务需求目标。
规则要求:
a、业务上两个阶段,前一个阶段没消费掉,后一阶段先不处理。如成交和回溯,先收到回溯给MQ回NACK重新排队使能先消费处理成交后消费处理回溯。
b、同一个业务状态多次变更,不能乱序导致最终错误。如先删除再新增,不能处理成先新增后删除导致数据不一致;又如最终状态为全部成交,实际乱序导致最终为部分成交。
-
【
建议
】可靠消费-错误重试策略规则目标:下游依赖的处理失败的情况下,使用框架的错误重试测试,重新延迟入队继续消费。
规则要求:
a、要考虑性能不能大量重试或无限重试,否则大量消息重发可能导致系统崩溃,大量交易消息可以考虑默认的重试3次进入死信的逻辑,手工类业务消息量不大,可以考虑时间范围,比如10分钟内重试N次。
b、重试时间间隔根据业务特性来设计,可以考虑调大或者变化频率,(默认是5秒)。
-
【
强制
】发送消息事务性规则目标:避免业务一个事务发多个消息,导致消息处理的不一致性
**规则要求:**同一个业务事务,只能产生发送一条消息。
规则示例:
反例1
:主表和从表一个事务更新,发送两条消息。 -
【
建议
】消费-幂等设计规则目标:必须支持幂等,发送方重试导致的重复消息能够处理。
规则要求:
a、首先要保证重复消息最终结果一致,不能重复处理导致业务数据错误。
b、考虑性能和系统压力,比如重复收到全部同步(全表刷新)的消息,好的设计是不重复处理,再刷一次逻辑上也不会错误可能造成系统压力。
评论