在去年双11之前，为了帮助商家准备天猫双11的大促，让用户更好的使用rds，把rds的性能发挥到最佳，保障双11当天面对爆发性增加的压力，不会由于rds的瓶颈导致系统出现问题，编写了rds的最佳实践。该文档的内容全部出自于生产实践，但由于篇幅的限制，我只是把其中的概要罗列到了ppt中，并没有展开详细的介绍，后续计划写一个系列，把ppt中的内容进一步展开来讲一讲，也算是对rds用户的一个交代。
我该如何选择rds？我要购买多大规格的rds？rds的连接数，iops指的是什么？上诉这些问题相信是每一个rds用户在开始使用的时候都会有这样的疑问。首先我们要了解一下rds的组成包括哪一些，从阿里云官网的购买页面中我们可以看到rds包括了以下参数：数据库类型，版本，存储空间，规格：内存+连接数+io，地域，那我们就一个个来分析一下：
rds目前支持的数据库类型有两种：mysql，sqlserver，为什么这里要特别提出来讲一讲？原因有以下两个方面：
a.由于受到sqlserver和windows license的影响，sqlserver价格会比mysql高出近50%，一个2g mem+50gb disk的mysql一年的价格是：4480 rmb；一个2g mem+50gb disk的sqlserver一年的价格是：6420 rmb;
b.sqlserver处于闭源状态，在出现异常疑难问题排查的时候，往往需要借助微软官方的帮助，同时rds如果想在sqlserver上面定制出一些自己特色的功能时候，往往其封闭的协议让rds望而退步；相对于mysql的开源而言，rds依托了阿里强大的mysql内核开发和运维经验，能够很好的定制出一些rds自己的特色功能，在出现疑难问题上能够迅速的进行debug排查。
在阿里的电商云平台聚石塔，已经有大量的isv，商家正在改造自己的后台系统从sqlserver转向的mysql，你还在犹豫什么？
2)提高性能和可扩展性
. 提高了默认线程并发数(innodb_thread_concurrency)
. 后台输入/输出线程控制（innodb_read_io_threads、innodb_write_io_threads）
. 适应性散列索引(hash index)控制，用户可以关闭适应性散列功能
. 插入缓冲（insert buffering）控制，用户可以关闭innodb的插入缓冲功能
. 恢复组提交（restored group commit）
. 多个回滚段（multiple rollback segments）,之前的innodb版本最大能处理1023个并发处理操作，现在mysql5.5可以处理高达128k的并发事物，
. 改善了日志系统互斥和单独刷新（flush）列表互斥
. 改善清除程序进度，在mysql5.5中清楚操作线程是独立的线程，并支持并发，可以使用innodb_purge_treads配置。
3)提高实用性
. 半同步复制（semi-synchronous replication）
. 复制heartbeat
. 中继日志自动恢复（automatic relay log recovery）
4)提高易管理性和效率
. 建立快速索引（faster index creation）
. 高效的数据压缩（efficient data compression）
. 为大物件和可变长度列提供高效存储
. 增加了information_schema表，新的表提供了与innodb压缩和事务处理锁定有关的具体信息
. 支持utf8mb4字符集
5)提高可用性
. 新的表/索引分区选项。mysql5.5将表和索引rang和list分区范围扩展到了非整数列和日期，并增加了在多个列上分区的能力。
6)改善检测和诊断
. mysql5.5引入了一种新的性能架构(performancn_shema,p_s),用于监控mysql监控服务器运行时的性能。
有了这么多功能的改进提升，还有什么理由不使用5.5.
在rds的工单问题中，空间问题的咨询应该可以算得上是top 5，当rds的实际使用空间超过了购买的空间后，实例就会被锁定了，这样就会导致应用无法再写入，更新数据，造成应用的报错，在rds的控制台中可以设定空间的报警阀值，当实例空间到达报警阀值后用户就会收到报警短信，这个时候用户则需要对判断当前的空间增长是否合理，如果合理的增长则需要对实例的进行弹性升级，如果增长不合理，则需要进行快速的判断。所以在这里我们就需要了解rds的空间组成到底包括了哪些？
rds的实例空间主要包括了：数据文件,日志文件，其他文件（包括系统文件，临时文件）
下面我们来详细介绍一下这些文件组成：
1. 数据文件：顾名思义该文件空间则是指的存放用数据的文件，对应到数据库中就是一张张的表，表的组成主要包括：数据和索引两类，所以当你看到你的数据文件占用实例的空间非常多的时候，你需要看一下到底是哪一张表占用了我的空间，rds在控制台中提供了：性能优化–>大表优化的性能报表，用户则可以在这里找到系统中占用最大的文件。但是凡事需要未雨绸缪，我们在设计应用的时候，就要考虑未来数据的增长趋势（数据的生命保留周期）,合理的设计数据的存放位置(存放文件or数据库),存储格式（数据类型，字段大小），存放方式（存储引擎选择，分区还是分表）。下图的案例案例中，数据空间占用了实例大量的空间，用户可以通过排查数据库中到底是哪一张表占用导致的（可以参考性能优化–>大表优化）
2. 日志文件：rds采用的主备m-m的高可用架构，其主备之间的数据同步依靠日志的方式，mysql：binlog，sqlserver：transaction log；同时rds支持将实例恢复到任何一个时间点，这个功能需要依靠运用备份和日志。为了减少日志空间对用户的空间的占用，rds mysql会定时的把日志备份到oss中，然后再将其清除，这样用户需要下载rds日志的时候可以从oss中获取；对于sqlserver，rds对定期的对数据库进行备份，然后将事务日志进行回收。当日志空间出现异常的时候，如下图，由于应用写入数据压力过大，导致binlog日志增加的速度大于了rds上传到oss的速度，造成了binlog日志增长迅猛，这时候需要用户对数据库的update，insert，delete进行优化，减小对数据库的变更操作：
3. 其他文件：
a.系统文件，每个数据库在安装的时候会初始化一些系统文件，这些系统文件是数据库正常运行的前提，mysql：ibdata1，ib_logfile0，sqlserver：msdblog，master.mdf，下面的这幅图反映了rds“其他文件”占用达到了非常多的问题，可以参考blog：ibdata1文件持续增加的问题定位
b.临时文件：通常可以理解为数据库做一个大的操作，由于内存不足，数据库需要将内存中的文件 写到磁盘上，这样则有可能导致临时文件写的非常大，通常出现这种情况的时候，数据库在做大 的排序操作（order by，group by），由于内存不足，需要将数据刷写到临时文件中，下图的案 例中，由于数据库中一条order by的语句频繁的执行，但是排序的sql没有索引，导致了临时文件 的频繁写操作：
ps.rds已经计划在idb中集成实例的空间诊断这个功能，帮助用户分析实例空间的使用，诊断问题的根源。
不同的rds实例规格提供了不同的性能指标，可以参考rds不同规格的测试报告。如何选择rds的规格，由于该选项会直接关系你的应用是否在rds上正常的运作起来，同时还关系成本的问题，所以深刻的理解这些参数，有助于你更好的使用rds，更低成本的使用rds。下面来分析一下rds规格中这3个关键指标：
1. 内存（mem）：内存是实例的核心指标之一，比如2400m mem内存的实例，内存参数大小配置在实例的参数文件中，限定了实例能够使用的内存大小为2400m。由于内存的访问速度远远大于磁盘，所以通常情况下，内存中缓存的数据越多，数据库的响应就越快；如果内存较小，当数据超过一定量后，就会被刷新到磁盘上，如果新的请求再次访问该数据，就要从磁盘上把它从磁盘中读取进内存，消耗磁盘io，这个时候数据库响应就会变慢。
2. iops:刚才提到数据从磁盘读取到内存，或者数据从内存写到磁盘都需要消耗io，而磁盘的io能力是有一定，比如新1型提供的iops为150个，也就是每秒能够提供150次的随机磁盘io操作，所以如果用户的数据量很大，内存很小，而写入，更新，删除，查询的压力很大，由于iops的限制，对于数据库来说就是一条sql需要执行很长的时间才能返回结果，对于应用来说就会造成整体响应的变慢；
3. 连接数：连接数是数据库中的一个概念，在rds中的连接数是指用户最多能够创建多少个连接。用户的连接数使用的多少取决于用户的连接类型，例如用户使用了连接池管理连接的长连接应用（如java类应用），在连接池中配置的最大连接数为100，那么在rds中看到的连接数应该为：app服务器×100；对于短连接的应用而言（如php应用，c/s结构的应用），一个请求到到数据库，就会产生一个连接，当请求完毕后就会释放连接。当用户使用的连接数超过了实例规定的连接数后，rds会直接抛错给应用，mysql：too many connections，sqlserver：logon failed for login ‘u_xxxx’ due to trigger execution.
可以看到上面的3个核心指标都能够直接影响用户使用，下图展示了不同规格能够达到的qps指标，该测试报告采用标准的sysbench oltp（读写混合）测试模型，可以作为每种实例规格的吞吐能力的参考，用户可以根据自己的业务压力来选择合适的实例规格：
rds的集群主要分布在杭州和青岛两个地域，用户往往采用slb+ecs+rds的架构，所以保持着三者在同一个地域就可以了，杭州到青岛的网络访问延迟大概在20ms左右，所以应当避免跨地域的访问情况。