Overview of Zhuanzhuan's Storage Infrastructure and Service Architecture
This article introduces Zhuanzhuan's multi‑service storage layer—including MySQL, TiDB, ZZRedis, ZZKV/ZZList, and ZZOS—detailing their applicable scenarios, architectural designs, and the improvements made to address scalability, security, and resource‑usage challenges.
Zhuanzhuan has rapidly expanded its business scenarios, requiring a diversified storage infrastructure; the company now offers several storage services such as MySQL, TiDB, ZZList, ZZRedis, and ZZOS to meet various needs.
The current infrastructure diagram (see image below) shows how these services compose the storage system, satisfying different business requirements.
MySQL : a traditional relational database used for storing fixed relational data.
TiDB : a distributed SQL database that addresses MySQL's scalability and throughput limitations for large‑scale data.
ZZRedis : a distributed Redis service built on Codis, providing cache capabilities while addressing Codis's shortcomings.
Codis‑based architecture lacked permission management, audit, traffic isolation, platform controls, and incurred high memory consumption. ZZRedis adds a new management portal, key‑based client routing, traffic and latency statistics, and a solid KV store to offload memory‑intensive workloads.
ZZOS : an object storage service for permanent storage of images, videos, audio, and text files, offering simple HTTP upload/download interfaces without complex file splitting; high availability is achieved via master‑slave replication.
The system exposes HTTP endpoints for storage, routing, and management. Storage clusters store binary data in groups (one master, one slave). Routing clusters handle load balancing and dispatch. Management clusters maintain user information and file indexes, with authentication performed by the WebServer.
File upload selects an appropriate group via the routing cluster, stores data on storage nodes, records the index in a DB, and returns a URL. Download uses the URL’s group information to retrieve the file directly from storage.
KV and KList Storage : To reduce memory pressure and support non‑latency‑critical workloads, Zhuanzhuan moved from pure Redis to a solid KV/KList service. Initially evaluated PIKA (Redis‑compatible), but due to failover latency and scalability issues, the team built a custom solution on TiKV, leveraging TiDB’s architecture and providing Redis‑compatible distributed KV/KList storage.
The custom KV/KList service, inspired by Meitu’s open‑source TiTan project, has been deeply customized and is now in production.
TiDB : Previously introduced in another article; its role in the storage ecosystem is acknowledged without repetition.
Overall, Zhuanzhuan's storage system now provides comprehensive services for the business, though continuous effort is required to further improve and optimize the infrastructure.
Zhuanzhuan Tech
A platform for Zhuanzhuan R&D and industry peers to learn and exchange technology, regularly sharing frontline experience and cutting‑edge topics. We welcome practical discussions and sharing; contact waterystone with any questions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.