事情是这样的,我们有一个项目,用的是云 Redis
,一个 6.0
的主备环境。
大致的架构是 应用: 192.168.2.8
--> Redis 代理:192.168.2.10
(这个是平台提供给我们的负载均衡地址) ---> Redis 实际节点: 192.168.50.11
(这个是我们在平台不可见的地址), 这个有点像Redis
主从是通过docker
的方式部署的, 而平台提供给我们的是部署Redis
主从的物理机的IP
然后这个问题就出现在 INFO REPLICATION
这个命令上,这个命令在读取主从信息时候,他直接返回的是 Redis
实际部署的节点的IP
, 也就是192.168.50.11
, 所以应用在调用时候,会直接用 192.168.50.11
, 而不是 192.168.2.10
, 这样就会导致 应用和Redis
不在同一网络下,从而出现无法访问的问题。
目前我们采用的解决方案是研发这边重写了相关代码,自己去适应这种,而我想的是是否可以通过调整Redis
架构来解决这个问题, 云平台肯定是无法变动,但是我如果自建的时候,该如何解决呢。我开始想通过代理Pridixy
来解决这个问题,但不知道是不是配置不对,也没有解决,不知道还有没有其他的方案。
1
zzlyzq 3 小时 36 分钟前
如果你的应用比较少,比如只有一台云主机里面部署了应用。那么,可以在这个云主机里面,做一个 lo 本地环回接口,地址 192.168.50.11 ,然后部署一个 rinetd 程序,将 192.168.50.11:6379 端口,转发到 192.168.2.10:6379.
|
2
FabricPath 3 小时 36 分钟前
跨 Vpc 访问底层数据库这个方案设计得不好。
你如果两个 Vpc 本来就属于同一业务,那直接建 peer ,无 nat 直接访问;如果本来就属于不同业务,那应该暴露 API 而不应该暴露 Redis 。 |
3
zzlyzq 3 小时 36 分钟前
不过,这个问题是云平台导致的问题。这个是自己的云,还是公有云?
|
5
0x5c0f OP @zzlyzq 关于转发是测试过了,主要是主备 Redis 本书数据存储的就是他们的实际节点,这个理论上是没有什么问题的, 因为这是正常的情况, 问题就是我后面说的这种,2 台机器 A 和 B ,B 上面通过 docker 创建 Redis 主备服务,那么 Redis 中存储的主备信息就是 docker 内的网络信息,A 机器是和 B 机器处于统一网段,但是,他不可能直接请求到 B 机器上 docker 内的 ip 。
|
6
0x5c0f OP @FabricPath 平台的架构看起来就是这样的,也没办法改变,我是想如果我自建的时候遇到这种情况,应该如何解决,根据平台反馈,他们的 redis 就是相当于一个虚拟机内的,他们提供给我们的就是一个映射的地址,而 Redis 主备存储的信息是他们虚拟机内的网络信息
|
7
julyclyde 3 小时 24 分钟前
我觉得是他们这个代理的问题啊
缺乏针对这个协议做的特殊处理 |
8
FabricPath 3 小时 23 分钟前
@0x5c0f 你自建没有问题,他这个问题是因为 redis 在公共服务区,他给你的是一个 1:1 nat 的访问地址
|
9
0x5c0f OP @FabricPath 是的,如果是按照正常流程,Redis 主备,应该每个节点都位于与应用同一网络下,这种就不会有问题,但是假设我 Redis 主备,是部署到虚拟机或者 k8s 这种大环境下,那么 redis 中存储的主备信息就是虚拟机或者 k8s 内部分配的 ip ,这种情况,如果应用通过 `INFO REPLICATION` 拿到的信息肯定就是不正确的了
|
10
guo4224 3 小时 10 分钟前
非得把所有节点 ip 都给你,你自己搞就好了
|
11
oneegg 3 小时 7 分钟前 via iPhone
看起来 redis proxy 都可以解决你的问题
|
12
adoal 3 小时 7 分钟前
为什么你在业务系统里直连主、备节点的实际地址呢,连负载均衡地址不能完成你的需求吗?
|
13
opengps 3 小时 1 分钟前
这种用了负载均衡的主备只有容灾效果,防止单个节点死掉,并不具备读写分离效果
|