快取

在 資料流 章節的介紹，可以知道 Broker 最主要的任務就是「比對路由規則並轉發」。 一般來說路由規則放在資料庫中，因此比對的速度將會成為關鍵瓶頸所在。尤其在同時間要轉發成千上萬筆資料的時候，對資料庫的壓力更是不言而喻。

眾所周知，要減輕資料庫的最佳方案就是快取，而 Redis 是目前相當流行的一個解決方案。

Sylvia-IoT 從最初的設計就希望能盡量簡單、盡可能同時採用最少的技術種類（您可以只使用 SQLite 和 MQTT 就運行完整的 Sylvia-IoT 功能）。 在快取技術上，使用了程序記憶體（in-process-memory）的方案，也就是將資料儲存在程序本身的變數中，比對的過程無需使用網路和 IPC，直接存取自身的變數即可。

目前 Broker 使用 std::collections::HashMap 實作。

上圖簡介了 Sylvia-IoT 的快取機制。為了滿足叢集架構，引入了 broadcast 佇列實作 控制通道 (Control Channel)。 為了保持資料的正確性，先更新資料庫，然後才更新快取。以下我們簡述步驟：

1. 使用者透過 HTTP API 修改路由規則。
2. 和正常的 API 實作一樣，直接操作資料庫。
3. 在 HTTP 回應前，先發送一個更新訊息到控制通道。內容含有必要的更新的資料（名稱等非必要的內容就不在其中）。
4. 在回應 HTTP 的同時，控制通道會向叢集中的所有程序發送更新訊息。
5. 程序收到後，變更變數的內容。

為了簡單，目前的實作大多是刪除快取資料（步驟 3 的內容是刪除動作），然後利用 cache-miss 填補內容。

這邊探討幾個特殊狀況：

• Broker 快取的設計採用「最終一致性（eventual consistency）」。在步驟 3 之後，可能還會有短暫的時間採用舊的路由，但是這段時間通常不會太久（幾十或幾百毫秒內，或許更短）。
• 為了避免資料不一致，當程序偵測到與控制通道的佇列有重新連線的情形時，會將快取內容完全清空，等 cache-miss 的時候從資料庫讀取資料。

設定檔 章節中的 mqChannels，裡面有許多關於各個 API 對應的控制通道設定。

靠著程序內的變數作為快取，正是 Sylvia-IoT Broker 可以做到高效轉發的秘訣唷 😊。