1. 增長

1.1. 在高速的業務環境中，流量可能逐年增長幾個數量級，環境會變得更加複雜，隨之而來的數據需求也會快速增加

1.2. 擴展Web伺服器

1.2.1. 在負載均衡的後端添加更多的伺服器節點，而這通常就是擴展We b伺服器的全部工作

2. 可擴展性

2.1. 系統支撐不斷增長的流量的能力

2.1.1. 可擴展性就是能夠通過增加資源來提升容量的能力

2.2. 一個系統擴展能力的好壞可以用成本和簡單性來衡量

2.3. 容量是一個和可擴展性相關的概念

2.3.1. 系統容量表示在一定時間內能夠完成的工作量

2.3.2. 容量可以簡單地被認為是處理負載的能力，從幾個不同的角度來考慮負載很有幫助

2.4. 系統的最大吞吐量並不等同於容量

2.4.1. 如果達到最大吞吐量，則性能會下降，響應時間會變得不可接受且非常不穩定

2.5. 即使系統性能不是很高也可以具備可擴展性

2.6. 數據量

2.6.1. 應用所能累積的大量數據是可擴展性最普遍的一個挑戰

2.6.2. 應用從不刪除任何數據

2.7. 用戶數

2.7.1. 當查詢依賴於用戶間的關係時（關係的數量可以用N*（N-1）/2來計算，這裡N表示用戶數

2.8. 用戶活躍度

2.8.1. 不是所有的用戶的活躍度都相同，並且用戶活躍度也不總是不變的

2.9. 相關數據集的大小

2.9.1. 社交網站經常會面臨由那些人氣很旺的用戶組或朋友很多的用戶所帶來的挑戰

2.10. 可擴展性的原則之一是避免節點之間的交叉訪問

2.11. 請專註於確定業務是讀限制的還是寫限制的

3. 擴展MySQL的理論思想

3.1. 優先使用更小的實例

3.1.1. 按功能、水平方式或兩者兼而有之來分割數據

3.1.2. 當故障發生時，實例越小，所造成的影響面也越小

3.2. 通過複製和自動寫故障切換來增強彈性

3.2.1. 在發生故障時，自動進行寫入故障切換，並管理拓撲更改和對資料庫節點的應用程式訪問，以使寫停機時間儘可能短

3.3. 通過半同步複製保證持久性

3.3.1. 相對於預設的非同步複製

4. 讀限制與寫限制工作負載

4.1. 工作負載

4.1.1. 系統能達到的QPS數

4.1.2. 是所有類型的查詢及其延遲的混合

4.2. 讀限制工作負載

4.2.1. 讀限制工作負載是指讀取（SELECT）總流量超過伺服器容量的工作負載

4.2.2. 單源主機

4.2.2.1. 增加更多應用節點可以擴展服務用戶請求的客戶端數

4.2.2.2. 最終會被單源資料庫主機的能力所限制，該資料庫主機將要負責響應所有的讀取請求

4.2.2.3. 高CPU使用率意味著伺服器正花費所有的時間處理查詢

4.2.2.4. CPU的使用率越高，查詢的延遲也會越長

4.2.3. 引入副本來擴展讀流量

4.3. 寫限制工作負載

4.3.1. 寫限制工作負載則超過了伺服器提供DML（INSERT、UPDATE、DELETE）操作的容量

4.3.2. 當寫入量成為瓶頸時，必須開始考慮使用拆分數據的方法，以便在單獨的子數據集上接受並行的寫入

4.3.3. 仔細檢查schema，確定是否存在讀需求增長比其他寫需求增長更快的表數據子集

5. 功能拆分

5.1. 基於業務中的“功能”來拆分數據是一項和業務背景強相關的任務，需要深入瞭解數據的用途

5.2. 指導原則

5.2.1. 不要根據工程團隊的組織架構進行拆分，它會經常變動

5.2.2. 根據業務功能來拆分表

5.2.3. 不要迴避處理數據中混雜了不同業務關係的問題，你不僅需要倡導數據分離，還需要倡導應用程式重構，並需要引入API來實現相互跨界的訪問

6. 用讀池擴展讀

6.1. 集群中的副本可用於多個目的

6.1.1. 副本是故障切換的候選對象

6.2. 並非所有的複製副本都在池中，這是一種防止不同的讀取工作負載相互影響的常見方法

6.3. 使用讀池時會有不止一臺服務讀請求的資料庫主機

6.4. 管理這些讀池的一種非常常見的方法是使用負載均衡器來提供虛擬IP

