How JinS Achieves Multi‑Region Data Consistency and High Performance

Background

Rapid business growth forces many companies to move beyond single‑region architectures, which suffer from limited scalability, regional outages, and high latency.

Challenges of Multi‑Active Deployments

Conflicts when writing data across multiple locations.

Network latency and reliability over long distances.

Data‑consistency problems during synchronization.

Idempotency of synchronization.

Data reuse at the synchronization hub.

Multi‑Active Principles

Business Cohesion: Each complete business flow must run within a single data center to ensure low latency and fast state transitions.

Availability First: During failover, system availability is prioritized; temporary inconsistency is tolerated and repaired later.

Data Correctness: On failures, abnormal data conflicts trigger manual intervention to guarantee correctness.

Product Features of JinS

Bidirectional Sync: Real‑time incremental synchronization between data sources.

Unidirectional Sync: MySQL → MySQL, MySQL → Redis, supporting disaster‑recovery and heterogeneous sync.

Data Subscription: Cache notifications, asynchronous decoupling, real‑time ETL, etc.

Consistency Check: End‑to‑end MySQL consistency verification and repair.

Data Migration: MySQL and heterogeneous migrations.

Consistency Assurance Exploration

1. Architecture Design

The data‑sync architecture consists of a Subscription Module (parser, sink, store, registry, monitor, protocol) and a Consumption Module (input, filter, output, registry, monitor). Supporting services include a Manager platform, Consul for service registration, and Prometheus/Grafana/AlertManager for monitoring.

2. Microkernel Architecture

The system adopts a plugin‑based microkernel design similar to Eclipse, UNIX, or Dubbo, separating core services (plugin loading, registration, communication) from business‑specific plugins.

3. Data‑Sync Architecture

The consumption module mirrors the microkernel approach, making components like registry, monitor, input, filter, and output pluggable. Output plugins follow the Java SPI/Dubbo SPI pattern (interface + strategy + config file).

Consistency Model Exploration

Sequential Consistency: Guarantees order within a process and across nodes.

Linearizability: Provides a single‑copy abstraction where all operations appear atomic.

Crash‑Safe via Two‑Phase Commit (2PC)

MySQL’s redo log and binlog are kept consistent using a 2PC protocol. The consumption module acts as the coordinator and the subscription module as the participant, ensuring that either both redo and binlog are persisted or both are rolled back.

Bidirectional Consistency

When both sites can modify the same record, a pre‑write consensus (e.g., Paxos) orders writes, and a post‑write reconciliation resolves conflicts using a trusted‑source rule (e.g., latest timestamp) and a conflict pool.

Single‑Loop Scheme

For low‑volume sites, a ring‑shaped synchronization loop guarantees eventual consistency, though network delays may cause version alternation or loss.

Practical Optimizations

1. File Storage

An MMap‑based file queue with index files reduces pressure on downstream databases. Initial read‑write‑lock implementation yielded ~800 qps; switching to a lock‑free design using ByteBuffer for writes and MMapByteBuffer for reads increased throughput to ~20 k qps.

2. Relay Log

Inspired by MySQL’s relay‑log, JinS separates I/O and SQL threads, using a relay log in the store and a ring buffer for consumption, reducing network impact.

3. Two‑Phase Lock

InnoDB row locks are held until transaction end. By postponing lock acquisition and merging DML statements for the same primary key, lock wait time is reduced. Batch processing of 1 000 inserts drops from 13 000 ms to 500 ms.

Performance Metrics

Benchmarks against leading open‑source and commercial solutions show JinS achieving roughly double the throughput of open‑source alternatives and about 30 % lower throughput than commercial products, while offering higher stability (99.999 % availability, second‑level cross‑region latency).

Conclusion

Compared with open‑source products, JinS delivers roughly a 2× performance boost.

Against commercial products, performance is about 30 % lower, but stability is higher.