主流資料庫架構設計

一主多從，主從同步，讀寫分離資料庫架構

本質是對資料的全量複製冗餘，適用於讀多寫少的大部分業務場景，而且這種架構不僅適用於資料庫，其他IO場景也能使用。

1. 多個從庫提供讀服務，線性提升讀資料的效能。
2. 因為讀寫不在同一個庫上發生，就沒有讀寫鎖的存在，提升寫資料的效能，本質是擴充套件獨立的IO服務數量（裝置數）減少IO競爭。
3. 全量複製也增加了高可用。
   這裡可以延伸下，資料IO的共享，就會牽涉到併發吞吐能力，就會牽涉到競爭和鎖，就會影響效能。在這裡提供效能，就是通過水平擴充套件IO的能力方式之一。
   全量複製資料相比增量複製資料，增加了同步資料複雜性，但也更加提高了讀效能。

水平切分

1. 分庫優於分表，分表還是在一個資料庫檔案上分享IO，還是存在IO競爭；而且分庫能夠方便遷移到不同的資料庫伺服器上，擴充套件性更好。（第1點也是一主多從解決的痛點，第2點則是資料庫關於庫和表2種粒度的特性決定）

2. 分片的問題在於每片的部分資料之間不能緊耦合。（緊耦合帶來的問題就是需要請求2次增加了RT，還要做額外的聚合計算，這個也是資料庫特性導致，關聯式資料庫原生的關係計算只適用於一張庫的全量表上）

3. 水平切分最大的問題是針對非切分欄位的條件查詢需要遍歷所有庫，影響效能。
   資料庫查詢分為點查詢（通常使用者端發起）和 批量分頁查詢（通常運營端發起）。
   2.1 點查詢解決非切分欄位思路：

• 建立非切分欄位和切分欄位的索引表，先通過索引表查詢到對映的切分欄位，再定位相應庫的位置。索引表可以根據欄位資料量決定單庫還是分庫。缺點在於多一次查詢。
• 在非切分欄位上加工生成切分欄位（目前系統就是採用這種方式，但不是所有非切分欄位都適用）。
  2.2 批量分頁查詢解決思路：
  批量分頁查詢特點：訪問計算量大，返回資料量大，佔用資料庫效能高。另外，運營端查詢維度各式各樣，往往要建各種索引，影響使用者端寫資料的效能。
  避免低效批量查詢引發使用者端查詢抖動，另外建立備庫，運營端查詢對於資料實時性要求較低，可以通過訊息或者線下方式非同步同步資料，不影響熱點前端業務流程。
  如果資料量非常大，複製資料成本過高，關係型資料庫查詢效能無法滿足需求，可以考慮外接索引elasticSearch，或者大資料處理hive。

3. 水平切分解決了最大的痛點就是單庫容量的問題，同一主多從的線性提升讀效能基礎上，水平切分線性提升了寫的效能。（很好理解，因為獨立IO數增加了；但是因為不是全量資料，所以所謂的線性提升也僅僅是讀寫不同分片的資料場景，這點還是不如一主多從的讀。至於單機瓶頸是因為時代技術原因所限，和設計無關）

4. 常見的水平切分演算法有“範圍法”和“雜湊法”。
   範圍法優點：擴容簡單。
   範圍法缺點：切分欄位要滿足遞增；資料分佈不均勻，同時導致了請求分佈不均勻。
   雜湊法的優缺點和範圍法正好相反。
   4.1 雜湊法最佳實踐：基因法 （分庫基因 % 分庫庫數）
   在一對多場景下，一個批次對應多筆訂單。先通過批次號最後4個bit決定落地到哪個資料庫的批次表裡，此時分庫基因就是這4個bit。在生成訂單號的時候，先生成除最後4位的前幾位，將分庫基因加到最後4位bit，使用相同的切分演算法就能落到和批次表同一個資料庫裡了。
   上述場景必須先外部批次號生成，外部訂單號才能生成；反過來根據訂單號確定分庫基因有些麻煩。

垂直切分

熱點小欄位和長尾大欄位分開切分，保證資料庫快取能夠儲存更多的熱點資料，增減快取命中率。適用於特殊的業務表。