本文作者：玄慚
2016年天貓雙11購物狂歡節已經完美落下帷幕，千億成交的背後，作為整個天貓商家背景資料庫的基石，aliclouddb是如何保障在零點洪峰來臨時候穩定、安全和順暢？如此龐大規模的資料庫執行個體叢集又是怎樣一步步成長起來的？aliclouddb團隊核心老司機玄慚，為你帶來，雙11是這樣用雲的姿勢....
多數使用者在雙11到來之前都會進行彈性擴容，常見的彈性擴容分為兩類：本機升降級和跨機升降級。例如現在有一個6g/6c的rds資料庫想要更新到12g/12c，如果本機資源足夠，則可以在本機完成升降級，無需遷移到其他機器上。雲資料庫預設是主備架構，本機更新時資源系統首先判斷更新是否可以在本機完成，工作原理如上圖所示：首先更新rds備庫；然後重新開機備庫；之後進行主備切換，再修改重新開機原主庫。
将本地更新變成一次主備切換，進而避免了重新開機主庫的操作。這裡需要注意的坑是：如果主備有延遲，那麼主備切換不會進行，更新任務也會被block。
另一種彈性擴容的方式是：跨機升降級。當本機資源不足以支撐更新所需要的資源的時候，需要将執行個體配置設定到另外一台機器上。是以跨機更新需要使用資料庫最近一次的備份和日志實時同步到新的主機上，保證新執行個體和舊執行個體的資料是完全一緻的。
而這裡需要注意的坑是：如果曆史備份集較大或原主庫壓力較大時，會導緻跨機遷移時間較長。
彈性擴容最佳實踐可以總結為以下四點：
1. 如果更新很長時間也沒有完成，可能發生了跨機遷移或者主備存在延遲。
2. 可用區遷移、資料庫版本更新耗時通常較長，是因為兩者遷移都會發生跨機遷移。
3. 空間更新非常快，這是因為空間更新無需重新開機、遷移資料庫，對業務也不會造成影響。
4. 彈性擴容時間的選擇，建議在業務低峰期進行彈性擴容。
在雲資料庫中，通路鍊路分為兩種模式：高安全通路鍊路和标準通路鍊路。在圖上流程圖的右側，rds在資料庫的前面增加了一層代理層，所有請求在代理層都被解析，在解析過程中添加了sql攔截規則，進而可以防止sql注入的攻擊。此外，高安全通路鍊路可以防止90%的連接配接閃斷；并支援内外網位址同時通路；對短連接配接應用有緩沖防護作用。需要注意的是高安全通路鍊路較标準鍊路增加了5%左右的響應時間。
标準通路鍊路與高安全通路鍊路相比，缺少了代理層，進而失去了連接配接保持、sql攔截以及内外網同時通路的能力；但相對于高安全通路鍊路響應時間會減少。
是以，通路鍊路最佳實踐可以總結為以下幾點：
1. 建議使用高安全通路模式，特别是短連接配接應用，高安全通路模式具有緩沖短連接配接對資料庫沖擊的效果。
2. 在标準通路鍊路切換到高安全通路鍊路時，切換過程最多會有30秒不可通路。
3. 如果ecs使用vpc，那麼資料庫隻能選擇高安全通路鍊路。
4. 通路鍊路上需要注意應用不要使用ip來通路資料庫，避免由于ip變化導緻故障。
3. 架構設計
架構設計就像我們修建一幢堅固的房子一樣，需要有整體的布局設計，同時在細節上材料的選擇以及施工品質的保障也同樣重要。在曆年的雙11中，由于業務流量的突增，那些平時沒有暴露出來的問題往往在這個時候爆發出來，是以我們要把資料庫這塊地基打好，細節上做好，架構設計就需要我們在這些上下功夫。
讀寫分離是常見的架構設計手段。rds支援隻讀節點，主庫主要承擔寫和實時性要求高操作，一些複雜的分析計算業務操作最好不要放在主庫上執行，而是選擇放在隻讀節點運算。使用讀寫分離架構時，首先資料庫版本需要更新到mysql5.6版本；同時目前rds最多隻支援五個隻讀節點。在讀寫分離時，延時是我們必須關注的重點，目前rds上通過源碼改進并行複制，提升複制性能，降低了主庫與備庫之間資料同步的延遲。
正如上圖的壓測結果顯示，5.6版本較5.5版本，在性能上有很大的提升。目前，rds隻有5.6版本支援隻讀執行個體，應用可以做讀寫分離；支援線上添加字段、索引和重建資料表，應用不再被阻塞。
引擎選擇是資料庫設計中很基礎的一點，這裡重點介紹下tokudb引擎。日志型應用的特性是：寫操作很高、讀操作相對較少。tokudb引擎壓縮比innodb引擎高出5~7倍，适合寫多讀少的應用；同時，tokudb引擎online ddl速度較快，适合表很大需要經常ddl操作的應用。同樣，tokudb引擎缺點也十分明顯，它會增加響應時間；同時online ddl對大字段不适用。
這裡需要注意一點的是：在5.5版本以後innodb 引擎已經是mysql的預設引擎，建議将myisam引擎轉換為innodb引擎，會避免很多問題的發生。
對于大字段，資料庫的更新寫入壓力過大，update、insert、delete會導緻binlog日志急劇增加，導緻執行個體磁盤報警。是以在資料庫設計時，要注意規避大字段引起的問題。常見的大字段有varchar（8000）、text、blob、clob（sqlserver/mysql），使用時建議将大字段拆分出主表或者存入到其他存儲系統中。
字段類型也是常見的問題之一。如上圖所示案例中表的user_id是varchar（64），但通路sql傳入的是數值類型，這就會導緻隐式轉換發生，進而導緻索引無效，可以使用explain 檢視是否使用到索引。是以，在設計開發階段，就要避免資料庫字段定義與應用程式參數定義不一緻的情況。
字段大小同樣會對資料庫性能造成影響。字段長度超過索引允許的最大長度會導緻索引字段被截斷；同時，過長的字段定義會消耗大量的排序記憶體以及臨時表空間。
索引設計也是大家經常犯錯的一個點，在曆年雙11保障中，索引出現的問題最多。這裡，重點講解單條sql的建立索引思路：
select person_role_id from moive where movie_id=1000 and role_id=1 order by nr_role desc;
對于這條sql語句，首先需要評估參與運算的結果集範圍，在該語句中建立movie_id和role_id的組合索引；第二步，考慮參與排序字段，在該語句中，排序用到的是nr_role，是以需要将其添加到索引中。大部分情況下，經過前兩步，就已經完成了索引的建立。
有時候，還需要考慮第三步：覆寫索引，在索引中添加需要查找的字段，無需回表，以期達到優化目的，在該例中将person_role_id添加到索引中。
常見的索引誤區包括：
• 對sql語句的每個查詢條件字段建立一個單列索引，mysql隻能使用其一個索引；
• 對sql語句的所有查詢字段建立組合索引，導緻索引遠大于資料，同時性能低下；
• 小表不建立索引。
4. 高可用配置
rds本身是一個主備的高可用架構，當主庫down後，會快速切換到備庫。在高可用架構中很重要的一點是資料同步，保障主備資料一緻不丢失。常見的高可用配置包括：
• 單可用區：主備都在統一個可用區内，可以實作主備之間的快速切換；
• binlog同步：采取異步和半同步的方式保障主備的資料一緻；
• binlog刷寫：根據應用特點設定安全模式或者高性能模式；
• 事務送出：預設采用最高安全模式。
此外，為了保障服務高可用，也可以采用多可用區配置，即主備在不同可用區，此時，應用同樣需要多可用區部署。此時需要注意binlog在主備的同步模式，通常這種情況下開啟半同步模式跨可用區通路，可能導緻寫入性能下降。
另外，還有一種跨資料中心的災備方案，在曆年的雙11中，已經有很多使用者實施過這樣的方案，你可以選擇在兩個不同的資料中心部署資料庫和應用，比如在杭州和上海兩個地區部署，兩個資料中心的資料同步采用dts，以保證一個資料中心挂掉後，另外一個資料中心能夠接管起來。
當性能問題出現時，例如上圖所示資料庫的qps高達2w+，這時候如何進行優化？首先我們需要明确導緻qps過高的原因，可以檢視sql運作報告，對一段時間内的sql語句進行歸類排序，這樣就知道了資料庫中是那些sql導緻qps提升的，然後針對這些sql進行分析，對應地給出解決方案，判斷調用是否合理，是否添加緩存等。性能優化中，慢日志也是需要重點關注的點。通過檢視慢日志運作報告，分析這些慢sql産生的原因：是否缺少索引、字段設計存在問題等等，在雙11之前優化掉，避免雙11高峰來臨的時候引發雪崩。
在rds中，大部分參數是已經經過調優的，是以很多參數是不需要再去調整的。但是使用者可以根據應用場景的不同選擇合适的參數，這裡重點看下rds新增的四個參數優化：
• rds_max_tmp_disk_space：控制mysql能夠使用的臨時檔案的大小，适用于一個sql就消耗掉整個資料庫的磁盤空間；
• tokudb_buffer_pool_ratio：控制tokudb引擎能夠使用的buffer記憶體大小，适用于選擇了tokudb作為存儲引擎的場景；
• max_statement_time：控制單個sql語句的最長執行時間，适用于控制資料庫中的慢sql數量；
• rds_threads_running_high_watermark：控制mysql并發的查詢數目，常用于秒殺場景的業務；
除此以外，阿裡雲的異地災備的産品化也非常值得分享。從2015年起，rds為天貓的商家背景資料庫提供了異地災備的功能。當主機房出現較大的負載壓力、斷網、斷電等極端情況，rds可将商家的背景系統在30分鐘内切換至災備機房繼續運作，以保障總體可靠性，進一步確定平台大型品牌商家雙11期間背景系統安全、穩定。
還記得2012年一家天貓服務商和我說：“今年遇到了一群靠譜的人，在加上靠譜的技術，才能夠一起做靠譜的事情。”這句話一直激勵着我。我們也相信，能夠真正地幫到商家，是對這次參與雙11所有人的最大回報。
從上雲肩挑背扛到線上遷移，讓上雲不再成為難事；
從資源手工離散和下線到自動化擴容和收容，讓資源真正流動起來；
将診斷經驗沉澱為自動化診斷工具，讓診斷不再成為難事。
一幕又一幕，我們始終堅信隻有把雙11的經驗和能力産品化和工具化，利用雙11這樣極具挑戰的項目不斷錘煉我們的産品，才是真正長遠發展之計。