Replies: 1 comment
-
related issues #213 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
对于发布订阅中的订阅请求,目前proxy的逻辑如下:
1、如果后端路由是redis-standalone或者redis-sentinel,则会绑定一个到后端redis节点的连接,透传所有的订阅消息
2、如果后端路由是redis-cluster,则会随机选择一个节点,再执行1)中的操作(如果是ssubscribe,则会哈希到特定节点)
3、如果后端路由是读写分离的配置,则pub命令会发给所有的写地址(也就是支持双写),sub命令只会建立到第一个写地址的连接
4、如果后端路由是一个自定义分片,则会报错不支持
5、此外,如果开启了ConverterProxyPlugin,则channel会被当作key字段进行转写,转写方法可以由业务方自定义(如增加前缀)
对于keyspace notifications,包括两种类型:
1、Key-space notification
2、Key-event notification
参考:keyspace-notifications
目前遇到的问题:
1、Redis keyspace notifications,如key过期事件等,也是依赖pubsub来实现的,并且不同于普通的channel,在redis-cluster集群中,消息是不会广播的。当redis-cluster挂在proxy后端,而proxy又被当作单点redis对外提供服务时,客户端会发现订阅keyspace相关的channel能成功,但是却不完整(因为proxy只建立了到后端的一个连接)
2、后端redis可能不支持keyspace功能,如各种redis兼容的kv存储(如 kvrocks 、 pika 、 tendis 等)
待讨论的方案:
1、对于问题1,可以在后端是redis-cluster时,并且订阅的channel是keyspace相关频道,则proxy订阅所有节点,聚合后再返回给客户端
2、对于问题1和问题2,还有一种方式,当订阅channel是keyspace相关频道,不再透传给后端,而是proxy拦截处理,这种方式需要处理如下几个问题:
1)proxy节点之间需要共享一下订阅信息,因为一个keyspace的notifications事件源头可能是其他proxy节点的请求
2)对于key过期这种事件,需要维护key的ttl状态,维护开销需要确认
Beta Was this translation helpful? Give feedback.
All reactions