6.4.1. 該IP充當所有要訪問讀副本的流量的中介

6.4.2. 技術包括HAProxy、自用主機時的硬體負載均衡器，或在公共雲環境中運行時的網路負載均衡器

6.5. 在MySQL中，建議使用leastconn實現池節點之間的平衡

6.6. 服務發現是一個很好的選擇，它可以自動發現新的主機並將其加入池列表

6.7. 每個副本池至少還要有三個節點服務於特定應用

6.8. 讀池健康檢查

6.9. 選擇負載均衡器演算法

6.9.1. 隨機

6.9.1.1. 負載均衡器將每個請求定向到從可用伺服器池中隨機選擇的伺服器

6.9.2. 輪詢

6.9.2.1. 負載均衡器以重覆的順序向伺服器發送請求

6.9.3. 最少連接

6.9.3.1. 下一個連接指向擁有最少活躍連接的伺服器

6.9.4. 最快響應

6.9.4.1. 處理請求最快的伺服器接收下一個連接

6.9.5. 哈希

6.9.5.1. 負載均衡器對連接的源IP地址進行哈希處理，這會將地址映射到池中的一臺伺服器

6.9.6. 權重

6.9.6.1. 負載均衡器可以組合幾種演算法並添加權重

6.9.7. MySQL的最佳演算法取決於具體工作負載

6.9.7.1. 一定要考慮在特殊情況下和日常情況下會發生什麼

7. 排隊機制

7.1. 使用設計上傾向於一致性而不是可用性的數據存儲來擴展寫事務時，擴展應用程式層會變得複雜得多

8. 使用分片擴展寫

8.1. 分片意味著將數據切分成不同的、更小的資料庫集群

8.1.1. 可以同時在更多的源主機上執行更多的寫入操作

8.2. 功能分割（Functional partitioning）

8.2.1. 職責劃分

8.2.2. 將不同的節點用於不同的任務

8.3. 數據分片（Data sharding）

8.3.1. 當今擴展超大型MySQL應用程式最常見和最成功的方法

8.4. 只對需要分片的數據進行切分

8.4.1. 通常是數據集中增長非常大的部分

8.5. 切分方案

8.5.1. 目標是使最重要和最頻繁的查詢接觸到儘可能少的分片

8.6. 多個分片鍵

8.6.1. 複雜的數據模型使數據分片更加困難

8.7. 跨分片查詢

8.7.1. 主動緩存通常也是有必要的

8.7.2. 設計間歇性運行的清理程式

8.8. Vitess

8.8.1. Vitess是面向MySQL的一個資料庫集群系統

8.8.2. 一個用於運行資料庫層的穩定平臺，而不是一個臨時的解決方案

8.8.3. 測試並記錄向整個系統引入的延遲

8.8.4. 使用金絲雀部署模型

8.8.5. 特性

8.8.5.1. 支持水平分片，包括數據分片

8.8.5.2. 拓撲結構管理

8.8.5.3. 源節點故障切換管理

8.8.5.4. schema變更管理

8.8.5.5. 連接池

8.8.5.6. 查詢重寫

8.8.6. 組件

8.8.6.1. Vitess pod

8.8.6.1.1. 對一組資料庫和Vitess相關部件的通用封裝

8.8.6.2. VTGate

8.8.6.2.1. 為應用程式與操作員控制資料庫實例訪問提供的服務

8.8.6.3. VTTablet

8.8.6.3.1. 在Vitess管理的每個資料庫實例上運行的代理

8.8.6.4. Topology

8.8.6.4.1. 在給定的pod中保存由Vitess管理的資料庫實例清單以及相應的信息

8.8.6.4.2. 元數據存儲

8.8.6.5. vtctl

8.8.6.5.1. 對Vitess pod進行操作更改的命令行工具

8.8.6.6. vtctld

8.8.6.6.1. 用來進行相同管理操作的圖形化界面

8.9. ProxySQL

8.9.1. René Cannaò

8.9.1.1. MySQL的長期貢獻者

8.9.2. 專門為MySQL協議編寫的，通過通用公共許可證（GPL）發佈

8.9.3. 提供了一個易於部署的抽象，比HAProxy更複雜，但在基礎設施和複雜性方面的前期投入較少

8.9.4. 可以使用ProxySQL作為任何應用程式代碼和MySQL實例的中間層

8.9.5. 一個很好的輕量級中間層，而且是分片感知的，還可以相應地路由應用程式連接

8.9.6. 按用戶分片

8.9.7. 按schema分片