## Sharded Pub/Sub
From Redis 7.0, sharded Pub/Sub is introduced in which shard channels are assigned to slots by the same algorithm used to assign keys to slots. [略]
Sharded Pub/Sub helps to scale the usage of Pub/Sub in cluster mode. It restricts the propagation of messages to be within the shard of a cluster. Hence, the amount of data passing through the cluster bus is limited in comparison to global Pub/Sub where each message propagates to each node in the cluster. This allows users to horizontally scale the Pub/Sub usage by adding more shards.
Redis Pub/Sub | Docs https://redis.io/docs/latest/develop/interact/pubsub/#sharded-pubsub
Redis ClusterでのPub/Subは、クラスターバスを介してのブロードキャストで、クラスター内のどのノードでSUBSCRIBEしてても、どのノードでPUBLISHされたメッセージでも受信できることが分かった。
けど、このブロードキャストはシャードの数やPUBLISH数が増えるとクラスターバスの帯域を圧迫してしまうという問題がある、らしい。
対策としてRedis7からSharded Pub/Subが入った。
これは、Redis ClusterでPub/Sub使ったら、ちゃんと上記の様にしてくれるのかどうか気になった時の、ちゃんとしてくれない方の挙動。
要するにブロードキャストせず一つシャードで完結するPub/Sub。
※シャードは、masterノードとreplicaノードのセット
keyspace notificationsの挙動に近い（かもしかしたら同じ？）keyspace notificationsはRedis7以前からあると思うので、keyspace notificationsがSharded Pub/Subを使ってるわけじゃないと思うけど。
Sharded Pub/Subは、Redisのデータストア用途と同様にkey名のCRCから算出してどのシャードに割り当てるか決まり。
PUBLISHもSUBSCRIBEもkey名から算出なので、使う側がどのシャードかと意識する必要は無い。
Redis ClusterでならSharded Pub/Subを使っておけば良さそうなのかな？
データストアのkeyと違って、少数のチャンネルだけど送受信数はやたらと多い場合に、運悪く1個のシャードに偏ると負荷が偏ってしまう問題はありそう？
けど、従来のPub/Sub（グローバルPub/Sub）は、その偏った負荷を全シャードにブロードキャストする事になると思うから、むしろ他のシャードの負荷が低い分お得、かも？
Redis 7 の Sharded Pub/Sub まとめ #AWS - Qiita https://qiita.com/komoken/items/1ab6d73683a890978da0
