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 条评论
登录 后参与评论

相关文章

来自专栏Jaycekon

消息队列性能对比——ActiveMQ、RabbitMQ与ZeroMQ(译文)

Dissecting Message Queues 概述:   我花了一些时间解剖各种库执行分布式消息。在这个分析中,我看了几个不同的方面,包括API特性,易于...

3625
来自专栏腾讯移动品质中心TMQ的专栏

老总让做后台接口监控,我却开发了一个App

最近投入到了一个新的项目中,是一个新的Android项目,项目涉及到智能聊天相关的功能,所以需要一个很好的接入层,总之肯定不能用通用的http协议来聊天。

1.4K2
来自专栏IMWeb前端团队

深入浅出React(一):React的设计哲学 - 简单之美

本文作者:IMWeb 刘起 原文出处:IMWeb社区 未经同意,禁止转载 编者按:自2013年Facebook发布以来,React吸引了越来越多的开发...

1865
来自专栏鸿的学习笔记

数据分区的策略

在之前的数据复制当中,我们有一个前提就是数据量不会很大,但是随着公司的发展,再加上埋点等各种数据收集的发展,数据量会爆发式的增长,那么单台服务器很难处理这么庞大...

693
来自专栏Java架构师学习

详细剖析kafka分布式消息系统

1.背景 最近因为工作需要,调研了追求高吞吐的轻量级消息系统Kafka,打算替换掉线上运行的ActiveMQ,主要是因为明年的预算日流量有十亿,而ActiveM...

3188
来自专栏企鹅号快讯

从微信、钉钉等APP,看六种常见的loading 加载设计

当页面的框架固定时,只需要加载框架内数据时,采用这种刷新样式,即先加载框架,再加载框架内的数据。为了反之框架内的内容为空,会用占位符或者预设图片来填充。 上面简...

1975
来自专栏美团技术团队

消息队列设计精要

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。 当今市面上...

5635
来自专栏领域驱动设计DDD实战进阶

DDD实战进阶第一波(三):开发一般业务的大健康行业直销系统(搭建支持DDD的轻量级框架二)

了解了DDD的好处与基本的核心组件后,我们先不急着进入支持DDD思想的轻量级框架开发,也不急于直销系统需求分析和具体代码实现,我们还少一块, 那就是经典DDD的...

3536
来自专栏大魏分享(微信公众号:david-share)

ACID到底是个啥?浅谈微服务架构中的分布式数据管理

ACID到底是个啥? 在传统的单体应用中,其后端通常会有一个关系型数据库,如Oracle DB、MySQL等。通过关系型数据库,有助于保证业务的ACID。 AC...

4195
来自专栏Java架构师历程

2、使用 API 网关

本书的七个章节是关于如何设计、构建和部署微服务。第一章介绍了微服务架构模式。它阐述了使用微服务的优点与缺点,以及尽管如此,微服务通常是复杂应用的理想选择。该系列...

633

扫码关注云+社区