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

Consistency  一致性
Availability 可用性
Partition Tolerance 分區容錯性

CAP取舍

CP：發生分區，需要犧牲用戶的體驗，等待所有數據全部一致了之后再讓用戶訪問系統。

AP：發生分區，為了高可用，每個節點只能用本地數據提供服務，會導致全局數據的不一致性。

理想情況下，單機數據庫 AC 模型

分布式數據庫系統 CP模型

單機數據庫分布式解決方案：例如mysql

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

帶來問題：

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

分布數據庫特性

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

分布數據庫設計思路

• 多副本的存儲

  保證數據一致性
  
              一般KV存儲模型
  

• 主從模型：

  提供數據分片路由支持

多副本的存儲方式

技術難點——熱數據問題

• 熱點數據

  數據分快
  
          熱數據遷移
  

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

技術難點——原子性問題

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

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

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

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

如圖所示：

RocksDB數據庫存儲原理

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

• LSM的設計依據

  隨機寫轉換成順序寫

  優化讀性能

• 三種數據結構

  MenTable

  logfile

  sstfiles

  如下圖：

RocksDB寫入

• 插入

  記錄log
  
        MenTable寫入新記錄
  

• 更新

  記錄log
  
        MenTable寫入新記錄
  

• 刪除

  記錄log
  
        MenTable標記key刪除
  

WAL：write-ahead log，確保數據不丟失全部是內存寫入，沒有磁盤I/O

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

LSM讀

• 讀MemTable

• 定位sslFile，文件內查找

  

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

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

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

TiDB架構

• 基于RocksDB
• Raft一致性協議
• Etcd存儲元數據
• 支持OLTA
• 支持OLAP

MySql遷移到TiDb：數據遷移和流量遷移

數據遷移：

            1、支持主從同步的方式

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

            1、切讀

            2、停雙寫

如下圖所示：

注意的事項：

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