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

一、写在前面的话

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

二、案例分析

1、案例的由来

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

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

2、出现的问题

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

三、思路和方法

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

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

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

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数量较多时需要仔细更改和核对,避免重蹈我的覆辙,一眼花,漏改了一个,结果就悲剧了,现在心情极度低落】

②解析问题

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

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

zkname 名字

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

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

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

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

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

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

②业务写入不规范

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

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

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

         

四、经验分享

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

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

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

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT技术精选文摘

Go语言构建千万级在线的高并发消息推送系统实践

4022
来自专栏「3306 Pai」社区

RadonDB架构解析

RadonDB在DTCC大会主会场宣布开源了, 一个期待已久的产品终于走进了开源社区。 感谢青云领导层的对技术贡献的情怀。

5291
来自专栏CSDN技术头条

携程开源Redis多数据中心解决方案XPipe

Redis在携程内部得到了广泛的使用,根据客户端数据统计,整个携程全部Redis的读写请求在每秒200W,其中写请求约每秒10W,很多业务甚至会将Redis当成...

4629
来自专栏子勰随笔

SDK设计心得之架构和资源

5944
来自专栏猿人谷

三种Linux服务器监控技术的对比

本文介绍三种Linux服务器监控技术的优缺点,其中有SNMP代理(客户端)方式、SSH方式、安装私有代理(客户端)方式等内容。 Linux系统的强大的功能和绚丽...

2417
来自专栏架构师之路

小小的IP,大大的耦合,你痛过吗?

什么是耦合? 耦合,是架构中,本来不相干的代码、模块、服务、系统因为某些原因联系在一起,各自独立性差,影响则相互影响,变动则相互变动的一种架构状态。 感官上,...

4656
来自专栏华章科技

如何用 Python 打造一个聊天机器人?

不知道玩Slack的人多不多?国内有一个类似的产品,之前搞PythonTG翻译组在用,但是没怎么用起来。感觉这些产品提供的灵活性还蛮大的,可以自己实现许多有意思...

1095
来自专栏机器学习算法与Python学习

Python中常用的一些架构

在各种语言平台中,python涌现的web框架恐怕是最多的,是一个百花齐放的世界,各种micro-framework、framework不可胜数;猜想原因应该是...

5564
来自专栏Android 开发者

Android 开发者 | 应用兼容性注意事项

2863
来自专栏匠心独运的博客

过来人的经验,谈谈一致性处理方案—分布式事务(DTS)

传统事务是使用数据库自身的事务属性(ACID),而数据库自身的事务属性是局限于当前实例,不能实现跨库。而对于大型分布式/微服务集群系统中,不仅存在着跨库的事务,...

4144

扫码关注云+社区

领取腾讯云代金券