# X-Pipe: cross-datacenter Redis replication with a disk-backed keeper layer from Ctrip

> X-Pipe is an Apache-2.0 Java system from Ctrip's infrastructure team that replicates Redis data across datacenters using a keeper component that acts as a pseudo-slave and caches replication logs to disk. The open-source release matches the internal production version, and the keeper model addresses specific failure modes in native Redis replication under cross-datacenter network conditions.

**ctripcorp/x-pipe** — X-Pipe is a Redis multi-datacenter replication management system developed by Ctrip's framework team. Built on the Redis master-slave replication protocol, it provides low-latency, highly available cross-datacenter and cross-WAN Redis replication, with one-click failover, replication monitoring and alerting. The open-source version matches Ctrip's internal production version.

- Repository: https://github.com/ctripcorp/x-pipe
- Stars: 2,088 · Forks: 509
- Language: Java
- License: Apache-2.0
- Published: 2026-10-11 · Updated: 2026-10-11 · Language: en
- Canonical page: https://hysenlabs.com/projects/ctripcorp-x-pipe

## The two Redis problems X-Pipe was built to solve at Ctrip's write scale

Redis at Ctrip's scale makes single-datacenter operation a practical liability. The README cites roughly 20 million read and write requests per second across all systems, with write requests at approximately 1 million per second, and notes that some services treat Redis as a persistent store rather than a cache. At that volume, either a datacenter outage that takes down Redis entirely or the latency penalty of cross-datacenter reads becomes a service-level problem.

X-Pipe addresses both by maintaining Redis replicas in multiple datacenters. Each datacenter reads from its own local Redis instances. When a datacenter goes down, a one-click DR switch promotes a replica datacenter to primary. The README states that the open-source version shipped to GitHub is identical to the version running in Ctrip's internal production environment.

Native Redis replication is not a drop-in solution for this. Each remote slave that connects directly to a master triggers a separate full synchronization. On an unstable cross-datacenter link, when the connection drops and reconnects, the Redis in-memory ring buffer may have already wrapped, forcing another full sync. X-Pipe's keeper layer exists to break both of those constraints.

## The keeper pseudo-slave: one stream crosses the link, logs cache on disk

X-Pipe implements the Redis replication protocol from scratch to create the keeper. From the master's point of view, the keeper is a slave, so the master pushes its replication stream to it. Remote datacenter slaves then attach to the keeper, not to the master, so the full synchronization count stays at one regardless of how many remote replicas exist.

Between any two datacenters, exactly one data stream crosses the inter-datacenter link. The keeper-to-keeper protocol is designed to support custom compression and encryption over that link. The README notes that compression is not yet implemented and encryption is also not yet implemented, which matters for deployments that send replication traffic over the public internet.

The more operationally significant difference from native replication is the log storage. Redis holds its replication backlog in a memory ring buffer of fixed size. When the buffer fills during a network outage, partial resync becomes impossible and a full resync is required when the link recovers. Keeper writes its log to disk instead, so a substantially larger backlog is available, and incremental resync remains possible after longer outage windows than Redis's ring buffer would allow.

## What the three-component design separates and why each boundary matters

Splitting X-Pipe into Console, Keeper and MetaServer separates concerns that are hard to combine. Console holds the cross-datacenter topology view and exposes it through a web interface. DR switching happens through Console rather than through direct Redis commands against masters and slaves in multiple locations. This makes a datacenter switch an auditable operator action rather than a scripted sequence of Redis commands.

Keeper pairs run per Redis cluster per datacenter, with a primary keeper and a standby. The standby replicates from the primary in real time. If the primary fails, MetaServer promotes the standby. Failure recovery for the replication path is therefore local to each datacenter, with no dependency on Console being reachable at the moment of the failover.

MetaServer holds within-datacenter topology state and owns keeper state transitions. Multiple MetaServer nodes share responsibility for the Redis clusters in a datacenter: each node covers a specific set of clusters, and when a MetaServer goes down its clusters are taken over by the remaining nodes. When a new MetaServer joins, automatic load balancing redistributes clusters to it. The project builds with Maven (pom.xml at the repository root), and the services/ directory holds the runnable components for each role.

## Docker quick start, the three separate processes and the cross-public-network proxy.md

The README does not include a complete install command. The Docker quick-start path is documented at https://github.com/ctripcorp/x-pipe/wiki/QuickStart#docker-start. General documentation is at the project wiki (https://github.com/ctripcorp/x-pipe/wiki), and a Q&A page at https://github.com/ctripcorp/x-pipe/wiki/XPipe-Q&A covers common setup questions.

For a production deployment, Console, MetaServer and Keeper run as separate processes and need to be configured to reach each other. Console is the single entry point for cross-datacenter operations. MetaServer nodes are deployed per datacenter. Keepers are deployed per Redis cluster per datacenter in primary-standby pairs.

The repository also includes a doc/proxy.md file that covers cross-public-network deployment architecture, relevant when datacenters are connected only through the public internet rather than a private backbone. The redis/ directory at the repository root contains Ctrip's Redis 3.0.7-derived source with the psync2.0 modifications described later in this article, which is a dependency for the keeper's incremental sync behavior.

## The DR switching sequence: write disable, promotion, and the prepare check

X-Pipe's one-click DR switch enforces an ordered sequence that prevents the most common failure mode during Redis datacenter transitions. The most dangerous moment in such a switch is the window between making the old primary read-only and establishing the new one, because a split-brain condition during that window can cause data loss.

