Design and Implementation of a Distributed Ticket Order Cache System at Ctrip

Background : With rapid growth in Ctrip's flight ticket business, user and order volumes increased steadily, leading to high query traffic and pressure on the order‑database‑centric query system, especially during peak QPS periods.

Bottleneck : Repeated high‑frequency access to order data caused database I/O and latency issues; traditional master‑slave replication and read‑write splitting only partially alleviated the load, prompting the need for a comprehensive caching solution.

Selection : After evaluating common cache technologies (Memcache, Redis, MongoDB), the team chose Redis for its fast recovery, high performance for simple key‑based lookups, and stable multi‑instance deployment that fits Ctrip's operational requirements.

Architecture : A two‑level cache was built—Level 1 caches entire order‑service responses for a few seconds, while Level 2 caches hot database tables identified from usage statistics. This decouples business services from the order database and improves scalability.

Solution : Both active (pre‑loading) and passive (lazy loading) caching approaches were combined. Two consistency mechanisms were implemented: scanning database change logs to evict stale entries, and subscribing to Ctrip's message notification platform to trigger precise cache updates, keeping latency under 100 ms.

Optimization : The team addressed cache‑penetration, cache‑breakdown, and cache‑avalanche with empty‑value markers, distributed locks, and random expiration offsets. Additional optimizations included time‑segmented expiration, status‑based caching policies, and pre‑loading high‑traffic orders during off‑peak hours.

Summary : After iterative improvements, cache hit rates exceeded 90%, database CPU usage dropped from 60% to 15%, and order‑detail service latency improved from 150 ms to under 120 ms. Techniques such as Redis pipelining, GZIP compression, NIO, and Hystrix circuit breaking further enhanced performance and reliability.