今年开发过很多类似本地积分扣减、本地库存扣减，同时调用rpc进行发券、兑换0元单等业务，对于分布式事务有了一点自己的开发经验，这里记录一下。
1、基本前提
在我看来，两个操作，想要保证分布式事务，必须有一个大前提，就是这两个操作都是幂等操作，也就是带着同一个幂等参数进行请求时，无论请求多少次，结果都和请求一次是一样的。
操作是幂等的，才可保证操作可重试，这是分布式事务的关键。无论是AT模式，还是TCC（try-commit-cancel）模式，当一次请求失败后，都需要可以支持用户或者业务的重试。
2、简单实现
最简单的实现方式莫过于将整个事务都丢进kafka消息队列中，依赖kafka的可靠性，如果任何一个流程发生异常，都进行全局回滚，任何一个流程出现未知状态，都进行不断的重试，这样来实现事务的最终一致性。
但是这种用法的缺陷是，消息队列是异步的，还需要不断的轮询获取实验结果，对于某些同步的流程，比如本地积分兑券的场景来说，会使得业务代码变得非常的恶心。
3、实战解决方案
3.1、表结构设计
我们组这边，借鉴了TCC模式，引入补偿任务的概念，设计出了一套可靠的分布式事务解决方案。
首先定义积分表，有一张任务记录表，一张积分表，他们的数据结构如下：
任务记录表：
字段名 | 含义 | 解释 |
uid | 用户uid | |
biz_id | 业务id | 可以用于多个业务的扩展 |
unit_id | 积分周期 | 可以用于多个维度，如时间，表示一周的积分，或者一次活动周期的积分 |
task_type | 任务类型 | |
task_id | 任务幂等id | 用户标示一次任务，比如每天打卡，则是uid+date |
guid | 事务id | 用户标示一次操作，比如每天的打卡，可能失败，标示这一次打卡，uid+date+timestamp |
tx_status | 事务状态 | 标示try，commit，cancel |
score | 积分 |
积分记录表
字段名 | 含义 | 解释 |
uid | 用户uid | |
biz_id | 业务id | 可以用于多个业务的扩展 |
unit_id | 积分周期 | 可以用于多个维度，如时间，表示一周的积分，或者一次活动周期的积分 |
score | 当前积分 |
3.2、主流程步骤
步骤设置为：
步骤1、try积分，即写入一条tx_status状态为try的记录，同时扣减积分，如积分不够则扣减失败；
步骤2、进行发券，需要感知三个状态，即发券成功、发券失败、发券状态未知；
步骤3、如果发券成功，将任务的tx_status状态改为commit；
步骤4、如果发券失败，将任务的tx_status状态改为cancel。
其中，每个步骤，都可能会有成功、失败、未知三种状态，我们可以来一一分析。
3.3、分流程解析
a、try成功，则正常执行下一步；
b、try失败，则直接整个事务执行失败，可以直接关闭事务；
c、try未知，此时在同步过程中无法处理，丢给补偿任务；（待定）
d、发券成功，此时正常执行下一步；
e、发券失败，此时回滚积分，执行步骤4；
f、发券未知，此时交给补偿任务；（待定）
g、commit成功，此时正常关闭事务；
h、commit失败、未知，此时交给补偿任务进行重试；（待定）
l、cancel成功，此时正常回滚事务；
m、cancel失败、未知，此时交给补偿任务进行重试；（待定）
这样，除了交予补偿任务进行重试的步骤外，其余步骤都可以拿到一个明确的执行结果了。
3.4、补偿任务
关于补偿任务，我们的执行方式是，扫描出2分钟前，任务记录表内全部处于try状态的任务记录，并执行接下来的发券-commit-cancel流程。
这样一来，所以表中，只要写入了的任务，且处于补偿状态时，就会继续执行解下来的操作，除非明确完成了发券-commit，发券失败-cancel操作外，会一直进行重试。
同时我们可以设置一个重试时间限制，重试超过了10次后，可以触发死信消息告警，让相关开发人工介入。
3.5、对账
即使做了上述的操作，但是依然还是有可能存在数据不一致的情况，此时需要有一个对账系统，每隔一段时间进行一次对账操作，比如业务记录发券了多少金额，在券侧又记录了多少发券金额，这种每隔一段时间进行一次比对，即可保证双方的数据保持同步。
4、总结
所以，关于分布式事务，实现的条件是：
1、任何一道rpc环节都必须是幂等的，否则无法支持重试；
2、需要关注每一次rpc操作的成功、失败、未知三种状态，并完整的设计出对应的处理方式；
3、本文介绍的方式还是有一些复杂，且比较局限性，只适合于所用到的场景，阿里等公司已经有了自己的分布式事务组件，如Seata等。
