【干货】乐视秒杀:每秒十万笔交易的数据架构解读

本贴最后更新于 3309 天前,其中的信息可能已经事过景迁

随着乐视硬件抢购的不断升级,乐视集团支付面临的请求压力百倍乃至千倍的暴增。作为商品购买的最后一环,保证用户快速稳定地完成支付尤为重要。所以在 2015 年 11 月,我们对整个支付系统进行了全面的架构升级,使之具备了每秒稳定处理 10 万订单的能力。为乐视生态各种形式的抢购秒杀活动提供了强有力的支撑。

一. 分库分表

在 redis,memcached 等缓存系统盛行的互联网时代,构建一个支撑每秒十万只读的系统并不复杂,无非是通过一致性哈希扩展缓存节点,水平扩展 web 服务器等。支付系统要处理每秒十万笔订单,需要的是每秒数十万的数据库更新操作(insert 加 update),这在任何一个独立数据库上都是不可能完成的任务,所以我们首先要做的是对订单表(简称 order)进行分库与分表。
在进行数据库操作时,一般都会有用户 ID(简称 uid)字段,所以我们选择以 uid 进行分库分表。
分库策略我们选择了“二叉树分库”,所谓“二叉树分库”指的是:我们在进行数据库扩容时,都是以 2 的倍数进行扩容。比如:1 台扩容到 2 台,2 台扩容到 4 台,4 台扩容到 8 台,以此类推。这种分库方式的好处是,我们在进行扩容时,只需 DBA 进行表级的数据同步,而不需要自己写脚本进行行级数据同步。
光是有分库是不够的,经过持续压力测试我们发现,在同一数据库中,对多个表进行并发更新的效率要远远大于对一个表进行并发更新,所以我们在每个分库中都将 order 表拆分成 10 份:order_0,order_1,....,order_9。
最后我们把 order 表放在了 8 个分库中(编号 1 到 8,分别对应 DB1 到 DB8),每个分库中 10 个分表(编号 0 到 9,分别对应 order_0 到 order_9),部署结构如下图所示:

1462851593368

根据 uid 计算数据库编号:
数据库编号 = (uid / 10) % 8 + 1
根据 uid 计算表编号:
表编号 = uid % 10
当 uid=9527 时,根据上面的算法,其实是把 uid 分成了两部分 952 和 7,其中 952 模 8 加 1 等于 1 为数据库编号,而 7 则为表编号。所以 uid=9527 的订单信息需要去 DB1 库中的 order_7 表查找。具体算法流程也可参见下图:

1462851617019

有了分库分表的结构与算法最后就是寻找分库分表的实现工具,目前市面上约有两种类型的分库分表工具:
1.客户端分库分表,在客户端完成分库分表操作,直连数据库
2.使用分库分表中间件,客户端连分库分表中间件,由中间件完成分
库分表操作
这两种类型的工具市面上都有,这里不一一列举,总的来看这两类工具各有利弊。客户端分库分表由于直连数据库,所以性能比使用分库分表中间件高 15% 到 20%。而使用分库分表中间件由于进行了统一的中间件管理,将分库分表操作和客户端隔离,模块划分更加清晰,便于 DBA 进行统一管理。
我们选择的是在客户端分库分表,因为我们自己开发并开源了一套数据层访问框架,它的代号叫“芒果”,芒果框架原生支持分库分表功能,并且配置起来非常简单。
芒果主页:mango.jfaster.org
芒果源码:github.com/jfaster/mango

二. 订单 ID

订单系统的 ID 必须具有全局唯一的特征,最简单的方式是利用数据库的序列,每操作一次就能获得一个全局唯一的自增 ID,如果要支持每秒处理 10 万订单,那每秒将至少需要生成 10 万个订单 ID,通过数据库生成自增 ID 显然无法完成上述要求。所以我们只能通过内存计算获得全局唯一的订单 ID。
JAVA 领域最著名的唯一 ID 应该算是 UUID 了,不过 UUID 太长而且包含字母,不适合作为订单 ID。通过反复比较与筛选,我们借鉴了 Twitter 的 Snowflake 算法,实现了全局唯一 ID。下面是订单 ID 的简化结构图:

