Closed crazyoyo closed 1 month ago
@crazyoyo Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.
@crazyoyo Thank you for signing the Contributor License Agreement!
Thanks for looking into this. We're not going to merge this PR as the changes pull in a lot of driver dependencies into the listening container. We do not want such a design, instead, a design where we could benefit from abstractions would be much better to align with how we design our components.
Hello:
According to Redis official statement about keyspace notifications, "Every node of a Redis cluster generates events about its own subset of the keyspace as described above. However, unlike regular Pub/Sub communication in a cluster, events' notifications are not broadcasted to all nodes." But Redis drivers, such as Jedis, randomly obtains a connection from a node of the redis cluster to subscribe events, including keyspace notifications. Which means that many events are missed from the Redis cluster.
Summary: This PR improves the eventuallyPerformSubscription() method in RedisMessageListenerContainer by first determine whether it is a keyspace notifications pattern, then traverse all master nodes, and create event subscriber one by one to ensure that no keyspace notifications events are missed.
Proposed solution: This PR improves the eventuallyPerformSubscription() method in RedisMessageListenerContainer by subscribe all master nodes to make sure no keyspace notifications events are missed.