How Meizu Scales Cloud Sync for Millions: Protocols, Architecture, and Data Strategies

Background

The cloud sync discussed refers to Meizu's service that keeps data consistent across multiple devices in mobile applications, covering contacts, notes, messages, call logs, calendars, and files, with a client‑server model serving millions of users since 2008.

Business Definition and Sync Protocols

2.1 MZ‑SyncML Protocol

MZ‑SyncML is a redesign of Microsoft SyncML, using JSON for data exchange and comprising interface layer, sync point management, data parsing, caching, sync engine, strategies, conflict resolution, and mapping management.

It supports four sync strategies: two‑way (200), slow sync (201), client‑refresh (203), and server‑refresh (205), and defines client and server anchors for incremental data selection.

A complete sync consists of four stages: Request, Submitdata, Getdata, and Result, with sessionId, isFinal, clientData, serverData, and resultList fields.

2.2 Semi‑Sync Protocol

The semi‑sync protocol prevents duplicate uploads and pulls after a failed sync by introducing a SemiAnchor alongside ClientAnchor and ServerAnchor.

Example of a 201 (slow) sync shows how failed items are filtered out in subsequent attempts, avoiding duplicate submissions and unnecessary data retrieval.

2.3 File‑Sync Protocol

File‑Sync, derived from MZ‑SyncML, synchronizes file‑type data using a similar change‑list approach, requiring that file objects align with their parent objects and share the same sync type.

2.4 One‑Sync Protocol

One‑Sync handles small data items (e.g., contact groups, notes, quick replies) in a single interaction, using a {key,value} model where keys are unique identifiers and values are JSON‑encoded attributes.

It supports standard sync types (200, 201, 203, 205) and defines client‑server interactions for uploading sync type, anchor, and changes, then returning updated data and a new server anchor.

2.5 Sync Failure Handling

During Submitdata, the server returns a Result for each item; during Getdata, the client also returns Result statuses. Any failure marks the entire sync as failed, and the next sync reuses the previous anchors to avoid duplicate transmission.

Service Architecture

The service scales with user count, evolving through multiple refactorings into the current architecture.

3.1 Interface Specification

Standardized parameters include fixed ones (userid, imei, sn) and optional ones (APK version, firmware). Responses follow a JSON format with code, message, and value fields, e.g.:

<code>{
  "code":10001,
  "message":"Invalid parameter",
  "value":""
}</code>

3.2 Modularity and Unitization

Core modules (contacts, SMS, call logs) are isolated due to high usage, while file sync is separated for targeted I/O optimizations. Services are partitioned into units (≤5 per IDC), each handling a manageable user segment for scalability and risk mitigation.

3.3 Massive Data and Routing Component

Data volumes reach billions of records, requiring horizontal sharding by userid across multiple databases, managed by a SyncRouter that maps userid to DB, unit, Redis, and file system, providing transparent access and low coupling.

Hot data uses RDB, while cold data (e.g., contact backups) uses NoSQL such as HBase.

3.4 Multi‑Datacenter Deployment

Three IDC sites host the service, with routing rules directing users to the nearest IDC. Data is replicated between sites for disaster recovery, and GSLB directs traffic based on IP region, avoiding DNS hijacking.

3.5 Traffic Optimization

Data transmission uses gzip/deflate compression and a compact JSON format (short field names, no nulls) that reduces traffic by 40‑60% compared to standard JSON, approaching Protobuf efficiency.

Conclusion

The article summarizes Meizu's sync protocols, architectural deployment, and data handling insights, highlighting the core solutions of MZ‑SyncML and Semi‑Sync, the business‑oriented File‑Sync and One‑Sync, and the multi‑IDC, GSLB, and routing components that ensure high availability, along with practical data exchange optimizations.

Produced by Meizu Flyme Technology Academy.