1462851628576

上图分为 3 个部分:
1 时间戳
这里时间戳的粒度是毫秒级,生成订单 ID 时,使用 System.currentTimeMillis 作为时间戳
2 机器号
每个订单服务器都将被分配一个唯一的编号,生成订单 ID 时,直接使用该唯一编号作为机器号即可。
3 自增序号
当在同一服务器的同一毫秒中有多个生成订单 ID 的请求时,会在当前毫秒下自增此序号,下一个毫秒此序号继续从 0 开始。比如在同一服务器同一毫秒有 3 个生成订单 ID 的请求,这 3 个订单 ID 的自增序号部分将分别是 0,1,2。
上面 3 个部分组合,我们就能快速生成全局唯一的订单 ID。不过光全局唯一还不够,很多时候我们会只根据订单 ID 直接查询订单信息,这时由于没有 uid,我们不知道去哪个分库的分表中查询,遍历所有的库的所有表?这显然不行。所以我们需要将分库分表的信息添加到订单 ID 上,下面是带分库分表信息的订单 ID 简化结构图:

1462851653506

我们在生成的全局订单 ID 头部添加了分库与分表的信息,这样只根据订单 ID,我们也能快速的查询到对应的订单信息。
分库分表信息具体包含哪些内容?第一部分有讨论到,我们将订单表按 uid 维度拆分成了 8 个数据库,每个数据库 10 张表,最简单的分库分表信息只需一个长度为 2 的字符串即可存储,第 1 位存数据库编号,取值范围 1 到 8,第 2 位存表编号,取值范围 0 到 9。
还是按照第一部分根据 uid 计算数据库编号和表编号的算法,当 uid=9527 时,分库信息 =1,分表信息 =7,将他们进行组合,两位的分库分表信息即为"17"。具体算法流程参见下图:

1462851669654

上述使用表编号作为分表信息没有任何问题,但使用数据库编号作为分库信息却存在隐患,考虑未来的扩容需求,我们需要将 8 库扩容到 16 库,这时取值范围 1 到 8 的分库信息将无法支撑 1 到 16 的分库场景,分库路由将无法正确完成,我们将上诉问题简称为分库信息精度丢失。
为解决分库信息精度丢失问题,我们需要对分库信息精度进行冗余,即我们现在保存的分库信息要支持以后的扩容。这里我们假设最终我们会扩容到 64 台数据库,所以新的分库信息算法为:
分库信息 = (uid / 10) % 64 + 1
当 uid=9527 时,根据新的算法,分库信息=57,这里的 57 并不是真正数据库的编号,它冗余了最后扩展到 64 台数据库的分库信息精度。我们当前只有 8 台数据库,实际数据库编号还需根据下面的公式进行计算:
实际数据库编号 = (分库信息 - 1) % 8 + 1
当 uid=9527 时,分库信息 =57,实际数据库编号 =1,分库分表信息="577"。
由于我们选择模 64 来保存精度冗余后的分库信息,保存分库信息的长度由 1 变为了 2,最后的分库分表信息的长度为 3。具体算法流程也可参见下图:

1462851686408

如上图所示,在计算分库信息的时候采用了模 64 的方式冗余了分库信息精度,这样当我们的系统以后需要扩容到 16 库,32 库,64 库都不会再有问题。
上面的订单 ID 结构已经能很好的满足我们当前与之后的扩容需求,但考虑到业务的不确定性,我们在订单 ID 的最前方加了 1 位用于标识订单 ID 的版本,这个版本号属于冗余数据,目前并没有用到。下面是最终订单 ID 简化结构图:

