逃不掉的双十一 阿里可怕的分布式架构隐患

在刚刚过去的双十一，淘宝怒斩571亿交易额，成为年度的最大赢家。负责本次双十一技术服务的蚂蚁金服集团表示：双十一的交易峰值已经达到285万笔/分钟，相比去年双十一期间79万笔/分钟的交易峰值，今年系统的支撑能力达到了去年3倍以上，用户总体支付体验相比去年也顺畅不了很多。从网友反馈的实际体验来讲，今年双十一相比往年的确有了不小的提高，页面打开的速度更快了，支付等待时间更短了，优惠力度更给力了……可是有没有问题?有，并且这些问题从某种意义上讲则是致命的。

　　抽风的支付宝，屡次付款的迷局

　　11月11日凌晨1点，多家电商平台反馈称，支付宝出现支付故障，用户没法正常支付。这也不是双十一第一次出现相似的故障。去年双11开始后，因为订单量瞬间激增，就曾爆发多家网银没法经过支付宝支付的状况。今年双11在手机支付宝上也一度出现瘫痪，即便在阿里巴巴的直播大厅中，也没法支付成功。

　　在笔者看来，即使是采用了云计算的全新方式，支付宝的使用弊端依然是存在的，并且这些弊端在系统架构层面一直是淘宝解决不了的死结，这就是系统架构层面的硬伤——分布式系统的数据一致性。而要解释这个问题，还要从淘宝主张的“去IOE”提及。

　　简单、有效的淘宝的分布式架构

　　2008年，从微软亚洲技术研究院离职来到阿里巴巴任首席架构师的王坚提出“去IOE”的技术路线，即以廉价的PC服务器替代小型机，以基于开源的MY SQL自研数据库替代Oracle数据库，用低端存储取代高端存储设备，阿里巴巴的交易系统架构进行了重构，根据业务和对象的不一样，统一集中的数据库被拆分红了无数的耦合度较小的数据库。显然在这种架构下，随着业务的发展，能够增长新的数据库，也能够扩展已有的数据库，系统的扩展性和总体拥有成本很是好。

　　多年来的市场表现证实，分布式架构有效解决了淘宝海量数据高并发、高增加的问题，对于淘宝这种简单事务为主的C2C的业务模式来讲也最适合。与此同时，在淘宝的系统架构中也秉承了扩展性高于一切、系统可用性高于一致性与适当放宽一致性约束等原则。对于绝大多数应用场景来讲，这种分布式系统是合适的、高效的。若是不是出现双十一这种前无古人、全球罕见的大规模交易，分布式系统堪称C2C业务的完美形态。

▲

　　问题正是出如今“分布式”这种特色中。按照美国著名科学家Eric Brewer在2000年提出的理论，当技术架构从集中式架构向分布式架构演进，会遇到 “CAP定律”的瓶颈。 CAP说明一个数据处理系统不能同时知足一致性，可用性和分区容错性这三个需求，最多只能同时知足两个。

　　一致性(Consistency)：任何一个读操做老是能读取到以前完成的写操做结果，也就是在分布式环境中，多点的数据是一致的;

　　可用性(Availability)：每个操做老是可以在肯定的时间内返回，也就是系统随时都是可用的。

　　分区容忍性(Partition Tolerance)： 在出现网络分区(好比断网)的状况下，分离的系统也能正常运行。

　　正如咱们刚刚提到的，淘宝在系统架构中选择了扩展性与可用性，放弃了一致性，这依然符合 “CAP定律”的观点，意识到这一点的淘宝也采用基于MySQL的分布式架构可以完美的解决掉高并发用户访问的难题。

　　分布式系统的软肋——数据一致性

　　咱们经过一个交易模型能够更好的解释这个问题。例如，一件商品有100个库存，而在同时有130我的在进行抢购的时候，集中式架构在完成买家付款这个业务操做时候系统须要作6个步骤：

