分布式消息管理服务

概述

分布式可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出消息， 事务参与方(消息消费者)一定能够接收消息并处理事务成功，提供相应的可靠消息管理， ，消息的最终一致性，消息发给事务参与方最终事务要达到一致。

针对人群

• 项目经理
• 技术经理
• 架构师

业务架构图

消息通过集成多种引擎，规避复杂度和场景，同时提供出公共的消息接口能力:

架构说明 :

• 消息管理平台封装了消息的统一管理能力，包括统计和业务接口，规避消息的复杂度
• 集成多种消息能力，这里主要集成 kafka/redis/rocketmq 三种引擎，其中默认是 redis 消息
• 业务通过本地事务之后，发送到消息管理平台，消费端处理业务，完成业务之后，清理消息
• 消息管理平台集成消息通用的事务管理能力，包括补偿机制，异常机制，业务集成机制等

使用场景

• 异步: 很多场景下，不会立即处理消息，此时可以在MQ中存储message，并在某一时刻再进行处理；
• 解耦: 不同进程间添加一层实现解耦，方便今后的扩展。
• 消除峰值: 在高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如大量的insert，update之类的请求同时到达mysql，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too manyconnections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。
• 耗时业务: 在一些比较耗时的业务场景中, 可以耗时较多的业务解耦通过异步队列执行, 提高系统响应速度和吞吐量;

解决问题

本地事务与消息发送的原子性问题

事务发起方在本地事务执行成功后消息必须发出去，否则就丢弃消息，实现类似于数据库事务的ACID，即实现本地事务和消息发送的原子性， 要么都成功，要么都失败。本地事务与消息发送的原子性问题是实现可靠消息最 终一致性方案的关键问题。

事务参与方接收消息的可靠性

事务参与方必须能够从消息队列接收到消息，消息中包含异常处理机制， 比如重复发送，多次发送，异常通知提醒等，如果接收消息失败可以重复接收消息。

消息重复消费的问题

若某一个消费节点超时但是消费成功，此时消息中间件会重复投递此消息，就导致了消息的重复和多次消息处理， 过程中同步解决消息的超时问题，遗留消息处理问题，消息的重复消费问题等。

产品优势

• 简单易用: 一行代码即可发布一条消息; 一行注解即可订阅一个消息主题;
• 轻量级: 基于docker/fastjar/k8s部署简单，一分钟上手；
• 消息失败告警：支持以Topic粒度监控消息，存在失败消息时主动推送告警邮件；默认提供邮件方式失败告警，同时预留扩展接口，可方面的扩展短信、钉钉等告警方式；
• 强数据安全：消息数据存储在DB中，可事务保障数据安全，防止消息数据丢失；
• 失败重试: 支持设置消息的重试次数, 在消息执行失败后将会按照设置的值进行消息重试执行,直至重试次数耗尽或者执行成功;
• 容器化：提供官方docker镜像，并实时更新推送dockerhub，进一步实现产品开箱即用；
• 消息可见: 系统中每一条消息可通过Web界面在线查看,甚至支持编辑消息内容和消息状态;
• 事务性: 消费者开启事务开关后,消息事务性保证只会成功执行一次;
• 消息持久化：全部消息持久化存储，消息中心支持通过配置选择是否清理过期消息。
• 消息可追踪: 支持追踪每一条消息的执行路径, 便于排查业务问题;

其它

• 无