1、背景（2023年左右）：
當時開始簡單的主從結構，隨著資料量增大、規模擴大、對高可用要求越來越高（之前從宕機兩小時到後來五分鐘），需要繼續拓展。
當時的資料庫拆分、分庫分表，資料庫伺服器達到4百台，只有乙個dba，每天的資料遷移、拓容很痛苦。
當時資料庫峰值能達到每秒2.5萬筆。當時**雙十一每秒峰值30萬筆。
2、為什麼使用mysql
社群（主要）、免費
3、mysql目前存在問題
1、單機效能
如果是小**，每天pv幾十萬、幾百萬，資料量不超過1個億，都不會問題。
資料量大、操作量大，就不行。
a、qps(讀/寫)
網上有專門對mysql資料庫效能測試的文章。
硬體在整個架構裡面是最廉價的。原則，如果硬體能解決問題，先公升級、增加硬體，不行再改系統架構。因為硬體是最快的，最省成本的。
b、響應時間
一般sql查詢要求小於50ms。
c、資料規模
單錶的規模不能超過2000萬，只能分表分庫。
原則，能用空間的去換時間的，盡量用空間。
4、iops是讀操作和寫操作的瓶頸
iops磁碟讀寫。
2、主從資料一致性
應用還是選擇主從複製。mysql半同步當時未發布正式版本，沒人敢去嘗試。
a、非同步複製
複製原理
binlog內部結構
複製協議
資料延遲判定
b、半同步複製
3、自動化擴容
按照一定規則擴容（1、hash取模拓容、範圍、日期等；2、水平、垂直拓容）
資料容量預估，提前預警（1、單錶容量預估（業務、現有機器配置、資料字段型別、資料量）；2、buffer pool容量、命中率；3、磁碟容量）
全量+增量自動化擴容（1、從庫提公升為新主庫（主從資料一致）；2、自動或者手動；3、擴融完畢通知**曾對前端透明）
4、主庫單點
主備策略（備庫只做資料同步，不做線上查詢）
資料補全（從主庫拉取binlog檔案進行資料補全）
單點切換（1、主庫宕機，切換新主庫，盡量儲存資料一致性（業務特性）；2、通知**層切換新的主庫對應用透明）
主庫就一台，資料庫峰值2.5萬筆每秒，扛不住。
（如何解決這些問題呢，思路引導，集群、分布式）
分布式系統跟集群的很大差別：集群系統幹的其實都是一件事情，分布式系統有分工的。
分布式系統兩種流：控制流、資料流。
架構設計原則：
1、空間換時間
2、硬體優先順序大於軟體
分布式資料庫
網路選課系統中分布式資料庫設計 何翠雙王巧雲張麗麗 摘要 關鍵字 選課 分布式 資料庫 distributed system of on line course choosing abstract key words course choosing distributed database 隨著學校...
分布式資料庫
1 背景 我們知道資料是乙個公司的命脈，隨著業務越做越大，資料量也會越來越大，計算也會越來越複雜，效能，可靠性，可擴充套件性的需求就會越來越強烈，這個時候乙個集中式的資料庫顯然已經滿足不了需求了。對於技術決策者來說有兩條路可以走，第一 按照現有的大型資料庫的解決方案，比如sql server clu...
分布式資料庫
一 分布式資料庫的出現的場景 網際網路 軟體國產化 o2o 五新 新零售 新製造，新金融 新資源 新技術 等主題接連提出來，並且在各個行業落地，給資料庫帶來了巨大機會，具體包含3個方向 1.遠超單機資料庫容量的資料儲存和訪問峰值 2.實時資料分析檢索 oltp兼顧olap 3.更高階別的容災需求。這...