雲計算之路-阿里雲上：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計算流量時也會去除一部分峯值。

更多從用戶角度考慮，不少問題就會迎刃而解，即便不能迎刃而解，折衷的方案也會減小用戶的痛處。雲計算作的不是高上大的技術，而是實實在在的服務。