Quorum NWR算法：想要靈活地自定義一致性，沒問題！
作者：lincyang
本文將詳細解析Quorum NWR的原理，并通過InfluxDB企業版中的實際實現為例，結合源碼片段進行深入剖析，幫助大家從理論到實踐全面掌握這個算法。
今天我們將深入探討分布式系統中一個極其重要且靈活的概念——Quorum NWR 算法。在分布式系統設計中，一致性、可用性和分區容錯性三者之間存在經典的CAP理論權衡。AP系統偏向可用性和分區容錯性，但有時我們又希望在特定場景下臨時實現強一致性，這時候，Quorum NWR就派上了用場。
本文將詳細解析Quorum NWR的原理，并通過InfluxDB企業版中的實際實現為例，結合源碼片段進行深入剖析，幫助大家從理論到實踐全面掌握這個算法。
一、Quorum NWR算法原理
1.1 什么是NWR？
在Quorum NWR中，有三個關鍵參數：
- N：副本總數（Number of Replicas），即數據存儲的副本數量。
- W：寫入成功所需的副本數量（Write Quorum）。
- R：讀取成功所需的副本數量（Read Quorum）。
一致性規則
在Quorum模型中，有一個關鍵公式：
W+R>NW + R > N
- 如果寫入副本數量（W）和讀取副本數量（R）的總和大于副本數量（N），則可以保證讀取到的是最新的數據，從而實現強一致性。
- 如果 W+R≤NW + R \leq N，那么系統只保證最終一致性。
示例
- N=3，W=2，R=2
- W+R=4>3W + R = 4 > 3，可以保證強一致性。
- N=3，W=1，R=2
W+R=3=3W + R = 3 = 3，只能保證最終一致性。
1.2 一致性級別的選擇
- 強一致性：W + R > N
- 高可用性：W 或 R 取較小值，盡量保證操作成功。
- 最終一致性：W + R <= N，允許讀取到舊數據，但最終會收斂到一致的狀態。
不同場景下，業務需求不同，我們可以動態調整W和R的值，從而實現不同級別的一致性。
二、InfluxDB企業版中NWR實現
InfluxDB是一個高性能的時序數據庫，企業版支持集群部署，同時也提供了對NWR的支持。
下面我們以InfluxDB為例，深入理解NWR的一些核心實現邏輯。
2.1 InfluxDB中的數據寫入過程
在InfluxDB中，每次寫入數據時，會將數據分發到多個數據節點上，副本數量由N決定。
源碼片段一：寫入請求處理
文件：cluster/points_writer.go
// WritePoints handles writing points to the cluster
func (pw *PointsWriter) WritePoints(database, retentionPolicy string, points []models.Point) error {
// 獲取副本信息
shardGroup, err := pw.MetaClient.ShardGroupByTimestamp(database, retentionPolicy, time.Now())
if err != nil {
return err
}
// 分發數據到各個節點
for _, shard := range shardGroup.Shards {
err := pw.writeToShard(shard, points)
if err != nil {
return err
}
}
return nil
}
// 將數據寫入指定的分片
func (pw *PointsWriter) writeToShard(shard *meta.ShardInfo, points []models.Point) error {
writeSuccessCount := 0
requiredWrites := pw.RequiredWriteQuorum() // 獲取W值
for _, node := range shard.Nodes {
err := pw.sendWriteRequest(node, points)
if err == nil {
writeSuccessCount++
}
// 判斷是否達到W個寫入成功
if writeSuccessCount >= requiredWrites {
return nil
}
}
return fmt.Errorf("unable to meet write quorum (W=%d)", requiredWrites)
}代碼解析
- ShardGroupByTimestamp：根據時間戳獲取分片信息。
- writeToShard：將寫入請求發送到每個節點。
- RequiredWriteQuorum：獲取當前寫入所需的最小節點數（W）。
- 當寫入成功的節點數達到W時，返回成功，否則返回錯誤。
核心要點：只有寫入到至少W個節點成功，寫入操作才算成功。
2.2 InfluxDB中的數據讀取過程
讀取時，InfluxDB會根據配置的R值，從多個節點中讀取數據。
源碼片段二：讀取請求處理
文件：cluster/points_reader.go
// ReadPoints handles reading points from the cluster
func (pr *PointsReader) ReadPoints(database, retentionPolicy string, query Query) ([]models.Point, error) {
shardGroup, err := pr.MetaClient.ShardGroupByTimestamp(database, retentionPolicy, time.Now())
if err != nil {
return nil, err
}
readSuccessCount := 0
requiredReads := pr.RequiredReadQuorum() // 獲取R值
results := make([]models.Point, 0)
for _, shard := range shardGroup.Shards {
for _, node := range shard.Nodes {
data, err := pr.sendReadRequest(node, query)
if err == nil {
results = append(results, data...)
readSuccessCount++
}
if readSuccessCount >= requiredReads {
return results, nil
}
}
}
return nil, fmt.Errorf("unable to meet read quorum (R=%d)", requiredReads)
}代碼解析
- ShardGroupByTimestamp：根據時間戳獲取分片信息。
- RequiredReadQuorum：獲取當前讀取所需的最小節點數（R）。
- 從各個節點讀取數據，直到成功讀取的節點數達到R。
- 如果達到R個節點返回成功，否則返回錯誤。
核心要點：只有從至少R個節點成功讀取到數據，讀取操作才算成功。
2.3 Quorum NWR的動態調整
InfluxDB允許我們動態調整W和R的值，以滿足不同場景下的一致性需求。
源碼片段三：動態配置
文件：config/config.go
type Config struct {
N int `toml:"replica-n"`
W int `toml:"write-quorum"`
R int `toml:"read-quorum"`
}通過修改配置文件：
[cluster]
replica-n = 3 # 副本數量
write-quorum = 2 # 寫入所需最小節點數
read-quorum = 2 # 讀取所需最小節點數在運行時，也可以通過API動態調整這些參數。
三、實際應用場景
場景一：實時數據分析
- N=3, W=2, R=2
- 實現強一致性，確保讀到最新數據。
場景二：高可用服務
- N=3, W=1, R=2
- 犧牲部分一致性，保證寫入的高可用性。
場景三：批量數據寫入
- N=3, W=1, R=1
- 允許臨時數據不一致，保證高寫入吞吐量。
四、總結
- Quorum NWR 是AP型分布式系統中實現可控一致性的重要方法。
- 通過調整N、W、R三個參數，我們可以根據業務需求靈活調整一致性級別。
- 在實際系統（如InfluxDB）中，Quorum NWR已經被廣泛應用，既滿足了高可用性，又能在特定場景下實現強一致性。
責任編輯：武曉燕
來源：
架構師秋天
