2.2 AliCloudDB--雙11商家后臺(tái)數(shù)據(jù)庫的基石

前言

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

?

1. 彈性擴(kuò)容

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

?

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

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

?

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

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

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

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

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

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

?

2. 訪問鏈路

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

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

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

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

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

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

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

?

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

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

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

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

引擎選擇是數(shù)據(jù)庫設(shè)計(jì)中很基礎(chǔ)的一點(diǎn)，這里重點(diǎn)介紹下Tokudb引擎。日志型應(yīng)用的特性是：寫操作很高、讀操作相對(duì)較少。Tokudb引擎壓縮比Innodb引擎高出5~7倍，適合寫多讀少的應(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ì)避免很多問題的發(fā)生。

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

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

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

索引設(shè)計(jì)也是大家經(jīng)常犯錯(cuò)的一個(gè)點(diǎn)，在歷年雙11保障中，索引出現(xià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語句，首先需要評(píng)估參與運(yùn)算的結(jié)果集范圍，在該語句中創(chuàng)建movie_id和role_id的組合索引；第二步，考慮參與排序字段，在該語句中，排序用到的是nr_role，因此需要將其添加到索引中。大部分情況下，經(jīng)過前兩步，就已經(jīng)完成了索引的創(chuàng)建。

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

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

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

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

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

[if !supportLists]

?

4. 高可用配置

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

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

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

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

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

[if !supportLists]

?

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

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

?

5. 性能優(yōu)化

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

?

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

在RDS中，大部分參數(shù)是已經(jīng)經(jīng)過調(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ù)庫的磁盤空間；

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

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

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

[if !supportLists]

?

除此以外，阿里云的異地災(zāi)備的產(chǎn)品化也非常值得分享。從2015年起，RDS為天貓的商家后臺(tái)數(shù)據(jù)庫提供了異地災(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. 未來，走出去傳承最佳實(shí)踐和保障經(jīng)驗(yàn)

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

???

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

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

將診斷經(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ì)。

轉(zhuǎn)載于:https://www.cnblogs.com/hujiapeng/p/6235847.html

總結(jié)

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

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