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

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

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

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

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

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

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

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

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

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