双十一数据库核心技术 2013-12-18 淘宝网 李圣陶(刘昆)

关于我 李圣陶 花名 刘昆，09年加入淘宝 Oracle,Mysql 数据库工程师 经历淘宝5年双十一 关注高并发数据库最佳实践 微博：@tao陶先生

双十一是什么 总理 : 消费的时间点 马云 : 中国消费者和厂家的感恩节 淘宝 : 购物狂欢节 DBA : 系统大考 每年双十一都是一次对各个系统的大考 前3分钟，是各个系统的压力高峰 总理 : 消费的时间点 马云 : 中国消费者和厂家的感恩节 淘宝 : 购物狂欢节 DBA : 系统大考

概要 2013 双十一数据库指导思想 2013 双十一数据库核心技术介绍 2013 双十一数据库案例分享 2013 双十一当天的故事

概要 2013 双十一数据库指导思想 2013 双十一数据库核心技术介绍 2013 双十一数据库案例分享 2013 双十一当天的故事

2013 双十一数据库指导思想 知己知彼，百战不殆 平时多流汗，战时少流血 决不在同一个地方跌倒两次 尽最大的努力，做最坏的打算 我们有多大能力，我们的库能撑多少的量，传统评估方法，CPU,Load 拍脑袋，要干多大的事情，业务会给我们带来多大的压力 我们真的有这么大的能力么？ 充分吸取历史经验教训 万一撑不住，我们怎么办

知己 – 如何准确评估数据库集群自身支撑能力 问题 : 同样硬件配置运行不同的业务，体现出来的 能力上限完全不同 方案 : Mytest 工具，针对不同硬件不同 业务场景，使用真实硬件环境，真实业务数 据，真实业务SQL，通过压测获得数据库能力 模型，指导各个集群的扩容规模 使用大促机型备份恢复真实数据库，获得真实压测基础数据 通过tcpdump 抓包分析，各个系统真实SQL 运行数据，及比例关系 准备动态拼接条件值，模拟真实SQL Mytest 驱动，随机获取拼接值，并按照核心SQL运行比例，真实压测

知己 – 如何准确评估数据库集群自身支撑能力 Mytest 工具特点: C 语言编写 压测采用C/S架构 支持分库分表逻辑 支持多表压测 SQL语句可定制 支持多SQL事物模型 支持事物提交方式定制 SQL 拼接变量全随机 支持多个SQL 不同比例配置 自动生成多种数据类型 使用大促机型备份恢复真实数据库，获得真实压测基础数据 通过tcpdump 抓包分析，各个系统真实SQL 运行数据，及比例关系 准备动态拼接条件值，模拟真实SQL Mytest 驱动，随机获取拼接值，并按照核心SQL运行比例，真实压测

知彼 – 业务指标如何向数据库指标转换 问题 : 业务要求系统能够支撑的交易创建能力，如何把这个指标向 问题 : 业务要求系统能够支撑的交易创建能力，如何把这个指标向 各个数据库集群分解，商品集群，交易集群等分别需要多少支撑 能力 方案 : a. 业务指标通过数据挖掘分析，分配创建指标到各个交易入口 b. 通过各个交易入口的浏览转化率，功能点点击率，获得各个应 用系统的业务压力指标 c. 通过分布式追踪系统的统计数据，将业务系统压力转换为数据 库集群压力 各个数据库集群要达到如何的支撑能力，才能满足创建能力的要求 根据历史数据创建会按照如何的分配比例，从那几个入口进来，多少次详情页面的浏览会走入下单流程, 每个入口的功能点的使用率，下单页面有多少比例会更换收货地址，

知彼 – 业务指标如何向数据库指标转换 基于历史成交数据分析，如购物车下单用户比例，立即购买用户比例 基于用户行为特点分析，多少次浏览会产生一次购买，多少人中会有一个人在购买时修改收货地址 基于淘宝自研的鹰眼系统将应用压力向数据库压力转换 缓存命中率在大促期间的特点，及可能出现的缓存失效问题 淘宝自研鹰眼系统，基于Google Dapper 论文研发，大型分布式追踪系统 Dapper, a Large-Scale Distributed Systems Tracing Infrastructure http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/zh-CN//pubs/archive/36356.pdf

