关于分布式系统的数据一致性问题(三)

在我的博文里面 关于分布式系统的数据一致性问题(二) 里面主要介绍了数据分布的情况下保证一致性的情况,在第二篇文章里面,我这里提出了三个问题

  1. 订单系统调用支付系统支付订单,支付成功,但是返回给订单系统数据超时,订单还是I(初始状态),但是此时会员帐户余额100,会员肯定会马上找京东骂京东,为啥不给老子发货,我都付钱了
  2. 订单系统调用支付系统成功,状态也已经更新成功,但是通知仓库发货失败,这个时候订单是P(已支付)状态,此时会员帐户余额是100,但是仓库不会发货。会员也要骂京东。
  3. 订单系统调用支付系统成功,状态也已经更新成功,然后通知仓库发货,仓库告诉订单系统,没有货了。这个时候数据状态和第二种情况一样。

 

重点分析解决了第一个的问题以及相应的方案,发现在数据分布的环境下,很难绝对的保证数据一致性(任何一段区间),但是有办法通过一种补偿机制,最终保证数据的一致性。

 

在下面在分析一下第二个问题

  • 订单系统调用支付系统成功,状态也已经更新成功,但是通知仓库发货失败,这个时候订单是P(已支付)状态,此时会员帐户余额是100,但是仓库不会发货。会员也要骂京东。

通过在上一篇文章里面分析过,这个相对来说是比较简单的,我可以采取重试机制,如果发现通知仓库发货失败,就一致重试,

这里面有两种方式:

1 异步方式:通过类似MQ(消息通知)的机制,这个是异步的通知

2 同步调用:类似于远程过程调用

对于同步的调用的方式,比较简单,我们能够及时获取结果,对于异步的通知,就必须采用请求,应答的方式进行,这一点在(关于分布式系统的数据一致性问题(一))里面有介绍。这里面就不再阐述。

 

来看看第三个问题

  • 订单系统调用支付系统成功,状态也已经更新成功,然后通知仓库发货,仓库告诉订单系统,没有货了。这个时候数据状态和第二种情况一样。

我觉得这是一个很有意思的问题,我们还是考虑几种解决的方案

1 在会员下单的时刻,就告诉仓库,我要你把货物留下来,

2 在会员支付订单时候,在支付之前检查仓库有没有货,如果没有货,就告知会员木有货物了

3 如果会员支付成功,这个时候没有货了,就会退款给用户或者等待有货的时候在发货

 

正常情况,京东的仓库一般都是有货的,所以影响到的会员很少,但是在秒杀和营销的时候,这个时候就不一定了,我们考虑假设仓库有10台iphone

如果采用第一种方案,

1 在会员下单的时候,相当于库存就-1,那么用户恶意拍下来,没有去支付,就影响到了其他用户的购买。京东可以设置一个订单超时时间,如果这段时间内没有支付,就自动取消订单

2 在会员支付之前,检查仓库有货,这种方案了,对于用户体验不好,但是对于京东比较好,至少我东西都卖出去了。那些没有及时付款的用户,只能投诉了京东无故取消订单

3 第三种方案,这个方案体验更不好,而且用户感觉受到京东欺诈,但是对于京东来说,比第二种方案更有益,毕竟我还可以多卖出一点东西。

 

个人觉得,京东应该会采用第二种或者第三种方式来处理这类情况,我在微博上搜索了 “京东 无故取消订单”,发现果真和我预料的处理方式。不过至于这里的无故取消是不是技术上的原因我不知道,如果真的是技术上的原因,我觉得京东可以采用不同的处理方案。对于秒杀和促销商品,可以考虑第一种方案,大多数人都会直接付款,毕竟便宜啊,如果用户抢不到便宜的东西,抱怨当然很大了。这样可以照顾大多数用户的体验。对于一般的订单,可以采用第二种或者第三种方式,这种情况下,发生付款之后仓库没有货的情况会比较少,并且就算发生了,用户也会觉得无所谓,大不了退钱吗,这样就可以实现自己的利益最大化而最低程度的减少用户体验。

 

而铁道部在这个问题上,采用的是第一种方案,为什么和京东不一样,就是因为用户体验,如果用户把票都买了,你告诉我木有票了,旅客会杀人的。哈哈,不过铁道部不担心票卖不出去,第一种方案对他影响没有什么。

 

说了这么多,就是说 分布式环境下(数据分布)要任何时刻保证数据一致性是不可能的,只能采取妥协的方案来保证数据最终一致性。这个也就是著名的CAP定理。

posted @ 2012-09-25 13:12 God Is Coder 阅读(...) 评论(...) 编辑 收藏