Before any state changes, a prepare phase runs that the README compares to the first phase of a two-phase commit. This confirms the switch can complete cleanly before anything is modified. Only after that check passes does X-Pipe disable writes on the original primary datacenter's master. The write-disable step ensures exactly one writeable master exists throughout the transition. The new primary datacenter's master is then promoted, and remaining datacenters direct their replication at it.

Rollback returns the system to the state before the switch attempt was made. Retry allows a database administrator to intervene, resolve an anomalous condition manually, and resume the switch from the stopped step rather than restarting from the beginning. Both paths are part of the one-click interface in Console.

## Latency test data from Ctrip's environment and the psync2.0 fork on Redis 3.0.7

X-Pipe's README includes latency measurements from two test setups. In a controlled environment, direct Redis master-to-slave replication measured 0.2ms. Adding one keeper layer increased total latency by 0.1ms to 0.3ms. These numbers are from a test configuration, not from the production measurements in the following paragraph.

Ctrip's own production environment showed an inter-datacenter ping round-trip of approximately 0.61ms between two datacenters. Through two keeper layers in that environment, the measured average replication latency was approximately 0.8ms, with the 99.9th percentile at 2ms. Both sets of figures come from Ctrip's specific network topology and should not be assumed to translate to other infrastructure.

The psync2.0 implementation in the redis/ directory addresses a Redis replication problem that affected versions before 4.0. Electing a new master in that era caused all connected slaves to perform a full resync, temporarily making slaves unavailable and increasing master load. X-Pipe took Redis 3.0.7 as the base and implemented the psync2.0 incremental sync protocol. The specification from the Redis author is at https://gist.github.com/antirez/ae068f95c0d084891305. Ctrip's modified Redis is maintained separately at https://github.com/ctripcorp/redis. Redis 4.0 introduced native psync2 behavior; for clusters already on 4.0 or later, the keeper-level fork is less necessary.

## Last release v1.2.0 from 2020-08-24, Apache-2.0 license and what remains unfinished

The last tagged release is v1.2.0, published on 2020-08-24. Before it came v1.0.0-release on 2018-11-30. The last push to master was on 2026-09-30, so the codebase has received changes since the last release, but no release has been tagged since August 2020. Teams evaluating X-Pipe will find that the tagged version and the current master state diverge without a documented changelog between them.

Two features in the keeper-to-keeper protocol are explicitly noted as not yet implemented in the README: compression for cross-datacenter transfers and encryption for transfers over public networks. For deployments that need to send replication traffic over the internet without relying on a VPN or dedicated link, the absence of built-in encryption is a gap to close externally.

The license is Apache 2.0 as stated in the LICENSE file at the repository root. Community support is through a QQ group visible in the README's contact section. Deeper background on the architecture is available in a WeChat article and a Ctrip conference presentation linked at the bottom of the README, both written in Chinese.

## Conclusion

X-Pipe suits infrastructure teams who run Redis across multiple datacenters, need one-click DR switching, and want to reduce full-sync pressure on Redis masters during long network outages. Skip it if Redis 4.0 or later psync2 already covers your sync requirements, or if keeper-to-keeper compression and encryption are required since those features are not yet implemented. Before deploying, read the Docker quick-start guide at https://github.com/ctripcorp/x-pipe/wiki/QuickStart#docker-start and confirm whether the Redis 3.0.7-derived psync2.0 fork in the redis/ directory is compatible with the Redis version your cluster currently runs.

## FAQ

### What does X-Pipe do?

X-Pipe replicates Redis data across multiple datacenters using a keeper component that acts as a Redis pseudo-slave, caches replication logs to disk, and relays data to remote slaves. It also provides one-click DR switching between datacenters and replication monitoring.

### How does X-Pipe's keeper reduce master load compared to native Redis replication?

With native Redis replication, each remote slave triggers a separate full synchronization on the master. X-Pipe's keeper receives one sync from the master and serves all remote slaves from its own log cache, so master load stays constant regardless of replica count.

### What is the latency overhead of adding a keeper layer?

Ctrip's test measurements show that one keeper layer adds approximately 0.1ms to replication latency, from 0.2ms for direct master-to-slave replication to 0.3ms with one keeper. In Ctrip's production environment with a 0.61ms inter-datacenter ping RTT, average latency through two keeper layers was approximately 0.8ms, with the 99.9th percentile at 2ms.

### How do I install X-Pipe?

The README points to a Docker quick-start guide at https://github.com/ctripcorp/x-pipe/wiki/QuickStart#docker-start. The wiki at https://github.com/ctripcorp/x-pipe/wiki covers general setup and the Q&A page there collects answers to common questions.

### Does X-Pipe support encryption for cross-datacenter replication?

The README states that keeper-to-keeper transfers are designed to support encryption for transmissions over public networks, but notes that this feature is not yet implemented. Teams sending replication traffic over the internet need to handle encryption externally.

## Sources

- [ctripcorp/x-pipe on GitHub](https://github.com/ctripcorp/x-pipe)
- [Issues](https://github.com/ctripcorp/x-pipe/issues)
- [License: Apache-2.0](https://github.com/ctripcorp/x-pipe/blob/master/LICENSE)
- [README](https://github.com/ctripcorp/x-pipe/blob/master/README.md)
- [Releases](https://github.com/ctripcorp/x-pipe/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ctripcorp-x-pipe