1462851699663

Snowflake 算法:github.com/twitter/snowflake

三. 最终一致性

到目前为止,我们通过对 order 表 uid 维度的分库分表,实现了 order 表的超高并发写入与更新,并能通过 uid 和订单 ID 查询订单信息。但作为一个开放的集团支付系统,我们还需要通过业务线 ID(又称商户 ID,简称 bid)来查询订单信息,所以我们引入了 bid 维度的 order 表集群,将 uid 维度的 order 表集群冗余一份到 bid 维度的 order 表集群中,要根据 bid 查询订单信息时,只需查 bid 维度的 order 表集群即可。
上面的方案虽然简单,但保持两个 order 表集群的数据一致性是一件很麻烦的事情。两个表集群显然是在不同的数据库集群中,如果在写入与更新中引入强一致性的分布式事务,这无疑会大大降低系统效率,增长服务响应时间,这是我们所不能接受的,所以我们引入了消息队列进行异步数据同步,来实现数据的最终一致性。当然消息队列的各种异常也会造成数据不一致,所以我们又引入了实时监控服务,实时计算两个集群的数据差异,并进行一致性同步。
下面是简化的一致性同步图:

1462851711668

四. 数据库高可用

没有任何机器或服务能保证在线上稳定运行不出故障。比如某一时间,某一数据库主库宕机,这时我们将不能对该库进行读写操作,线上服务将受到影响。
所谓数据库高可用指的是:当数据库由于各种原因出现问题时,能实时或快速的恢复数据库服务并修补数据,从整个集群的角度看,就像没有出任何问题一样。需要注意的是,这里的恢复数据库服务并不一定是指修复原有数据库,也包括将服务切换到另外备用的数据库。
数据库高可用的主要工作是数据库恢复与数据修补,一般我们以完成这两项工作的时间长短,作为衡量高可用好坏的标准。这里有一个恶性循环的问题,数据库恢复的时间越长,不一致数据越多,数据修补的时间就会越长,整体修复的时间就会变得更长。所以数据库的快速恢复成了数据库高可用的重中之重,试想一下如果我们能在数据库出故障的 1 秒之内完成数据库恢复,修复不一致的数据和成本也会大大降低。
下图是一个最经典的主从结构:

1462851726511

上图中有 1 台 web 服务器和 3 台数据库,其中 DB1 是主库,DB2 和 DB3 是从库。我们在这里假设 web 服务器由项目组维护,而数据库服务器由 DBA 维护。
当从库 DB2 出现问题时,DBA 会通知项目组,项目组将 DB2 从 web 服务的配置列表中删除,重启 web 服务器,这样出错的节点 DB2 将不再被访问,整个数据库服务得到恢复,等 DBA 修复 DB2 时,再由项目组将 DB2 添加到 web 服务。
当主库 DB1 出现问题时,DBA 会将 DB2 切换为主库,并通知项目组,项目组使用 DB2 替换原有的主库 DB1,重启 web 服务器,这样 web 服务将使用新的主库 DB2,而 DB1 将不再被访问,整个数据库服务得到恢复,等 DBA 修复 DB1 时,再将 DB1 作为 DB2 的从库即可。
上面的经典结构有很大的弊病:不管主库或从库出现问题,都需要 DBA 和项目组协同完成数据库服务恢复,这很难做到自动化,而且恢复工程也过于缓慢。
我们认为,数据库运维应该和项目组分开,当数据库出现问题时,应由 DBA 实现统一恢复,不需要项目组操作服务,这样便于做到自动化,缩短服务恢复时间。
先来看从库高可用结构图:

1462851736677

如上图所示,web 服务器将不再直接连接从库 DB2 和 DB3,而是连接 LVS 负载均衡,由 LVS 连接从库。这样做的好处是 LVS 能自动感知从库是否可用,从库 DB2 宕机后,LVS 将不会把读数据请求再发向 DB2。同时 DBA 需要增减从库节点时,只需独立操作 LVS 即可,不再需要项目组更新配置文件,重启服务器来配合。
再来看主库高可用结构图:

1462851744785

如上图所示,web 服务器将不再直接连接主库 DB1,而是连接 KeepAlive 虚拟出的一个虚拟 ip,再将此虚拟 ip 映射到主库 DB1 上,同时添加 DB_bak 从库,实时同步 DB1 中的数据。正常情况下 web 还是在 DB1 中读写数据,当 DB1 宕机后,脚本会自动将 DB_bak 设置成主库,并将虚拟 ip 映射到 DB_bak 上,web 服务将使用健康的 DB_bak 作为主库进行读写访问。这样只需几秒的时间,就能完成主数据库服务恢复。
组合上面的结构,得到主从高可用结构图:

1462851752590

数据库高可用还包含数据修补,由于我们在操作核心数据时,都是先记录日志再执行更新,加上实现了近乎实时的快速恢复数据库服务,所以修补的数据量都不大,一个简单的恢复脚本就能快速完成数据修复。

五. 数据分级
支付系统除了最核心的支付订单表与支付流水表外,还有一些配置信息表和一些用户相关信息表。如果所有的读操作都在数据库上完成,系统性能将大打折扣,所以我们引入了数据分级机制。
我们简单的将支付系统的数据划分成了 3 级:
第 1 级:订单数据和支付流水数据;这两块数据对实时性和精确性要求很高,所以不添加任何缓存,读写操作将直接操作数据库。
第 2 级:用户相关数据;这些数据和用户相关,具有读多写少的特征,所以我们使用 redis 进行缓存。
第 3 级:支付配置信息;这些数据和用户无关,具有数据量小,频繁读,几乎不修改的特征,所以我们使用本地内存进行缓存。
使用本地内存缓存有一个数据同步问题,因为配置信息缓存在内存中,而本地内存无法感知到配置信息在数据库的修改,这样会造成数据库中数据和本地内存中数据不一致的问题。
为了解决此问题,我们开发了一个高可用的消息推送平台,当配置信息被修改时,我们可以使用推送平台,给支付系统所有的服务器推送配置文件更新消息,服务器收到消息会自动更新配置信息,并给出成功反馈。

六. 粗细管道
黑客攻击,前端重试等一些原因会造成请求量的暴涨,如果我们的服务被激增的请求给一波打死,想要重新恢复,就是一件非常痛苦和繁琐的过程。
举个简单的例子,我们目前订单的处理能力是平均 10 万下单每秒,峰值 14 万下单每秒,如果同一秒钟有 100 万个下单请求进入支付系统,毫无疑问我们的整个支付系统就会崩溃,后续源源不断的请求会让我们的服务集群根本启动不起来,唯一的办法只能是切断所有流量,重启整个集群,再慢慢导入流量。
我们在对外的 web 服务器上加一层“粗细管道”,就能很好的解决上面的问题。
下面是粗细管道简单的结构图:

1462851761961

请看上面的结构图,http 请求在进入 web 集群前,会先经过一层粗细管道。入口端是粗口,我们设置最大能支持 100 万请求每秒,多余的请求会被直接抛弃掉。出口端是细口,我们设置给 web 集群 10 万请求每秒。剩余的 90 万请求会在粗细管道中排队,等待 web 集群处理完老的请求后,才会有新的请求从管道中出来,给 web 集群处理。这样 web 集群处理的请求数每秒永远不会超过 10 万,在这个负载下,集群中的各个服务都会高校运转,整个集群也不会因为暴增的请求而停止服务。
如何实现粗细管道?nginx 商业版中已经有了支持,相关资料请搜索 nginx max_conns,需要注意的是 max_conns 是活跃连接数,具体设置除了需要确定最大 TPS 外,还需确定平均响应时间。
nginx 相关:
http://nginx.org/en/docs/http/ngx_http_upstream_module.html