平时多流汗 – 1.真实环境压测之缓存穿透 问题 : 按照Mytest 压测结果及业务指标转换后，数据库集群进行了适 当的扩容，扩容后的集群的支撑能力上限是多少，在真实的业务 场景中是否可以达到Mytest 压测获得的能力上限 方案 : a. 关闭Put 缓存功能，逐步减低缓存命中率，让线上真实访问 压力直接打在数据库上 b. 在关闭Put 缓存功能后，一次性手动清空所有缓存集群 c. 仅针对单个DB 关闭Put 缓存功能 关闭put 缓存，手动清空缓存集群，对业务是瞬间有损的，当达到数据库集群能力上限时，会发生业务卡顿现象，需要立即恢复缓存 早期关闭Put 缓存，是以整个集群为最小操作单位，对业务损害较大，后期改进为仅针对单个分库进行关闭 下跌的尖刺点，是数据库出现瓶颈，处理能力下跌

平时多流汗 – 2.MetaQueue 消息积压 问题 : 按照Mytest 压测结果及业务指标转换后，数据库集群进行了适 当的扩容，扩容后的集群的支撑能力上限是多少，在真实的业务 场景中是否可以达到Mytest 压测获得的能力上限 方案 : 针对通过收发消息的系统，人为造成短暂消息积压，通过大量 消息瞬间涌入，实现系统支撑能力压测

决不在同一个地方跌倒两次 – 吸取以往双十一经验 网卡瓶颈问题，2012年 出现数据库集群网卡接近上限 a. Mytest进行压测的过程中，加入网卡容量指标 b. 核心集群升级至万兆网络环境 c. 普通集群网络环境升级到双A工作模式 热点问题，2012 年出现热点数据并发更新，导致MySQL Thread running 飙升 a. 引入MySQL并发控制Patch b. 引入MySQL 自我保护机制 大卖家倒订单问题 a.超大卖家走订单中心 b.一般卖家订单信息从ISV各自拉取，改为主动推送 c.独立第三套卖家读库，支撑倒订单服务 万兆环境考虑到上联收敛比，可以确保400MB 带宽，单台高峰期间网络流量达到70MB 并发控制具体原理，后面会详细介绍 超大卖家订单中心系统 ISV 拉取SQL 效率无法保证，主动推送SQL经过严格审核，高峰期前两个小时订单导出降级

做最坏的打算 – 243条双十一数据库预案 243条详尽的数据库大促预案 按照功能维度分: a. 应用降级预案 b. 流量分配预案 c. 限流保护预案 d. 主备切换预案 e. 全网公共预案 预案线上环境业务低峰期真实演练 预案管控系统，上下游联动，自动实时通知机制

一主多备切换预案 部分集群采用一主库多读库结构，提高集群读支撑能力 集群采用星形主备结构，简化异常切换场景 当主库出现问题时，先将所有备库指向新主库，新主库再放开写流量 Slave Master Slave Master 备库挂掉，直接通过TDDL将分配给它的读流量分指向其他备库 MM结构备库承担小压力读，避免延迟 主库挂到，先将所有备库指向新主库，，这时假定所有备库的数据是一致的，然后再放开写入流量 如果有部分备库有延迟，发生数据

概要 2013 双十一数据库指导思想 2013 双十一数据库核心技术介绍 2013 双十一数据库案例分享 2013 双十一当天的故事

核心技术介绍 TDDL --分布式数据库访问层 ADHA -- MySQL高可用架构 DBFree -- MySQL集群弹性伸缩系统 AliMySQL 分支 -- MySQL自我保护Patch -- MySQL热点更新Patch -- MySQL主备延迟解决方案

DB Free – DBA Free 增加读库 实例迁移 实例拆分 实例扩容 TDDL 作为数据中间层，让DB 切换对业务透明，但针对大规模集群无法通过人工操作TDDL Dbfree 让大规模集群具有批量快速透明扩容能力 增加读库– 新增备库

数据库限流 -- 数据库自我保护 超出数据库容量的自我保护 a. 数据库自身保护机制，不再依赖应用保护 b. 根据预设的容量阀值进行限流，保护DB c. 更新开发观念，数据库限流常态化 对异常SQL语句进行限制 a. 一条异常SQL会影响整个DB，甚至整个系统 b.可以对特定SQL语句限流 c. 慢查询自动超时功能 数据库自身保护机制，自己的命运自己掌握，不再依赖应用对数据库的保护 大多数开发的观念是，数据库的服务等级就像我们日常生活中的银行一样，除了有公告的例行维护以外，在日常的使用中是不能够有任何报错的，报错是一个很严重的问题。这个观念要被更新，数据库自我保护常态化 9/9 大促大卖家订单SQL 问题，开发无法快速过滤，DBA命运掌握在开发手中

