大型网站的分布式事务
来源:互联网 发布:淘宝上好看的情侣装店 编辑:程序博客网 时间:2024/06/05 23:07
我们都熟悉mysql事务,它保证要么全做,要么全不做。但是对于一个大型系统来说,mysql一般会分库分表,多物理机部署,同时业务逻辑更加复杂漫长,同时需要调用很多服务(SOA)。
因此可以想象,在一个处理逻辑中,任何一个中间环节出现异常中断(请求超时,进程自杀等等不可控因素)都是很麻烦的。麻烦在于我们要知道上次中断在哪里以便重试的时候可以跳过之前的环节,这对编写函数流程的方式方法论就有一定的要求了。
我们知道,任何一个可靠的系统都应该符合”可重入”,”幂等性”,因此我们也相信我们依赖的其他服务也是遵循这些守则的,因此我们重试或者并发的访问其他服务都会得到正确且一致的应答。有了这个前提,我们才能讨论如何解决”分布式事务”问题。另外,这里提到的”分布式事务”是”柔性事务”,只能保证最终一致性,因为任何中间环节中断是无法避免的,并且通常不考虑中途回滚,需要事务完整做完再进入其他回滚流程。
分布式事务案例
继续以”付款环节”为例,当我们收到付款后,希望给用户生成消费码,然后给用户发送一条短信告知消费码,最终返回”接受付款”。为了简化,我们不考虑”拒绝付款”的场景,整个流程简化如下:继续以”付款环节”为例,当我们收到付款后,希望给用户生成消费码,然后给用户发送一条短信告知消费码,最终返回”接受付款”。为了简化,我们不考虑”拒绝付款”的场景,整个流程简化如下:
微信支付系统调用我们的接口,告知我们收到了order订单付款。
从mysql读取这个order,并且假设order的status总是”待付款”。
请求券码服务,为这个order分配1个消费码。
更新mysql将消费码存到order中。
请求短信服务,为这个order的用户发送这个消费码。
更新这个订单为”已付款”。
返回微信支付”接受付款”。
整个流程比较明确,我们完全可以顺序的把代码编出来,在各种环境都非常稳定的情况下,可以正常运行。但是程序复杂的永远是异常,下面我们分别考虑每个步骤失败会带来什么问题。
第三步:券码服务超时,但其服务内部实际上已经生成了一个券码,按照博客之前的介绍,我们只能退出程序,稍后重试。问题是重试的时候,我们再次请求券码服务,会不会又多生成了1个券码呢?其实很好解决,券码服务的接口设计满足幂等性即可,例如:createCoupon(orderId),我们每次调用传入订单号,券码服务在mysql中维护orderId唯一索引,从而保证一个order只能生成一次券码。问题得到解决。
第四部:更新mysql超时,分两种情况,虽然超时但已经写入到mysql和没有写入。在重试的时候,我们可能会想到,可以首先判断order中是否已经填写了消费码,如果有就不需要执行第三步和第四步了,否则依旧从第三步开始执行。
第五步:短信服务超时,其实和第三步的场景一样,短信服务可以保证幂等性,从而不会因为异常导致重试的时候给用户多发1次短信。
第六步:更新mysql超时,也分实际写入和没有写入mysql。在重试的时候,如果order的status是”已付款”,那么直接就应该跳转步骤7),否则仍旧应该从第五步执行。
回归问题本质,降低问题复杂度从2个方向入手。首先这一段逻辑是写在一个函数流程里的,先做1后做2…最后做7,我们仍旧想保持这么简单的代码。其次,我们期望的效果是即便做到6失败了,在重试的时候可以直接从6开始重做,而不是从1做到7。
根据上述思路,我们除了保持订单的status不变,新增一个sub_status字段用于记录”分布式事务”的中间状态,如果sub_status=5代表步骤5执行成功,且步骤6尚未执行或者上一次执行失败。这样,每完成一个步骤,我们将sub_status记录到mysql中,以便下次重试可以直接从中断的sub_status位置继续执行逻辑处理。
而整个代码将被简化成如下伪代码:
function logic(orderId) {
order = mysql->find(orderId);
if (order.status == '待付款') {
if (order.sub_status == 0) { // 初始化状态
coupon = createCoupon(orderId);
if (coupon == false) {
raise;
}
order.coupon = coupon;
order.sub_status = 1;
if (mysql->update(order)
->where(order . status = '待付款', order . sub_status = 0) == false) {
raise;
}
}
if (order.sub_status == 1) {
if (sendMessage(orderId) == false) {
raise;
}
order.sub_status = 2;
if (mysql->update(order)
->where(order . status = '待付款', order . sub_status = 1) == false) {
raise;
}
}
if (order.sub_status == 2) {
order.status = '已付款';
order.sub_status = 0;
if (mysql->update(order)
->where(order . status = '待付款', order . sub_status = 2) == false) {
raise;
}
}
} else if (order.status == '已付款') {
}
return '接受付款';
}
上述都是一些基本的理念,仅具有指导意义。实际问题还是需要实际分析,记住这些思路,是为了在解决具体问题时能帮助梳理思绪,简化问题。
- 大型网站的分布式事务
- 大型分布式网站的分布式缓存
- 大型分布式网站的形成过程
- 大型分布式网站的技术需求
- 大型分布式网站的架构演进
- 分布式 大型网站的架构演进
- 大型分布式网站架构
- 大型分布式网站架构
- 大型分布式网站架构
- 《大型分布式网站架构》
- 大型分布式网站术语分析
- 大型分布式网站术语分析
- 大型分布式网站术语分析
- 大型分布式网站术语分析
- 大型分布式网站术语分析
- 大型分布式网站演变架构
- 大型分布式网站术语分析
- 大型分布式网站术语分析
- 过滤器模式
- 用淘宝接口通过ip查询地域
- COCOA多窗口编程及卷帘式显示
- pc端向手机发送验证码
- js中获取系统的应用路径
- 大型网站的分布式事务
- 秒杀多线程第二篇 多线程第一次亲密接触 CreateThread与_beginthreadex本质区别
- PLinq
- 要点
- “创新驱动的结构化思维”培训
- 量化分析师的Python日记【Q Quant兵器谱之偏微分方程2】
- Linux chmod命令详解
- C++ 用libcurl库进行http通讯网络编程
- web安全————注入(初识篇)