云计算之路-阿里云上：RDS用户的烦恼

这篇博文分享的是咱们使用阿里云RDS（关系型数据库服务）遇到的2个烦恼——让人无奈的资源争抢与缺乏弹性的限制策略。

昨天用2台临时磁盘的云服务器成功顶住了访问高峰，并且表现不错！相关背景见以前的博文：云计算之路-阿里云上：3月5日下午出现的异常状况。

云服务器的问题解决以后，却遭遇了RDS的2个问题。

第1个问题——资源争抢形成的RDS响应慢

问题表现于经过SQL Server Management Studio操做RDS实例频繁出现响应速度很慢的状况，有时鼠标点下去要等很长时间才有反应，甚至Management Studio标题栏会出现Not Responding的提示。

开始还觉得是咱们的RDS实例负载太高，可是当时这个实例的IOPS并不高（见下图），咱们购买的RDS实例的最大IOPS是4000。

后来在访问低峰操做，也是一样的问题。因而，咱们不得不怀疑是同1台物理机上的其余RDS实例惹的祸——抢占了更多计算资源。

提交工单以后，客服的说法也验证了咱们的怀疑——咱们的RDS实例所在的物理机压力比较大，今天通过RDS DBA的确认，的确存在资源争抢的问题。

针对这个问题，阿里云目前的解决方法是先将抢占资源的RDS实例移至其余负载低的物理机临时解决问题，而后考虑更有效的资源隔离方案。

虽然有效地解决资源隔离问题是云服务商面临的一个很大的挑战，可是从一个用户角度，若是不解决这个问题，真的很痛苦与无奈——本身再怎么努力优化性能也无济于事，只能天天祈祷同一艘服务器上的其余RDS实例安分守己。

第2个问题——阿里云RDS对数据库最大链接数的硬性限制

先看下面一张RDS实例数据库链接数的监控图：

咱们购买的RDS实例的最大链接数是800。如今工做日访问高峰会出现几回达到最大链接数的状况，咱们面临这样一个选择——要不要升级RDS？而升级规格也只有1个选择——最大链接数：1200。也就是说为了1周不超过10次的数据库链接数超过800的状况，咱们却要将RDS扩容40%，弹性扩展能力都去哪儿了？

若是咱们的应用程序的负载真的偶尔须要超过800的数据库链接，咱们进行升级也就罢了。可是，这些数据库链接其实是ADO.NET链接池保持着的链接，是为了更好的性能——新建数据库链接是不容忽视的开销，实际的活跃链接数没这么高。

因此，阿里云RDS把链接数做为衡量用户使用数据库服务器资源的一个硬性指标，咱们以为不合理。除了数据库链接数不表明活跃链接数外，一样是一次数据库链接，有的快如闪电，有的慢如蜗牛，资源消耗不是一个级别的。即便使用的是最低规格的RDS，只用了不多的数据库链接，可是若是SQL操做性能低下，也会占用不少资源。

在RDS规格中还有另一个硬性指标——IOPS，这个指标却是比链接数靠谱得多，至少反映了用户实际消耗的IO。固然，仅靠它判断资源消耗量也是不够的，还有内存、CPU，因此RDS规格中也有内存大小，但目前没有CPU的限制（也许这里偏偏就是资源争抢的主战场）。

因此，要判断一个用户实际消耗的数据库服务器的计算资源，须要结合多个因素综合考虑，而如今RDS最大的问题是——会彻底依据最大链接数这个单一指标进行强制限制，只要超过了最大链接数，就会拒绝后续的全部数据库链接——逼着用户赶忙升级。即便假设这样的限制有1万个不得已的理由，那也得从用户角度考虑，留必定的峰值余度，好比1天内能够超过最大链接数多少次，就是CDN计算流量时也会去除一部分峰值。

更多从用户角度考虑，不少问题就会迎刃而解，即便不能迎刃而解，折衷的方案也会减小用户的痛处。云计算作的不是高上大的技术，而是实实在在的服务。