我的物联网项目(十四) 分布式事务

本文探讨了在2.0平台服务化架构下如何处理分布式事务,通过一个移动充值业务的例子介绍了分布式事务的处理方法。当前采用的是基于日志(事件)的最终一致性来实现,涉及到数据库事务、MQ消息通知、定时调度和异步处理。文章通过用户扫码启动摇摇车的业务场景,详细阐述了这种实现思路,并讨论了异常容灾处理和单链路灵活性的优化方案。
摘要由CSDN通过智能技术生成

2.0平台服务化架构,必然分库,分库又必然面临一个分布式事务处理问题,所以无论是设计还是编码远远比1.0单体应用架构的工作量要大。不过做任何事情,重点不在实施,而是在思路,所以要解决分布式事务问题,还得先想清楚屡清楚怎么去做才是重点之重。

分布式事务处理方法其实大把,无需担忧找不到解决方法,关键是要找到满足自己业务场景,适合自己业务场景的方法,我之前做的项目涉及个分布式事务处理的方法也有好几个,其中记忆较为清晰的是一个移动充值的业务,大概业务就是用户通过银行在线支付完成后,然后给自己的手机号码充值,这个里面就涉及到银行充值和手机话费充值两个一致性的事务,当初用的就是通过每天凌晨的对账来处理这种事务问题,实现思路就是手机话费充值这端每天凌晨会上传一个订单文件到一个FTP服务器,然后通知银行那边去拿这个对账单文件来对账,然后再实行差补各种结算。当然具体问题还得具体分析,如果我们现在的业务场景直接也生搬硬套用这种方式来处理会不会也行呢?肯定不行!

我们的业务场景流程:用户通过APP扫码摇摇车,消费1块钱,针对每条订单马上所有参与方进行算账。

1. 用户账户扣1块钱。

2. 平台分2毛钱。

3. 城市合伙人账户分4毛钱。

4. 商家账户分4毛钱。

备注:前面在2.0架构体系里面已经说过分库分成用户库,平台库,城市合伙人库,商家库。

所以像这种业务场景,我们这边目前采用的是基于日志(事件)的最终一致性来实现分布式事务,当然里面涉及到知识点也较多,包括数据库单机

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值