作者:头条号 / DBAplus 社群
链接:http://toutiao.com/i6282460032487391746/
来源:头条号(今日头条旗下创作平台)
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

  • 架构

    我们平时所说的“架构”主要是指软件架构,这是有关软件整体结构与组件的抽象描述,用于指导软件系统各个方面的设计。另外还有“业务架构”、“网络架构”、“硬件架构”等细分领域。

    142 引用 • 442 回帖 • 1 关注
  • 乐视
    1 引用 • 8 回帖
  • 数据库

    据说 99% 的性能瓶颈都在数据库。

    345 引用 • 749 回帖 • 2 关注

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...

推荐标签 标签

  • 996
    13 引用 • 200 回帖 • 3 关注
  • HHKB

    HHKB 是富士通的 Happy Hacking 系列电容键盘。电容键盘即无接点静电电容式键盘(Capacitive Keyboard)。

    5 引用 • 74 回帖 • 515 关注
  • Elasticsearch

    Elasticsearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于 RESTful 接口。Elasticsearch 是用 Java 开发的,并作为 Apache 许可条款下的开放源码发布,是当前流行的企业级搜索引擎。设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便。

    117 引用 • 99 回帖 • 199 关注
  • 正则表达式

    正则表达式(Regular Expression)使用单个字符串来描述、匹配一系列遵循某个句法规则的字符串。

    31 引用 • 94 回帖 • 1 关注
  • 支付宝

    支付宝是全球领先的独立第三方支付平台,致力于为广大用户提供安全快速的电子支付/网上支付/安全支付/手机支付体验,及转账收款/水电煤缴费/信用卡还款/AA 收款等生活服务应用。

    29 引用 • 347 回帖
  • 阿里巴巴

    阿里巴巴网络技术有限公司(简称:阿里巴巴集团)是以曾担任英语教师的马云为首的 18 人,于 1999 年在中国杭州创立,他们相信互联网能够创造公平的竞争环境,让小企业通过创新与科技扩展业务,并在参与国内或全球市场竞争时处于更有利的位置。

    43 引用 • 221 回帖 • 56 关注
  • 机器学习

    机器学习(Machine Learning)是一门多领域交叉学科,涉及概率论、统计学、逼近论、凸分析、算法复杂度理论等多门学科。专门研究计算机怎样模拟或实现人类的学习行为,以获取新的知识或技能,重新组织已有的知识结构使之不断改善自身的性能。

    77 引用 • 37 回帖
  • Electron

    Electron 基于 Chromium 和 Node.js,让你可以使用 HTML、CSS 和 JavaScript 构建应用。它是一个由 GitHub 及众多贡献者组成的活跃社区共同维护的开源项目,兼容 Mac、Windows 和 Linux,它构建的应用可在这三个操作系统上面运行。

    15 引用 • 136 回帖 • 6 关注
  • SOHO

    为成为自由职业者在家办公而努力吧!

    7 引用 • 55 回帖
  • Python

    Python 是一种面向对象、直译式电脑编程语言,具有近二十年的发展历史,成熟且稳定。它包含了一组完善而且容易理解的标准库,能够轻松完成很多常见的任务。它的语法简捷和清晰,尽量使用无异义的英语单词,与其它大多数程序设计语言使用大括号不一样,它使用缩进来定义语句块。

    554 引用 • 675 回帖
  • Swagger

    Swagger 是一款非常流行的 API 开发工具,它遵循 OpenAPI Specification(这是一种通用的、和编程语言无关的 API 描述规范)。Swagger 贯穿整个 API 生命周期,如 API 的设计、编写文档、测试和部署。

    26 引用 • 35 回帖 • 4 关注
  • CSDN

    CSDN (Chinese Software Developer Network) 创立于 1999 年,是中国的 IT 社区和服务平台,为中国的软件开发者和 IT 从业者提供知识传播、职业发展、软件开发等全生命周期服务,满足他们在职业发展中学习及共享知识和信息、建立职业发展社交圈、通过软件开发实现技术商业化等刚性需求。

    14 引用 • 155 回帖
  • 微软

    微软是一家美国跨国科技公司,也是世界 PC 软件开发的先导,由比尔·盖茨与保罗·艾伦创办于 1975 年,公司总部设立在华盛顿州的雷德蒙德(Redmond,邻近西雅图)。以研发、制造、授权和提供广泛的电脑软件服务业务为主。

    8 引用 • 44 回帖
  • 服务

    提供一个服务绝不仅仅是简单的把硬件和软件累加在一起,它包括了服务的可靠性、服务的标准化、以及对服务的监控、维护、技术支持等。

    41 引用 • 24 回帖
  • Bootstrap

    Bootstrap 是 Twitter 推出的一个用于前端开发的开源工具包。它由 Twitter 的设计师 Mark Otto 和 Jacob Thornton 合作开发,是一个 CSS / HTML 框架。

    18 引用 • 33 回帖 • 646 关注
  • Tomcat

    Tomcat 最早是由 Sun Microsystems 开发的一个 Servlet 容器,在 1999 年被捐献给 ASF(Apache Software Foundation),隶属于 Jakarta 项目,现在已经独立为一个顶级项目。Tomcat 主要实现了 JavaEE 中的 Servlet、JSP 规范,同时也提供 HTTP 服务,是市场上非常流行的 Java Web 容器。

    162 引用 • 529 回帖 • 1 关注
  • 招聘

    哪里都缺人,哪里都不缺人。

    188 引用 • 1057 回帖
  • 生活

    生活是指人类生存过程中的各项活动的总和,范畴较广,一般指为幸福的意义而存在。生活实际上是对人生的一种诠释。生活包括人类在社会中与自己息息相关的日常活动和心理影射。

    229 引用 • 1432 回帖 • 1 关注
  • SSL

    SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全(Transport Layer Security,TLS)是为网络通信提供安全及数据完整性的一种安全协议。TLS 与 SSL 在传输层对网络连接进行加密。

    70 引用 • 193 回帖 • 415 关注
  • Android

    Android 是一种以 Linux 为基础的开放源码操作系统,主要使用于便携设备。2005 年由 Google 收购注资,并拉拢多家制造商组成开放手机联盟开发改良,逐渐扩展到到平板电脑及其他领域上。

    336 引用 • 324 回帖
  • 房星科技

    房星网,我们不和没有钱的程序员谈理想,我们要让程序员又有理想又有钱。我们有雄厚的房地产行业线下资源,遍布昆明全城的 100 家门店、四千地产经纪人是我们坚实的后盾。

    6 引用 • 141 回帖 • 596 关注
  • DevOps

    DevOps(Development 和 Operations 的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。

    59 引用 • 25 回帖 • 2 关注
  • 自由行
    1 关注
  • Laravel

    Laravel 是一套简洁、优雅的 PHP Web 开发框架。它采用 MVC 设计,是一款崇尚开发效率的全栈框架。

    19 引用 • 23 回帖 • 738 关注
  • FFmpeg

    FFmpeg 是一套可以用来记录、转换数字音频、视频,并能将其转化为流的开源计算机程序。

    23 引用 • 32 回帖
  • JRebel

    JRebel 是一款 Java 虚拟机插件,它使得 Java 程序员能在不进行重部署的情况下,即时看到代码的改变对一个应用程序带来的影响。

    26 引用 • 78 回帖 • 676 关注
  • Openfire

    Openfire 是开源的、基于可拓展通讯和表示协议 (XMPP)、采用 Java 编程语言开发的实时协作服务器。Openfire 的效率很高,单台服务器可支持上万并发用户。

    6 引用 • 7 回帖 • 116 关注