售前咨询
技术支持
渠道合作

MySQL分库分表弃强妥最提高性能(10th)

回顾

之前我们介绍了使用分布式事务(XA)处理用户下订单,对MySQL有所了解的都知道XA其实是在非用不可的情况下才用的,因为它实在是影响性能。当然,其实迫使我们使用XA的原因也是因为我们的设计决定的(其实使用XA这种分库分表的方案基本能满足那些一定需要强一致性的需求)。

之前我们的设计是为了方便卖家的,所以完整的订单信息只保存在卖家方,而在买家方我们只保存着完整订单的引用。这样做是因为业务需要强一致性,迫使我们使用XA,但我们又希望让数据写磁盘少一点,让插入快一点。

我们想要的

无论在买家还是卖家在操作订单数据的时候都能方便。为了满足这样的情况,我们只能做到数据冗余了。就是买家有一个完整的数据卖家也有一份完整的数据。这样操作起来就能在单机上进行,这样是最方便的。

业务最终一致性

其实,往往再深入分析业务,可以发现其实业务上并非一定需要强一致性。我们的目的只要买家已经下的订单能完整让卖家看到,卖家多久能看到其实并不是很关心。因为如果卖家没看到订单也不会对订单进行操作,也不会发货给买家,这样卖家是不会有损失的。而买家就算是付了款,发现买家没发货,也可以退款。这样一来买家也没有金钱的损失。所以我们这边能使用最终一致性来解决问题。

为什么要最终一致性

说白了就是为了提高性能,因为我们现在需要买家和卖家都有完整的订单数据,为了让买家下单时不用跨库、跨实例或跨节点执行XA事务。这样我们保证买家的订单数据先入库后能马上返回成功信息。而不用关心卖家的数据是否入库,只是提醒卖家有订单信息要入库了。

kafka配合完成最终一致性

要完成最终一致性这种业务,我最先想到的就是使用消息队列了。而在消息队列中我最熟悉的只能是kafka了,我使用kafka的原因是他能高可用,还能将消息持久化。

下面我们就来演示使用kafka来完成最终一致性

重构买家订单表(buy_order_x)结构:

为买家创建订单商品表:

这边我不关心kafka是如何搭建的,就直接使用了。要想知道如何搭建kafka请点击一下网址:http://www.linuxidc.com/Linux/2014-07/104470.htm

买家下订单演示:

注意这边python代码使用的是simplejson因此需要安装。安装包simplejson-master

生成卖家订单信息:

通过上面买家下订单,现在订单的信息在队列中。我们只需要将队列中的数据取出并保存就好了。

 

文章转载来自:ttlsa.com

上一篇:

下一篇:

相关文章