REDIS中的碎片酒吧/Sub通過在多個線程中分配消息流量來改善酒吧/子伸縮性。傳統的Redis Pub/Sub受到單線程模型的限制，該模型可能會成為高負載下的瓶頸。使用碎片酒吧/子，將通道分為分配給特定I/O線程的碎片；每個線程都會為其分配的碎片處理消息傳遞，從而降低爭執(zhí)和提高性能。關鍵點包括：1）通過哈希進行頻道到碎片映射； 2）可配置的碎片數； 3）使用SsubScribe進行碎片訂閱； 4）在發(fā)布期間自動碎片。它非常適合具有許多渠道的應用程序，例如實時聊天系統或物聯網平臺。要使用它，請用ssubscribe替換訂閱，而發(fā)布保持不變。客戶必須明確選擇進入碎片，並且兩種模式都可以在遷移過程中共存。

Redis 7中的碎片酒吧/子是一個新功能，它涉及傳統的Redis Pub/Sub System（可伸縮性）的局限性之一。如果您將REDIS用於實時消息並具有多個渠道或模式，尤其是在高負載下，您可能以前遇到了績效問題。 Sharded Pub/sub通過在所有可用事件循環(huán)（或線程）中傳播酒吧/子流量來幫助，而不是通過主線程路由所有內容。

為什麼需要它

Redis一直使用單線程模型來處理命令，這使事情變得簡單，但是在處理大量酒吧/子消息時可能會成為瓶頸。在較早的版本中，即使啟用了REDIS，REDIS已啟用了螺紋I/O，所有酒吧/子操作仍然通過主線程。這意味著向許多訂戶發(fā)布或傳遞消息可能會阻止其他操作。

隨著redis 7，這會改變。

碎片/sub如何工作？

Sharded Pub/sub背後的核心思想是碎片- 分發(fā)跨多個線程的消息傳遞的責任。這是其工作原理：

• 將通道重新分為稱為“碎片”的邏輯組。
• 每個碎片都分配給特定的I/O線程。
• 當客戶端訂閱通道時，訂閱將以負責該通道的碎片（以及線程）註冊。
• 發(fā)表在通道上的消息通過同一線程處理和傳遞，避免了交叉線程同步開銷。

這樣，Redis可以隨著CPU核心數量的增加，可以更有效地擴展酒吧/子性能。

一些要點：

• 使用哈希功能將頻道名稱映射到碎片。
• 碎片的數量可通過redis.conf （ pubsub_shard_streams_per_node ）配置。
• 訂閱者僅從他們已將訂閱的渠道接收消息 - 有一個單獨的命令： SSUBSCRIBE 。

您什麼時候應該使用它？

您應該考慮使用：

• 您的應用程序使用大量渠道。
• 由於大量的酒吧/子使用情況，您會體驗性能瓶頸。
• 您想水平擴展Redis，而不僅僅是添加更多實例以用於消息分佈。

它在以下應用程序中特別有用：

• 帶有許多房間或主題的實時聊天系統。
• 通知服務向許多用戶廣播更新。
• 物聯網平臺每個設備都會在其自己的頻道上發(fā)布狀態(tài)更新。

如果您的用例僅涉及許多訂戶的少數渠道，則標準酒吧/sub仍然可以。但是，一旦您開始縮放通道的數量或每條消息需要較低的延遲，碎片就會變得更好。

如何使用碎片酒吧/sub

使用Sharded Pub / Sub很簡單，但與經典SUBSCRIBE / PUBLISH流程不同。這是您需要做的：

• 要以碎片方式訂閱頻道，請使用SSUBSCRIBE而不是SUBSCRIBE 。
• 要發(fā)佈到碎片頻道，請使用PUBLISH - 碎片是根據頻道名稱自動處理的。
• 要取消訂閱，請使用SUNSUBSCRIBE 。

例子：

 ＃訂閱碎片頻道
客戶端1> ssubscribe myChannel

＃發(fā)布消息 - 由正確的線程處理
客戶端2>發(fā)布MyChannel“ Hello Sharded World”

記?。?/p>

• 客戶必須明確使用SSUBSCRIBE來利用碎片。
• 經典SUBSCRIBE和SSUBSCRIBE不能以相同的聯繫混合。
• 除非修改，否則未更新的REDIS 7更新的工具或客戶不會使用Sharded Pub/sub。

另外，由於Redis 7支持這兩種模式，因此您可以逐漸遷移應用程序的一部分以使用碎片訂閱，同時將其他人保留在傳統模型上。

最後的想法

REDIS 7中的碎片酒吧/子為Redis的實時消息傳遞功能帶來了急需的可伸縮性。通過將頻道分配給不同的線程，Redis可以處理更高的吞吐量，而無需犧牲簡單性或可靠性。

如果您正在與Redis進行大規(guī)模合作，尤其是在酒吧/超級繁重的環(huán)境中，那麼值得升級並嘗試此功能。

基本上就是這樣 - 並不是太複雜了，但是對於Redis作為消息平臺來說，這絕對是邁出的一大步。

以上是REDIS 7中的碎片酒吧/子是什麼？的詳細內容。更多資訊請關注PHP中文網其他相關文章！