2.2 AliCloudDB--双11商家后台数据库的基石
前言
2016年天猫双11购物狂欢节已经完美落下帷幕，千亿成交的背后，作为整个天猫商家后台数据库的基石，AliCloudDB是如何保障在零点洪峰来临时候稳定、安全和顺畅？如此庞大规模的数据库实例集群又是怎样一步步成长起来的？AliCloudDB团队核心老司机玄惭，为你带来，双11是这样用云的姿势....
1. 弹性扩容
多数用户在双11到来之前都会进行弹性扩容，常见的弹性扩容分为两类：本机升降级和跨机升降级。例如现在有一个6G/6C的RDS数据库想要升级到12G/12C，如果本机资源足够，则可以在本机完成升降级，无需迁移到其他机器上。云数据库默认是主备架构，本机升级时资源系统首先判断升级是否可以在本机完成，工作原理如上图所示：首先升级RDS备库；然后重启备库；之后进行主备切换，再修改重启原主库。
将本地升级变成一次主备切换，进而避免了重启主库的操作。这里需要注意的坑是：如果主备有延迟，那么主备切换不会进行，升级任务也会被block。
另一种弹性扩容的方式是：跨机升降级。当本机资源不足以支撑升级所需要的资源的时候，需要将实例分配到另外一台机器上。所以跨机升级需要使用数据库最近一次的备份和日志实时同步到新的主机上，保证新实例和旧实例的数据是完全一致的。
而这里需要注意的坑是：如果历史备份集较大或原主库压力较大时，会导致跨机迁移时间较长。
弹性扩容最佳实践可以总结为以下四点：
1. 如果升级很长时间也没有完成，可能发生了跨机迁移或者主备存在延迟。
2. 可用区迁移、数据库版本升级耗时通常较长，是因为两者迁移都会发生跨机迁移。
3. 空间升级非常快，这是因为空间升级无需重启、迁移数据库，对业务也不会造成影响。
4. 弹性扩容时间的选择，建议在业务低峰期进行弹性扩容。
2. 访问链路
在云数据库中，访问链路分为两种模式：高安全访问链路和标准访问链路。在图上流程图的右侧，RDS在数据库的前面增加了一层代理层，所有请求在代理层都被解析，在解析过程中添加了SQL拦截规则，进而可以防止SQL注入的攻击。此外，高安全访问链路可以防止90%的连接闪断；并支持内外网地址同时访问；对短连接应用有缓冲防护作用。需要注意的是高安全访问链路较标准链路增加了5%左右的响应时间。
标准访问链路与高安全访问链路相比，缺少了代理层，进而失去了连接保持、SQL拦截以及内外网同时访问的能力；但相对于高安全访问链路响应时间会减少。
因此，访问链路最佳实践可以总结为以下几点：
1. 建议使用高安全访问模式，特别是短连接应用，高安全访问模式具有缓冲短连接对数据库冲击的效果。
2. 在标准访问链路切换到高安全访问链路时，切换过程最多会有30秒不可访问。
3. 如果ECS使用VPC，那么数据库只能选择高安全访问链路。
4. 访问链路上需要注意应用不要使用IP来访问数据库，避免由于IP变化导致故障。
3. 架构设计
架构设计就像我们修建一幢坚固的房子一样，需要有整体的布局设计，同时在细节上材料的选择以及施工质量的保障也同样重要。在历年的双11中，由于业务流量的突增，那些平时没有暴露出来的问题往往在这个时候爆发出来，所以我们要把数据库这块地基打好，细节上做好，架构设计就需要我们在这些上下功夫。
读写分离是常见的架构设计手段。RDS支持只读节点，主库主要承担写和实时性要求高操作，一些复杂的分析计算业务操作最好不要放在主库上执行，而是选择放在只读节点运算。使用读写分离架构时，首先数据库版本需要升级到MySQL5.6版本；同时目前RDS最多只支持五个只读节点。在读写分离时，延时是我们必须关注的重点，目前RDS上通过源码改进并行复制，提升复制性能，降低了主库与备库之间数据同步的延迟。
正如上图的压测结果显示，5.6版本较5.5版本，在性能上有很大的提升。目前，RDS只有5.6版本支持只读实例，应用可以做读写分离；支持在线添加字段、索引和重建数据表，应用不再被阻塞。
引擎选择是数据库设计中很基础的一点，这里重点介绍下Tokudb引擎。日志型应用的特性是：写操作很高、读操作相对较少。Tokudb引擎压缩比Innodb引擎高出5~7倍，适合写多读少的应用；同时，Tokudb引擎online ddl速度较快，适合表很大需要经常DDL操作的应用。同样，Tokudb引擎缺点也十分明显，它会增加响应时间；同时online ddl对大字段不适用。
这里需要注意一点的是：在5.5版本以后innodb 引擎已经是MySQL的默认引擎，建议将Myisam引擎转换为innodb引擎，会避免很多问题的发生。
对于大字段，数据库的更新写入压力过大，update、insert、delete会导致binlog日志急剧增加，导致实例磁盘报警。因此在数据库设计时，要注意规避大字段引起的问题。常见的大字段有varchar（8000）、text、blob、clob（sqlserver/mysql），使用时建议将大字段拆分出主表或者存入到其他存储系统中。
字段类型也是常见的问题之一。如上图所示案例中表的user_ID是varchar（64），但访问SQL传入的是数值类型，这就会导致隐式转换发生，进而导致索引无效，可以使用explain 查看是否使用到索引。因此，在设计开发阶段，就要避免数据库字段定义与应用程序参数定义不一致的情况。
字段大小同样会对数据库性能造成影响。字段长度超过索引允许的最大长度会导致索引字段被截断；同时，过长的字段定义会消耗大量的排序内存以及临时表空间。
索引设计也是大家经常犯错的一个点，在历年双11保障中，索引出现的问题最多。这里，重点讲解单条SQL的创建索引思路：
select person_role_id from moive where movie_id=1000 and role_id=1 order by nr_role desc;
对于这条SQL语句，首先需要评估参与运算的结果集范围，在该语句中创建movie_id和role_id的组合索引；第二步，考虑参与排序字段，在该语句中，排序用到的是nr_role，因此需要将其添加到索引中。大部分情况下，经过前两步，就已经完成了索引的创建。
有时候，还需要考虑第三步：覆盖索引，在索引中添加需要查找的字段，无需回表，以期达到优化目的，在该例中将person_role_id添加到索引中。
常见的索引误区包括：
• 对SQL语句的每个查询条件字段建立一个单列索引，MySQL只能使用其一个索引；
• 对SQL语句的所有查询字段建立组合索引，导致索引远大于数据，同时性能低下；
• 小表不建立索引。
[if !supportLists]
4. 高可用配置
RDS本身是一个主备的高可用架构，当主库Down后，会快速切换到备库。在高可用架构中很重要的一点是数据同步，保障主备数据一致不丢失。常见的高可用配置包括：
• 单可用区：主备都在统一个可用区内，可以实现主备之间的快速切换；
• Binlog同步：采取异步和半同步的方式保障主备的数据一致；
• Binlog刷写：根据应用特点设置安全模式或者高性能模式；
• 事务提交：默认采用最高安全模式。
[if !supportLists]
此外，为了保障服务高可用，也可以采用多可用区配置，即主备在不同可用区，此时，应用同样需要多可用区部署。此时需要注意Binlog在主备的同步模式，通常这种情况下开启半同步模式跨可用区访问，可能导致写入性能下降。
另外，还有一种跨数据中心的灾备方案，在历年的双11中，已经有很多用户实施过这样的方案，你可以选择在两个不同的数据中心部署数据库和应用，比如在杭州和上海两个地区部署，两个数据中心的数据同步采用DTS，以保证一个数据中心挂掉后，另外一个数据中心能够接管起来。
5. 性能优化
当性能问题出现时，例如上图所示数据库的QPS高达2W+，这时候如何进行优化？首先我们需要明确导致QPS过高的原因，可以查看SQL运行报告，对一段时间内的SQL语句进行归类排序，这样就知道了数据库中是那些SQL导致QPS提升的，然后针对这些SQL进行分析，对应地给出解决方案，判断调用是否合理，是否添加缓存等。性能优化中，慢日志也是需要重点关注的点。通过查看慢日志运行报告，分析这些慢SQL产生的原因：是否缺少索引、字段设计存在问题等等，在双11之前优化掉，避免双11高峰来临的时候引发雪崩。
6. 参数优化
在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并发的查询数目，常用于秒杀场景的业务；
[if !supportLists]
除此以外，阿里云的异地灾备的产品化也非常值得分享。从2015年起，RDS为天猫的商家后台数据库提供了异地灾备的功能。当主机房出现较大的负载压力、断网、断电等极端情况，RDS可将商家的后台系统在30分钟内切换至灾备机房继续运行，以保障总体可靠性，进一步确保平台大型品牌商家双11期间后台系统安全、稳定。
7. 未来，走出去传承最佳实践和保障经验
还记得2012年一家天猫服务商和我说：“今年遇到了一群靠谱的人，在加上靠谱的技术，才能够一起做靠谱的事情。”这句话一直激励着我。我们也相信，能够真正地帮到商家，是对这次参与双11所有人的最大回报。
从上云肩挑背扛到在线迁移，让上云不再成为难事；
从资源手工离散和下线到自动化扩容和收容，让资源真正流动起来；
将诊断经验沉淀为自动化诊断工具，让诊断不再成为难事。
一幕又一幕，我们始终坚信只有把双11的经验和能力产品化和工具化，利用双11这样极具挑战的项目不断锤炼我们的产品，才是真正长远发展之计。