对不少商家而言，双 11 销量往往是平时的N倍。
云数据库如何从容应对双 11 当日的流量高峰?
今天，特别邀请到 ApsaraDB 团队的大牛级人物玄惭和大家分享，结合历年双十一活动中云数据库保障经验，从弹性扩容、访问链路、架构设计、高可用配置、参数优化等五个方面详解讲解云数据库大流量峰值保障的最佳实践。
玄惭被誉为双 11 护航老司机。过去五年，他一直负责天猫双 11 项目的数据库运维，0 故障，0 丢单。
1、弹性扩容的两种方式
多数用户在双十一到来之前都会进行弹性扩容。
常见的弹性扩容分为两类：本机升降级和跨机升降级。
本机升降级的话，比较简单。举个栗子，一个 6G/6C 的 RDS 数据库想要升级到 12G/12C，如果本机资源足够，则可以在本机完成升降级，无需迁移到其他机器上。
另一种弹性扩容的方式是：跨机升降级。
当本机资源不足以支撑升级所需要的资源的时候，需要将实例分配到另外一台机器上。所以跨机升级需要使用数据库最近一次的备份和日志实时同步到新的主机上，保证新实例和旧实例的数据是完全一致的。
这里需要注意的坑是：如果历史备份集较大或原主库压力较大时，会导致跨机迁移时间较长。
那些老司机踩过的坑：
- 如果升级很长时间也没有完成，可能发生了跨机迁移或者主备存在延迟。
- 可用区迁移、数据库版本升级耗时通常较长，是因为两者迁移都会发生跨机迁移。
- 空间升级非常快，这是因为空间升级无需重启、迁移数据库，对业务也不会造成影响。
- 弹性扩容时间的选择，建议在业务低峰期进行弹性扩容。
2、双 11 期间，如何让访问链路更安全?
在云数据库中，访问链路分为两种模式：高安全访问链路和标准访问链路。
双 11 期间，流量高的网站也会成为黑客的重点关注对象。所以建议商家提前采用高安全访问链路。
高安全访问链路在数据库的前面增加了一层代理层，所有请求在代理层都被解析，在解析过程中添加了 SQL 拦截规则，进而可以防止 SQL 注入的攻击。
此外，高安全访问链路可以防止 90% 的连接闪断;并支持内外网地址同时访问;对短连接应用具有缓冲防护作用。
需要注意的是高安全访问链路较标准链路增加了 5% 左右的响应时间。
那些老司机踩过的坑：
- 建议使用高安全访问模式，特别是短连接应用，高安全访问模式具有缓冲短连接对数据库冲击的效果。
- 在标准访问链路切换到高安全访问链路时，切换过程最多会有30秒不可访问。
- 如果ECS使用VPC，那么数据库只能选择高安全访问链路。
- 访问链路上需要注意应用不要使用IP来访问数据库，避免由于IP变化导致故障。
3、双 11 的架构如何设计?
在历年的双 11 中，由于业务流量的突增，那些平时没有暴露出来的问题往往在这个时候爆发出来，所以我们要把数据库这块地基打好，细节上做好，架构设计就需要我们在这些上下功夫。
读写分离是常见的架构设计手段。
RDS 支持只读节点，主库主要承担写和实时性要求高操作，一些复杂的分析计算业务操作最好不要放在主库上执行，而是选择放在只读节点运算。
使用读写分离架构时，首先数据库版本需要升级到 MySQL 5.6 版本;同时目前 RDS 最多可以支持到五个只读节点。
在读写分离时，延时是我们必须关注的重点，目前 RDS 上通过源码改进并行复制，提升复制性能，降低了主库与备库之间数据同步的延迟。
引擎选择是数据库设计中很基础的一点，这里重点介绍下 Tokudb 引擎。日志型应用的特性是：写操作很高、读操作相对较少。Tokudb 引擎压缩比 Innodb 引擎高出 5~7 倍，适合写多读少的应用;同时，Tokudb 引擎 online ddl 速度较快，适合表很大需要经常 DDL 操作的应用。
对于大字段，数据库的更新写入压力过大，update、insert、delete 会导致 binlog 日志急剧增加，导致实例磁盘报警。因此在数据库设计时，要注意规避大字段引起的问题。常见的大字段有 varchar(8000)、text、blob、clob(sqlserver/mysql)，使用时建议将大字段拆分出主表或者存入到其他存储系统中。
字段类型也是常见的问题之一。在设计开发阶段，就要避免数据库字段定义与应用程序参数定义不一致的情况。
字段大小同样会对数据库性能造成影响。字段长度超过索引允许的最大长度会导致索引字段被截断;同时，过长的字段定义会消耗大量的排序内存以及临时表空间。
索引设计也是大家经常犯错的一个点，在历年双十一保障中，索引出现的问题最多。
这里，重点讲解单条SQL的创建索引思路，常见的索引误区包括但不限于：
- 对SQL语句的每个查询条件字段建立一个单列索引，MySQL 只能使用其一个索引;
- 对SQL语句的所有查询字段建立组合索引，导致索引远大于数据，同时性能低下;
- 小表不建立索引。
4、双 11 的高可用配置如何搞?
RDS 本身是一个主备的高可用架构，当主库 Down 后，会快速切换到备库。在高可用架构中很重要的一点是数据同步，保障主备数据一致不丢失。
常见的高可用配置包括：
- 单可用区：主备都在同一个可用区内，可以实现主备之间的快速切换;
- Binlog 同步：采取异步和半同步的方式保障主备的数据一致;
- Binlog 刷写：根据应用特点设置安全模式或者高性能模式;
- 事务提交：默认采用最高安全模式。
此外，为了保障服务高可用，也可以采用多可用区配置，即主备在不同可用区，此时，应用同样需要多可用区部署。需要注意 Binlog 在主备的同步模式，通常这种情况下开启半同步模式跨可用区访问，可能导致写入性能下降。
另外，还有一种跨数据中心的灾备方案，在历年的双 11 中，已经有很多用户实施过这样的方案，你可以选择在两个不同的数据中心部署数据库和应用，比如在杭州和上海两个地区部署，两个数据中心的数据同步采用 DTS，以保证一个数据中心挂掉后，另外一个数据中心能够接管起来。
此外，从 2015 年起，RDS 为天猫的商家后台数据库提供了异地灾备的功能。当主机房出现较大的负载压力、断网、断电等极端情况，RDS 可将商家的后台系统在 30 分钟内切换至灾备机房继续运行，以保障总体可靠性，进一步确保平台大型品牌商家双 11 期间后台系统安全、稳定。
5、针对双 11，如何做参数优化?
在 RDS 中，大部分参数是已经经过调优的，因此很多参数是不需要再去调整的。
但是用户可以根据应用场景的不同选择合适的参数，这里重点看下 RDS 新增的四个参数优化：
- rds_max_tmp_disk_space：控制 MySQL 能够使用的临时文件的大小，适用于一个 SQL 语句就消耗掉整个数据库的磁盘空间;
- tokudb_buffer_pool_ratio：控制 TokuDB 引擎能够使用的 buffer 内存大小，适用于选择了 tokudb 作为存储引擎的场景;
- max_statement_time：控制单个 SQL 语句的最长执行时间，适用于控制数据库中的慢 SQL 数量;
- rds_threads_running_high_watermark：控制 MySQL 并发的查询数目，常用于秒杀场景的业务;
看完了“玄惭大师”的经验分享， 那么，你对大流量峰值下保障云数据库有什么好的经验可以分享吗?
