如何使用NoSQL（Cassandra）實現客戶端身份驗證解決方案？

Question

我目前正在考慮如何使用NoSQL解決方案實現Web應用程序的身份驗證。我遇到的問題是在大多數NoSQL解決方案（例如Cassandra，MongoDB）中可能會延遲寫入。例如，我們寫在節點A上，但不能保證寫入同時出現在節點B上。這與NoSQL解決方案背後的方法是合理的。

現在有一個想法是，你沒有二次讀取（所以一切都超過了主人）。這可能適用於MongoDB（實際上有一個主節點），但不適用於Cassandra（所有節點均相等）。但是我們的應用程序在世界各地的幾個獨立點上運行，所以我們需要多主控功能。

目前我還沒有意識到Cassandra的解決方案，我可以更新數據並確保隨後的讀取（對所有節點）確實發生了變化。那麼，如何在身份驗證請求（讀取）可以在多個節點上並行顯示的NoSQL解決方案之上構建身份驗證呢？

感謝您的幫助！

Answer 1

用方面的Apache Cassandra的：

• http://wiki.apache.org/cassandra/API#ConsistencyLevel

的ConsistencyLevel是一個枚舉同時控制模式中的定義基礎上讀取和寫入性能。不同的一致性級別具有不同的含義，具體取決於您是在執行寫入操作還是讀取操作。請注意，如果W + R> ReplicationFactor（其中W是要寫入時阻止的節點數），並且R是要在讀取時阻止的數字，則您將具有強烈的一致行爲;也就是說，讀者總是會看到最近的寫作。其中最有意思的是執行QUORUM讀寫操作，這樣可以保持一致性，同時仍允許節點故障時的可用性達到ReplicationFactor的一半。當然，如果延遲比一致性更重要，那麼你可以使用較低的值作爲其中的一個或兩個。

這是在應用程序端進行管理的。具體來說，可以歸結爲如何設計Cassandra實現，跨Cassandra節點的複製因子以及應用程序在讀取/寫入時的行爲方式。

寫

• ANY：確保寫已被寫入至少1個節點，包括HintedHandoff收件人。
• ONE：在響應客戶端之前，確保寫入已寫入至少一個副本的提交日誌和內存表。
• QUORUM：在響應客戶端之前，確保寫入已寫入N/2 + 1副本。
• LOCAL_QUORUM：確保寫已經被寫入/ 2 + 1個節點，本地數據中心內（需要NetworkTopologyStrategy）
• EACH_QUORUM：確保寫已經被寫入/ 2 + 1個節點中的每個數據中心（需要NetworkTopologyStrategy）
• ALL：確保在寫入所有N個副本之前，響應客戶端。任何無響應的副本都會使操作失敗。

讀

• ANY：不支持。您可能需要一個。
• ONE：將返回第一個副本返回的記錄進行響應。一致性檢查總是在後臺線程中完成，以便在使用ConsistencyLevel.ONE時修復任何一致性問題。這意味着即使初始讀取的值較舊，後續調用也會有正確的數據。 （這稱爲ReadRepair）
• QUORUM：將查詢所有副本，並在至少有大部分副本（N/2 + 1）已報告時使用最新時間戳記返回記錄。再次，剩餘的副本將在後臺進行檢查。
• LOCAL_QUORUM：一旦本地數據中心內的大多數副本已回覆，則返回具有最新時間戳記的記錄。
• EACH_QUARUM：每個數據中心內的大多數副本都回復後，返回具有最新時間戳記的記錄。
• ALL：將查詢所有副本，並在所有副本已回覆時返回具有最新時間戳的記錄。任何無響應的副本都會使操作失敗。