本文探讨了在2.0平台服务化架构下如何处理分布式事务，通过一个移动充值业务的例子介绍了分布式事务的处理方法。当前采用的是基于日志（事件）的最终一致性来实现，涉及到数据库事务、MQ消息通知、定时调度和异步处理。文章通过用户扫码启动摇摇车的业务场景，详细阐述了这种实现思路，并讨论了异常容灾处理和单链路灵活性的优化方案。
2.0平台服务化架构，必然分库，分库又必然面临一个分布式事务处理问题，所以无论是设计还是编码远远比1.0单体应用架构的工作量要大。不过做任何事情，重点不在实施，而是在思路，所以要解决分布式事务问题，还得先想清楚屡清楚怎么去做才是重点之重。
分布式事务处理方法其实大把，无需担忧找不到解决方法，关键是要找到满足自己业务场景，适合自己业务场景的方法，我之前做的项目涉及个分布式事务处理的方法也有好几个，其中记忆较为清晰的是一个移动充值的业务，大概业务就是用户通过银行在线支付完成后，然后给自己的手机号码充值，这个里面就涉及到银行充值和手机话费充值两个一致性的事务，当初用的就是通过每天凌晨的对账来处理这种事务问题，实现思路就是手机话费充值这端每天凌晨会上传一个订单文件到一个FTP服务器，然后通知银行那边去拿这个对账单文件来对账，然后再实行差补各种结算。当然具体问题还得具体分析，如果我们现在的业务场景直接也生搬硬套用这种方式来处理会不会也行呢？肯定不行！
我们的业务场景流程：用户通过APP扫码摇摇车，消费1块钱，针对每条订单马上所有参与方进行算账。
1. 用户账户扣1块钱。
2. 平台分2毛钱。
3. 城市合伙人账户分4毛钱。
4. 商家账户分4毛钱。
备注:前面在2.0架构体系里面已经说过分库分成用户库，平台库，城市合伙人库，商家库。
所以像这种业务场景，我们这边目前采用的是基于日志(事件)的最终一致性来实现分布式事务，当然里面涉及到知识点也较多，包括数据库单机
最低0.47元/天 解锁文章
扫一扫
60
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
