數據訪問層

• 單機數據庫

數據庫減壓：

• 硬件升級（簡單粗暴、效果明顯、很快進入瓶頸，解決不了）
• 其餘三思路：
  • 優化應用（是否給了數據庫沒必要要的壓力）
  • 是否有其餘辦法減輕數據庫的壓力（引入緩存、搜索引擎）
  • 把數據庫的數據和訪問分佈多臺機器上
    • 垂直拆分（不一樣業務單元拆分到不一樣的庫裏）
      • 帶來影響：
        • 單機ACID 變得複雜
        • Jion操做變得困難
        • 靠外鍵約束場景受影響
    • 水平拆分（按照必定規則，把統一業務單元數據拆分到不一樣庫裏面）
      • 帶來影響：
        • 單機ACID 變得複雜
        • Jion操做變得困難
        • 靠外鍵約束場景受影響
        • 單庫的自增id 惟一序列受影響
        • 單個邏輯意義上表的查詢要跨庫

分佈式事務x/open DTP模型

 

• 2PC（兩階段正常提交）

• 2PC（回滾狀況）

CAP理論：

• 一致性
• 可用性
• 分區容錯性

BASE理論：

• 選擇AP 對於C ，確保最終一致性就好

Paxos 協議：

• 比兩階段更加輕量級的一致性協議
• 分佈式系統中，節點之間信息交換有兩種方式：
  • 共享內存
  • 信息投遞
    • 分佈式系統中，信息投遞會發生不少意外：網絡問題、進程掛掉、反應很慢、進程重啓、機器掛掉等
• 不存在拜占庭將軍問題（即：通訊環境不可靠）
• 本人已有博客專門討論該問題，不作贅述

集羣內數據一致性算法：

Quorum算法（權衡分佈式系統中數據一致性和可用性的）

• W+R>N 強一致性
• W+R<=N最終一致性 

Vector Lock算法

• 對同一份數據的修改，每次都加上<修改者，版本號>
• 好比：能看書Dave 的建議版本2最新

多機 Sequence 問題與處理

• 單機序列不是問題，分庫分表後成爲問題
  • 連續性
  • 惟一性
    • 單考慮惟一性，UUID
• 分佈式系統中，能夠考慮作一個獨立的系統來完成該工做（ID生成器）
  • 存在問題須要解決：
    1. 性能問題
       • 每次遠程取id 會有資源消耗（改進：每次取一段id，緩存到本地；可是取了後不用會照成浪費）
    2. 生成器穩定性問題
       • id 生成器做爲一個無狀態集羣，其可用性要靠整個集羣來保證
    3. 存儲的問題
       • 選擇空間大，須要根據不一樣類型對應不一樣的容災方案

• 改進：省掉單獨的id 生成器，這樣數據可能不是嚴格的順序增加的，須要額外的管理

應對多機的數據查詢：

• 跨庫join：
  • 在應用層，把原來join 操做分紅多個數據庫操做
  • 對經常使用數據進行冗餘，變跨庫爲單表
  • 藉助外部系統解決一些跨庫問題，好比：搜索引擎
• 外鍵約束
  • 比較難解決，不能徹底依靠數據庫自己，須要應用程序的合做

跨庫查詢問題及解決：

• 具體要參看如何分庫分表的
• 排序
  • 各路先排好序、再多路歸併排序
• 函數處理
• 求平均值
  • 多數據源求和後，再算平均值
• 非排序分頁
  • 同等步長
    • 數字表明所在頁數
  • 同等比例
    • 數字表明所在頁數
• 排序後分頁
  • 各個數據源排序，歸併
  • 大型系統請儘可能避免

數據訪問層，簡稱數據層：

• 數據讀寫的抽象層
• 對外提供訪問層方式：
  • 第一種：爲用戶提供專有API（不推薦，通用性不好），即使採用也要提供通用方式
  • 第二種：通用方式，Java提供JDBC
  • 還有一種，基於ORM類或ORM接口的形式（myBatis、hibernate、springJDBC）

• 合併排序查詢場景下，取一頁4條數據，須要在每個數據源取4條做比較，取出排在最前面的4條
  • 主要是要考慮極端狀況，有可能某一數據源的4條數據就是要的4條
  • JDBC 的方式實現
    • 使用jdbc 的方式，能夠設置每次取回的數據，作鏈式排序，分屢次查詢取回（要考慮網絡平衡）

按照數據流程的順序，看數據層設計

• 規則處理

• 一致性哈希算法
  • 把節點對應的hash 值變成一個範圍
  • 減去一個節點（範圍），變成：
    • 第一和第四管理的數據沒影響，第三也沒影響，把第二映射到第三就好
  • 增長一個節點道理相似

• 增長節點時，只有一個節點受影響，增長節點和受影響節點負載明顯低於其餘
• 減小節點反之

虛擬節點對一致性hash 進行改進

• 4個物理節點變成多個虛擬節點，增長一個物理節點就會增長相應的多個虛擬節點
• 這些插入的虛擬節點均勻分配到5個物理節點上

映射表與規則自定義計算

• 通常用於熱點數據的特殊處理

自定義規則計算是最靈活的方式

########################

分庫分表沒有統一的規則

• 原則是分庫後儘可能避免跨庫查詢

數據源管理多個分庫

• spring 配置多個數據源
  • 能夠考慮在配置管理中心統一配置

• 數據源分組

• 管理單庫的數據源
  • 能夠把單個數據源配置集中起來統一存儲
  • 機房遷移改ip很是方便
  • 禁止某些sql的執行等

• 三層數據源總體視圖

• 獨立部署的數據訪問層

• 讀寫分離帶來的挑戰

• 主庫從庫非對稱場景

• 得到消息後開始進行數據的複製（行復制）
  • 不優雅，優雅的方式應該採用基於數據庫日誌進行數據複製

• 數據庫複製在讀寫分離中是比較關鍵的任務
  • 也有非對稱場景：
    • 主從不是鏡像關係
    • 主從採用不一樣庫

• 數據變動平臺

• 數據平滑遷移
  • 擴容、縮容不能接受長時間停機：
    • 平滑遷移
      • 最大挑戰：遷移過程當中又會有數據變化
      • 能夠考慮方案：
        • 在開始進行數據遷移時，記錄增量的日誌，遷移結束後再對增量的變化進行處理
        • 最後被遷移數據的寫暫停，保證增量數據處理完畢，再放開