Azure - 將消息發送給所有其他角色並等待響應

Question

我在多實例Web應用程序中需要的一種非常常見的模式是使所有實例的MemoryCache無效 - 並等待確認已完成此操作。 （因爲用戶可能在刷新後否則突然看到在另一個實例上的舊數據）

我們可以組合使這個：

• AzureServicebus，
• 發送消息到一個主題
• 其他實例發回消息回覆原始實例
• 有一個等待循環等待消息返回，
• 請注意有多少其他實例在杉木st地方。
• 可能有些超時，因爲如果一個實例在兩者之間崩潰會發生什麼？

我認爲所有這些小邊緣案例的工作可能是很多工作 - 所以在我們重新開始之前 - 是否已有一個共同的模式或庫？

（當然一個解決方案將使用Redis的像一個共享緩存，但是有些情況下一個的MemoryCache是​​快了很多）

Answer 1

看看Azure的耐用功能，例如Fan-In/Fan-Out scenario。他們使用下面的Azure存儲隊列，但提供更高級別的抽象。

請注意，耐用功能仍在早期預覽中（截至2017年8月），因此尚不適合用於生產。

Answer 2

我認爲制定出所有這些小邊緣案例可能會有很多工作 - 所以在我們重新發明方向盤之前 - 是否已經有一個共同的模式或庫？

確實。這聽起來像是一箇中間件框架的候選人，如NServiceBus或MassTransit。

AzureServicebus

兩個NServiceBus和MassTransit支持Azure的服務總線作爲傳輸。

發送消息到一個主題

兩個NServiceBus和MassTransit可以Publish消息（events）到主題。

其他實例發送消息發送回用的ReplyTo到原始實例

兩個NServiceBus和MassTransit可以將消息發送至特定的目的地。 NServiceBus也可以使用request/reply pattern傳入消息的發起者Reply。

有等待消息後面

兩個NServiceBus和MassTransit支持Sagas，也被稱爲Process Coordinator pattern等待循環。

首先要知道還有多少個其他實例。

不確定這個要求。擴展時，您正在與競爭對手競爭，並且不應該關心端點實例的數量。

可能有些超時，因爲如果一個實例在兩者之間崩潰會發生什麼？

如果您參考重試和恢復，則NServiceBus和MassTransit都支持重試。

Answer 3

您可以使用Azure Redis緩存發佈/訂閱模型來執行此操作。 1）訂閱的Redis複用器

connectionMultiplexer.GetSubscriber().Subscribe(
         "SubscribeChannelName", 
         (channel, message) => { 

invalidate cache here and publish the confirmation using below publish method 
connectionMultiplexer.GetSubscriber().PublishAsync("PublishChannelName", "Cache invalidated for instance").Wait(); 
}); 

2）發佈的高速緩存無效，並從實例認購確認

var connection = ConnectionMultiplexer.Connect("redis connection string"); 
var redisSubscriber = connection.GetSubscriber(); 
redisSubscriber.Subscribe(
         "PublishChannelName", 
         (channel, message) => { 

// write logic to verify if all instances notified about cache invalidation. 
}); 
redisSubscriber.PublishAsync("SubscribeChannelName","invalidate cache")).Wait();