我有一個簡單的用例。我有一個系統,對REST服務(有許多實例)的重複請求是不允許的。但是,由於複雜的數據存儲配置和下游服務也難以防止。我是否應該使用Hazelcast檢測重複請求到REST服務
所以我可以防止重複「交易」的唯一方法是有一個集中的地方,我寫一個請求數據的唯一散列。每個REST端點首先檢查新請求的散列是否已經存在,並且僅在沒有這種散列存在時纔會繼續。
爲了這個問題的目的,假設不可能用數據庫約束來做到這一點。
一個解決方案是在數據庫中創建一個表,用於存儲我的請求散列,並且在繼續處理請求之前始終寫入此表。但是,我想要比這更輕的東西。
另一種解決方案是使用類似Redis的東西,並在繼續處理請求之前寫入redis我的獨特散列。但是,我不想旋轉Redis集羣並維護它等等。我想在每個應用程序實例中嵌入Hazelcast,並在那裏寫入我獨特的哈希值。理論上,所有實例都會在內存網格中看到散列,並能夠檢測到重複的請求。這解決了我擁有比數據庫更輕的解決方案的問題,以及不需要維護Redis集羣的其他要求。
好吧,現在終於爲我的問題。這個用例使用Hazelcast是個好主意嗎? 榛樹會不會足夠快地檢測出重複的請求,而這些請求會以毫秒或微秒爲單位發生?
如果請求1進入實例1,請求2進入實例2微秒。實例1向hazelcast寫入請求的散列,實例2僅在毫秒後檢查哈希是否存在散列才能檢測到哈希值?榛色是否會及時在整個集羣中傳播數據?它甚至需要這樣做嗎?
在此先感謝,所有的想法都歡迎。
有道理。還有一個問題,那就是Hazelcast客戶端的.NET實現。但是,這是否意味着我只能從.NET加入現有的Hazelcast羣集,或者實際上是否可以將hazelcast實例嵌入.NET應用程序(類似於java)?意思是,我可以創建一個只包含.NET嵌入式hazelcast實例的新集羣嗎? – DKhanaf
不,它只是一個客戶端,也就是說,集羣仍然是Java。 – noctarius