遇到一个 Redis 跨 VPC 读取的问题

[0x5c0f]

• 事情是这样的，我们有一个项目，用的是云 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来解决这个问题，但不知道是不是配置不对，也没有解决，不知道还有没有其他的方案。

[zzlyzq]

如果你的应用比较少，比如只有一台云主机里面部署了应用。那么，可以在这个云主机里面，做一个 lo 本地环回接口，地址 192.168.50.11 ，然后部署一个 rinetd 程序，将 192.168.50.11:6379 端口，转发到 192.168.2.10:6379.

[FabricPath]

跨 Vpc 访问底层数据库这个方案设计得不好。
你如果两个 Vpc 本来就属于同一业务，那直接建 peer ，无 nat 直接访问；如果本来就属于不同业务，那应该暴露 API 而不应该暴露 Redis 。

[zzlyzq]

不过，这个问题是云平台导致的问题。这个是自己的云，还是公有云？

[0x5c0f]

@zzlyzq 公有云平台

[0x5c0f]

@zzlyzq 关于转发是测试过了，主要是主备 Redis 本书数据存储的就是他们的实际节点，这个理论上是没有什么问题的, 因为这是正常的情况， 问题就是我后面说的这种，2 台机器 A 和 B ，B 上面通过 docker 创建 Redis 主备服务，那么 Redis 中存储的主备信息就是 docker 内的网络信息，A 机器是和 B 机器处于统一网段，但是，他不可能直接请求到 B 机器上 docker 内的 ip 。

[0x5c0f]

@FabricPath 平台的架构看起来就是这样的，也没办法改变，我是想如果我自建的时候遇到这种情况，应该如何解决，根据平台反馈，他们的 redis 就是相当于一个虚拟机内的，他们提供给我们的就是一个映射的地址，而 Redis 主备存储的信息是他们虚拟机内的网络信息

[julyclyde]

我觉得是他们这个代理的问题啊
缺乏针对这个协议做的特殊处理

[FabricPath]

@0x5c0f 你自建没有问题，他这个问题是因为 redis 在公共服务区，他给你的是一个 1：1 nat 的访问地址

[0x5c0f]

@FabricPath 是的，如果是按照正常流程，Redis 主备，应该每个节点都位于与应用同一网络下，这种就不会有问题，但是假设我 Redis 主备，是部署到虚拟机或者 k8s 这种大环境下，那么 redis 中存储的主备信息就是虚拟机或者 k8s 内部分配的 ip ，这种情况，如果应用通过 `INFO REPLICATION` 拿到的信息肯定就是不正确的了

[guo4224]

非得把所有节点 ip 都给你，你自己搞就好了

[oneegg]

看起来 redis proxy 都可以解决你的问题

[adoal]

为什么你在业务系统里直连主、备节点的实际地址呢，连负载均衡地址不能完成你的需求吗？

[opengps]

这种用了负载均衡的主备只有容灾效果，防止单个节点死掉，并不具备读写分离效果

[0x5c0f]

@adoal 因为程序这边那个默认组件他使用的是 INFO REPLICATION 去获取的主备信息，只有第一次程序会去通过配置文件中设置的负载地址连接，后面就通过 INFO 拿了，所以上面也说了，研发去重写代码自适应这个了

[0x5c0f]

@opengps 对啊，所以我才想要请教，有没有什么方案，可以解决这个问题，可以解决 `INFO REPLICATION`获取到实际节点信息的问题

[opengps]

@0x5c0f 用了负载均衡你就知连接到单个负载均衡节点行了，不需要再考虑你的程序里自动切换节点了

[iloveayu]

@0x5c0f #4 公有云平台开支持单给他们啊，把你的需求扔过去让支持工程师们给方案，如果公有云的能力没办法支持你的想法，自己搞完等到上线后跑出问题，那锅就都在你了。

[sagaxu]

用了 redis 代理，就不该获取主备信息，因为你只能连接代理，对你来说只有一个结点，背后是什么结构对你是透明的。

如果你是要一个高可用的获得 redis 主备的方式，那你应该用 sentinel ，从 sentinel 获取主备信息，而不该用代理。

[ICKelin]

感觉差一个打通网络的产品，可以用来打通 VPC 网络，甚至可以打通不同的 k8s 集群的网络，这样以后同样的跨网络的业务也都不需要再解决了。

[0x5c0f]

@iloveayu 这个和云平台确认了，他们目前的架构就是这样，没办法改变。 所以目前的解决是让研发自己适配 ，我考虑的就像 @opengps #16 、 @sagaxu #18 和 @ICKelin #19 说的这种，程序不应该考虑自动切换，但问题是`INFO REPLICATION`拿到的就是实际的节点信息， 我希望是否有可能通过调整架构，让程序即使通过`INFO REPLICATION`获取信息时，也可以拿到正确的代理地址。