携程开源Redis多数据中心解决方案XPipe
Redis在携程内部得到了广泛的使用,根据客户端数据统计,整个携程全部Redis的读写请求在每秒200W,其中写请求约每秒10W,很多业务甚至会将Redis当成内存数据库使用。
这样,就对Redis多数据中心提出了很大的需求,一是为了提升可用性,解决数据中心DR(Disaster Recovery)问题;二是提升访问性能,每个数据中心可以读取当前数据中心的数据,无需跨机房读数据。在这样的需求下,XPipe应运而生 。
从实现的角度来说,XPipe主要需要解决三个方面的问题,一是数据复制,同时在复制的过程中保证数据的一致性;二是高可用,Xpipe本身的高可用和Redis系统的高可用;三是如何在机房异常时,进行DR切换。
下文将会从这三个方面对问题进行详细阐述。最后,将会对测试结果和系统在生产环境运行情况进行说明。
为了方便描述,后面的行文中用DC代表数据中心(Data Center)。
一、数据复制问题
多数据中心首先要解决的是数据复制问题,即数据如何从一个DC传输到另外一个DC,通常有如下方案:
客户端双写
从客户端的角度来解决问题,单个客户端双写两个DC的服务器。初看没有什么问题。但是深入看下去,如果写入一个IDC成功,另外一个IDC失败,那数据可能会不一致,为了保证一致,可能需要先写入一个队列,然后再将队列的数据发送到两个IDC。如果队列是本地队列,那当前服务器挂掉,数据可能会丢失;如果队列是远程队列,又给整体的方案带来了很大的复杂度。
目前的应用一般都是集群部署,会有多个客户端同时操作。在多个客户端的前提下,又带来了新的问题。比如两个客户端ClientA和ClientB:
ClientA: set key value1
ClientB: set key value2
由于两个客户端独立操作,到达服务器的顺序不可控,所以可能会导致两个DC的服务器对于同一个key,value不一致,如下:
Server1: set key value1; set key value2;
Server2: set key value2; set key value1;
在Server1,最终值为value2,在Server2,最终值为value1。
服务器代理
proxy模式解决了多客户端写可能会导致数据不一致的问题。proxy类似于一个client,和单个client双写的问题类似,需要一个数据队列保数据一致性。
为了提升系统的利用率,单个proxy往往需要代理多个Redis server,如果proxy出问题,会导致大面积的系统故障。这样,就对系统的性能和可用性提出了极大的挑战,带来实现的复杂度。
此外,在特殊的情况下,仍然会可能带来数据的不一致,比如value和时间相关,或者是随机数,两个Redis服务器所在系统的不一致带来了数据的不一致。
考虑到以上情况,为了解决复制问题,我们决定采用伪slave的方案,即实现Redis协议,伪装成为Redis slave,让Redis master推送数据至伪slave。这个伪slave,我们把它称为keeper,如下图所示:
有了keeper之后,多数据中心之间的数据传输,可以通过keeper进行。keeper将Redis日志数据缓存到磁盘,这样,可以缓存大量的日志数据(Redis将数据缓存到内存ring buffer,容量有限),当数据中心之间的网络出现较长时间异常时仍然可以续传日志数据。
Redis协议不可更改,而keeper之间的数据传输协议却可以自定义。这样就可以进行压缩,以提升系统性能,节约传输成本;多个机房之间的数据传输往往需要通过公网进行,这样数据的安全性变得极为重要,keeper之间的数据传输也可以加密,提升安全性。
二、高可用
任何系统都可能会挂掉,如果keeper挂掉,多数据中心之间的数据传输可能会中断,为了解决这个问题,需要保证keeper的高可用。我们的方案中,keeper有主备两个节点,备节点实时从主节点复制数据,当主节点挂掉后,备节点会被提升为主节点,代替主节点进行服务。
提升的操作需要通过第三方节点进行,我们把它称之为MetaServer,主要负责keeper状态的转化以及机房内部元信息的存储。同时MetaServer也要做到高可用:每个MetaServer负责特定的Redis集群,当有MetaServer节点挂掉时,其负责的Redis集群将由其它节点接替;如果整个集群中有新的节点接入,则会自动进行一次负载均衡,将部分集群移交到此新节点。
Redis也可能会挂,Redis本身提供哨兵(Sentinel)机制保证集群的高可用。但是在Redis4.0版本之前,提升新的master后,其它节点连到此节点后都会进行全量同步,全量同步时,slave会处于不可用状态;master将会导出rdb,降低master的可用性;同时由于集群中有大量数据(RDB)传输,将会导致整体系统的不稳定。
截止当前文章书写之时,4.0仍然没有发布release版本,而且携程内部使用的Redis版本为2.8.19,如果升到4.0,版本跨度太大,基于此,我们在Redis3.0.7的版本基础上进行优化,实现了psync2.0协议,实现了增量同步。
下面是Redis作者对协议的介绍:https://gist.github.com/antirez/ae068f95c0d084891305。
三、DR切换
DR切换分为两种可能,一种是机房真的挂了或者出异常,需要进行切换,另外一种是机房仍然健康,但是由于演练、业务要求等原因仍然需要切换到另外的机房。XPipe处理机房切换的流程如下:
- 检查是否可以进行DR切换
类似于2PC协议,首先进行prepare,保证流程能顺利进行。 - 原主机房master禁止写入
此步骤,保证在迁移的过程中,只有一个master,解决在迁移过程中可能存在的数据丢失情况。 - 提升新主机房master
- 其它机房向新主机房同步
当然了,即使做了检查,也无法绝对保证整个迁移过程肯定能够成功,为此,我们提供回滚和重试功能。回滚功能可以回滚到初始的状态,重试功能可以在DBA人工介入的前提下,修复异常条件,继续进行切换。
根据以上分析,XPipe系统的整体架构如下所示:
Console用来管理多机房的元信息数据,同时提供用户界面,供用户进行配置和DR切换等操作。Keeper负责缓存Redis操作日志,并对跨机房传输进行压缩、加密等处理。Meta Server管理单机房内的所有keeper状态,并对异常状态进行纠正。
四、测试数据
我们关注的重点在于增加keeper后,平均延时的增加。测试方式如下图所示。从client发送数据至master,并且slave通过keyspace notification的方式通知到client,整个测试延时时间为t1+t2+t3。
首先我们测试Redis master直接复制到slave的延时,为0.2ms。然后在master和slave之间增加一层keeper,整体延时增加0.1ms,到0.3ms。相较于多个DC之间几毫秒,几十毫秒的延时,增加一层keeper带来的延时是完全没问题的。
在携程生产环境进行了测试,生产环境两个机房之间的ping RTT约为0.61ms,经过跨数据中心的两层keeper后,测试得到的平均延时约为0.8ms,延时99.9线为2ms。
综上所述:XPipe主要解决Redis多数据中心数据同步以及DR切换问题,同时,由于XPipe增强后的Redis版本优化了psync协议,会极大的提升Redis集群的稳定性。
同时,整个系统已经开源,欢迎大家一起参与优化整个系统:
XPipe: https://github.com/ctripcorp/x-pipe
XRedis(在Redis3.0.7版本上进行增强的版本):
https://github.com/ctripcorp/redis
携程开源Redis多数据中心解决方案XPipe相关推荐
- 携程开源Redis多数据中心解决方案-XPipe
https://zhuanlan.zhihu.com/p/27125444 Redis在携程内部得到了广泛的使用,根据客户端数据统计,整个携程全部Redis的读写请求在每秒200W,其中写请求约每秒1 ...
- 干货 | 快速融入云原生,携程开源 Dubbo for Go 版本
作者简介 何鑫铭,携程基础中台研发部技术专家,dubbo-go 主要作者.目前专注于 Golang & Java.中台架构.中间件与区块链等技术. *本文来自开源中国对何鑫铭的采访,首发于开源 ...
- 携程开源配置管理中心Apollo简介
一.为什么需要配置中心? 由于程序日益复杂,相应的配置也越来越多,对配置的期望也会变高(比如实时性,分环境管理),因此我们需要一个配置中心去管理我们的配置. 二.Apollo是什么? Apollo是携 ...
- rn源码ios_携程开源RN开发框架CRN
作者|赵辛贵 来源|携程技术中心 经过近两个月的准备,携程无线平台研发团队正式将内部的React Native开发框架 - CRN 实现开源.CRN对原生的React Native框架进行了大量架构简 ...
- python 携程 apollo_手把手教你使用携程开源框架Apollo(阿波罗)
配置中心 在现实的Coding工作中,我们是否会遇到这样的问题,我们本地开发环境会用到一套配置参数和配置文件,测试环境会用到另一套配置参数和配置文件,然而项目打包发布时又会用到一套配置参数和配置文件. ...
- 携程Apollo分布式配置中心搭建指南
Apollo配置中心介绍 Apollo(阿波罗)是携程框架部门研发的开源配置管理中心,能够集中化管理应用不同环境.不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限.流程治理等特性. ...
- apollo修改配置刷新bean_携程开源的分布式apollo技术整合springboot集成实现动态刷新配置
分布式apollo简介 Apollo(阿波罗)是携程框架部门研发的开源配置管理中心,能够集中化管理应用不同环境.不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限.流程治理等特性. 本 ...
- SpringCloud - Spring Cloud 之 Apollo Config携程阿波罗配置中心(二十一)
由于Spring Cloud自带的Config 需要配合 Bus 使用,且不能实时刷新,因此市面上出现了很多开元的配置中心 市面上开源的配置中心 Apollo(阿波罗):携程框架部门研发的分布式配置中 ...
- 干货 | 终于来了!携程开源RN开发框架 - CRN
作者简介 赵辛贵,携程无线平台研发部开发总监.2013年加入携程,主要负责App基础框架研发相关工作,曾参与Native.Hybrid和React Native框架设计.工程模块化.Android插件 ...
最新文章
- python中font_Python ColorFont包_程序模块 - PyPI - Python中文网
- docker ps 只显示容器名称 显示列名
- python入门新手项目-Python入门实战项目有哪些适合新手?
- 转:Oracle 应用服务器 MapViewer 10.1.2截图
- 玩具版VR盒子没玩够?小米正式开放高端VR头显的开发机申请
- 2020 操作系统第二天复习(习题总结)
- 2009最后一天,为了期盼而祝福
- Android Studio导入project和module的方法
- 金九银十专供 | 175 道 Go 工程师必考面试题 + 详细解答
- 来自一个用户的体验-Alpha项目测试
- 帮你理解vue的数据绑定的流程
- python输入整数反转输出_Python反转输出正整数
- 专利分析的方法和流程
- VM虚拟机安装CentOS7添加硬盘扩展存储空间的方法
- 作为一名31岁的软件测试员,工作3年,月薪不到2W,担心被应届生取代
- 四年Android面试遇到的问题整理,值得收藏!
- 基于大数据的线上线下电商用户数据挖掘研究
- 整理chinaUnix上【你职业生涯中最难忘的误操作】
- windows怎么查看本地80端口被占用
- 第三章 栈与队列(二)
热门文章
- 基于微信小程序的药店管理系统设计与实现-计算机毕业设计源码+LW文档
- MAC OS程序的签名问题
- 我的数据分析师转行之路
- 比特币 事务ID txID transaction hash怎么计算
- StandFord的parser的调用API
- yum 安装daemonize 错误:依赖检测失败: daemonize 被 jenkins-2.303.1-1.1.noarch 需要
- CCIE-DMVPN阶段二
- Bilibili直播弹幕抓取(1):WebSocket
- 再告菲氏微积分的徒子徒孙,无穷小放飞互联网不可阻挡
- App的打磨之路(中)