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

标签: 双十一 分布 架构 | 发表时间:2014-11-18 11:14 | 作者:
出处:http://kb.cnblogs.com/

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

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

   抽风的支付宝,多次付款的迷局

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

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

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

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

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

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

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

   一致性(Consistency):任何一个读操作总是能读取到之前完成的写操作结果,也就是在分布式环境中,多点的数据是一致的。

   可用性(Availability):每一个操作总是能够在确定的时间内返回,也就是系统随时都是可用的。

   分区容忍性(Partition Tolerance): 在出现网络分区(比如断网)的情况下,分离的系统也能正常运行。

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

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

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

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

  1. 启动事务,通过数据库锁等方式保证事务中的数据修改的一致性
  2. 更改买家支付宝金额
  3. 更改卖家支付宝金额
  4. 修改订单已付款状态
  5. 修改卖家货物数量信息
  6. 提交事务,保证数据全部更新

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

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

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

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

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

   去 IOE,并不是去掉“宰牛刀”

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

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

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

相关 [双十一 分布 架构] 推荐:

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

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

淘宝双十一架构优化及应急预案

- - InfoQ cn
 每年的双十一,在整体架构上最依仗的是过去几年持续建设的稳定的服务化技术体系和去IOE带来整体的扩展性和成本的控制能力. 今年在架构上做的比较大的优化有三点:. 第一是导购系统的静态化改造. 今年淘宝和天猫都分别根据自身的业务特性进行了Detail页面的静态化改造,但核心的思路都是通过CDN+nginx+JBoss+缓存的架构,将页面信息进行静态化缓存.

网站的分布式架构

- - 互联网的那点事
互联网的网站和大部分企业管理软件一样都是使用B/S架构模型,但是大型的公共网站B/S架构会更加复杂,对架构人员的要求更高,今天我想在自己博客里聊聊我设计的网站的B/S技术架构. 不管是B/S架构的企业管理系统还是网站技术架构可以抽象为如下简图:. 在传统B/S架构的企业管理系统里,技术架构往往就是一个工程项目,各个逻辑分层都是该工程的业务逻辑模块.

FastDFS分布式文件系统架构

- - 企业架构 - ITeye博客
FastDFS分布式文件系统架构.            FastDFS是一个开源的分布式文件系统,她对文件进行管理,功能包括:文件存储、文件同步、文件访问(文件上传、文件下载)等,解决了大容量存储和负载均衡的问题. 特别适合以文件为载体的在线服务,如相册网站、视频网站等等. 二、 FastDFS系统架构.

分布式架构的套路No.74

- -
今天小蕉跟大伙一起聊聊分布式系统的架构的套路. 在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构. 大多数的开发者大多数的系统可能从来没接触过分布式系统,也根本没必要进行分布式系统架构,为什么. 因为在访问量或者QPS没有达到单台机器的性能瓶颈的时候,根本没必要进行分布式架构. 那如果业务量上来了,一般会怎么解决呢.

分布式架构之 Paxos 协议

- - IT瘾-dev
这周一下了个决定"裸辞",逼自己一把. 当你在一个复杂的环境下,对所负责的项目失去激情时、不开心时你会选择怎样. 已经进入到分布式架构系列的尾声了,倒数第三篇文章. Paxos、Raft、以及变种/类似的协议都是用于在分布式里面解决选举的问题. 2pc、3pc、Waro是保证数据的强一致性,它们之间的强一致性在层次上是不同的概念、解决的问题不同,需要注意区分.

案例分析:基于消息的分布式架构

- - 简单文本
美国计算机科学家,LaTex的作者Leslie Lamport说:“分布式系统就是这样一个系统,系统中一个你甚至都不知道的计算机出了故障,却可能导致你自己的计算机不可用. ”一语道破了开发分布式系统的玄机,那就是它的复杂与不可控. 所以Martin Fowler强调:分布式调用的第一原则就是不要分布式.

基于Dubbo框架构建分布式服务

- - 简单之美
有关Dubbo服务框架的简单使用,可以参考我的其他两篇文章(《基于Dubbo的Hessian协议实现远程调用》,《基于Dubbo的Hessian协议实现远程调用》,后面参考链接中已给出链接),这里主要围绕Dubbo分布式服务相关配置的使用来说明与实践. 首先,根据Dubbo文档,我们引用文档提供的一个架构图以及各组件关系说明,如下所示:.

分布式会话跟踪系统架构设计与实践

- - 美团点评技术团队
本文整理自美团点评技术沙龙第08期:大规模集群的服务治理设计与实践. 美团点评技术沙龙由美团点评技术团队主办,每月一期. 每期沙龙邀请美团点评及其它互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域. 目前沙龙会分别在北京、上海和厦门等地举行,要参加下一次最新沙龙活动. 赶快关注微信公众号“美团点评技术团队”.

分布式领域架构师要掌握的技术

- - hellojavacases微信公众号网站
分布式系统无疑是持久的热门话题,但其实如果不是一定有必要,强烈建议不要进入分布式领域,在集中式的情况下很多问题都会简单不少,技术人员千万不要因为外界火热的例如微服务,就把自己的产品的也去做改造,一定要仔细判断是否有必要,不要为了技术而技术,那么在必须分布式的情况下(访问量、存储量或开发人数),一个分布式领域的合格的架构师要掌握哪些技术呢,这篇文章就聊聊这个话题.