這篇博文分享的是我們使用阿里雲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計算流量時也會去除一部分峰值。
更多從用戶角度考慮，很多問題就會迎刃而解，即使不能迎刃而解，折衷的方案也會減少用戶的痛處。雲計算做的不是高上大的技術，而是實實在在的服務。