[[175723]]

對不少商家而言，雙 11 銷量往往是平時的N倍。

云數(shù)據(jù)庫如何從容應(yīng)對雙 11 當日的流量高峰?

今天，特別邀請到 ApsaraDB 團隊的大牛級人物玄慚和大家分享，結(jié)合歷年雙十一活動中云數(shù)據(jù)庫保障經(jīng)驗，從彈性擴容、訪問鏈路、架構(gòu)設(shè)計、高可用配置、參數(shù)優(yōu)化等五個方面詳解講解云數(shù)據(jù)庫大流量峰值保障的最佳實踐。

玄慚被譽為雙 11 護航老司機。過去五年，他一直負責(zé)天貓雙 11 項目的數(shù)據(jù)庫運維，0 故障，0 丟單。

1、彈性擴容的兩種方式

多數(shù)用戶在雙十一到來之前都會進行彈性擴容。

常見的彈性擴容分為兩類：本機升降級和跨機升降級。

本機升降級的話，比較簡單。舉個栗子，一個 6G/6C 的 RDS 數(shù)據(jù)庫想要升級到 12G/12C，如果本機資源足夠，則可以在本機完成升降級，無需遷移到其他機器上。 

另一種彈性擴容的方式是：跨機升降級。

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

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

那些老司機踩過的坑：

• 如果升級很長時間也沒有完成，可能發(fā)生了跨機遷移或者主備存在延遲。
• 可用區(qū)遷移、數(shù)據(jù)庫版本升級耗時通常較長，是因為兩者遷移都會發(fā)生跨機遷移。
• 空間升級非常快，這是因為空間升級無需重啟、遷移數(shù)據(jù)庫，對業(yè)務(wù)也不會造成影響。
• 彈性擴容時間的選擇，建議在業(yè)務(wù)低峰期進行彈性擴容。

2、雙 11 期間，如何讓訪問鏈路更安全?

在云數(shù)據(jù)庫中，訪問鏈路分為兩種模式：高安全訪問鏈路和標準訪問鏈路。

雙 11 期間，流量高的網(wǎng)站也會成為黑客的重點關(guān)注對象。所以建議商家提前采用高安全訪問鏈路。 

高安全訪問鏈路在數(shù)據(jù)庫的前面增加了一層代理層，所有請求在代理層都被解析，在解析過程中添加了 SQL 攔截規(guī)則，進而可以防止 SQL 注入的攻擊。

此外，高安全訪問鏈路可以防止 90% 的連接閃斷;并支持內(nèi)外網(wǎng)地址同時訪問;對短連接應(yīng)用具有緩沖防護作用。

需要注意的是高安全訪問鏈路較標準鏈路增加了 5% 左右的響應(yīng)時間。

那些老司機踩過的坑：

• 建議使用高安全訪問模式，特別是短連接應(yīng)用，高安全訪問模式具有緩沖短連接對數(shù)據(jù)庫沖擊的效果。
• 在標準訪問鏈路切換到高安全訪問鏈路時，切換過程最多會有30秒不可訪問。
• 如果ECS使用VPC，那么數(shù)據(jù)庫只能選擇高安全訪問鏈路。
• 訪問鏈路上需要注意應(yīng)用不要使用IP來訪問數(shù)據(jù)庫，避免由于IP變化導(dǎo)致故障。

3、雙 11 的架構(gòu)如何設(shè)計?

在歷年的雙 11 中，由于業(yè)務(wù)流量的突增，那些平時沒有暴露出來的問題往往在這個時候爆發(fā)出來，所以我們要把數(shù)據(jù)庫這塊地基打好，細節(jié)上做好，架構(gòu)設(shè)計就需要我們在這些上下功夫。 

讀寫分離是常見的架構(gòu)設(shè)計手段。

RDS 支持只讀節(jié)點，主庫主要承擔(dān)寫和實時性要求高操作，一些復(fù)雜的分析計算業(yè)務(wù)操作最好不要放在主庫上執(zhí)行，而是選擇放在只讀節(jié)點運算。

使用讀寫分離架構(gòu)時，首先數(shù)據(jù)庫版本需要升級到 MySQL 5.6 版本;同時目前 RDS 最多可以支持到五個只讀節(jié)點。

在讀寫分離時，延時是我們必須關(guān)注的重點，目前 RDS 上通過源碼改進并行復(fù)制，提升復(fù)制性能，降低了主庫與備庫之間數(shù)據(jù)同步的延遲。

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

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

字段類型也是常見的問題之一。在設(shè)計開發(fā)階段，就要避免數(shù)據(jù)庫字段定義與應(yīng)用程序參數(shù)定義不一致的情況。

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

索引設(shè)計也是大家經(jīng)常犯錯的一個點，在歷年雙十一保障中，索引出現(xiàn)的問題最多。

這里，重點講解單條SQL的創(chuàng)建索引思路，常見的索引誤區(qū)包括但不限于：

• 對SQL語句的每個查詢條件字段建立一個單列索引，MySQL 只能使用其一個索引;
• 對SQL語句的所有查詢字段建立組合索引，導(dǎo)致索引遠大于數(shù)據(jù)，同時性能低下;
• 小表不建立索引。

4、雙 11 的高可用配置如何搞?

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

常見的高可用配置包括：

• 單可用區(qū)：主備都在同一個可用區(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ù)中心能夠接管起來。

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

5、針對雙 11，如何做參數(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ù);

看完了“玄慚大師”的經(jīng)驗分享， 那么，你對大流量峰值下保障云數(shù)據(jù)庫有什么好的經(jīng)驗可以分享嗎?