How Meizu Scales Cloud Sync: Protocols, Architecture & Data Handling

Background

In Meizu's mobile application scenario, cloud sync keeps data consistent across devices, covering contacts, notes, messages, call logs, calendars, files, etc., via client and server components.

Meizu Cloud Sync launched in 2008 and now serves tens of millions of users. The following sections share its sync protocols, architecture, deployment, and data processing.

Business Definition and Sync Protocols

MZ‑SyncML Protocol

MZ‑SyncML is a redesign of Microsoft SyncML (four‑step sync) tailored for Meizu, focusing on structured data such as contacts, calendars, notes, call logs, and messages. It uses JSON for data exchange and consists of interface layer, sync point management, data parsing, intermediate cache, sync engine, sync strategies, conflict resolution, and mapping management.

Supported sync strategies include Two‑way (200), Slow sync (201), Client‑refresh (203), and Server‑refresh (205). Sync points include ClientAnchor and ServerAnchor for managing incremental data.

A full sync consists of four phases: Request, SubmitData, GetData, Result, with fields like sessionId, isFinal, clientData, serverData, and resultList.

Semi‑Sync Protocol

Semi‑Sync adds a SemiAnchor to avoid duplicate uploads and pulls when a sync fails, distinguishing it from MySQL semi‑synchronous replication.

During a 201 (slow) sync, the client submits data, the server writes successful items, returns mapping and updates SemiAnchor. On retry, the client filters out already synced items using SemiAnchor and Mapping, preventing duplicate transmission.

File‑Sync Protocol

File‑Sync, derived from MZ‑SyncML, handles file‑type data. It synchronizes a list of changed files and uploads/downloads as needed, ensuring file objects stay consistent with their parent objects (e.g., contact avatar sync type must match the contact sync type).

One‑Sync Protocol

One‑Sync performs a single interaction to sync small data such as contact groups, notes groups, quick replies, email accounts, and browser bookmarks. Data is modeled as {key, value} where key is a unique identifier and value is a JSON object of attributes.

It supports N (new), U (update), D (delete) operations, with updates on keys decomposed into N and D. Only one sync point (ServerAnchor) is used. The client sends SyncType, ServerAnchor, and changes; the server compares, stores, and returns new SyncType, changes, and New_ServerAnchor.

One‑Sync supports sync types 200, 201, 203, 205. Example: a 205 (server‑refresh) sync where the client receives all server data, replaces local data, and prepares for a fast 200 sync next time.

Sync Failure Handling

Both client and server mark each data item as success or failure. If any item fails, the whole sync is considered failed. Subsequent syncs reuse the previous sync points, leveraging the Semi‑Sync mechanism to avoid retransmission.

Service Architecture

The cloud sync service scales linearly with user count. Over multiple redesigns, Meizu built a modular backend comprising contact, SMS, call‑log, and file‑sync modules, each deployed in separate service units within an IDC.

Interface specifications define mandatory and optional parameters (e.g., userid, imei, sn) and a unified JSON response format with error codes.

Modules are isolated to balance load and simplify maintenance. File sync runs after its parent object sync completes, and its sync type must match the parent’s.

Routing and Data Sharding

Data volume reaches billions of records, requiring horizontal sharding by userid across multiple databases. A routing component (SyncRouter) maps userid to a specific database, unit, Redis instance, or file system, providing transparent access and self‑managed connection pools.

Hot data is stored in relational databases, while cold data uses NoSQL (e.g., HBase for contact backups).

Multi‑IDC Deployment

Three IDC sites host the service, with routing rules directing users to the nearest IDC. Data is isolated per IDC, with asynchronous replication for disaster recovery. GSLB directs traffic based on user IP, and clients access sync services via IP to avoid DNS hijacking.

For browser access, a GSLB module distributes requests across sub‑domains mapped to IDC sites.

Traffic Optimization

Data compression (gzip/deflate) and compact data formats reduce bandwidth. The system evolved from XML to JSON, then to a streamlined JSON (short field names, omit nulls) and evaluated Protobuf. The compact JSON achieved 40‑60% traffic reduction, comparable to Protobuf.

Conclusion

The article summarizes Meizu's sync protocols, architectural deployment, and data handling insights. MZ‑SyncML and Semi‑Sync form the core sync solution, while File‑Sync and One‑Sync address specific business needs. The multi‑IDC, GSLB, and routing design ensure high availability, and the compact JSON approach demonstrates an effective data exchange strategy.