前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Redis 经典案例分析:消失的连接

Redis 经典案例分析:消失的连接

原创
作者头像
迪B哥
修改2017-08-16 14:46:37
2.4K0
修改2017-08-16 14:46:37
举报
文章被收录于专栏:MySQL实战分享MySQL实战分享

一、写在前面的话

Redis作为如今托管平台最重要的服务之一,几乎OMG所有的线上业务多多少都在使用Redis,那么其稳定性和维护的高效性必然成为我们所关注的一个重要的问题,在【Redis经典案例分析】这一专题中,我将与大家一起学习关于Redis维护的相关内容,把真是业务环境中遇到的维护问题与大家分享,共同积累Redis维护的经验,提高托管平台Redis服务的高效和可靠性。

二、案例分析

1、案例的由来

A是最早接入托管Redis平台的业务,其使用的旧的Redis服务机制(下图左),故存在无法多IDC自动同步数据和监控项不完善的一系列痛点,其数据只能依靠多地复写的方式,保证各个IDC内数据的一致性,各IDC间数据不要进行严格的一致性校验,容易造成数据一致性出错的现象。

[1499672139339_6820_1499672139747.png]
[1499672139339_6820_1499672139747.png]

在新的Redis服务机制中(上图右),通过改造同步机制,实现了多IDC自动同步的机制(理论上支持任何一地写入,自动多IDC同步),使得业务在写入数据时只需要单点写,多地自动通过内置的同步自己进行同步和校验,严格的保证了数据一致性。

2、出现的问题

正常来说当我们迁移一地以后,会先确定数据的一致性,接着进行其他两地的自动同步,但是在进行A业务从旧架构到新架构改造过程中,当我们迁移完成一地之后,进行验证时,业务反馈其数据出现了不一致的现象,即写入的部分数据,无法获取的情况。

三、思路和方法

简单来说,问题就是在迁移完之后的架构中数据的同步出现了问题。下面来我们一起来一步一步的排查下这个问题:

1、自查---迁移操作出错?

可以检查下再执行搬迁操作时候的操作流程是否出错,其中特别注意在手动slaveof数据的时候各“”格子“的一一对应关系是否有错。

[1499672179646_7493_1499672180023.png]
[1499672179646_7493_1499672180023.png]

2、同步机制---机制有BUG?

检查一下是否迁移后的业务可以正常的进行多地IDC同步。方法如下:

①首先分别在深圳、上海、天津的proxy中get一个key,确认其不存在(value值为nil);

②接着在深圳的proxys上set这个key value;

③分别在上海和天津两地的proxy上get刚刚写入的key,如果均可以得到正确的value值,即说明其同步机制并没有问题。

3、中间件---名字服务配置和解析?

①配置问题

在ons.webdev.com中查看名字服务(读名字、写名字)的关联IP是否已经修改,删除旧IP(或是权重为0),添加新IP。【IP数量较多时需要仔细更改和核对,避免重蹈我的覆辙,一眼花,漏改了一个,结果就悲剧了,现在心情极度低落】

[1499672263757_3637_1499672264394.png]
[1499672263757_3637_1499672264394.png]

②解析问题

关于解析名字服务的问题,这里就介绍两种常见的方式:

a. 第一种(只能检查名字服务本身在IP的配置同步上出现问题):

zkname 名字

由于名字下IP过多,这个命令时随机返回IP,应该大量多次的执行该命令,查看解析出的IP地址是否是配置过的IP,是否会出现已经删除或者不属于该业务的IP。

b. 第二种(可以同时检查业务使用的解析逻辑)

在旧业务上添加扩几个新的proxy(为了减小对业务的影响,数量应与原先的proxy一致),通过调整原先所有的proxy的权重(调整为0),观察业务此时的数据是否能保证一致性。

4、业务源头---使用不规范?

①是否有长链接【这一步应该最排查】

在旧业务机器上(为了保险起见,防止原先业务直接连接redis的IP,在proxy和redis上均检查),通过netstat -anp | grep 端口 ,查看一下是否还有长链接,如果有,那么很有可能不同步的问题是由于业务此时还是用其链接将数据写在旧的机器上,造成新机器中没有此数据。

②业务写入不规范

当你排查完操作流程、同步机制的问题以后,如果还是无法解决,那么此时就不要太难为自己了,很可能问题压根就出现在业务的写入逻辑或者代码逻辑上。

正常来说当我们迁移一地以后,会先确定数据的一致性,的业务逻辑如下:

[1499672355022_8149_1499672355438.png]
[1499672355022_8149_1499672355438.png]

此时正常情况,当业务向已经迁移的”深圳“写入数据时,是不存在数据不一致的现象,但如果业务的写入流程是下图这样,就会出现问题了。此时业务写入的数据由一部分将写到“上海“和“天津”中,这样就造成了数据的不一致。

[1499672374929_6900_1499672375205.png]
[1499672374929_6900_1499672375205.png]
代码语言:txt
复制
         

四、经验分享

由于开发使用读写名字的不定性,为了防止这一种虽然看似简单,但却隐藏的十分好的原因,同时又因为在没确定数据一致性的情况下,不能轻易配置自动多IDC同步,那么在验证一地数据一致性的时候切记,可以先将原先的读名字中其他地方的IP权重调为0,然后进行数据一致性校验。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、写在前面的话
  • 二、案例分析
    • 1、案例的由来
      • 2、出现的问题
      • 三、思路和方法
        • 1、自查---迁移操作出错?
          • 2、同步机制---机制有BUG?
            • 3、中间件---名字服务配置和解析?
              • 4、业务源头---使用不规范?
              • 四、经验分享
              相关产品与服务
              云数据库 Redis
              腾讯云数据库 Redis(TencentDB for Redis)是腾讯云打造的兼容 Redis 协议的缓存和存储服务。丰富的数据结构能帮助您完成不同类型的业务场景开发。支持主从热备,提供自动容灾切换、数据备份、故障迁移、实例监控、在线扩容、数据回档等全套的数据库服务。
              领券
              问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档