選自《不一樣的技術(shù)創(chuàng)新——阿里巴巴2016雙11背后的技術(shù)》，全書目錄：https://yq.aliyun.com/articles/68637

本文作者：玄慚

前言

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

1. 彈性擴容

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

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

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

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

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

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

???? 2.?? 可用區(qū)遷移、數(shù)據(jù)庫版本升級耗時通常較長，是因為兩者遷移都會發(fā)生跨機遷移。

???? 3.?? 空間升級非常快，這是因為空間升級無需重啟、遷移數(shù)據(jù)庫，對業(yè)務(wù)也不會造成影響。

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

2. 訪問鏈路

在云數(shù)據(jù)庫中，訪問鏈路分為兩種模式：高安全訪問鏈路和標準訪問鏈路。在圖上流程圖的右側(cè)，RDS在數(shù)據(jù)庫的前面增加了一層代理層，所有請求在代理層都被解析，在解析過程中添加了SQL攔截規(guī)則，進而可以防止SQL注入的攻擊。此外，高安全訪問鏈路可以防止90%的連接閃斷；并支持內(nèi)外網(wǎng)地址同時訪問；對短連接應(yīng)用有緩沖防護作用。需要注意的是高安全訪問鏈路較標準鏈路增加了5%左右的響應(yīng)時間。

標準訪問鏈路與高安全訪問鏈路相比，缺少了代理層，進而失去了連接保持、SQL攔截以及內(nèi)外網(wǎng)同時訪問的能力；但相對于高安全訪問鏈路響應(yīng)時間會減少。

因此，訪問鏈路最佳實踐可以總結(jié)為以下幾點：

???? 1.?? 建議使用高安全訪問模式，特別是短連接應(yīng)用，高安全訪問模式具有緩沖短連接對數(shù)據(jù)庫沖擊的效果。

???? 2.?? 在標準訪問鏈路切換到高安全訪問鏈路時，切換過程最多會有30秒不可訪問。

???? 3.?? 如果ECS使用VPC，那么數(shù)據(jù)庫只能選擇高安全訪問鏈路。

???? 4.?? 訪問鏈路上需要注意應(yīng)用不要使用IP來訪問數(shù)據(jù)庫，避免由于IP變化導(dǎo)致故障。

?3. 架構(gòu)設(shè)計

架構(gòu)設(shè)計就像我們修建一幢堅固的房子一樣，需要有整體的布局設(shè)計，同時在細節(jié)上材料的選擇以及施工質(zhì)量的保障也同樣重要。在歷年的雙11中，由于業(yè)務(wù)流量的突增，那些平時沒有暴露出來的問題往往在這個時候爆發(fā)出來，所以我們要把數(shù)據(jù)庫這塊地基打好，細節(jié)上做好，架構(gòu)設(shè)計就需要我們在這些上下功夫。

讀寫分離是常見的架構(gòu)設(shè)計手段。RDS支持只讀節(jié)點，主庫主要承擔寫和實時性要求高操作，一些復(fù)雜的分析計算業(yè)務(wù)操作最好不要放在主庫上執(zhí)行，而是選擇放在只讀節(jié)點運算。使用讀寫分離架構(gòu)時，首先數(shù)據(jù)庫版本需要升級到MySQL5.6版本；同時目前RDS最多只支持五個只讀節(jié)點。在讀寫分離時，延時是我們必須關(guān)注的重點，目前RDS上通過源碼改進并行復(fù)制，提升復(fù)制性能，降低了主庫與備庫之間數(shù)據(jù)同步的延遲。

正如上圖的壓測結(jié)果顯示，5.6版本較5.5版本，在性能上有很大的提升。目前，RDS只有5.6版本支持只讀實例，應(yīng)用可以做讀寫分離；支持在線添加字段、索引和重建數(shù)據(jù)表，應(yīng)用不再被阻塞。

引擎選擇是數(shù)據(jù)庫設(shè)計中很基礎(chǔ)的一點，這里重點介紹下Tokudb引擎。日志型應(yīng)用的特性是：寫操作很高、讀操作相對較少。Tokudb引擎壓縮比Innodb引擎高出5~7倍，適合寫多讀少的應(yīng)用；同時，Tokudb引擎online ddl速度較快，適合表很大需要經(jīng)常DDL操作的應(yīng)用。同樣，Tokudb引擎缺點也十分明顯，它會增加響應(yīng)時間；同時online ddl對大字段不適用。

