「玄慚大師」談雙十一活動中雲數據庫保障經驗

一、彈性擴容的兩種方式

多數用戶在雙十一到來以前都會進行彈性擴容。常見的彈性擴容分爲兩類：本機升降級和跨機升降級。

本機升降級的話，比較簡單。舉個栗子，一個 6G/6C 的 RDS 數據庫想要升級到 12G/12C，若是本機資源足夠，則能夠在本機完成升降級，無需遷移到其餘機器上。

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

這裏須要注意的坑是：若是歷史備份集較大或原主庫壓力較大時，會致使跨機遷移時間較長。

那些老司機踩過的坑：

1. 若是升級很長時間也沒有完成，可能發生了跨機遷移或者主備存在延遲。
2. 可用區遷移、數據庫版本升級耗時一般較長，是由於二者遷移都會發生跨機遷移。
3. 空間升級很是快，這是由於空間升級無需重啓、遷移數據庫，對業務也不會形成影響。
4. 彈性擴容時間的選擇，建議在業務低峯期進行彈性擴容。 

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

在雲數據庫中，訪問鏈路分爲兩種模式：高安全訪問鏈路和標準訪問鏈路。雙 11 期間，流量高的網站也會成爲黑客的重點關注對象。因此建議商家提早採用高安全訪問鏈路。

高安全訪問鏈路在數據庫的前面增長了一層代理層，全部請求在代理層都被解析，在解析過程當中添加了 SQL 攔截規則，進而能夠防止 SQL 注入的攻擊。

此外，高安全訪問鏈路能夠防止 90% 的鏈接閃斷；並支持內外網地址同時訪問；對短鏈接應用具備緩衝防禦做用。
須要注意的是高安全訪問鏈路較標準鏈路增長了 5% 左右的響應時間。
那些老司機踩過的坑：

1. 建議使用高安全訪問模式，特別是短鏈接應用，高安全訪問模式具備緩衝短鏈接對數據庫衝擊的效果。
2. 在標準訪問鏈路切換到高安全訪問鏈路時，切換過程最多會有30秒不可訪問。
3. 若是ECS使用VPC，那麼數據庫只能選擇高安全訪問鏈路。
4. 訪問鏈路上須要注意應用不要使用IP來訪問數據庫，避免因爲IP變化致使故障。

三、雙 11 的架構如何設計？

在歷年的雙 11 中，因爲業務流量的突增，那些平時沒有暴露出來的問題每每在這個時候爆發出來，因此咱們要把數據庫這塊地基打好，細節上作好，架構設計就須要咱們在這些上下功夫。

讀寫分離是常見的架構設計手段。RDS 支持只讀節點，主庫主要承擔寫和實時性要求高操做，一些複雜的分析計算業務操做最好不要放在主庫上執行，而是選擇放在只讀節點運算。使用讀寫分離架構時，首先數據庫版本須要升級到 MySQL 5.6 版本；同時目前 RDS 最多能夠支持到五個只讀節點。在讀寫分離時，延時是咱們必須關注的重點，目前 RDS 上經過源碼改進並行複製，提高複製性能，下降了主庫與備庫之間數據同步的延遲。

引擎選擇是數據庫設計中很基礎的一點，這裏重點介紹下 Tokudb 引擎。日誌型應用的特性是：寫操做很高、讀操做相對較少。Tokudb 引擎壓縮比 Innodb 引擎高出 5~7 倍，適合寫多讀少的應用；同時，Tokudb 引擎 online ddl 速度較快，適合表很大須要常常 DDL 操做的應用。

對於大字段，數據庫的更新寫入壓力過大，update、insert、delete 會致使 binlog 日誌急劇增長，致使實例磁盤報警。所以在數據庫設計時，要注意規避大字段引發的問題。常見的大字段有 varchar（8000）、text、blob、clob（sqlserver/mysql），使用時建議將大字段拆分出主表或者存入到其餘存儲系統中。

字段類型也是常見的問題之一。在設計開發階段，就要避免數據庫字段定義與應用程序參數定義不一致的狀況。

字段大小一樣會對數據庫性能形成影響。字段長度超過索引容許的最大長度會致使索引字段被截斷；同時，過長的字段定義會消耗大量的排序內存以及臨時表空間。

索引設計也是你們常常犯錯的一個點，在歷年雙十一保障中，索引出現的問題最多。
這裏，重點講解單條SQL的建立索引思路，常見的索引誤區包括但不限於：

1. 對SQL語句的每一個查詢條件字段創建一個單列索引，MySQL 只能使用其一個索引；
2. 對SQL語句的全部查詢字段創建組合索引，致使索引遠大於數據，同時性能低下；
3. 小表不創建索引。

四、雙 11 的高可用配置如何搞？

RDS 自己是一個主備的高可用架構，當主庫 Down 後，會快速切換到備庫。在高可用架構中很重要的一點是數據同步，保障主備數據一致不丟失。

常見的高可用配置包括：

1. 單可用區：主備都在同一個可用區內，能夠實現主備之間的快速切換；
2. Binlog 同步：採起異步和半同步的方式保障主備的數據一致；
3. Binlog 刷寫：根據應用特色設置安全模式或者高性能模式；
4. 事務提交：默認採用最高安全模式。

此外，爲了保障服務高可用，也能夠採用多可用區配置，即主備在不一樣可用區，此時，應用一樣須要多可用區部署。須要注意 Binlog 在主備的同步模式，一般這種狀況下開啓半同步模式跨可用區訪問，可能致使寫入性能降低。
另外，還有一種跨數據中心的災備方案，在歷年的雙 11 中，已經有不少用戶實施過這樣的方案，你能夠選擇在兩個不一樣的數據中心部署數據庫和應用，好比在杭州和上海兩個地區部署，兩個數據中心的數據同步採用 DTS，以保證一個數據中心掛掉後，另一個數據中心可以接管起來。

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

五、針對雙 11，如何作參數優化？

在 RDS 中，大部分參數是已經通過調優的，所以不少參數是不須要再去調整的。
可是用戶能夠根據應用場景的不一樣選擇合適的參數，這裏重點看下 RDS 新增的四個參數優化：

1. rds_max_tmp_disk_space：控制 MySQL 可以使用的臨時文件的大小，適用於一個 SQL 語句就消耗掉整個數據庫的磁盤空間；
2. tokudb_buffer_pool_ratio：控制 TokuDB 引擎可以使用的 buffer 內存大小，適用於選擇了 tokudb 做爲存儲引擎的場景；
3. max_statement_time：控制單個 SQL 語句的最長執行時間，適用於控制數據庫中的慢 SQL 數量；
4. rds_threads_running_high_watermark：控制 MySQL 併發的查詢數目，經常使用於秒殺場景的業務；

看完了「玄慚大師」的經驗分享， 那麼，你對大流量峯值下保障雲數據庫有什麼好的經驗能夠分享嗎？

原文來自：https://linux.cn/article-7941-1.html

本文地址：http://www.linuxprobe.com/doble11-operation.html