企业级消息平台化-幂等组件

一、背景

在网络不可靠的背景下，消息的投递和Ack都存在不确定性，消息中间件通常采用的方式是重试，保证至少消费一次，那么消费者需要保证幂等性

二、解决方案

常见的幂等：

1. 业务表保存上游唯一键
2. 领域状态机CAS，单向流转
3. 本地消息表
4. 事件版本号

2.1 业务表插入上游唯一键

此方案和本地消息表方案类似，都是向​​rds​​插入一条数据。 不同之处在于这条数据通常还承载了业务其他信息

适用场景： 新增型的事务

劣势： 需要业务场景支持，幂等跟业务操作是耦合的

2.2 领域状态机

此方案和业务表插入上游唯一键方案类似 不同之处在于这条数据是属于​​UP​​操作

使用场景：

1. 更新型事务
2. 存在状态机
3. 状态机的流转是单向的

劣势： 需要业务场景支持，幂等跟业务操作是耦合的

2.3 本地消息表

此方案需要上游传入​​bizModule​​​和​​bizKey​​消息头信息， 消费者服务需要建立本地消息表，将业务操作和幂等插入在一个原子性事务内

基于存储实现方案类型：

1. 基于​​rds​​方案
2. 基于​​nosql​​方案

rds方案

需要数据支持跨表事务，需要插入数据操作（仅存储​​bizModule​​​ 、 ​​bizKey​​），

优势：

1. 保证仅消费一次
2. 不侵入业务
3. 不需要后期补数据

劣势：

1. 在并发场景高的场景，会影响系统性能

使用场景：

1. 对数据可靠性要求高业务
2. 性能不敏感
3. 业务操作也落地在​​rds​​中

nosql方案

通常的​​nosql​​​选型是​​redis​​​，本地消息表数据存储在​​redis​​​中， 使用​​setNx​​​方法，保证幂等性，可靠性比​​rds​​低一些

优势：

1. 性能高

劣势：

1. 无法保证完全可靠，在极端场景需要补偿消费

使用场景：

1. 对性能敏感
2. 存在数据对账补偿程序，保证可靠性
3. 业务操作不落地在​​rds​​中

三、平台化

平台提供​​SDK​​​组件，基于注解启用，抽象幂等组件，提供基础​​RDS​​​和​​Redis​​​实现的幂等组件，注解支持自定义幂等组件，统一标准化消息参数，生产端加入​​bizModule​​​和​​bizKey​​​消息头属性赋值，消费端拦截监听器的​​handler​​，先校验幂等再执行业务方法