什么时候使用分布式？业务太复杂，对业务进行拆分，进行服务化，对数据库进行拆分，水平拆分或垂直拆分。
不管怎么拆分吧，拆出了其他问题，当我们系统最初级阶段，所有数据都在一个数据库中，进行事务一致性控制很容易，但是当我们分库，分表后，曾经的兄弟姐妹表们都风流云散了，如果业务执行失败，你再给我一个回滚试试，离得十万八千里，想全部一起控制，有心无力，鞭长莫及。
这时候就出现了分布式事务解决方案，今天说的基于可靠消息的最终一致性方案 只是其中的一个方案。而这个方案最重要的就是保证状态一致，没有状态一致的分布式事务解决方案，那就是耍流氓。
但是，我们系统总会出现难以预料的这样那样异常，比如网络中断，服务器宕机等，这时候，就要进行异常控制，只要出现异常的时候，我们的状态依然可以保持一致，那才能保持最终的一致。
该方案要引入一个角色——消息中间件，他起到缓存消息，解耦服务的作用，也是我们基于可靠消息的最终一致性方案的 控制枢纽。
当我们通过可靠消息调用服务的时候，调用方如下
{
1.发送 待处理业务 状态消息
2.处理业务
3.更新消息状态为已处理待发送
}
该方案中有两个角色，一个是调用方，一个是消息中间件
我自己总结的01理论就是：
调用方和消息中间件都具有0和1的状态。
调用方业务未执行（或执行失败）为0状态，业务执行成功为1状态，消息中间件，消息在存储中不存在（根本不存在，或已删除）为0，业务执行成功后消息成功更新为已执行待发送为1.
那状态不一致又是怎么出现的呢，注意，消息中间件还有一个状态，就是预发送消息后，消息状态为待处理业务，这个状态为0.5.
好，我们给两边状态都分了编号，以下是可能出现的情况。
调用方 |
消息中间件 | 备注 |
| 0 | 0 | 业务未执行，由于异常，预处理消息未进入存储 |
| 0 | 0.5 | 业务未执行0（或出现异常回滚），消息入存储，状态为 待处理业务0.5 |
| 1/0 | 0.5 | 业务已执行（成功1或失败0），但由于异常未更新消息状态到已处理待发送1或删除消息0（还保持待处理业务状态0.5） |
| 1/0 | 1/0 | 业务已执行（成功1或失败0），成功状态更新为已处理待发送1，失败删除消息0 |
由上图我们看出，第一条，当状态都为0时，属于状态一致，就算由于网络原因或其他原因出现了某些异常，但由于状态一致。不用做异常处理。
第四条，当都为1或0时，为正常状态，自然不用异常处理。
根据以上三步流程分析，不会出现调用方为0，消息中间件为1情况，不做讨论。
需要异常处理的状态不一致出现在什么地方呢，出现在消息中间件多出来的哪一个状态——0.5.
也就是当消息中间件为0.5时，不管业务执行成功或失败，只要两者状态编码不一致，就算异常，需要进行异常控制，该异常控制的目的是让两者回到状态一致的状态。
处理方式比如：消息中间件主动进行业务状态查询，进行消息更新或删除。总之，剩下的就是进行正确异常处理了。
该篇说了这么多，总结一句话就是：在出现状态不一致时，在应该进行异常处理的地方进行异常处理，使系统回到一致状态。
而该篇就是告诉你哪里应该进行异常处理，哪里不用。注：发生异常，不一定要进行处理。因为某些状态下不处理他的状态也是一致的，比如上面的00状态。
end