目录

零、双十一是什么/p>

一、2013 双十一数据库指导思想

1、知己知彼，百战不殆

（1）如何做到知己

（2）如何做到知彼

2、平时多流汗，战时少流血

（1）真实环境压测之缓存穿透

（2）MetaQueue 消息积压

3、决不在同一个地方跌倒两次

（1） 卡瓶颈问题，2012年 出现数据库集群 卡接近上限

（2）热点问题，2012 年出现热点数据并发更新，导致MySQL Thread running 飙升

（3）大卖家倒订单问题

4、尽最大的努力，做最坏的打算

（1）243条双十一数据库预案

（2）主多备切换预案

二、2013 双十一数据库核心技术介绍

1、核心技术介绍

2、DB Free – DBA Free

3、数据库限流

（1）超出数据库容量的自我保护

（2）对异常SQL语句进行限制

4、热点数据更新排队

（1）减库存操作场景，热点商品库存更新排队

（2）并发控制Patch

5、并行复制

三、2013 双十一数据库案例分享

1、Cache 失效线上压测抖动

2、硬件导致抖动问题

3、降低并发 提升性能

四、2013 双十一当天的故事

1、全 公共预案

2、核心系统双十一零点高峰指标

3、DCP 大盘监控系统

---

零、双十一是什么/h1>

那么双11到底是什么呢/strong>

• 总理 : 消费的时间点
• 马云 : 中国消费者和厂家的感恩节
• 淘宝 : 购物狂欢节
• DBA : 系统大考

---

一、2013 双十一数据库指导思想

总体指导思想

• 知己知彼，百战不殆
• 平时多流汗，战时少流血
• 决不在同一个地方跌倒两次
• 尽最大的努力，做最坏的打算

1、知己知彼，百战不殆

（1）如何做到知己

如何准确评估数据库集群自身支撑能力

问题 :  

同样硬件配置运行不同的业务，体现出来的能力上限完全不同
方案 :  

Mytest 工具，针对不同硬件不同业务场景，使用真实硬件环境，真实业务数据，真实业务SQL，通过压测获得数据库能力模型，指导各个集群的扩容规模

Mytest 工具特点:

1. C 语言编写
2. 压测采用C/S架构
3. 支持分库分表逻辑
4. 支持多表压测
5. SQL语句可定制
6. 支持多SQL事物模型
7. 支持事物提交方式定制
8. SQL 拼接变量全随机
9. 支持多个SQL 不同比例配置
10. 自动生成多种数据类型

（2）如何做到知彼

问题 :  

业务要求系统能够支撑的交易创建能力，如何把这个指标向各个数据库集群分解，商品集群，交易集群等分别需要多少支撑能力

方案 :  

a. 业务指标通过数据挖掘分析，分配创建指标到各个交易入口

b. 通过各个交易入口的浏览转化率，功能点点击率，获得各个应用系统的业务压力指标

c. 通过分布式追踪系统的统计数据，将业务系统压力转换为数据库集群压力
 

业务指标如何向数据库指标转换

• 基于历史成交数据分析，如购物车下单用户比例，立即购买用户比例
• 基于用户行为特点分析，多少次浏览会产生一次购买，多少人中会有一个人在购买时修改收货地址
• 基于淘宝自研的鹰眼系统将应用压力向数据库压力转换
• 缓存命中率在大促期间的特点，及可能出现的缓存失效问题
• 淘宝自研鹰眼系统，基于Google Dapper 论文研发，大型分布式追踪系统

2、平时多流汗，战时少流血

（1）真实环境压测之缓存穿透

问题 :  
按照Mytest压测结果及业务指标转换后，数据库集群进行了适当的扩容，扩容后的集群的支撑能力上限是多少，在真实的业务场景中是否可以达到Mytest 压测获得的能力上限

方案 :  
a. 关闭Put 缓存功能，逐步减低缓存命中率，让线上真实访问压力直接打在数据库上
b. 在关闭Put 缓存功能后，一次性手动清空所有缓存集群
c. 仅针对单个DB 关闭Put 缓存功能
 

