Mongo CP，Cassandra AP？
我在網上閱讀了很多文章，但仍然對為什麼 Mongo CP、Cassandra AP、RDBMS CA 感到困惑？將解釋我的理解和查詢。
蒙哥
考慮一個場景，我有一個主人和兩個奴隸。考慮
- 寫請求到達並轉到主控。
- 它僅在主伺服器上送出，但主伺服器在寫入從伺服器之前關閉（崩潰）
- 直到master連任，寫請求需要等待，系統不可用
- 一旦前一個節點（在步驟 2 中崩潰的節點）返回，該節點的待處理寫入將被寫回從屬節點。這稱為最終一致性。
根據我的理解，由於第 3 步和第 4 步，Mongo 被稱為 CP，其中 C 代表最終一致。正確的 ？
卡桑德拉
這裡沒有主/從模型，每個節點都基於分片鍵接收其共享寫入和讀取請求。
- 寫請求到達任意節點（稱為協調節點）。
- 協調節點根據分片鍵重定向到其中一個節點
- 它被送出，但節點在寫入其他複製節點之前關閉（崩潰）。
- 再次使用相同的分片鍵寫入請求，現在協調節點立即將其重定向到副本節點（崩潰節點的副本）
- 一旦前一個節點（在步驟 3 中崩潰的節點）返回，該節點的待處理寫入將被寫回副本節點。所以 cassandra 似乎最終也是一致的？
第 4 步解釋了為什麼 cassandra 具有高可用性，但第 5 步也描述了它最終的一致性。因此，根據我的理解，cassandra 提供了最終一致性和可用性。那為什麼說它不提供 Consitency 呢？
C 代表最終一致。正確的 ？
CAP 定理中的一致性是指強一致性，即每次讀取都會收到最近的寫入或錯誤。預設情況下，MongoDB 驅動程序將所有讀取和寫入定向到副本集的主節點，這是高度一致的。
CAP 定理斷言，分佈式系統必須在網路分區的情況下在一致性和可用性之間進行選擇。MongoDB 的副本集方法使用單個主節點來實現寫入一致性 (CP)，而 Cassandra 的複制策略則傾向於寫入可用性 (AP)。網路分區不可能實現強一致性，因為如果分區的兩側更新相同的數據，可能會發生衝突。為了保持寫入可用性，AP 數據庫系統需要解決衝突的解決方案，這是與最終一致性分開的考慮因素。
然而，CAP 是對現實世界行為的簡化：MongoDB 和 Cassandra 都具有可調整的讀寫一致性級別。例如：MongoDB 有寫關注來確定寫操作所需的確認級別，讀偏好將請求路由到副本集的成員，讀關注來控制從副本集讀取的數據的新近性、一致性和隔離屬性，以及分片部署。
CAP Theorem 的作者 Eric Brewer 在 2012 年重新審視了這一點，並進行了更細緻的解讀：CAP 十二年後：“規則”如何改變。
- 直到master連任，寫請求需要等待，系統不可用
沒有主節點就沒有寫入，但副本集仍然具有讀取可用性。MongoDB 3.6 添加了Retryable Writes功能，可幫助應用程序更好地處理副本集選舉和瞬態網路錯誤。
- 一旦前一個節點（在步驟 2 中崩潰的節點）返回，該節點的待處理寫入將被寫回從屬節點。
如果 MongoDB 副本集中的主節點不可用，如果有合格的輔助節點和法定成員投票，則副本集的其餘成員將選舉一個新的主節點。在您的範例中，投票多數將是您的副本集的 2/3 成員。前主節點接受的任何未寫入大多數副本集成員的寫入都將被回滾（保存到磁碟），因此前主節點從與目前主節點歷史一致的狀態恢復同步。