選擇分佈式共享內存解決方案

Question

我有一個任務是爲大規模可擴展分佈式共享內存（DSM）應用程序構建原型。原型只能作爲一個概念驗證，但我想通過選擇稍後將在真實解決方案中使用的組件來最有效地度過我的時間。

該解決方案的目的是從外部來源獲取數據輸入，將其轉移並使結果可用於多個前端。那些「前端」只需從緩存中獲取數據並在沒有額外處理的情況下提供服務。前端命中這個數據的數量實際上可能是每秒數百萬次。

數據本身非常不穩定;它可以（並且確實）變化很快。然而，前端應該看到「舊」數據，直到最新的數據被處理和緩存。處理和寫入由單個（冗餘）節點完成，而其他節點只讀取數據。換句話說：沒有通讀行爲。

我一直在尋找到解決方案，如memcached然而，這尤其是一個不履行在下面列出的所有我們的要求：

1. 該解決方案必須至少有Java客戶端API這是相當不錯因爲應用程序的其餘部分是用Java編寫的，而且我們是經驗豐富的Java開發人員;
2. 該解決方案必須完全彈性：應該可以添加新節點而不重新啓動集羣中的其他節點;
3. 該解決方案必須能夠處理故障轉移。是的，我意識到這意味着一些開銷，但總體服務的數據量不大（最大1G），所以這應該不成問題。通過「故障轉移」，我的意思是在節點關閉時無需硬編碼/更改服務器IP地址（如）在memcached客戶端中的無縫執行;
4. 理想情況下，應該可以指定數據重疊程度（例如，應該在DSM羣集中存儲多少份相同的數據）;
5. 沒有必要永久存儲所有數據，但可能需要對某些數據進行後處理（例如對數據庫進行序列化）。
6. 價格。顯然，我們更喜歡免費/開放源代碼，但如果解決方案是值得的，我們很樂意支付合理的費用。無論如何，付費24小時/天支持合同是必須的。
7. 整個事情必須在我們的數據中心託管，所以像Amazon SimpleDB這樣的SaaS產品不在範圍之內。如果沒有其他選項可用，我們只會考慮這一點。
8. 理想的解決方案是嚴格一致（如在CAP中）;然而，最終一致可以被視爲一個選項。

在此先感謝您的任何想法。

Answer 1

看一看Hazelcast。它是純Java，開源（Apache許可證）高度可擴展的內存數據網格產品。它確實提供7X24支持。它確實解決了我試圖解釋其中的每個問題的所有問題：

1. 它具有本地Java客戶端。
2. 它是100％動態的。動態添加和刪除節點。無需改變任何東西。
3. 再一切都是動態的。
4. 您可以配置多個備份節點。
5. Hazelcast支持持久性。
6. Hazelcast提供的一切都是免費的（開源），它確實提供企業級支持。
7. Hazelcast是單個jar文件。超級好用。只需將jar添加到您的類路徑中即可。看看主屏幕上的屏幕投射。
8. Hazelcast是嚴格一致的。你永遠不會閱讀陳舊的數據。

Answer 2

查看Terracotta的JVM集羣，它是OpenSource;） 當它在JVM級別上工作時，它沒有API，當您將值存儲在複製對象中時，它會發送到所有其他節點。 即使鎖定，所有這些工作都是透明的，無需添加任何新代碼。

Answer 3

您可能希望籤像連貫特定Java的解決方案：http://www.oracle.com/global/ru/products/middleware/coherence/index.html

不過，我認爲這樣的解決方案過於複雜，喜歡使用像memcached的解決方案。爲你的目的，Memcached的巨大缺點是缺乏記錄鎖定，並且沒有內置的方法來複制故障轉移數據。這就是爲什麼我要研究關鍵值數據存儲。其中許多將完全滿足您的需求。

以下是可幫助您完成任務的鍵值數據存儲列表： http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores 只需選擇一個您感覺舒適的鍵值數據存儲。

Answer 4

你有沒有關於使用標準的消息解決方案，如rabbitmq？ RabbitMQ是AMQP protocol的開源實現。

你的應用程序似乎或多或少像一個發佈/訂閱系統。 發佈者節點是執行處理並將消息（已處理數據）放入服務器隊列中的節點。 訂戶可以通過各種方式從服務器獲取消息。 AMQP將消息的生產者和消費者分開，並且在如何組合雙方方面非常靈活。

Answer 5

我正在做一個類似的項目，而是針對.NET平臺。除了已經提到的解決方案，我認爲你應該看看ScaleOut StateServer和Alachisoft NCache。恐怕這些替代品都不便宜，但根據我的判斷，它們比商業解決方案的開源更安全。

1. 兩者都提供Java客戶端API，儘管我只是玩過.NET API。
2. StateServer具有新緩存節點的自我發現功能，而且NCache具有可添加新緩存節點的管理控制檯。
3. 兩者都應該能夠無縫地處理故障轉移。
4. StateServer可以擁有1個或2個被動副本的數據。 NCache具有更多緩存拓撲可供選擇。
5. 如果您指的是可寫入/寫入兩​​者都可用的數據庫。
6. 我不知道你打算多少緩存服務器來使用，但這裏有全價規格： ScaleOut StateServer Alachisoft NCache
7. 兩者都安裝在服務器上進行本地配置和他們都有GUI管理。
8. 我不知道到底是什麼嚴格一致涉及，所以我會留給你來調查..

總體而言，StateServer的是最好的選擇，如果你想跳過高速緩存配置每一個小細節羣集，而NCache具有非常多的功能和緩存拓撲可供選擇。

根據數據對客戶端的行爲（如果數據從同一客戶端多次讀取），將客戶端上的本地緩存與羣集中的分佈式緩存混合可能是一個好主意（可用於NCache和StateServer），只是一個想法。

Answer 6

取決於你喜歡什麼樣的，我一定會按照別人的建議Hazelcast如果你對AP從CAP定理，但如果你需要CP，我會選擇Redis

Answer 7

我建議你使用Redisson - 基於Redis的用於Java的內存數據網格。工具（BitSet，BloomFilter，Set，SortedSet，Map，ConcurrentMap，List，Queue，Deque，BlockingQueue，BlockingDeque，ReadWriteLock，Semaphore，Lock，AtomicLong，CountDownLatch，Publish/Subscribe，RemoteService，ExecutorService，LiveObjectService，SchedulerService）上Redis服務器之上！它支持主/從，哨兵和集羣服務器模式。還支持自動羣集/哨兵服務器拓撲發現。這個lib是免費且開源的。

完美的作品在雲感謝AWS Elasticache支持

Answer 8

指定的使用案例似乎屬於Netflix的Hollow。這是一個只有一個生產者和多個消費者的只讀複製緩存。