目录
1、术语定义
2、功能性需求及任务
2.1 需求概述
2.2 任务分解
3、非功能性需求
3.1 可用性
3.2 扩展性
3.3 性能
4、 体系结构
4.1功能模块划分
4.1.1幂等性切面实现
4.1.2幂等性消息管理功能
4.2与前端的交互
4、 关键技术点
4.1 消息重试
4.2 消息大表查询
5、面向对象设计
5.1 类图
5.2 幂等消息状态转换图
6、数据库设计
1、术语定义
重复提交： 用户通过界面向应用服务器重复提交同一个请求。例如：用户在提交订单页面，将相同的商品明细提交给应用服务器多次，在后台就会产生完全相同的多个订单，除了订单号不一样，其他的数据全部一样，这样就产生的重复提交的问题。
重复调用： 重复调用常见于微服务之前的RPC调用，在调用一个RPC接口的时候，客户端会有意、无意的进行重复调用。例如：
1、flsc-cps会调用代扣服务，如果代扣服务超时/网络异常，可能flsc-cps会进行重试，如果是open-feign底层会自动重试3次，公司统一把重试的开关关闭了。但是有的应用场景就是客户端调用服务端失败，就要发起重复调用，这个场景我们是阻止不了的。
2、mq的重试机制：mq将消息投递给消费者，如果消费者消费失败(网络异常)，mq底层也会重复将消息投递给消费者，这个时候也会发生重复调用。
幂等性： 幂等（Idempotence）是一个数学和计算科学概念，简单的来说就是一个操作多次执行产生的结果与一次执行产生的结果一致。要求实现幂等的场景：
1、订单的支付接口提供者。如果支付接口不实现幂等，则可能会出现同一笔订单多次支付，导致账上混乱。
2、回调接口实现者。因为回调接口可能会被底层组件回调多次，也有可能通过界面，人工触发，从而导致多次被回调，如果是一些重要的业务，当被回调多次时，会产生脏数据。
3、MQ的消费者监听器。因为MQ底层会有重试机制，当消费者消费成功，还未来得及向MQ发送ACK确认时，下次MQ会继续向消费者投递消息，从而同一条消息会被消费多次；其次，消息的消费也有可能是发布/订阅模式，如果不实现幂等，多个实例可能会执行消费业务逻辑。
消息重试：可以针对一次请求，将请求输入参数，返回结果，处理状态等上下文信息持久化。当需要对请求进行重放时，需要加载当时的输入参数，请求请求后台服务，此时，称之为消息重试，系统需要将消息重试信息同样的进行持久化。
2、功能性需求及任务
2.1 需求概述
有一些场景是要实现接口的幂等性的，需要提供一个通用的幂等性问题解决方案，像Spring事务一样，即要提供注解声明式的API、也要提供侵入式代码式的API；其次，需要在
管理界面查询幂等性消息日志，并可以对失败的幂等性消息进行手动重试。
图1 幂等性消息管理
图2 幂等消息详情
图3 幂等消息重试明细
2.2 任务分解
1.幂等性切面实现
2.幂等性消息管理功能，包含界面与后台接口
3、非功能性需求
3.1 可用性
作为flsc-cps应用的一个内部模块，对高可用无特别要求。
3.2 扩展性
1、幂等消息要考虑对全链路的追踪，与链路追踪中的traceId进行集成；
2、幂等消息要考虑对全链路的追踪，与链路追踪中的spanId进行集成；
3、对处理状态为处理成功的幂等消息也要支持重试，在一些特殊场景下，是
要支持对一条消息可重复处理的情况。
4、需要支持对幂等消息统一elapsedTime功能，开始处理时间，结束处理时间。
3.3 性能
1、增加了幂等切面逻辑，要求对接口的响应时间，基本无影响。
2、幂等日志随着时间的推移，日志量将越来越大，要考虑单表数据量大的问题。
4、 体系结构
4.1功能模块划分
4.1.1幂等性切面实现
4.1.1幂等性切面实现
实现对幂等消息的通用切面功能，实现RequireIdempotence注解的切面功能。
4.1.2幂等性消息管理功能
需要实现幂等消息列表管理功能，实现对幂等消息列表查询、详情、重试明细、重试功能。
4.2与前端的交互
进入福利商城>订单管理>幂等消息管理
- 幂等消息管理列表
2.幂等消息重试明细
在某一条具体的消息行上，点击“已经重试次数/最大重试次数”列超链接，弹窗显示消息重试明细。
3.幂等消息详情
在某一条具体的消息行上，点击操作列中“详情”按钮，弹窗显示消息详情。
4.幂等消息重试
在某一条具体的消息行上，点击操作列中“重试”按钮，可以对处理失败的消息进行重试。
4、 关键技术点
4.1 消息重试
要支持不同的微服务不的业务处理逻辑进行重试，要消息管理界面，重试功能，要适合所有的业务场景的消息重试。
4.2 消息大表查询
消息日志表在未来数据量会急剧增加，要考虑单表数据库过百万而导致查询慢的问题。
5、面向对象设计
5.1 类图
5.2 幂等消息状态转换图
