redis 在微服务领域的贡献,java 制作微信小程序教程
如
/dubbo/com.newboo.sample.api.DemoService/consumers``/dubbo/com.newboo.sample.api.DemoService/providers
hash 数据结构下保存的 key 是注册上来的 url,value 是过期时间
127.0.0.1:6379> hgetall /dubbo/com.newboo.sample.api.DemoService/providers``1) "dubbo://172.23.233.142:20881/com.newboo.sample.api.DemoService?anyhost=true&application=boot-samples-dubbo&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=com.newboo.sample.api.DemoService&metadata-type=remote&methods=sayHello&pid=19807&release=2.7.8&side=provider×tamp=1621857955355"``2) "1621858734778"
从理论上来说,注册中心只要符合数据存储、监听推送变更、心跳检测这几个基本的功能即可。
以 dubbo 为例看下 redis 是如何利用自身特性来完成注册中心的功能( 以 dubbo 2.7.8 版本为例):
服务注册
provider 在服务注册时,将服务提供方的 url 写入/dubbo/${service}/providers
下,数据类型为 hash,key 为提供方 url,value 为 key 的过期时间,默认为 60s,可
配置
写入完成后以/dubbo/${service}/providers
为 key 调用publish
命令发布一个 register 事件
provider 在初始化时起一个单独的线程每隔1/2过期时间
(默认 30s)时对 provider 进行重新重新注册并发布 register 事件
服务发现
获取匹配/dubbo/${service}/*
的 key(此处用到了keys
命令),拿到的有这几种:/dubbo/${service}/providers
、/dubbo/${service}/routers
、/dubbo/${service}/configuators
对/dubbo/${service}/*
拿到的 key 进行hgetall
,拿到真实的 provider 列表以及配置等数据,进行组装、匹配
同时对每个 subscribe 的服务单独开一个线程,对/dubbo/${service}
执行psubscribe
命令阻塞等待有事件发生
从源码和测试来看,dubbo 的 redis 注册中心不能直接用于生产环境,原因有如下两点:
使用了
keys
命令,会阻塞单线程的 redis,keys 执行期间,其他命令都得排队没有心跳检测这个功能,我测试了 provider 被
kill -9
杀死后,consumer 是无法感知的。但从实现上来看是想通过存储的过期时间来判断服务是否可用,即需要对比 url 对应的 value 与当前的时间,如果过期应被剔除,但这部分貌似没有实现完整
虽然 dubbo 的 redis 注册中心生产不可用,但这并不影响他可以构建一个生产可用的注册中心,陌陌就是个很好的例子。
RPC 调用协议
redis 协议作为 RPC 调用协议也是陌陌同学告诉我的,当时我问了他两个问题:
为什么选择 redis 协议作为 RPC 调用协议
redis 协议如何透传类似 header 的
隐式参数
第一个问题的答案也比较出乎意料,他说是为了跨语言调用,当时觉得只有 http、gRPC 等协议做到了跨语言,redis 协议跨语言也是第一次听说。但仔细一想,确实没毛病,现在哪个后端语言没有实现 redis 的客户端呢?
之所以 redis 协议能够做到跨语言,这也全仰仗它的设计非常简洁,易于实现,详细协议内容可以参考这个链接:
评论