RabbitMQ开发规范

RabbitMQ开发基础

  1. 学习了解MQ的AMOP基本原理 AMQP是一个异步消息传递所使用的应用层协议规范,AMQP客户端能够无视消息来源任意发送和接受消息,Broker提供消息的路由、队列等功能。Broker主要由Exchange和Queue组成:Exchange负责接收消息、转发消息到绑定的队列;Queue存储消息,提供持久化、队列等功能。AMQP客户端通过Channel与Broker通信,Channel是多路复用连接中的一条独立的双向数据流通道。

设计规范

  1. 选择RabbitMQ

    **规则目标:**什么业务设计场景应该选择RabbitMQ?

    规则要求:

    a、微服务(系统)间交互场景是联机交易需要实时返回,不能选消息队列而选RPC。

    b、微服务(系统)间交互场景被调用方可以异步延时处理,选择RabbitMQ来做解耦。解耦的好处:

    i、解耦降低复杂度:调用方(发送方)不关心被调用方(消费方)的处理结果,只保证发送到MQ服务器。异步消息队列是一种弱依赖设计,相对同步RPC是强依赖设计。

    ii、削峰:上下游处理能力不一致情况下,下游的处理性能不影响上游。

    规则示例:

    a、股票交易过程中,下达订单,交易微服务调用风控微服务,需要实时返回风控判断结果,风控通过才能进行交易,否则不允许交易。这种场景选择同步RPC。 b、股票交易过程中,订单已经成交,交易微服务调用风控微服务,不需要风控微服务实时处理,可以异步处理。这种场景选择异步消息队列RabbitMQ。

  2. 强制】Topic的命名规范。

    **规则目标:**主题含义清晰不会误用,同时不会和其他系统冲突,能适应一体化的场景。

    **规则要求:**按照微服务命名规范,平台名.系统名.服务名.功能名

    规则示例:“hsfund.ips.otc.deposit_insdirect 资管投资公共场外存款指令下达”。

  3. 建议】Exchange的命名规范

    **规则目标:**队列含义清晰不会误用,逻辑上做一下划分。

    **规则要求:**按照微服务来设计,“exchange.平台名.系统名”,同一技术产品用一个(没法约束共用)。

    规则示例:“exchange.hsfund. o45”、“exchange.hsfund. am4”、“exchange.cop COP”。

  4. 建议】Queue的命名规范。

    **规则目标:**队列含义清晰不会误用,不会和其他模块冲突,同时内部有合理的业务划分。

    **规则要求:**按照微服务命名规范,“平台名.系统名.服务名.内部业务划分”,这里的服务名指消费方,如果消费处理多个业务分类,内部也可以考虑分开不同队列处理。

    规则示例:“hsfund.ips.basic.usercenter IPS基础订阅操作员中心队列”。

  5. 强制】连接和断连

    **规则目标:**考虑网络异常,避免没连接上或没有断开导致处理异常。

    **规则要求:**自动重连、超时自动断连 Jres和Cres框架包装实现。 优雅关闭Jres默认封装无需业务实现,Cres需要业务实现优雅关闭(Cres框架下业务来操作这些指针,包括释放)。

  6. 强制】订阅和取消订阅

    **规则目标:**业务设计变更可能导致不再需要,无效部分需要取消订阅,避免造成流量浪费或引起处理异常。

    **规则要求:**Jres配置需要的主题即可(框架自动取消不需要的主题订阅)。Cres新增配置方法,业务按照框架要求配置即可(框架自动取消不需要的主题订阅)。

  7. 强制】可靠发送

    **规则目标:**业务提交保证发送到MQ服务器,除非行情这类业务上允许丢失。

    **规则要求:**Java调用Jres框架的可靠发送API,非极速Cres调用框架的可靠发送API (业务处理和框架写待发送一个数据库事务);UFT部分参照业务设计方案,业务上做待发送消息的持久化和重试。

  8. 强制】可靠消费-手工ACK

    **规则目标:**确保消费成功,避免消息丢失未消费。

    **规则要求:**消费处理成功再ACK让服务器删除消息,除非消息处理不成功没有影响。

  9. 强制】可靠消费-避免消息乱序

    **规则目标:**消息发送和消费通过网络没法保证严格顺序,需要业务设计来保证一致性,达到业务需求目标。

    规则要求

    a、业务上两个阶段,前一个阶段没消费掉,后一阶段先不处理。如成交和回溯,先收到回溯给MQ回NACK重新排队使能先消费处理成交后消费处理回溯。

    b、同一个业务状态多次变更,不能乱序导致最终错误。如先删除再新增,不能处理成先新增后删除导致数据不一致;又如最终状态为全部成交,实际乱序导致最终为部分成交。

  10. 建议】可靠消费-错误重试策略

    规则目标:下游依赖的处理失败的情况下,使用框架的错误重试测试,重新延迟入队继续消费。

    规则要求:

    a、要考虑性能不能大量重试或无限重试,否则大量消息重发可能导致系统崩溃,大量交易消息可以考虑默认的重试3次进入死信的逻辑,手工类业务消息量不大,可以考虑时间范围,比如10分钟内重试N次。

    b、重试时间间隔根据业务特性来设计,可以考虑调大或者变化频率,(默认是5秒)。

  11. 强制】发送消息事务性

    规则目标:避免业务一个事务发多个消息,导致消息处理的不一致性

    **规则要求:**同一个业务事务,只能产生发送一条消息。

    规则示例:反例1:主表和从表一个事务更新,发送两条消息。

  12. 建议】消费-幂等设计

    规则目标:必须支持幂等,发送方重试导致的重复消息能够处理。

    规则要求:

    a、首先要保证重复消息最终结果一致,不能重复处理导致业务数据错误。

      b、考虑性能和系统压力,比如重复收到全部同步(全表刷新)的消息,好的设计是不重复处理,再刷一次逻辑上也不会错误可能造成系统压力。
    
end
  • 作者:旭仔(联系作者)
  • 发表时间:2022-03-19 22:48
  • 版权声明:自由转载-非商用-非衍生-保持署名
  • 转载声明:如果是转载栈主转载的文章,请附上原文链接
  • 公众号转载:请在文末添加作者公众号二维码(公众号二维码见右边,欢迎关注)
  • 评论