X-Pipe是由携程框架部门研发的Redis多数据中心复制管理系统。基于Redis的Master-Slave复制协议,实现低延时、高可用的Redis多数据中心复制,并且提供一键机房切换,复制监控、异常报警等功能。
Clone or download
Pull request Compare This branch is 908 commits behind ctripcorp:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
core
doc
redis
services
.gitignore
.travis.yml
LICENSE
README.md
codetemplates.xml
pom.xml
xpipe-stype.xml

README.md

x-pipe

[master]

Build Status Coverage Status Coverity Scan Build Status

[dev]

Build Status Coverage Status

XPipe 解决什么问题

Redis 在携程内部得到了广泛的使用,根据客户端数据统计,整个携程全部 Redis 的读写请求在每秒 200W,其中写请求约 10W,很多业务甚至会将 Redis 当成内存数据库使用。这样,就对 Redis 多数据中心提出了很大的需求,一是为了提升可用性,解决数据中心 DR(Disaster Recovery) 问题,二是提升访问性能,每个数据中心可以读取当前数据中心的数据,无需跨机房读数据,在这样的需求下,XPipe 应运而生 。

为了方便描述,后面用 DC 代表数据中心(Data Center)。

系统详述

整体架构

整体架构图如下所示:
design

  • Console 用来管理多机房的元信息数据,同时提供用户界面,供用户进行配置和 DR 切换等操作。
  • Keeper 负责缓存 Redis 操作日志,并对跨机房传输进行压缩、加密等处理。
  • Meta Server 管理单机房内的所有 keeper 状态,并对异常状态进行纠正。

Redis 数据复制问题

多数据中心首先要解决的是数据复制问题,即数据如何从一个 DC 传输到另外一个 DC。我们决定采用伪 slave 的方案,即实现 Redis 协议,伪装成为 Redis slave,让 Redis master 推送数据至伪 slave。这个伪 slave,我们把它称为 keeper,如下图所示:
keepers

有了 keeper 之后,多数据中心之间的数据传输,可以通过 keeper 进行。keeper 将 Redis 日志数据缓存到磁盘,这样,可以缓存大量的日志数据(Redis 将数据缓存到内存 ring buffer,容量有限),当数据中心之间的网络出现较长时间异常时仍然可以续传日志数据。

Redis 协议不可更改,而 keeper 之间的数据传输协议却可以自定义。这样就可以进行压缩,以提升系统性能,节约传输成本;多个机房之间的数据传输往往需要通过公网进行,这样数据的安全性变得极为重要,keeper 之间的数据传输也可以加密,提升安全性。

机房切换

切换流程

  • 检查是否可以进行 DR 切换
    类似于 2PC 协议,首先进行 prepare,保证流程能顺利进行。
  • 原主机房 master 禁止写入
    此步骤,保证在迁移的过程中,只有一个 master,解决在迁移过程中可能存在的数据丢失情况。
  • 提升新主机房 master
  • 其它机房向新主机房同步

同时提供回滚和重试功能。回滚功能可以回滚到初始的状态,重试功能可以在 DBA 人工介入的前提下,修复异常条件,继续进行切换。

高可用

XPipe 系统高可用

如果 keeper 挂掉,多数据中心之间的数据传输可能会中断,为了解决这个问题,keeper 有主备两个节点,备节点实时从主节点复制数据,当主节点挂掉后,备节点会被提升为主节点,代替主节点进行服务。

提升的操作需要通过第三方节点进行,我们把它称之为 MetaServer,主要负责 keeper 状态的转化以及机房内部元信息的存储。同时 MetaServer 也要做到高可用:每个 MetaServer 负责特定的 Redis 集群,当有 MetaServer 节点挂掉时,其负责的 Redis 集群将由其它节点接替;如果整个集群中有新的节点接入,则会自动进行一次负载均衡,将部分集群移交到此新节点。

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 作者对协议的介绍:psync2.0

携程内部 Redis 地址链接

测试数据

延时测试

测试方案

测试方式如下图所示。从 client 发送数据至 master,并且 slave 通过 keyspace notification 的方式通知到 client,整个测试延时时间为 t1+t2+t3。
test

测试数据

首先我们测试 Redis master 直接复制到 slave 的延时,为 0.2ms。然后在 master 和 slave 之间增加一层 keeper,整体延时增加 0.1ms,到 0.3ms。

在携程生产环境进行了测试,生产环境两个机房之间的 ping RTT 约为 0.61ms,经过跨数据中心的两层 keeper 后,测试得到的平均延时约为 0.8ms,延时 99.9 线为 2ms。

深入了解

XPipe Wiki

技术交流

tech-support-qq

License

The project is licensed under the Apache 2 license.