（2）MetaQueue 消息积压

问题 :  
按照Mytest压测结果及业务指标转换后，数据库集群进行了适当的扩容，扩容后的集群的支撑能力上限是多少，在真实的业务场景中是否可以达到Mytest 压测获得的能力上限

方案 : 
针对通过收发消息的系统，人为造成短暂消息积压，通过大量消息瞬间涌入，实现系统支撑能力压测

3、决不在同一个地方跌倒两次

（1） 卡瓶颈问题，2012年 出现数据库集群 卡接近上限

a. Mytest进行压测的过程中，加入 卡容量指标
b. 核心集群升级至万兆 络环境
c. 普通集群 络环境升级到双A工作模式

（2）热点问题，2012 年出现热点数据并发更新，导致MySQL Thread running 飙升

a. 引入MySQL并发控制Patch
b. 引入MySQL 自我保护机制

（3）大卖家倒订单问题

a.超大卖家走订单中心
b.一般卖家订单信息从ISV各自拉取，改为主动推送
c.独立第三套卖家读库，支撑倒订单服务

4、尽最大的努力，做最坏的打算

（1）243条双十一数据库预案

（1）243条详尽的数据库大促预案，按照功能维度分:

a. 应用降级预案

b. 流量分配预案

c. 限流保护预案

d. 主备切换预案

e. 全 公共预案

（2）预案线上环境业务低峰期真实演练

（3）预案管控系统，上下游联动，自动实时通知机制

（2）主多备切换预案

• 部分集群采用一主库多读库结构，提高集群读支撑能力
• 集群采用星形主备结构，简化异常切换场景
• 当主库出现问题时，先将所有备库指向新主库，新主库再放开写流量

---

二、2013 双十一数据库核心技术介绍

1、核心技术介绍

核心技术介绍

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

2、DB Free – DBA Free

• 增加读库
• 实例迁移
• 实例拆分
• 实例扩容

3、数据库限流

（1）超出数据库容量的自我保护

a. 数据库自身保护机制，不再依赖应用保护

b. 根据预设的容量阀值进行限流，保护DB

c. 更新开发观念，数据库限流常态化

（2）对异常SQL语句进行限制

a. 一条异常SQL会影响整个DB，甚至整个系统

b.可以对特定SQL语句限流

c. 慢查询自动超时功能

4、热点数据更新排队

（1）减库存操作场景，热点商品库存更新排队

a.量更新同一条记录并发到达数据库

b.由于行锁机制全部进入排队队列

c.Innodb 内部维护队列锁争用及死锁检测机制性能消耗

d.原生MySQL单行更新的性能会跌到500以下

（2）并发控制Patch

a.淘宝MySQL内核组根据业务特点定制化开发

b.Innodb内部排队队列受innodb_thread_concurrency 限制

c.其他请求在MySQL Server 层面排队，不占用Innodb 资源

d.受大事物影响明显，需要应用配合保证

e.并发控制Patch 提升单行更新能力到4000 左右

5、并行复制

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

---

三、2013 双十一数据库案例分享

1、Cache 失效线上压测抖动

• 线上压测远远低于4W QPS 的目标
• 整个系统会Hang住2秒左右，同时CPU飙升，MySQL卡住，应用大面积 警
• 解决方法
  • 数据库进一步拆分，降低连接数
  • MySQL替换为AliMySQL限流版本

2、硬件导致抖动问题

• 正常压力下集群内各个单机表现稳定
• 压力摸高的过程中发现一台主机，RT 比集群内其他主机多400us
• 经排查确认原因为主机维修后BIOS参数未调整

3、降低并发 提升性能

---

四、2013 双十一当天的故事

1、全 公共预案

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

2、核心系统双十一零点高峰指标

• 单机峰值最高达到 1.5W QPS / 1.2W TPS
• 单机 络达到 75MB
• 交易创建数据库响应时间  500us 

3、DCP 大盘监控系统

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

 没看够载原始PPT继续学习吧！

更多web系统架构设计相关资料↓↓↓

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树首页概览31716 人正在系统学习中