V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
0x5c0f
V2EX  ›  DevOps

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

  •  
  •   0x5c0f · 59 天前 · 1455 次点击
    这是一个创建于 59 天前的主题,其中的信息可能已经有所发展或是发生改变。
    • 事情是这样的,我们有一个项目,用的是云 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来解决这个问题,但不知道是不是配置不对,也没有解决,不知道还有没有其他的方案。

    20 条回复    2024-10-24 14:01:27 +08:00
    zzlyzq
        1
    zzlyzq  
       59 天前
    如果你的应用比较少,比如只有一台云主机里面部署了应用。那么,可以在这个云主机里面,做一个 lo 本地环回接口,地址 192.168.50.11 ,然后部署一个 rinetd 程序,将 192.168.50.11:6379 端口,转发到 192.168.2.10:6379.
    FabricPath
        2
    FabricPath  
       59 天前
    跨 Vpc 访问底层数据库这个方案设计得不好。
    你如果两个 Vpc 本来就属于同一业务,那直接建 peer ,无 nat 直接访问;如果本来就属于不同业务,那应该暴露 API 而不应该暴露 Redis 。
    zzlyzq
        3
    zzlyzq  
       59 天前
    不过,这个问题是云平台导致的问题。这个是自己的云,还是公有云?
    0x5c0f
        4
    0x5c0f  
    OP
       59 天前
    @zzlyzq 公有云平台
    0x5c0f
        5
    0x5c0f  
    OP
       59 天前
    @zzlyzq 关于转发是测试过了,主要是主备 Redis 本书数据存储的就是他们的实际节点,这个理论上是没有什么问题的, 因为这是正常的情况, 问题就是我后面说的这种,2 台机器 A 和 B ,B 上面通过 docker 创建 Redis 主备服务,那么 Redis 中存储的主备信息就是 docker 内的网络信息,A 机器是和 B 机器处于统一网段,但是,他不可能直接请求到 B 机器上 docker 内的 ip 。
    0x5c0f
        6
    0x5c0f  
    OP
       59 天前
    @FabricPath 平台的架构看起来就是这样的,也没办法改变,我是想如果我自建的时候遇到这种情况,应该如何解决,根据平台反馈,他们的 redis 就是相当于一个虚拟机内的,他们提供给我们的就是一个映射的地址,而 Redis 主备存储的信息是他们虚拟机内的网络信息
    julyclyde
        7
    julyclyde  
       59 天前
    我觉得是他们这个代理的问题啊
    缺乏针对这个协议做的特殊处理
    FabricPath
        8
    FabricPath  
       59 天前
    @0x5c0f 你自建没有问题,他这个问题是因为 redis 在公共服务区,他给你的是一个 1:1 nat 的访问地址
    0x5c0f
        9
    0x5c0f  
    OP
       59 天前
    @FabricPath 是的,如果是按照正常流程,Redis 主备,应该每个节点都位于与应用同一网络下,这种就不会有问题,但是假设我 Redis 主备,是部署到虚拟机或者 k8s 这种大环境下,那么 redis 中存储的主备信息就是虚拟机或者 k8s 内部分配的 ip ,这种情况,如果应用通过 `INFO REPLICATION` 拿到的信息肯定就是不正确的了
    guo4224
        10
    guo4224  
       59 天前
    非得把所有节点 ip 都给你,你自己搞就好了
    oneegg
        11
    oneegg  
       59 天前 via iPhone
    看起来 redis proxy 都可以解决你的问题
    adoal
        12
    adoal  
       59 天前
    为什么你在业务系统里直连主、备节点的实际地址呢,连负载均衡地址不能完成你的需求吗?
    opengps
        13
    opengps  
       59 天前
    这种用了负载均衡的主备只有容灾效果,防止单个节点死掉,并不具备读写分离效果
    0x5c0f
        14
    0x5c0f  
    OP
       59 天前
    @adoal 因为程序这边那个默认组件他使用的是 INFO REPLICATION 去获取的主备信息,只有第一次程序会去通过配置文件中设置的负载地址连接,后面就通过 INFO 拿了,所以上面也说了,研发去重写代码自适应这个了
    0x5c0f
        15
    0x5c0f  
    OP
       59 天前
    @opengps 对啊,所以我才想要请教,有没有什么方案,可以解决这个问题,可以解决 `INFO REPLICATION`获取到实际节点信息的问题
    opengps
        16
    opengps  
       59 天前
    @0x5c0f 用了负载均衡你就知连接到单个负载均衡节点行了,不需要再考虑你的程序里自动切换节点了
    iloveayu
        17
    iloveayu  
       59 天前
    @0x5c0f #4 公有云平台开支持单给他们啊,把你的需求扔过去让支持工程师们给方案,如果公有云的能力没办法支持你的想法,自己搞完等到上线后跑出问题,那锅就都在你了。
    sagaxu
        18
    sagaxu  
       59 天前
    用了 redis 代理,就不该获取主备信息,因为你只能连接代理,对你来说只有一个结点,背后是什么结构对你是透明的。

    如果你是要一个高可用的获得 redis 主备的方式,那你应该用 sentinel ,从 sentinel 获取主备信息,而不该用代理。
    ICKelin
        19
    ICKelin  
       59 天前
    感觉差一个打通网络的产品,可以用来打通 VPC 网络,甚至可以打通不同的 k8s 集群的网络,这样以后同样的跨网络的业务也都不需要再解决了。
    0x5c0f
        20
    0x5c0f  
    OP
       58 天前
    @iloveayu 这个和云平台确认了,他们目前的架构就是这样,没办法改变。 所以目前的解决是让研发自己适配 ,我考虑的就像 @opengps #16 、 @sagaxu #18 和 @ICKelin #19 说的这种,程序不应该考虑自动切换,但问题是`INFO REPLICATION`拿到的就是实际的节点信息, 我希望是否有可能通过调整架构,让程序即使通过`INFO REPLICATION`获取信息时,也可以拿到正确的代理地址。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2514 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 20ms · UTC 02:56 · PVG 10:56 · LAX 18:56 · JFK 21:56
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.