基於Redis構建微服務的反應式架構 - bitsrc

構建反應式架構
這裡首先要了解什麼是反應式架構，為什麼我們要構建一個而不是採用更傳統的方法？
簡而言之，反應式架構是在滿足所有前提條件的那一刻開始執行每一位邏輯的架構——我想我應該在“簡單”這個詞周圍加上引號。
讓我換一種說法：當您需要在特定事件發生後觸發邏輯時，您有兩種選擇：

• 定期檢查某種標誌，直到它開啟，這意味著事件發生了。
• 坐等，直到其他東西通知您的服務該事件已觸發。

• 您不必浪費時間和網路流量輪詢特定標誌的資料來源（或您認為應該輪詢的任何內容）。此外，如果您使用的是按使用付費的基礎架構，則不需要的輪詢可能會導致額外費用，在目標服務上進行不必要的工作，並且如果在您的程式碼等待輪詢期間發生多個事件，您可能最終不得不聚合事件.
• 您可以透過新增新服務、並行工作和儘可能快地捕獲事件來擴充套件服務的處理能力。
• 平臺更穩定。透過被動工作，您可以確保您的服務以最佳速度執行，而不必擔心由於來自客戶端的資料過載而崩潰。

那我們需要什麼？
撇開這一點，我們需要什麼才能使我們的平臺/架構成為反應式平臺/架構？它不是 ReactJS，這是肯定的。我們需要一個訊息代理，它可以集中多個服務之間的訊息分發。
有了可以充當代理的東西，我們需要確保我們的程式碼的編寫方式可以透過讓代理知道它在哪裡以及它需要的事件型別來訂閱某些事件。
之後，將向我們的服務傳送通知，並觸發我們的邏輯。
聽起來很簡單吧？那是因為它就是！
 

那麼 Redis 是如何考慮的呢？
Redis 不僅僅是一個鍵值記憶體儲存，事實上，它有 3 個我喜歡它的特性，允許我根據不同的預期行為建立反應式架構。
這3個特點是：

• 釋出/訂閱。Redis 內部有一個訊息佇列，它允許我們傳送訊息並將它們分發給每個訂閱的程式。這是一種即發即棄的合約，這意味著如果沒有監聽器處於活動狀態，那麼訊息就會丟失。所以在使用這個頻道時要考慮到這一點。
• 鍵空間(KeySpace)通知。可能是我最喜歡的 Redis 功能。這些壞男孩是由 Redis 本身建立的事件，並分發給決定訂閱它們的每個程式。它們與鍵空間的變化有關，這意味著您儲存在其中的資料發生的任何事情。例如，當您刪除或更新金鑰時，或者當其 TTL 計數器達到 0 時自動刪除。這允許您生成定時事件。在“某事”發生 3 天后，您是否必須觸發一些邏輯？這是如何。
• Redis 流。這是 Redis 資料型別的混合體，混合了鍵空間通知和釋出/訂閱，所有這些組合在一起並且執行良好。Streams 嘗試模擬tail -f命令在您的終端上的行為。如果您從未見過該命令，那麼這是一個 *nix 命令，它顯示檔案的最後一行，並持續監聽檔案的更改，以便在您新增新行時，它會立即列出。流也會發生同樣的情況。考慮到正確的用例，它們非常強大且非常有用。您可以在此處閱讀有關它們的更多資訊。

看上圖，把中央的紅管看成是Redis的Pub/Sub或者Blocking list，這是一個更可靠的Pub/Sub的自定義實現。
流程從 #1 開始，由“客戶端應用程式”提交請求，並在 9 點結束，“客戶端應用程式”收到有關響應的通知。其餘的部分？我不在乎，客戶端應用程式也不應該在乎。
這是這種正規化的優點之一，該架構成為客戶端的黑匣子。單個請求可以觸發數百個事件或僅觸發一個，行為將是相同的：一旦響應準備就緒，它將被傳遞給客戶端。而不是客戶端知道需要多長時間或多久需要檢查它是否準備好。這些都不重要。
請記住以下注意事項：

• 訊息由其訂閱者釋出到“通道”中。如果您想釋出不同型別的主題，建議您擁有不同的頻道。此外，如果您需要額外的粒度來區分哪個消費者必須負責處理一條特定的訊息，則詳細資訊將需要成為訊息的一部分。這是因為一個頻道的所有訂閱者都將獲得相同的訊息，因此如果您有多個程式偵聽並獲得相同的訊息，您最終可能會重新執行相同的操作。可以在 Redis 中使用訊息的 ID 實現一個標誌（例如），以確保建立它的第一個程式是負責處理事件的程式，而其餘程式可以忽略它。這是一種可靠的方法，因為在 Redis 中設定金鑰是一個原子過程，
• 如果沒有訂閱者收聽某個特定頻道，則釋出的訊息將丟失。如果您使用 Pub/Sub 模式就是這種情況，因為它在“即發即忘”機制下工作。如果您想確保您的郵件在處理之前一直保留在那裡，您可以使用“阻止列表”方法。該解決方案包括直接在 Redis 的鍵空間上建立一個列表（即一個普通的值列表），並讓程式訂閱以獲取有關該鍵的鍵空間通知。這樣他們就可以決定如何處理插入的資料（即如果他們想忽略它，處理它並刪除它等）。
• 如果您要傳送複雜的訊息，例如 JSON，則需要對其進行序列化。這是因為對於阻止列表和 Pub/Sub，您唯一可以傳送的是字串。話雖如此，如果您需要在沒有序列化的情況下透過線路傳送複雜型別，您可以考慮使用 Redis Streams，這是它​​們允許的。當然，這裡的限制是唯一允許的型別是 Redis，而不是您用來編寫解決方案的語言的型別。

基於時間的觸發
反應式架構的另一個常見行為是能夠在預定義的時間過去後觸發某些事件。例如：在發現資料問題 10 分鐘後觸發警報。或者等待 30 分鐘，然後觸發 IoT 裝置已停止傳送資料的警報。
這些通常是與現實世界的限制相關的行為，需要一些時間來解決，或者甚至可以透過“稍等片刻”並重新開始倒數計時來解決自己的問題（例如連線不可靠的物聯網裝置） ）。
對於這種情況，架構保持不變，唯一的區別是中央通訊集線器肯定使用來自 Redis的鍵空間通知。
您會看到，您需要了解有關 Redis 的兩個主要功能才能實現這一目標：

1. 設定鍵值對時，您可以選擇以秒為單位定義 TTL（生存時間）。這就變成了倒數計時，一旦達到 0，金鑰將自動銷燬。
2. 當您訂閱一個鍵空間時（這也適用於 pub/sub，但我們在這裡沒有使用它），您可以使用模式進行訂閱。換句話說，您可以訂閱“last_connection_time_of_device*”，而不是訂閱鍵“last_connection_time_of_device100002”的事件。然後，一旦發生某些事情，建立的每個與該模式匹配的金鑰都會通知您。

影鍵技術
另一方面，如果您在該鍵中儲存了一個複雜的結構並且需要它，則必須稍微更改此方法。這是因為當 TTL 到期時，金鑰將被刪除，從而刪除其中的資料，因此您無法真正檢索它。這時，您可以使用一種稱為“陰影鍵”的技術。
影子鍵本質上是用於觸發事件的鍵，但這實際上是在隱藏包含您需要的資料的實際鍵。回到我們的例子，假設生產者每次收到心跳都會更新 2 個鍵：

• “last_connection_time_of_device100002”帶有最後從裝置接收到的有效負載的unix時間戳。
• “device_data_id100002”帶有來自裝置的額外資訊。