在去年雙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左右，是以應當避免跨地域的通路情況。