TiDB 會支持通過 Arbiter 節點或通過外部服務（如：ZooKeeper）來進行主節點選舉么？

比如阿里雲等雲計算運營商底層存儲已包含分散式3副本技術，因此TiDB數據節點伺服器組採用兩節點一組（分跨不同 IDC），組成跨可用區的分散式 6 副本存儲已經足夠。

但為解決網路分區時的腦裂等不一致問題，此時需要由 Arbiter 節點或外部的分散式協調服務來完成主節點選舉工作。

TiDB 支持用戶自定義的選舉策略么？或者 TiDB 中可配置 Replica Set 中的某個成員扮演 Arbiter（僅投票，不複製數據）角色么？或者未來有支持的計劃么？

BTW：作為對比，MySQL 的 NDB Cluster 既支持用戶自定義的選舉策略，也內置 Arbiter 仲裁節點支持。MongoDB Replica Set 亦支持 Arbiter Node。

你的前提："比如阿里雲等雲計算運營商底層存儲已包含分散式3副本技術"，這個對於資料庫來說不太友好，雖然 IOPS 看上去符合要求，但是單次 IO 的延遲還遠遠沒有達到 OLTP 資料庫的需求（比如現代本地 SSD 可以做到 10~50 微秒的延遲，但是網路盤不行）。所以 TiDB 一定需要自己管理物理磁碟。

另外啊，本身 tidb 內數據是由動態劃分的 regions （連續的一段 kv pairs）組成，每個 region 都是三個副本（默認），三個副本之間通過 Raft 協議選主和進行日誌複製，因為這個 regions 是動態分裂的，所以可能整個系統並不是一個主，因為有多個 regions（Raft group），幾乎每時每刻都會進行選主，如果依賴一個第三方組件進行 leader election 肯定是不現實的。

我想，你的需求可能是強制要求所有的 raft leaders 都按照特定的邏輯被選舉出來（比如所有的 leader 都集中在一個數據中心），這個是可以做的，也很簡單。tidb 也擴展了 raft 協議，加入了 leader transfer 的實現，可以做到控制某個 peer 一定會被選成 leader，所以是可以做到的。

另一方面，"TiDB 中可配置 Replica Set 中的某個成員扮演 Arbiter（僅投票，不複製數據）角色"

我其實沒太理解這個需求，正常來說，如果需要控制 leader 的歸屬，其實不需要這個角色，有更簡單的做法（比如參考 tidb 的 leader transfer）。但是反過來，不投票，只同步數據這樣的角色，類似 paxos 的 learner 倒是有必要存在的，至於為什麼，就留給大家去思考了，在 tidb 1.1 中我們給 raft 引入了 learner 的角色，只負責同步 snapshot 和追日誌，不參與投票。