分布式存儲的技術原理

CAP定理： 在一個分布式計算機系統(tǒng)中，一致性，可用性和分區(qū)容錯性這三種保證無法同時得到滿足；

Consistency  一致性
Availability 可用性
Partition Tolerance 分區(qū)容錯性

CAP取舍

CP：發(fā)生分區(qū)，需要犧牲用戶的體驗，等待所有數(shù)據(jù)全部一致了之后再讓用戶訪問系統(tǒng)。

AP：發(fā)生分區(qū)，為了高可用，每個節(jié)點只能用本地數(shù)據(jù)提供服務，會導致全局數(shù)據(jù)的不一致性。

理想情況下，單機數(shù)據(jù)庫 AC 模型

分布式數(shù)據(jù)庫系統(tǒng) CP模型

單機數(shù)據(jù)庫分布式解決方案：例如mysql

• 垂直拆分
• 水平拆分
• 讀寫分離

帶來問題：

• 業(yè)務侵入大，維護成本高
• 帶來分布式事務問題

分布數(shù)據(jù)庫特性

• 存儲量不受單機容量限制
• 計算能力不受單機資源限制
• 擴展性強
• 容錯能力強
• 數(shù)據(jù)可靠性高

分布數(shù)據(jù)庫設計思路

• 多副本的存儲

  保證數(shù)據(jù)一致性
  
              一般KV存儲模型
  

• 主從模型：

  提供數(shù)據(jù)分片路由支持

多副本的存儲方式

技術難點——熱數(shù)據(jù)問題

• 熱點數(shù)據(jù)

  數(shù)據(jù)分快
  
          熱數(shù)據(jù)遷移
  

解決思路：實時調(diào)整塊位置將讀寫頻繁的塊均勻分布在各個存儲節(jié)點；

技術難點——原子性問題

• 保障多個Key寫入的原子性

解決思路：一般都遵守Google Percolator分布式事務。（在這里不具體講）

采取的樂觀鎖的方式，如圖所示：

兩階段提交：Prewrite（預寫）、commit（提交）；并發(fā)沖突提交的問題。

如圖所示：

RocksDB數(shù)據(jù)庫存儲原理

RocksDB：使用C++編寫的嵌入式kv存儲引擎，其鍵值均允許使用二進制流。由Facebook基于levelDB開發(fā)。

• LSM的設計依據(jù)

  隨機寫轉(zhuǎn)換成順序?qū)?/p>

  優(yōu)化讀性能

• 三種數(shù)據(jù)結構

  MenTable

  logfile

  sstfiles

  如下圖：

RocksDB寫入

• 插入

  記錄log
  
        MenTable寫入新記錄
  

• 更新

  記錄log
  
        MenTable寫入新記錄
  

• 刪除

  記錄log
  
        MenTable標記key刪除
  

WAL：write-ahead log，確保數(shù)據(jù)不丟失全部是內(nèi)存寫入，沒有磁盤I/O

MenTable寫滿后寫入磁盤，順序I/O。

LSM讀

• 讀MemTable

• 定位sslFile，文件內(nèi)查找

  

RocksDB首先會去查看內(nèi)存中的Memtable，如果Memtable中包含key及其對應的value，則返回value值即可；如果在Memtable沒有讀到key，則接下來到同樣處于內(nèi)存中的Memtable中去讀取，類似地，如果讀到就返回，若是沒有讀到,那么會從磁盤中的SSTable文件中查找。

RocksDB為了提高讀取速遞，增加了讀cache和Bloomfilter。

上面的分布式存儲原理都理解了，那我們具體的tidb的架構原理就很簡單了。

TiDB架構

• 基于RocksDB
• Raft一致性協(xié)議
• Etcd存儲元數(shù)據(jù)
• 支持OLTA
• 支持OLAP

MySql遷移到TiDb：數(shù)據(jù)遷移和流量遷移

數(shù)據(jù)遷移：

            1、支持主從同步的方式

            2、雙寫（MQ）
流量遷移：

            1、切讀

            2、停雙寫

如下圖所示：

注意的事項：

樂觀鎖沖突的問題，使用分布式鎖，串行化處理解決；