热点数据更新排队 减库存操作场景，热点商品库存更新排队 a. 大量更新同一条记录并发到达数据库 b. 由于行锁机制全部进入排队队列 c. Innodb 内部维护队列锁争用及死锁检测机制性能消耗 d. 原生MySQL单行更新的性能会跌到500以下 并发控制Patch a. 淘宝MySQL内核组根据业务特点定制化开发 b. Innodb内部排队队列受innodb_thread_concurrency 限制 c. 其他请求在MySQL Server 层面排队，不占用Innodb 资源 d. 受大事物影响明显，需要应用配合保证 e. 并发控制Patch 提升单行更新能力到4000 左右 队列过长，死锁检测，kernel_mutex 争用，造成大量无用功

并行复制 -- 淘宝MySQL主备延迟解决方案 解决主备库复制延迟问题 通过动态参数配置开启及并行度 支持数据库，表级别，事物级并行

概要 2013 双十一数据库指导思想 2013 双十一数据库核心技术介绍 2013 双十一数据库案例分享 2013 双十一当天的故事

Cache 失效线上压测抖动

Cache 失效线上压测抖动 线上压测远远低于4W QPS 的目标 整个系统会Hang住2秒左右，同时CPU飙升，MySQL卡住，应用大面积报警 解决方法 a. 数据库进一步拆分，降低连接数 d. MySQL替换为AliMySQL限流版本 压测结果远远低于预期，线下Mytest 压测可以达到4W 考虑到这个是新上的万兆环境，新万兆网卡的驱动，之前有收到网络部分邮件，这个版本驱动非标准化，首先调整了万兆网卡驱动，调整后没有明显效果 另外一个与之前线下压测不同的点就是连接数，应用服务器达到的规模，Mysql 单实例链接数上万，同时在发生抖动的2-3秒内，发现大量的kernel_mutex ，怀疑与高连接数下同时并发量过大，造成Mysql 锁资源争用导致抖动 FIO在Hang 的瞬间，有IO Wait出现，移除redolog 降低FIO 抖动几率 在排查问的过程中，发现一些硬件参数不标准，比如FIO 供电问题，在FGC时需要请求更高的电压以加快GC完成速度。BIOS 中c-stats 参数问题，sysprofile 未调整为最高性能模式问题 在追查商品库问题的同时，改进了Cache 失效压测方法，从以整个Cache 集群为操作单位，改进为以单个DB为操作单位 当Mysql 出现卡顿的现象是，必须进行干预，或者应用限流保护数据库，或者数据自身限流，否则在持续压力的情况下，DB 很难缓解

硬件导致抖动问题 正常压力下集群内各个单机表现稳定 压力摸高的过程中发现一台主机，RT 比集群内其他主机多400us 经排查确认原因为主机维修后BIOS参数未调整 魔鬼都出在细节 400 us 的偏差，基本感觉不到 只有通过大压力的检验，细心的观察诊断 如果这个问题没有及时发现，一部分买家的购物体验在双十一当天就会受到影响

降低并发 提升性能 低并发高性能 有序请求，避免不必要的锁争用，Mysql 拥有更好的处理能力 应用端，数据库端双重排序

概要 2013 双十一数据库指导思想 2013 双十一数据库准备阶段总结 2013 双十一数据库新技术使用介绍 2013 双十一当天的故事 在应用端进行对减库存操作排队 根据itemId来进行排队，相同itemId的减库存操作会进入串行化排队处理逻辑 应用端的排队只能做到单机内存排队 db端也加上排队策略， “并发控制” 低并发，高性能

全网公共预案 读写分流，各个读业务按照不同比例分配读流量到备库， 降低主库压力，让主库有更多余量来抗写入 数据库集群开启自我保护 写入型数据库修改双一参数 sync_binlog flush_log_at_trx_commit 零点高峰前调大修改脏页比例 innodb_max_dirty_pages_pct

核心系统双十一零点高峰指标 单机峰值最高达到 1.5W QPS / 1.2W TPS 单机网络达到 75MB 交易创建数据库响应时间 500us

DCP 大盘监控系统 实时展现性能采集数据 图形化展示核心集群水位状态 详细指标信息精确到每个实例 网络包流量自动异常监控

欢迎加入阿里数据库团队 Java 后端开发 Python , C/C++ 开发 热爱数据库 来往 陶先生 微博私信 @tao陶先生 产品DBA 支持淘宝上百条业务线 基础DBA 运维淘宝上万台数据库服务器 工具开发组，自动化工具平台 Mysql 内核开发，定制化Patch OB ,Hbase 分布式数据库团队 来往 陶先生 微博私信 @tao陶先生 邮箱地址 liukun@taobao.com

Q & A