對不少商家而言，雙 11 銷量往往是平時的n倍。
雲資料庫如何從容應對雙 11 當日的流量高峰？
今天，特别邀請到 apsaradb 團隊的大牛級人物玄慚和大家分享，結合曆年雙十一活動中雲資料庫保障經驗，從彈性擴容、通路鍊路、架構設計、高可用配置、參數優化等五個方面詳解講解雲資料庫大流量峰值保障的最佳實踐。
玄慚被譽為雙 11 護航老司機。過去五年，他一直負責天貓雙 11 項目的資料庫運維，0 故障，0 丢單。
<a target="_blank"></a>
多數使用者在雙十一到來之前都會進行彈性擴容。
常見的彈性擴容分為兩類：本機升降級和跨機升降級。
本機升降級的話，比較簡單。舉個栗子，一個 6g/6c 的 rds 資料庫想要更新到 12g/12c，如果本機資源足夠，則可以在本機完成升降級，無需遷移到其他機器上。
另一種彈性擴容的方式是：跨機升降級。
當本機資源不足以支撐更新所需要的資源的時候，需要将執行個體配置設定到另外一台機器上。是以跨機更新需要使用資料庫最近一次的備份和日志實時同步到新的主機上，保證新執行個體和舊執行個體的資料是完全一緻的。
這裡需要注意的坑是：如果曆史備份集較大或原主庫壓力較大時，會導緻跨機遷移時間較長。
那些老司機踩過的坑：
如果更新很長時間也沒有完成，可能發生了跨機遷移或者主備存在延遲。
可用區遷移、資料庫版本更新耗時通常較長，是因為兩者遷移都會發生跨機遷移。
空間更新非常快，這是因為空間更新無需重新開機、遷移資料庫，對業務也不會造成影響。
彈性擴容時間的選擇，建議在業務低峰期進行彈性擴容。
在雲資料庫中，通路鍊路分為兩種模式：高安全通路鍊路和标準通路鍊路。
雙 11 期間，流量高的網站也會成為黑客的重點關注對象。是以建議商家提前采用高安全通路鍊路。
高安全通路鍊路在資料庫的前面增加了一層代理層，所有請求在代理層都被解析，在解析過程中添加了 sql 攔截規則，進而可以防止 sql 注入的攻擊。
此外，高安全通路鍊路可以防止 90% 的連接配接閃斷；并支援内外網位址同時通路；對短連接配接應用具有緩沖防護作用。
需要注意的是高安全通路鍊路較标準鍊路增加了 5% 左右的響應時間。
建議使用高安全通路模式，特别是短連接配接應用，高安全通路模式具有緩沖短連接配接對資料庫沖擊的效果。
在标準通路鍊路切換到高安全通路鍊路時，切換過程最多會有30秒不可通路。
如果ecs使用vpc，那麼資料庫隻能選擇高安全通路鍊路。
通路鍊路上需要注意應用不要使用ip來通路資料庫，避免由于ip變化導緻故障。
在曆年的雙 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語句的所有查詢字段建立組合索引，導緻索引遠大于資料，同時性能低下；
小表不建立索引。
rds 本身是一個主備的高可用架構，當主庫 down 後，會快速切換到備庫。在高可用架構中很重要的一點是資料同步，保障主備資料一緻不丢失。
常見的高可用配置包括：
單可用區：主備都在同一個可用區内，可以實作主備之間的快速切換；
binlog 同步：采取異步和半同步的方式保障主備的資料一緻；
binlog 刷寫：根據應用特點設定安全模式或者高性能模式；
事務送出：預設采用最高安全模式。
此外，為了保障服務高可用，也可以采用多可用區配置，即主備在不同可用區，此時，應用同樣需要多可用區部署。需要注意 binlog 在主備的同步模式，通常這種情況下開啟半同步模式跨可用區通路，可能導緻寫入性能下降。
另外，還有一種跨資料中心的災備方案，在曆年的雙 11 中，已經有很多使用者實施過這樣的方案，你可以選擇在兩個不同的資料中心部署資料庫和應用，比如在杭州和上海兩個地區部署，兩個資料中心的資料同步采用 dts，以保證一個資料中心挂掉後，另外一個資料中心能夠接管起來。
此外，從 2015 年起，rds 為天貓的商家背景資料庫提供了異地災備的功能。當主機房出現較大的負載壓力、斷網、斷電等極端情況，rds 可将商家的背景系統在 30 分鐘内切換至災備機房繼續運作，以保障總體可靠性，進一步確定平台大型品牌商家雙 11 期間背景系統安全、穩定。
在 rds 中，大部分參數是已經經過調優的，是以很多參數是不需要再去調整的。
但是使用者可以根據應用場景的不同選擇合适的參數，這裡重點看下 rds 新增的四個參數優化：
<code>rds_max_tmp_disk_space</code>：控制 mysql 能夠使用的臨時檔案的大小，适用于一個 sql 語句就消耗掉整個資料庫的磁盤空間；
<code>tokudb_buffer_pool_ratio</code>：控制 tokudb 引擎能夠使用的 buffer 記憶體大小，适用于選擇了 tokudb 作為存儲引擎的場景；
<code>max_statement_time</code>：控制單個 sql 語句的最長執行時間，适用于控制資料庫中的慢 sql 數量；
<code>rds_threads_running_high_watermark</code>：控制 mysql 并發的查詢數目，常用于秒殺場景的業務；
原文釋出時間為：2017-11-08
本文來自雲栖社群合作夥伴“linux中國”