　　启动事务，经过数据库锁等方式保证事务中的数据修改的一致性

　　更改买家支付宝金额

　　更改卖家支付宝金额

　　修改订单已付款状态

　　修改卖家货物数量信息

　　提交事务，保证数据所有更新

　　在集中式模型下，数据库和中间件均采用单线程模式处理业务，所以以上4个步骤的修改是同步的，所以若是支付宝接收到买家的付款之后，数据库事务处理将保证4个步骤的数据修改的一致性，即便该事务出现由于系统问题失败了，系统将同步退回到执行事务之前的状态。所以及时出现页面提交失败而从新刷新的时候，维护系统可以很方便查出买家付款但没有修改状态的问题，经过从新执行上述流程就可更新系统状态，所以不会出现重复付款的状况。另外在完成该数据库事务操做中的几毫秒中，卖家的货物数量会暂时被锁住，其余买家在这个时间段内没法修改卖家货物数量信息这个字段，所以也不存在超售的状况。

　　但在分布式模型下，数据库采用分布式的和数据库读写分离，也就是买家库、卖家库、订单库、支付宝帐户库等均是彻底物理分离的数据库，而为了提升并发访问的效率，每一个库都由多台镜像数据库组成，同时为了消除读写瓶颈，每一个数据库的数据只保存一部分数据，由上层应用来进行复杂的系统调度。在执行事务中的每个步骤都是经过异步方式来完成的。

　　隔日退款——马云真不是为了凑成交额

　　昨天在跟几个业内朋友吃饭的时候，有人提到本次双十一期间，特别是从11日零点到11日24点这段时间内，用户是不能获得退款的，当时便有人戏称马云为了突破去年的成交额“禁止退款”。但事实上，且不说马云是否是须要经过这种方式实现成交额的激增，单看淘宝在系统架构上的设计，在如此大规模并发的请求下，退款将是一件很是困难的事情。

　　当完成银联支付的时候，修改订单已付款状态这个步骤出现了瓶颈，在理论设计须要在秒级修改的状态在1个小时内都没有更新，所以淘宝页面就重复提示买家须要支付货款，这样就为整个业务引入了“脏数据”，出现的货款与订单的重复关联，而这种错误理论上是不该该出如今正常的业务逻辑中的，所以要从系统中找回多余的付款将十分的麻烦，这也就是为何支付宝必须在当天关闭退款申请，须要等高峰期事后经过系统维护将多余的付款退回。同时因为订单修改状态迟迟不更新，致使库存在买家完成采购付款依然无法正常扣除，从而致使“超售”的情形发生。

　　去IOE，并非去掉“宰牛刀”

　　记得当年淘宝大规模宣布“去IOE”时，业内对于阿里的技术能力和IT视野都给予了充分的确定。即使是到了如今，去IOE依然被证实是淘宝正确的举措。以技术能力而言，淘宝具有了世界顶尖的系统开发、运营和维护能力，丝绝不逊色于国外的Google和永远打不开的Facebook。并且从业务模式来讲，C2C对于业务的安全性并无苛刻的要求，从成本和应用的角度考虑，小型机抑或大型机的确是“宰牛刀”。

　　但正是从淘宝开始，去IOE彷佛成为了一种行业的趋势，并大有蔓延之势。想一想以淘宝的技术能力尚有每一年双十一的支付困境，其余企业如何可以真正实现系统与业务的安枕无忧?想一想每到春运便被吐槽无数的12306，想一想若是是在电信、银行这样的关键系统中出现支付问题，其影响与后果都将是耸人听闻。

　　有道是”术业有专攻“，没有哪一种架构是万能的，分布式也不是万能的。双十一是一面照妖镜，让咱们看到分布式系统的强大，也看到集中式系统的稳健。就是你有勇气决定进行分布式的改造，风险、技术门槛、后期的运维，估计也只有像阿里才能创造这样的神话。