52
“玄慚大師”談雙十一活動中雲數據庫保障經驗
對不少商家而言，雙 11 銷量往往是平時的N倍。
雲數據庫如何從容應對雙 11 當日的流量高峰？
今天，特別邀請到 ApsaraDB 團隊的大牛級人物玄慚和大家分享，結合曆年雙十一活動中雲數據庫保障經驗，從彈性擴容、訪問鏈路、架構設計、高可用配置、參數優化等五個方麵詳解講解雲數據庫大流量峰值保障的最佳實踐。
玄慚被譽為雙 11 護航老司機。過去五年，他一直負責天貓雙 11 項目的數據庫運維，0 故障，0 丟單。
1、彈性擴容的兩種方式
多數用戶在雙十一到來之前都會進行彈性擴容。
常見的彈性擴容分為兩類：本機升降級和跨機升降級。
本機升降級的話，比較簡單。舉個栗子，一個 6G/6C 的 RDS 數據庫想要升級到 12G/12C，如果本機資源足夠，則可以在本機完成升降級，無需遷移到其他機器上。
另一種彈性擴容的方式是：跨機升降級。
當本機資源不足以支撐升級所需要的資源的時候，需要將實例分配到另外一台機器上。所以跨機升級需要使用數據庫最近一次的備份和日誌實時同步到新的主機上，保證新實例和舊實例的數據是完全一致的。
這裏需要注意的坑是：如果曆史備份集較大或原主庫壓力較大時，會導致跨機遷移時間較長。
那些老司機踩過的坑：
- 如果升級很長時間也沒有完成，可能發生了跨機遷移或者主備存在延遲。
- 可用區遷移、數據庫版本升級耗時通常較長，是因為兩者遷移都會發生跨機遷移。
- 空間升級非常快，這是因為空間升級無需重啟、遷移數據庫，對業務也不會造成影響。
- 彈性擴容時間的選擇，建議在業務低峰期進行彈性擴容。
2、雙 11 期間，如何讓訪問鏈路更安全？
在雲數據庫中，訪問鏈路分為兩種模式：高安全訪問鏈路和標準訪問鏈路。
雙 11 期間，流量高的網站也會成為黑客的重點關注對象。所以建議商家提前采用高安全訪問鏈路。
高安全訪問鏈路在數據庫的前麵增加了一層代理層，所有請求在代理層都被解析，在解析過程中添加了 SQL 攔截規則，進而可以防止 SQL 注入的攻擊。
此外，高安全訪問鏈路可以防止 90% 的連接閃斷；並支持內外網地址同時訪問；對短連接應用具有緩衝防護作用。
需要注意的是高安全訪問鏈路較標準鏈路增加了 5% 左右的響應時間。
那些老司機踩過的坑：
- 建議使用高安全訪問模式，特別是短連接應用，高安全訪問模式具有緩衝短連接對數據庫衝擊的效果。
- 在標準訪問鏈路切換到高安全訪問鏈路時，切換過程最多會有30秒不可訪問。
- 如果ECS使用VPC，那麼數據庫隻能選擇高安全訪問鏈路。
- 訪問鏈路上需要注意應用不要使用IP來訪問數據庫，避免由於IP變化導致故障。
3、雙 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的創建索引思路，常見的索引誤區包括但不限於：
- 對SQL語句的每個查詢條件字段建立一個單列索引，MySQL 隻能使用其一個索引；
- 對SQL語句的所有查詢字段建立組合索引，導致索引遠大於數據，同時性能低下；
- 小表不建立索引。
4、雙 11 的高可用配置如何搞？
RDS 本身是一個主備的高可用架構，當主庫 Down 後，會快速切換到備庫。在高可用架構中很重要的一點是數據同步，保障主備數據一致不丟失。
常見的高可用配置包括：
- 單可用區：主備都在同一個可用區內，可以實現主備之間的快速切換；
- Binlog 同步：采取異步和半同步的方式保障主備的數據一致；
- Binlog 刷寫：根據應用特點設置安全模式或者高性能模式；
- 事務提交：默認采用最高安全模式。
此外，為了保障服務高可用，也可以采用多可用區配置，即主備在不同可用區，此時，應用同樣需要多可用區部署。需要注意 Binlog 在主備的同步模式，通常這種情況下開啟半同步模式跨可用區訪問，可能導致寫入性能下降。
另外，還有一種跨數據中心的災備方案，在曆年的雙 11 中，已經有很多用戶實施過這樣的方案，你可以選擇在兩個不同的數據中心部署數據庫和應用，比如在杭州和上海兩個地區部署，兩個數據中心的數據同步采用 DTS，以保證一個數據中心掛掉後，另外一個數據中心能夠接管起來。
此外，從 2015 年起，RDS 為天貓的商家後台數據庫提供了異地災備的功能。當主機房出現較大的負載壓力、斷網、斷電等極端情況，RDS 可將商家的後台係統在 30 分鍾內切換至災備機房繼續運行，以保障總體可靠性，進一步確保平台大型品牌商家雙 11 期間後台係統安全、穩定。
5、針對雙 11，如何做參數優化？
在 RDS 中，大部分參數是已經經過調優的，因此很多參數是不需要再去調整的。
但是用戶可以根據應用場景的不同選擇合適的參數，這裏重點看下 RDS 新增的四個參數優化：
-
rds_max_tmp_disk_space：控製 MySQL 能夠使用的臨時文件的大小，適用於一個 SQL 語句就消耗掉整個數據庫的磁盤空間； -
tokudb_buffer_pool_ratio：控製 TokuDB 引擎能夠使用的 buffer 內存大小，適用於選擇了 tokudb 作為存儲引擎的場景； -
max_statement_time：控製單個 SQL 語句的最長執行時間，適用於控製數據庫中的慢 SQL 數量； -
rds_threads_running_high_watermark：控製 MySQL 並發的查詢數目，常用於秒殺場景的業務；
原文發布時間為：2017-11-08
本文來自雲棲社區合作夥伴“Linux中國”
最後更新：2017-06-06 07:33:15