一组 Redis 实际应用中的异常场景及其根因分析和解决方案

前言

在上一场 Chat《基于 Redis 的分布式缓存实现方案及可靠性加固策略》中,我已经较为全面的介绍了 Redis 的原理和分布式缓存方案。如果只是从“会用”的角度出发,已经有很多 Chat 和博客可供参考,但是,在实际应用中,异常场景时有出现,作为一名攻城狮,仅仅“会用”是不够的,还需要能够定位、解决实际应用中出现的异常问题。

我总结了一组 Redis 实际应用中遇到的异常场景,如 Redis 进程无法拉起,故障倒换失败,Slot 指派失败等,并针对这些异常场景给出了根因分析和可供参考的解决方案。如果你对 Redis 感兴趣并且在工作中可能使用 Redis,本文介绍的“踩坑”案例值得一看。

本场 Chat 涉及的实际应用异常场景及解决方案包括:

  1. 编译好的 Redis-Server 在 Linux 系统上无法启动;
  2. Redis 集群故障倒换失败,备节点无法升主;
  3. Redis 集群状态显示正常,但读写操作部分失败;
  4. Redis 集群 Slot 丢失后,重新指派 Slot 失败;

redis-server 启动报错

问题基本信息

xxx 项目中,使用 Redis 集群作为分布式缓存,它只是整个项目中的一个模块。 Redis 集群部署环境:Suse12(Linux) 每一次迭代,项目组都会编译一个大包进行验证,在同一套部署环境中,Redis 集群部署 “偶现” 失败,失败原因为部分节点上 redis-server 进程未能拉起,尝试用命令:./redis-server ./xxx/redis.conf 手动拉起 redis-server 进程报错:/lib64/libc.so.6: version `GLIBC_2.14' not found(required by /opt/…/redis-server)。

表因分析

很明显,报错显示安装环境 Linux 系统找不到 GLIBC2.14 版本库,而 redsi-server 依赖 GLIBC2.14,使用命令:strings /lib64/libc.so.6 | grep GLIBC 查看安装环境 GLIBC 版本,如下所示:

install_ENV:/opt/xxx/redis/bin # strings /lib64/libc.so.6 | grep GLIBCGLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_PRIVATE

可以看出,安装环境系统最高支持 GLIBC_2.11,低于需要的 2.14。至此,可初步定性为:编译 redis-server 的编译机 GLIBC 版本 (2.14) 高于安装环境的 GLIBC 版本 (2.11),即:高版本编译,低版本安装,因不兼容而安装失败。

进一步分析,使用命令:strings /lib/x86_64-linux-gnu/libc.so.6 | grep GLIBC (编译机是 Ubuntu)查看编译机的 GLIBC 版本:编译机 GLIBC 版本高达 2.18(为谨慎起见,查看 libc.so.6 的软连接,确认实际采用的 GLIBC 版本)。如果是 GLIBC 版本问题,编译机的版本远高于安装环境,上述问题不应该为 “偶现”,应该 “必现”,因此,GLIBC 版本不是导致上述问题的根因。

compile_ENV: # strings /lib/x86_64-linux-gnu/libc.so.6 | grep GLIBCGLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_2.18
GLIBC_PRIVATE

根因分析

在安装环境 redis-server 所在路径下输入命令:objdump -T redis-server| fgrep GLIBC2.14 查看 redis-server 依赖的 GLIBC2.14 版本库的具体函数:如下所示,只有一个函数 memcpy,依赖版本为 GLIBC_2.14。

install_ENV:/opt/xxx/redis/bin # objdump -T redis-server| fgrep GLIBC_2.140000000000000000      DF *UND*  0000000000000000  GLIBC_2.14 memcpy

输入命令:objdump -T /lib64/libc.so.6 | fgrep memcpy, 查看安装环境支持的 memcpy 版本:如下所示,安装环境支持的 memcpy 函数对应 GLIBC_2.2.5。

install_ENV:/opt/xxx/redis/bin # objdump -T /lib64/libc.so.6 | fgrep memcpy000000000008c400  w   DF .text  0000000000000009  GLIBC_2.2.5 wmemcpy
00000000000eef00 g    DF .text  000000000000001b  GLIBC_2.4   __wmemcpy_chk
0000000000084670 g    DF .text  0000000000000465  GLIBC_2.2.5 memcpy
0000000000084660 g    DF .text  0000000000000009  GLIBC_2.3.4 __memcpy_chk

输入命令:objdump -T /lib/x86_64-linux-gnu/libc.so.6 | fgrep memcpy 查看编译机支持的 memcpy 版本:

compile_ENV:# objdump -T /lib/x86_64-linux-gnu/libc.so.6 | fgrep memcpy00000000000alcc0  w   DF .text  0000000000000009  GLIBC_2.2.5 wmemcpy000000000010bdf0 g    DF .text  000000000000001b  GLIBC_2.4   __wmemcpy_chk0000000000091620 g    DF .text  0000000000000465  GLIBC_2.14 memcpy000000000008c420 g    DF .text  0000000000000465  (GLIBC_2.2.5) memcpy0000000000108990 g    DF .text  0000000000000009  GLIBC_2.3.4 __memcpy_chk

可见,编译机支持两种版本的 memcpy 函数 (2.14 和 2.2.5)。至此,根因已清晰:redis 源码依赖 GLIBC 提供的 memcpy 函数,在分布式编译中概率性的采用 memcpy[GLIBC2.2.5] 和 memcpy[GLIBC2.14] 编译 redis-server,而安装环境仅支持 memcpy[GLIBC2.2.5],由此导致 redis-server 概率性安装失败。

解决方案

  • 升级安装环境的 GLIBC 版本,这显然是非常不明智的,无异于削足适履;
  • 统一编译环境和安装环境,消除版本差异,这种方案需要满足一个约束:安装环境版本可控。如果你卖的是产品,用户将你的产品部署到什么系统中,你可能没办法控制,如是,该方案不可取;
  • 最佳方案:

可在 redis 源码中添加约束,显式指定所依赖的 memcpy 函数的 GLIBC 版本,需添加的约束代码如下:asm(".symver memcpy,memcpy@GLIBC_2.2.5"); 【注意】只需在调用函数 memcpy 的源文件中加入此约束

解决方案的验证例子

【步骤 1】编写一个简单的 C 测试程序:test.c,功能:将 src 中的字符串复制到字符数组 dest 中.

#include<stdio.h>#include<string.h>int main(){    char*src="Just for Testing";    char dest[20];    memcpy(dest,src,strlen(src));
    d[strlen(src)]='\0';    printf("%s",dest);
    getchar();    return 1;
}

【步骤 2】在同时具有 GLIBC_2.2.5 和 GLIBC2.14 版本 memcpy 的 Linux 系统上编译 test.c,执行命令:gcc -o test test.c,再运行 test 可执行文件:输出结果 Just for Testing。

【步骤 3】命令:objdump -T test| fgrep GLIBC2.14 确认 test 依赖的 memcpy 函数的 GLIBC 版本:将会发现 memcpy 采用的是 GLIBC2.14

【步骤 4】在源码中对依赖的 memcpy 函数进行版本约束,使其按指定版本编译。添加约束代码:asm(".symver memcpy,memcpy@GLIBC_2.2.5");

#include<stdio.h>#include<string.h>__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");int main(){    char*src="Just for Testing";    char dest[20];    memcpy(dest,src,strlen(src));
    d[strlen(src)]='\0';    printf("%s",dest);
    getchar();    return 1;
}

【步骤 5】再次执行编译,运行,检测 memcpy 的版本,将会看到,test 依赖的 memcpy 的版本为 GLIBC_2.2.5,说明添加的版本约束生效。

openSSL 版本不兼容导致 Redis 进程拉起失败

问题基本信息

曾经遇到一个需求:出于安全考虑,在 Redis 中加入了证书机制,因此使用了 openSSL,正因为使用了 openSSL,在安装部署中遇到了 redis-server 进程无法拉起的问题。由于安装环境 (Centos6.2 系统)openssl 版本低于编译环境,两者不兼容,导致 redis-server 启动失败。

初步定位

部署 Redis 集群失败,部分节点 redis-server 进程无法拉起,没有报错信息。尝试 gdb 调试,命令:gdb ./redis-server,报错内容:

/opt/xxx/redis-server: symbol lookup error: /opt/xxx/redis-server: undefined symbol: TLSv1_2_server_method

根因分析

根据报错内容,很明显,redis-server 运行中,有一个函数:TLSv12servermethod 找不到,那么,直观的思路便是查询 TLSv12servermethod,根据 IBM 的介绍),获悉:此函数为 openSSL 库函数。根据报错提示,猜测为 openSSL 版本问题,于是,分别查询安装环境和编译环境的 openSSL 版本:

查看安装环境openSSL版本:命令openssl versionInstall-DEV:# openssl version OpenSSL1.0.0-fips 29 Mar 2010

然后查看编译环境的openSSL版本:Compile-DEV:# openssl versionOpenSSL 1.0.2h  3 May 2016

从查询结果可以看出,编译环境和安装环境的 openSSL 版本差距明显,到 openSSL 官网(https://www.openssl.org/)查询,确认 TLSv12server_method 函数在 OpenSSL1.0.1e 以后才出现,至此问题定位完成。定位结论:编译机和执行机 openSSL 版本相差过大,不兼容。

解决方案

鉴于实际安装部署中,操作系统版本较多,常用的有:CentOS7.1,CentOS6.2,CentOs7.4,Red Hat 7.0,Red Hat 6.4,SuSE11sp4,SuSE12sp2 等,这些系统搭载的 openSSL 版本差别较大,可能存在不兼容的问题,因此,设计解决方案如下:

通过静态链接的方式将对 openssl 的依赖打入 redis-server 中,解除 redis-server 对操作系统的 openssl 依赖。涉及修改例子如下:

#1.自定义脚本,准备好redis编译依赖的openssl,并放入新建文件夹include和libtar -zxvf ../openssl-1.0.2k.tar.gz
cd openssl-1.0.2k
./config -fPIC no-shared
make
cd ..
mkdir lib 
cp openssl-1.0.2k/libcrypto.a ./lib
cp openssl-1.0.2k/libssl.a  ./lib
mkdir includecp openssl-1.0.2k/include/openssl/*  ./include#2.修改redis原生的MakeFile文件else
        # All the other OSes (notably Linux)
        FINAL_LDFLAGS+= -rdynamic
        FINAL_LIBS+= -pthread -lrt        #此行有新增内容,添加静态链接库的路径
        FINAL_LIBS+= -L../../lib -lssl -lcryptoendifendifendif#Include paths to dependencies#此行有新增内容,添加需要库的名称FINAL_CFLAGS+= -I../deps/hiredis -I../deps/linenoise -I../deps/lua/src  -I../../include

nodes-xxx.conf 错误导致 Redis 进程拉起失败

问题基本信息

集群模式下,有一个 Redis 节点宕机,由于 Redis 集群本身有可靠性机制,通过故障倒换,备节点升主,集群仍可以提供服务。然而,宕机的节点经过修复,一段时间后重新上电,却发现 redis-server 进程无法拉起,查看服务端日志,报错信息如下:

=== REDIS BUG REPORT START: Cut & paste starting from here ===78114:M 02 Apr 21:59:54.538 #     Redis 3.0.7.6 crashed by signal: 1178114:M 02 Apr 21:59:54.538 #     SIGSEGV caused by address: 0x20000000478114:M 02 Apr 21:59:54.538 #     Failed assertion: <no assertion failed> (<no file>:0)78114:M 02 Apr 21:59:54.538 # --- STACK TRACE/xxx/bin/redis-server(logStackTrace+0x44)[0x494074]
/lib64/libc.so.6(+0x3703a)[0x7fe90a86603a]
/usr/java/jre1.8.0_162/lib/amd64/server/libjvm.so(+0x92b3c2)[0x7fe90b8f23c2]
/usr/java/jre1.8.0_162/lib/amd64/server/libjvm.so(JVM_handle_linux_signal+0xb6)[0x7fe90b8f9196]
/usr/java/jre1.8.0_162/lib/amd64/server/libjvm.so(+0x928253)[0x7fe90b8ef253]
/lib64/libpthread.so.0(+0xf7c0)[0x7fe90abb57c0]
/lib64/libc.so.6(+0x3703a)[0x7fe90a86603a]
/xxx/bin/redis-server(clusterLoadConfig+0x117)[0x49d257]
/xxx/bin/redis-server(clusterInit+0xfd)[0x49d99d]
/opt/xxx/bin/redis-server(initServer+0x595)[0x464ec5]
/opt/xxxs/bin/redis-server(main+0x412)[0x465ef2]
/lib64/libc.so.6(__libc_start_main+0xe6)[0x7fe90a84dc36]
/opt/xxx/bin/redis-server[0x45a029]78114:M 02 Apr 21:59:54.538 # --- INFO OUTPUT

问题根因

通过排查,我们发现问题根因为宕机节点上的 Redis 集群配置文件 nodes-xxx.conf 存在异常,最后一行信息不完整,如下所示:

正常的集群配置文件 nodes-xxx.conf 最后一行的形式如下:

vars currentEpoch 36 lastVoteEpoch 36

故障节点 nodes-xxx.conf 最后一行的形式:

vars currentEpoch

Redis 集群一旦创建完成,每一个节点都会生成一个保存集群基本信息的配置文件 (nodes-xxx.conf),当下线的节点重新上线时,会加载这个配置文件以恢复集群。这个过程中会调用一系列函数的调用,主要如下:

main()->initServer()->clusterInit(void)->clusterLoadConfig(char *filename)

加载配置文件的函数 clusterLoadConfig(char *filename) 部分代码如下:

/* Split the line into arguments for processing. */
        argv = sdssplitargs(line,&argc);        if (argv == NULL) goto fmterr;        /* Handle the special "vars" line. Don't pretend it is the last
         * line even if it actually is when generated by Redis. */
        if (strcasecmp(argv[0],"vars") == 0) {            for (j = 1; j < argc; j += 2) {                if (strcasecmp(argv[j],"currentEpoch") == 0) {
                    server.cluster->currentEpoch =
                            strtoull(argv[j+1],NULL,10);
                } else if (strcasecmp(argv[j],"lastVoteEpoch") == 0) {
                    server.cluster->lastVoteEpoch =
                            strtoull(argv[j+1],NULL,10);
                } else {
                    redisLog(REDIS_WARNING,                        "Skipping unknown cluster config variable '%s'",
                        argv[j]);
                }
            }
            sdsfreesplitres(argv,argc);            continue;
        }        /* Regular config lines have at least eight fields */
        if (argc < 8) goto fmterr;

如上代码所示,在加载配置文件时,由于配置文件存在上述错误,经过分割参数 argc=2(空格也计算在内)argv =["vars","currentEpoch"],由于 currentEpoch 存在,将会执行 strtoull(argv[j+1],NULL,10),即为:strtoull(argv[2],NULL,10),而 argv[2] 事实上是不存在的,因此报错。

解决方案

修改源码,增加校验机制防止发生此类错误:对于一个宕机的节点,它的 currentEpoch 必然是小于等于在线的节点的,一旦宕机的节点重新上线,也会根据收到的其它节点的报文更新自己的 currentEpoch,因此,可以考虑为 currentEpoch 设置一个默认值,当 nodes-xxx.conf 出错时,可以采用默认的默认值。 另外,需要对下面这一行代码进行容错处理,这行代码会检验 nodes-xxx.conf 最后一行是否完整,不完整则报错。

/* Regular config lines have at least eight fields */
        if (argc < 8) goto fmterr;

补充

Redis 集群配置文件 nodes-xxx.conf 如果出现错误,对应的节点宕机后无法自愈。除了上面介绍的报错案例,nodes-xxx.conf 的缺损情况不同,报错内容也有区别,比如,报错形式 2:

=== REDIS BUG REPORT START: Cut & paste starting from here ===55251:M 02 Apr 19:38:35.892 # ------------------------------------------------55251:M 02 Apr 19:38:35.892 # !!! Software Failure. Press left mouse button to continue55251:M 02 Apr 19:38:35.892 # Guru Meditation: "Unknown flag in redis cluster config file" #cluster.c:20855251:M 02 Apr 19:38:35.892 # (forcing SIGSEGV in order to print the stack trace)55251:M 02 Apr 19:38:35.892 # ------------------------------------------------55251:M 02 Apr 19:38:35.892 #     Redis 3.0.7.6 crashed by signal: 1155251:M 02 Apr 19:38:35.892 #     SIGSEGV caused by address: 0xffffffffffffffff55251:M 02 Apr 19:38:35.892 #     Failed assertion: <no assertion failed> (<no file>:0)55251:M 02 Apr 19:38:35.892 # --- STACK TRACE/opt/xxx/bin/redis-server(logStackTrace+0x44)[0x494074]
/opt/xxx/bin/redis-server(_redisPanic+0x7e)[0x493b4e]
/usr/java/jre1.8.0_162/lib/amd64/server/libjvm.so(+0x92b3c2)[0x7fe450d0f3c2]
/usr/java/jre1.8.0_162/lib/amd64/server/libjvm.so(JVM_handle_linux_signal+0xb6)[0x7fe450d16196]
/usr/java/jre1.8.0_162/lib/amd64/server/libjvm.so(+0x928253)[0x7fe450d0c253]
/lib64/libpthread.so.0(+0xf7c0)[0x7fe44ffd27c0]
/opt/xxx/bin/redis-server(_redisPanic+0x7e)[0x493b4e]
/opt/xxx/bin/redis-server(clusterLoadConfig+0x70e)[0x49d84e]
/opt/xxx/bin/redis-server(clusterInit+0xfd)[0x49d99d]
/opt/xxx/bin/redis-server(initServer+0x595)[0x464ec5]
/opt/xxxbin/redis-server(main+0x412)[0x465ef2]
/lib64/libc.so.6(__libc_start_main+0xe6)[0x7fe44fc6ac36]

原文发布于微信公众号 - GitChat精品课(CSDN_Tech)

原文发表时间:2018-05-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Linux Python 加油站

什么是爬虫?python爬虫基本知识

把互联网比喻成一个蜘蛛网,那么Spider就是在网上爬来爬去的蜘蛛。 网络蜘蛛是通过网页的链接地址来寻找网页的。

1723
来自专栏AndroidTv

讲讲断点续传那点儿事提问理论基础代码示例

这次想来讲讲断点续传,以前没相关需求,所以一直没去接触,近阶段了解了之后,其实并不复杂,那么也便来写一篇记录一下,分享给大伙,也方便自己后续查阅。

942
来自专栏北京马哥教育

Python爬虫基本知识:什么是爬虫?

豌豆贴心提醒,本文阅读时间5分钟 一、网络爬虫的定义 网络爬虫,即Web Spider,是一个很形象的名字。 把互联网比喻成一个蜘蛛网,那么Spider就是...

3436
来自专栏专注于主流技术和业务

axios2教程

axios 是一个基于 promise 的 HTTP 库,用于浏览器和node.js的http客户端,支持拦截请求和响应,自动转换 JSON 数据, 客户端支持...

7512
来自专栏前端布道

HTML5离线应用与客户端存储

支持离线 Web 应用开发是 HTML5 的另一个重点。所谓离线 Web 应用,就是在设备不能上网的情况下仍然可以运行的应用。

1241
来自专栏静晴轩

浅谈android中的目录结构

之前在android游戏开发中就遇到本地数据存储的问题:一般情形之下就将动态数据写入SD中存储,在没有SD卡的手机上就需另作处理了;再有在开发android应用...

34610
来自专栏Seebug漏洞平台

Joomla 权限提升漏洞(CVE-2016-9838)分析

0x00 漏洞概述 1.漏洞简介 Joomla 于12月13日发布了3.6.5的升级公告,此次升级修复了三个安全漏洞,其中 CVE-2016-9838 被官方定...

33310
来自专栏技术之路

go微服务框架go-micro深度学习(一) 整体架构介绍

      产品嘴里的一个小项目,从立项到开发上线,随着时间和需求的不断激增,会越来越复杂,变成一个大项目,如果前期项目架构没设计的不好,代码会越来越臃肿,难以...

1.1K3
来自专栏Alice

1、大部分社交平台接口不支持https协议。

参考文献来自:http://wiki.mob.com/ios9-%E5%AF%B9sharesdk%E7%9A%84%E5%BD%B1%E5%93%8D%EF%...

3595
来自专栏前端杂货铺

Nodejs cluster模块深入探究

由表及里 HTTP服务器用于响应来自客户端的请求,当客户端请求数逐渐增大时服务端的处理机制有多种,如tomcat的多线程、nginx的事件循环等。而对于nod...

54810

扫码关注云+社区

领取腾讯云代金券