标签：更新 排序 写入 list 最佳实践 lse 互联网应用 实例 根据
摘要： 在大流量高并发互联网应用实践在线峰会上，阿里云数据库专家罗龙九结合历年双十一活动中云数据库保障经验，从弹性扩容、访问链路、架构设计、高可用配置、性能优化、参数优化六个方面详解讲解云数据库大流量峰值保障的最佳实践。
在9月20日-21日举办的大流量高并发互联网应用实践在线峰会上，阿里云数据库专家罗龙九（花名：玄惭）分享的主题是《云数据库大流量峰值保障最佳实践》，他结合历年双十一活动中云数据库保障经验，从弹性扩容、访问链路、架构设计、高可用配置、性能优化、参数优化六个方面详解讲解云数据库大流量峰值保障的最佳实践。
以下为在线分享观点整理。
弹性扩容
多数用户在双十一到来之前都会进行弹性扩容，常见的弹性扩容分为两类：本机升降级和跨机升降级。例如现在有一个6G/6C的RDS数据库想要升级到12G/12C，如果本机资源足够，则可以在本机完成升降级，无需迁移到其他机器上。云数据库默认是主备架构，本机升级时资源系统首先判断升级是否可以在本机完成，工作原理如上图所示：首先升级RDS备库；然后重启备库；之后进行主备切换，再修改重启原主库。将本地升级变成一次主备切换，进而避免了重启主库的操作。这里需要注意的是如果主备有延迟，那么主备切换不会进行，升级任务也会被block。
另一种弹性扩容的方式是：跨机升降级。当本机资源不足以支撑升级所需要的资源的时候，需要将实例分配到另外一台机器上。所以跨机升级需要使用数据库最近一次的备份和日志实时同步到新的主机上，保证新实例和旧实例的数据是完全一致的，如果历史备份集较大或原主库压力较大时，会导致跨机迁移时间较长。
弹性扩容最佳实践可以总结为以下四点：
访问链路
在云数据库中，访问链路分为两种模式：高安全访问链路和标准访问链路。在图上流程图的右侧，RDS在数据库的前面增加了一层代理层，所有请求在代理层都被解析，在解析过程中添加了SQL拦截规则，进而可以防止SQL注入的攻击。此外，高安全访问链路可以防止90%的连接闪断；并支持内外网地址同时访问；对短连接应用有缓冲防护作用。需要注意的是高安全访问链路较标准链路增加了5%左右的响应时间。
标准访问链路与高安全访问链路相比，缺少了代理层，进而失去了连接保持、SQL拦截以及内外网同时访问的能力；但相对于高安全访问链路响应时间会减少。
因此，访问链路最佳实践可以总结为以下几点：
架构设计
架构设计就像我们修建一幢坚固的房子一样，需要有整体的布局设计，同时在细节上材料的选择以及施工质量的保障也同样重要。在历年的双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 查看是否使用到索引。因此，在设计开发阶段，就要避免数据库字段定义与应用程序参数定义不一致的情况。
字段大小同样会对数据库性能造成影响。字段长度超过索引允许的最大长度会导致索引字段被截断；同时，过长的字段定义会消耗大量的排序内存以及临时表空间。
索引设计也是大家经常犯错的一个点，在历年双十一保障中，索引出现的问题最多。这里，重点讲解单条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添加到索引中。
常见的索引误区包括：
高可用配置
RDS本身是一个主备的高可用架构，当主库Down后，会快速切换到备库。在高可用架构中很重要的一点是数据同步，保障主备数据一致不丢失。常见的高可用配置包括：
此外，为了保障服务高可用，也可以采用多可用区配置，即主备在不同可用区，此时，应用同样需要多可用区部署。此时需要注意Binlog在主备的同步模式，通常这种情况下开启半同步模式跨可用区访问，可能导致写入性能下降。
另外，还有一种跨数据中心的灾备方案，在历年的双11中，已经有很多用户实施过这样的方案，你可以选择在两个不同的数据中心部署数据库和应用，比如在杭州和上海两个地区部署，两个数据中心的数据同步采用DTS，以保证一个数据中心挂掉后，另外一个数据中心能够接管起来。
性能优化
当性能问题出现时，例如上图所示数据库的QPS高达2W+，这时候如何进行优化？首先我们需要明确导致QPS过高的原因，可以查看SQL运行报告，对一段时间内的SQL语句进行归类排序，这样就知道了数据库中是那些SQL导致QPS提升的，然后针对这些SQL进行分析，对应地给出解决方案，判断调用是否合理，是否添加缓存等。性能优化中，慢日志也是需要重点关注的点。通过查看慢日志运行报告，分析这些慢SQL产生的原因：是否缺少索引、字段设计存在问题等等，在双11之前优化掉，避免双11高峰来临的时候引发雪崩。
参数优化
在RDS中，大部分参数是已经经过调优的，因此很多参数是不需要再去调整的。但是用户可以根据应用场景的不同选择合适的参数，这里重点看下RDS新增的四个参数优化：
在双十一中，秒杀是非常常见的活动，因此这里重点分析下秒杀参数优化。从左上图可以看到，数据库的活跃连接数和总连接数同时达到高峰，右上图显示了数据库中有大量堆积的update语句正在执行，意味着秒杀开始。数据库前端涌入大量的请求，由于后端数据库处理过慢，导致了数据库中的连接也随之全部堆积起来，从左下图中可以看到数据库的update TPS 跳跃幅度很大，其中的run活跃线程数表明了数据库这个时候已经满负荷运转了。
通过采用rds_threads_running_high_watermark参数，将并发值限制在300后，效果如右下方图显示，update TPS 已经趋近平稳，run活跃线程数也随之下降。对于被限流的应用请求会收到MySQL too busy的报错，需要应用这个时候适当做出对应的处理。
关于分享者：
罗龙九（花名：玄惭），阿里云数据库专家，有着丰厚的DBA经验，经历阿里历年双11考验，负责阿里云RDS线上稳定以及专家服务团队，积累了6年对阿里云数据库用户的运维、调优、诊断等丰富的经验。
通过 Google drive 备份与同步 Keepass 数据库
标签：更新 排序 写入 list 最佳实践 lse 互联网应用 实例 根据
原文地址：https://www.cnblogs.com/syncnavigator/p/10189430.html
