马云做的国外的网站叫什么名字,巨量引擎广告投放平台登录入口,肇庆自助网站建设系统,9377传奇转载自 聊聊微服务架构及分布式事务解决方案
分布式事务场景如何设计系统架构及解决数据一致性问题#xff0c;个人理解最终方案把握以下原则就可以了#xff0c;那就是#xff1a;大事务小事务#xff08;原子事务#xff09;异步#xff08;消息通知#xff09;个人理解最终方案把握以下原则就可以了那就是大事务小事务原子事务异步消息通知解决分布式事务的最好办法其实就是不考虑分布式事务将一个大的业务进行拆分整个大的业务流程转化成若干个小的业务流程然后通过设计补偿流程从而考虑最终一致性。 什么是事务
事务Transaction及其ACID属性
事务是由一组SQL语句组成的逻辑处理单元事务具有以下4个属性通常简称为事务的ACID属性
原子性Atomicity事务是一个原子操作单元其对数据的修改要么全都执行要么全都不执行。
一致性Consistent在事务开始和完成时数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改以保持数据的完整性事务结束时所有的内部数据结构如B树索引或双向链表也都必须是正确的。
隔离性Isoation数据库系统提供一定的隔离机制保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的反之亦然。
持久性Durabe事务完成之后它对于数据的修改是永久性的即使出现系统故障也能够保持。 典型场景银行转账业务
例如李雷账户中有500块钱韩梅梅账户有200块钱李雷要从自己的账户中转100块钱给韩梅梅转账事务成功执行完成后应该是李雷账户减100变为400韩梅梅账户加100变为300不能出现其他情况即在事务开始和结束时数据都必须保持一致状态一致性事务结束时所有的数据及结构都必须是正确的。并且同样的转账操作同一流水即一次转账操作无论执行多少次结果都相同幂等性。幂等性可以点击这里参考这篇文章。
电商场景流量充值业务
再说我们做的一个项目中国移动-流量充值能力中心核心业务流程为 用户进入流量充值商品购买页面选择流量商品 购买流量充值商品有库存限制则判断库存生成流量购买订单 选择对应的支付方式和包、银联、支付宝、微信进行支付操作 支付成功后近实时流量到账即可使用流量商品
此业务流程看似不是很复杂对吧不涉及到类似电商业务的实物购买但是我认为其中的区别并不是很大只是缺少电商中的物流发货流程其他流程几乎是一样的也有库存以及优惠折扣等业务存在。
整个系统交互如下图 分布式事务
上述两个场景的业务需求已经说完了接着谈谈分布式事务要说分布式事务那就先聊聊本地事务与分布式事务
Ps相同点首先都是要保证数据正确即ACID本地事务与分布式事务还可以对应为刚性事务与柔性事务在我个人理解刚性事务与柔性事务的最大区别就是一个完整的事务操作是否可以在同一物理介质例如内存上同时完成柔性事务就是一个完整事务需要跨物理介质或跨物理节点网络通讯那么排它锁、共享锁等等就没有用武之地了这里并不是指大事务拆小事务【本地事务】后无法保证原子性Atomicity完成事务。个人理解分布式柔性事务本质意义上就是-伪事务柔性事务其实就是根据不同的业务场景使用不同的方法实现最终一致性因为可以根据业务的特性做部分取舍在业务过程中可以容忍一定时间内的数据不一致。
在知乎上面看过一篇文章支付宝的柔性事务实现方式有四种分别针对不同的业务场景如下图 两阶段型 补偿型 异步确保型 最大努力通知型
回到我们流量交易中心的业务场景。通过Dubbo实现了微服务化大致拆分如下 商品服务 订单服务 库存服务 支付服务 直充服务 消息服务 等其他服务 场景一
库存数量与订单数量一致性采用补偿型最大努力通知型采用原因为不涉及跨机房和长事务正常情况下库存与订单服务处理很快 用户下单先减库存库存减成功后 调用下单服务 2-1.下单成功两事务均提交完成 2-2.下单失败库存回滚两事务均失败此处还有一个保障机制最大努力通知型就是如果调用库存服务异常确定库存回滚失败了则放入消息服务延时消息队列分阶段定时重试努力重试保证库存服务正常后成功回滚。消息队列选型可以点击这里参考这篇文章。 场景二
订单信息、支付信息、充值信息三者之间的一致性采用异步确保型的原因是整个业务链路太长且跨不同的机房系统网络延迟较高业务方面恰好不需要非常高的实时性所以采用小事务异步通知目前正常情况下用户从下单到完成支付到流量到账平均为1-5分钟左右 下单成功即订单服务创建订单成功并发送支付请求到支付网关系统订单状态-待支付超过1小时未支付则流转为超时未付撤销此处用到了RocketMQ的延时消费恰好实现定时器业务场景。 返回支付页面用户在支付交易系统完成支付业务流程支付网关异步通知流量中心流量中心接收到支付成功状态后修改订单状态-支付成功并给支付网关返回成功结果此处并发压力目前不大暂时没有再进行异步解耦。 流量中心修改完订单状态后调用消息服务将直充业务放入消息队列对直充业务进行解耦原因是直充需要调用31省移动CRM系统此链路过长且部分省CRM系统耗时非常大每个省的处理能力不同经常出现20秒以上的超时因此要考虑部分超时较高的省份拖垮系统进行业务的削峰填谷 3-1. 当直充成功时修改订单状态-已完成 3-2.当直充失败时移动特性例如直充时正好用户销户或者停机了修改订单状态为待退款并调用支付网关系统的退款接口退款成功后支付网关异步通知流量中心流量中心修改订单状态为-退款成功 3-3.当直充超时时调用定时任务服务进行超时重试机制第一次重试在10分钟后执行、第二次在30分钟后、第三次…..直到最大超时重试次数后还得不到直充结果订单状态会卡在支付成功状态依赖T1对账稽核流程保证最终一致性订单状态根据对账结果流转为已完成或待退款–退款成功。 场景三
直充到账后的消息通知APP消息推送或短信通知采用最大努力通知型这个业务场景比较简单在直充成功后订单状态流转为已完成此时通过消息服务进行到账通知业务的解耦调用消息服务失败的情况下使用定时任务努力通知。 场景四
对账稽核
按照支付账期每日进行T1对账对账原则以支付交易记录为准对流量中心订单记录支付网关交易记录省CRM充值记录三方比对将某些中间状态的订单例如支付成功、待退款核对后将订单状态流转完结已完成、退款成功。
结算稽核
对账成功后的数据定期进入结算流程对支付网关周期内的支付金额与结算数据的金额进行核对稽核成功后进行财务结算流程将钱结算给省公司并提供结算明细给省公司供省公司与直充成本记录进行复核。
Ps以下是流量中心的部分架构设计总体原则方向微服务化
流量中心-架构设计 架构设计思想在系统初期设计时以及部分硬性环境约束下我们根据业务拆分为多个子系统微服务商品服务、订单服务、库存服务、支付网关、统一接口平台、对账服务、结算服务、网关对接服务等后续还会增加账户服务、虚拟货币服务、卡券服务等等…。
按照微服务的核心设计思想所有服务完全独立、隔离因此所有服务从上至下请求接入连接管理、请求处理计算服务、数据存储存储服务进行拆分接入与计算尽最大可能实现无状态数据存储进行垂直水平拆分垂直拆分商品库-mysql读多写少主从架构读写分离redis读多写少集群方式、订单库-mysql读写均衡多主多从水平拆分、库存专用库-redis分布式主备容灾、外部交易系统-支付网关、外部办理系统-统一接口平台。 Ps此架构目前已支撑总交易额3.6亿总订单4680万日均交易额500万日订单量50万后续业务量持续增加的情况下按照微服务思想继续拆分例如将订单服务再拆分为下单服务、查单服务直到根据业务需求与系统关系耦合性拆分到最细粒度为止。
性能扩展应用层计算服务无状态应用通过增加服务节点同比提升运算性能配套质量性能监控服务dubbo monitor及整合Netflix的Hystrix熔断器对业务质量进行管理实现应用层的动态扩缩容。
容量扩展数据层存储服务有状态应用通过对数据水平拆分实现容量的无限扩容Nosql类方案Codis中间件关系型数据库Mycat数据库分库分表中间件。目前项目中采用twitter的snowflake唯一ID生成器根据业务场景优化后自己实现数据的水平拆分和路由规则。
存储性能Nosql针对读多写少场景-使用淘宝的Tedis多写随机读的特性提高性能读写均衡使用-CodisMysql读多写少场景使用一主多从架构例如商品信息读写均衡场景使用多主多从架构例如订单信息。
整体拆分原则如下图 Never Give Up!
