本文解釋CockroachDB複製和分佈特性如何影響讀和寫。
本文以總結某些重要的CockroachDB架構概念開始，接著，介紹幾個簡單的讀寫場景。
--注意：
1）一個查詢通過CockroachDB架構各層的更多細節，請參考分散式事務的生命週期。

一.重要概念
1.叢集（Cluster）：CockroachDB部署，充當單個邏輯應用。
2.節點（Node）：執行CockroachDB的單個機器。多個節點聯合一起建立叢集。
3.範圍（Range）：CockroachDB儲存所有的使用者資料（表，索引等。），以及幾乎一個巨大的鍵值對排序對映的所有系統資料。該鍵空間分成"範圍"，鍵空間的連續塊，以便每個鍵值總是能在單個範圍內發現。

從SQL角度，表及其二級索引最初對映到單個範圍，範圍中的每個鍵值對代表表（也稱為主鍵索引，因為表通過主鍵排序）中的一行資料，或二級索引中的一行資料。範圍一達到512MiB大小，其將分成兩個範圍。當表和二級索引持續變大時，該過程對新範圍會持續。
4.副本（Replica）：CockroachDB複製每個範圍（預設為三倍）且將每個副本儲存到不同的節點上。
5.租約持有者（Leaseholder）：對每個範圍，其中一個副本持有"範圍租約（range lease）"。該副本，稱為"租約持有者"，為接收和協調該範圍上所有讀寫請求的副本。
不像寫，讀請求訪問租約持有者並將結果發給客戶端，而無需與其他範圍副本協調。這減少了相關網路往返和可能的，因為租約持有者保證是最新的，這是由於所有寫請求都會到租約持有者的事實。
6.Raft領導者（Raft Leader）：對每個範圍，副本之一是寫請求的領導者。通過Raft共識協議，該副本確保提交寫前，多數副本（領導者和足夠的追隨者）基於它們的Raft日誌會同意。Raft領導者和租約持有者幾乎總是同一個副本。
7.Raft日誌（Raft log）：對每個範圍，是一個其副本已同意的範圍的寫按時間排序的日誌。該日誌儲存於每個副本的磁碟上，且是範圍一致複製的真實來源。
如上所述，當查詢執行時，叢集將請求路由到包含相關資料範圍的租約持有者。如果查詢接觸多個範圍，請求會到多個租約持有者。對讀請求，僅相關範圍的租約持有者獲取資料。對寫請求，Raft共識協議規定寫提交前相關範圍的多數副本必須達成一致。
讓我們考慮一下這些機制如何在一些假設的查詢中發揮作用。

二.讀場景
首先，設想一個簡單的讀場景：
1.叢集中有3個節點。
2.有3個小表，每個可以在單個範圍內容納。
3.範圍被複制3次（預設）。
4.查詢在節點2執行，從表3中讀取資料。

該場景中：
1.節點2（閘道器節點）從接收從表3讀取資料的請求。
2.表3的租約持有者在節點3，因此，該請求被路由到那裡。
3.節點3將資料返回到節點2。
4.節點2響應客戶端。
如果擁有相關範圍租約持有者的節點接收到該查詢，網路跳數更少：

三.寫場景
現在，設想一個簡單寫場景，其中，查詢在節點3執行，往表1寫資料：

該場景中：
1.節點3（閘道器節點）接收往表1寫資料的請求。
2.表1的租約持有者在節點1，因此，請求被路由到那裡。
3.租約持有者與Raft領導者為同一副本（典型地），因此，其同時將寫附加到其自己的Raft日誌，並通知其節點2和節點3上的追隨者副本。
4.一旦一個追隨者將寫附加到其Raft日誌（這樣，大部分副本基於同一Raft日誌達成一致），其通知領導者，並將寫提交到一致副本的鍵值。該圖中，節點2上的追隨者確認寫，但其也可以是節點3上的追隨者。也注意未涉及一致同意的追隨者通常其他副本後很快提交寫。
5.節點1向節點3返回提交確認。
6.節點3響應客戶端。
正像讀場景，如果擁有相關範圍租約持有者和Raft領導者的節點接收了寫請求，網路跳數更少：

四.網路和I/O瓶頸
記住上述的例子，將網路延遲和磁碟I/O認為潛在的效能瓶頸總是很重要。總之：
1.對讀來說，閘道器節點和租約持有者間的跳數會增加延遲。
2.對寫來說，閘道器節點和租約持有者/Raft領導者將的跳數，以及租約持有者/Raft領導者和Raft追隨者間的跳數，會增加延遲。此外，由於寫條件前Raft日誌專案被持久化到磁碟，因此，磁碟I/O很重要。

五.個人觀點
1.本文對通過特定場景對Cockroach讀寫機制及過程進行了詳盡講述。
2.本文對CockroachDB中各層間機制和原理的理解和掌握起到了鞏固和加強作用。