一、自动还款业务 事故 案例
事故名称：
事故描述：
事故现象：
事故造成影响：
事故发生原因：
事故解决过程描述：
事故总结教训：
二、金融场景幂等性思考
重复出款特指代付或者转账场景下，服务消费者A重复向服务提供者B发起的重复交易，导致资金损失；后续特指各类重复金融性交易导致的资金损失。出错的原因如下：
1、程序逻辑错误：
2、跨会计日场景
3、多任务并发：通常是指定时任务中，同一个定时任务并发处理的资源导致；
4、提交并发：也就是防重复提交指引提到的；
5、服务器异常：由于服务异常崩溃，消息或者缓存信息丢失，等服务器重启后，可能导致；
设计原则：
- 先扣款，再生成处理订单，宁可长款也不能短款，宽进严出。
- 数据校验：设置校验规则，同一时间段，同一客户，相同金额的交易发起记录；如果是客户发起，提示客户确认；如系统发起（例如代付），建议转人工处理。
- 状态控制：交易状态为，成功、失败、未知（或处理中），对于未知状态，不能再重复自动发起。
- 时间控制：对于未实现24小时服务的应用，尽可能避免在23点30后做出款处理。
- 提交并发控制：审核提交等做防重复提交控制。
- 定时并发控制：禁止提交同一个文件给多个定时任务。
- 对账及差错处理：要对交易进行对账，并对差错交易进行差错处理
相关阅读：
支付系统的防重设计 (qq.com)
三、服务间超时处理
在一个很普遍的场景中，涉及到双端通信的情况下，不论是传统的单机服务，还是现在的微服务，甚至事异步通信技术（进程内，进程与进程），一直都存在着三态的问题，即成功，失败，超时。
如下图两个服务间：
成功失败具有明确的业务语义和边界，正常处理即可。最复杂的就是超时，因为网络通信原因，双端都不总是确定，到底哪个环节超时。
3.1 同步调用超时
超时点：
- -请求超时；
- -服务端内部处理超时：比如操作耗时的资源，调用第三方系统等造成客户端请求整体超时而主动断开连接；
- -服务端处理正常，但响应结果阶段超时；
3.1.1 处理
客户端:
无论那个阶段，客户端都不确定请求是否被应答，即服务端处理的结果，客户端不知道是否成
功。客户端此时能做的，有两种方法：
不管哪种方式，需要服务端接口具备幂等性。
服务端:
服务端不存在请求超时和响应超时，但存在自身超时的情况，解决方案：
- 自身rt值需要优化，比如慢sql等；
- 以来三方接口的时候，跟第三方接口又形成了一个客户端-服务端模式，根据具体场景或者快速失败，或者做好容错措施，必要的时候，还会有比如金融领域的冲正操作；
3.2 异步调用超时
异步调用，类似ajax，客户端同步请求，服务端异步响应
超时点：
- 请求超时；
- 服务端内部处理超时：比如操作耗时的资源，调用第三方系统等造成客户端请求整体超时而主动断开连接；
- 服务端处理正常，但响应结果阶段超时；
- 异步响应超时；
客户端：
参考同步-客户端
服务端：
服务端不存在请求超时和同步响应超时，对于内部处理超时，同同步情况一样。那么就只剩下异步响应超时了。
比较有代表性的就是支付结果通知，可参考： 支付结果通知文档
存在此问题就是服务端通知客户端的时候（客户端需要同步提供响应服务端结果通知的接口），未接受
到客户端的响应。
MQ超时:
在此处讨论的超时，其实相当于另外一个话题，如何保证mq不丢消息，无论是kafka和RocketMQ，都支持ack的机制，用以确认消息的发送和接受的成功.
