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

本文作者：玄慚

前言

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

1. 彈性擴(kuò)容

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

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

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

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

彈性擴(kuò)容最佳實(shí)踐可以總結(jié)為以下四點(diǎn)：

???? 1.?? 如果升級(jí)很長(zhǎng)時(shí)間也沒(méi)有完成，可能發(fā)生了跨機(jī)遷移或者主備存在延遲。

???? 2.?? 可用區(qū)遷移、數(shù)據(jù)庫(kù)版本升級(jí)耗時(shí)通常較長(zhǎng)，是因?yàn)閮烧哌w移都會(huì)發(fā)生跨機(jī)遷移。

???? 3.?? 空間升級(jí)非?？?#xff0c;這是因?yàn)榭臻g升級(jí)無(wú)需重啟、遷移數(shù)據(jù)庫(kù)，對(duì)業(yè)務(wù)也不會(huì)造成影響。

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

2. 訪問(wèn)鏈路

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

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

因此，訪問(wèn)鏈路最佳實(shí)踐可以總結(jié)為以下幾點(diǎn)：

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

???? 2.?? 在標(biāo)準(zhǔn)訪問(wèn)鏈路切換到高安全訪問(wèn)鏈路時(shí)，切換過(guò)程最多會(huì)有30秒不可訪問(wèn)。

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

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

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

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

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

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

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

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

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

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

字段大小同樣會(huì)對(duì)數(shù)據(jù)庫(kù)性能造成影響。字段長(zhǎng)度超過(guò)索引允許的最大長(zhǎng)度會(huì)導(dǎo)致索引字段被截?cái)?#xff1b;同時(shí)，過(guò)長(zhǎng)的字段定義會(huì)消耗大量的排序內(nèi)存以及臨時(shí)表空間。

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

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

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

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

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

?????? ?????? 對(duì)SQL語(yǔ)句的每個(gè)查詢條件字段建立一個(gè)單列索引，MySQL只能使用其一個(gè)索引；

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

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

4. 高可用配置

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

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

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

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

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

?

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

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

5. 性能優(yōu)化

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

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

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

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

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

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

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

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

7. 未來(lái)，走出去傳承最佳實(shí)踐和保障經(jīng)驗(yàn)

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

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

從資源手工離散和下線到自動(dòng)化擴(kuò)容和收容，讓資源真正流動(dòng)起來(lái)；

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

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

總結(jié)

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

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