這里需要注意一點的是：在5.5版本以后innodb 引擎已經(jīng)是MySQL的默認引擎，建議將Myisam引擎轉(zhuǎn)換為innodb引擎，會避免很多問題的發(fā)生。

對于大字段，數(shù)據(jù)庫的更新寫入壓力過大，update、insert、delete會導(dǎo)致binlog日志急劇增加，導(dǎo)致實例磁盤報警。因此在數(shù)據(jù)庫設(shè)計時，要注意規(guī)避大字段引起的問題。常見的大字段有varchar（8000）、text、blob、clob（sqlserver/mysql），使用時建議將大字段拆分出主表或者存入到其他存儲系統(tǒng)中。

字段類型也是常見的問題之一。如上圖所示案例中表的user_ID是varchar（64），但訪問SQL傳入的是數(shù)值類型，這就會導(dǎo)致隱式轉(zhuǎn)換發(fā)生，進而導(dǎo)致索引無效，可以使用explain 查看是否使用到索引。因此，在設(shè)計開發(fā)階段，就要避免數(shù)據(jù)庫字段定義與應(yīng)用程序參數(shù)定義不一致的情況。

字段大小同樣會對數(shù)據(jù)庫性能造成影響。字段長度超過索引允許的最大長度會導(dǎo)致索引字段被截斷；同時，過長的字段定義會消耗大量的排序內(nèi)存以及臨時表空間。

索引設(shè)計也是大家經(jīng)常犯錯的一個點，在歷年雙11保障中，索引出現(xiàn)的問題最多。這里，重點講解單條SQL的創(chuàng)建索引思路：

select person_role_id from moive where movie_id=1000 and role_id=1 order by nr_role desc;

對于這條SQL語句，首先需要評估參與運算的結(jié)果集范圍，在該語句中創(chuàng)建movie_id和role_id的組合索引；第二步，考慮參與排序字段，在該語句中，排序用到的是nr_role，因此需要將其添加到索引中。大部分情況下，經(jīng)過前兩步，就已經(jīng)完成了索引的創(chuàng)建。

有時候，還需要考慮第三步：覆蓋索引，在索引中添加需要查找的字段，無需回表，以期達到優(yōu)化目的，在該例中將person_role_id添加到索引中。

常見的索引誤區(qū)包括：

?????? ?????? 對SQL語句的每個查詢條件字段建立一個單列索引，MySQL只能使用其一個索引；

?????? ?????? 對SQL語句的所有查詢字段建立組合索引，導(dǎo)致索引遠大于數(shù)據(jù)，同時性能低下；

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

4. 高可用配置

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

?????? ?????? 單可用區(qū)：主備都在統(tǒng)一個可用區(qū)內(nèi)，可以實現(xiàn)主備之間的快速切換；

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

?????? ?????? Binlog刷寫：根據(jù)應(yīng)用特點設(shè)置安全模式或者高性能模式；

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

?

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

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

5. 性能優(yōu)化

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

6. 參數(shù)優(yōu)化

?在RDS中，大部分參數(shù)是已經(jīng)經(jīng)過調(diào)優(yōu)的，因此很多參數(shù)是不需要再去調(diào)整的。但是用戶可以根據(jù)應(yīng)用場景的不同選擇合適的參數(shù)，這里重點看下RDS新增的四個參數(shù)優(yōu)化：

?????? ?????? rds_max_tmp_disk_space：控制MySQL能夠使用的臨時文件的大小，適用于一個SQL就消耗掉整個數(shù)據(jù)庫的磁盤空間；

?????? ?????? tokudb_buffer_pool_ratio：控制TokuDB引擎能夠使用的buffer內(nèi)存大小，適用于選擇了tokudb作為存儲引擎的場景；

?????? ?????? max_statement_time：控制單個SQL語句的最長執(zhí)行時間，適用于控制數(shù)據(jù)庫中的慢SQL數(shù)量；

?????? ?????? rds_threads_running_high_watermark：控制MySQL并發(fā)的查詢數(shù)目，常用于秒殺場景的業(yè)務(wù)；?

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

7. 未來，走出去傳承最佳實踐和保障經(jīng)驗

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

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

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

將診斷經(jīng)驗沉淀為自動化診斷工具，讓診斷不再成為難事。?

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

總結(jié)

以上是生活随笔為你收集整理的【双11背后的技术】AliCloudDB——双11商家后台数据库的基石的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。