2.2 AliCloudDB--雙11商家后臺數據庫的基石

前言

2016年天貓雙11購物狂歡節已經完美落下帷幕，千億成交的背后，作為整個天貓商家后臺數據庫的基石，AliCloudDB是如何保障在零點洪峰來臨時候穩定、安全和順暢？如此龐大規模的數據庫實例集群又是怎樣一步步成長起來的？AliCloudDB團隊核心老司機玄慚，為你帶來，雙11是這樣用云的姿勢....

?

1. 彈性擴容

多數用戶在雙11到來之前都會進行彈性擴容，常見的彈性擴容分為兩類：本機升降級和跨機升降級。例如現在有一個6G/6C的RDS數據庫想要升級到12G/12C，如果本機資源足夠，則可以在本機完成升降級，無需遷移到其他機器上。云數據庫默認是主備架構，本機升級時資源系統首先判斷升級是否可以在本機完成，工作原理如上圖所示：首先升級RDS備庫；然后重啟備庫；之后進行主備切換，再修改重啟原主庫。

?

將本地升級變成一次主備切換，進而避免了重啟主庫的操作。這里需要注意的坑是：如果主備有延遲，那么主備切換不會進行，升級任務也會被block。

另一種彈性擴容的方式是：跨機升降級。當本機資源不足以支撐升級所需要的資源的時候，需要將實例分配到另外一臺機器上。所以跨機升級需要使用數據庫最近一次的備份和日志實時同步到新的主機上，保證新實例和舊實例的數據是完全一致的。

?

而這里需要注意的坑是：如果歷史備份集較大或原主庫壓力較大時，會導致跨機遷移時間較長。

彈性擴容最佳實踐可以總結為以下四點：

???? 1.?? 如果升級很長時間也沒有完成，可能發生了跨機遷移或者主備存在延遲。

???? 2.?? 可用區遷移、數據庫版本升級耗時通常較長，是因為兩者遷移都會發生跨機遷移。

???? 3.?? 空間升級非?？?#xff0c;這是因為空間升級無需重啟、遷移數據庫，對業務也不會造成影響。

???? 4.?? 彈性擴容時間的選擇，建議在業務低峰期進行彈性擴容。?

?

2. 訪問鏈路

在云數據庫中，訪問鏈路分為兩種模式：高安全訪問鏈路和標準訪問鏈路。在圖上流程圖的右側，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語句的所有查詢字段建立組合索引，導致索引遠大于數據，同時性能低下；

?????? ?????? 小表不建立索引。

[if !supportLists]

?

4. 高可用配置

RDS本身是一個主備的高可用架構，當主庫Down后，會快速切換到備庫。在高可用架構中很重要的一點是數據同步，保障主備數據一致不丟失。常見的高可用配置包括：

?????? ?????? 單可用區：主備都在統一個可用區內，可以實現主備之間的快速切換；

?????? ?????? Binlog同步：采取異步和半同步的方式保障主備的數據一致；

?????? ?????? Binlog刷寫：根據應用特點設置安全模式或者高性能模式；

?????? ?????? 事務提交：默認采用最高安全模式。

[if !supportLists]

?

此外，為了保障服務高可用，也可以采用多可用區配置，即主備在不同可用區，此時，應用同樣需要多可用區部署。此時需要注意Binlog在主備的同步模式，通常這種情況下開啟半同步模式跨可用區訪問，可能導致寫入性能下降。

另外，還有一種跨數據中心的災備方案，在歷年的雙11中，已經有很多用戶實施過這樣的方案，你可以選擇在兩個不同的數據中心部署數據庫和應用，比如在杭州和上海兩個地區部署，兩個數據中心的數據同步采用DTS，以保證一個數據中心掛掉后，另外一個數據中心能夠接管起來。?

?

5. 性能優化

當性能問題出現時，例如上圖所示數據庫的QPS高達2W+，這時候如何進行優化？首先我們需要明確導致QPS過高的原因，可以查看SQL運行報告，對一段時間內的SQL語句進行歸類排序，這樣就知道了數據庫中是那些SQL導致QPS提升的，然后針對這些SQL進行分析，對應地給出解決方案，判斷調用是否合理，是否添加緩存等。性能優化中，慢日志也是需要重點關注的點。通過查看慢日志運行報告，分析這些慢SQL產生的原因：是否缺少索引、字段設計存在問題等等，在雙11之前優化掉，避免雙11高峰來臨的時候引發雪崩。

?

6. 參數優化

在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并發的查詢數目，常用于秒殺場景的業務；

[if !supportLists]

?

除此以外，阿里云的異地災備的產品化也非常值得分享。從2015年起，RDS為天貓的商家后臺數據庫提供了異地災備的功能。當主機房出現較大的負載壓力、斷網、斷電等極端情況，RDS可將商家的后臺系統在30分鐘內切換至災備機房繼續運行，以保障總體可靠性，進一步確保平臺大型品牌商家雙11期間后臺系統安全、穩定。

?

7. 未來，走出去傳承最佳實踐和保障經驗

?還記得2012年一家天貓服務商和我說：“今年遇到了一群靠譜的人，在加上靠譜的技術，才能夠一起做靠譜的事情?！边@句話一直激勵著我。我們也相信，能夠真正地幫到商家，是對這次參與雙11所有人的最大回報。

???

從上云肩挑背扛到在線遷移，讓上云不再成為難事；

從資源手工離散和下線到自動化擴容和收容，讓資源真正流動起來；

將診斷經驗沉淀為自動化診斷工具，讓診斷不再成為難事。

?

一幕又一幕，我們始終堅信只有把雙11的經驗和能力產品化和工具化，利用雙11這樣極具挑戰的項目不斷錘煉我們的產品，才是真正長遠發展之計。

轉載于:https://www.cnblogs.com/hujiapeng/p/6235847.html

總結

以上是生活随笔為你收集整理的第二章 存储，2.2 AliCloudDB--双11商家后台数据库的基石(作者：玄惭)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。