Cassandra是否适用于多站点数据复制、主节点部署及数据过滤？

Great question—your scenario is exactly the kind of distributed, offline-first use case Cassandra was built to handle, and your proposed approach aligns perfectly with its core capabilities. Let’s break this down, including how it solves the gaps you hit with symmetric-ds:

Why Cassandra Fixes Your Symmetric-Ds Pain Point #

First, the biggest issue you faced—offline sync within a site—is solved out of the box with Cassandra’s local cluster architecture. Unlike symmetric-ds, which relies on a central server for all sync (even between local machines), Cassandra’s nodes in the same site (data center) use the Gossip protocol to replicate data in real time. So if machine A writes data offline, machine B in the same site will get that sync as long as they can communicate locally—no need to wait for a connection to the main server.

Your Proposed Architecture: Feasibility & Implementation Details #

Let’s walk through each of your ideas and how to execute them in Cassandra:

1. Each site as its own replica set (even single-machine sites) #

This is fully supported. In Cassandra terms, each site is a data center (DC). Even a single-node DC works perfectly:

• The local node handles all read/write requests while offline, with no dependency on external servers.
• When network connectivity is restored, it automatically syncs with the main DC and other nodes in its own site (if you add more machines later).
• You can configure each DC to only store data relevant to its company using row key design and replication policies (more on that below).

2. Sites replicate data to the main server #

Cassandra’s cross-data center replication (CDC) handles this natively:

• Configure your main site as a central DC, and each regional site as a secondary DC.
• Set up asynchronous replication from secondary DCs to the main DC. This means local writes are persisted immediately, and sync to the main DC happens in the background when network is available—no data loss during offline periods.
• The main DC will store full data from all sites, as required.

3. Main server writes sync only to relevant sites #

This is achievable with a combination of row key design and NetworkTopologyStrategy:

• Embed the company/site identifier as part of your row keys (e.g., {company_id}_{record_id}). This ensures data is sharded by company.
• Use NetworkTopologyStrategy to define replication rules:
  • For the main DC, set a replication factor (RF) that ensures full data redundancy (e.g., RF=3 for high availability).
  • For each secondary DC, set RF=1 (or higher, based on local machine count) only for the keyspaces/tables associated with their company. Alternatively, use filtering replication (available in newer Cassandra versions) to explicitly restrict which data is replicated to each DC.
• When the main DC writes data for a specific company, it will only sync to that company’s associated site DC—no unnecessary data is sent to unrelated sites.

Key Advantages Over Symmetric-Ds + RDBMS #

• Local offline sync: No more waiting for central server connectivity to sync between machines in the same site.
• Built-in replication: No need to maintain a separate sync middleware like symmetric-ds—Cassandra handles all replication logic internally.
• High availability: If one machine in a site goes down, other local nodes can still serve requests (unlike single-machine RDBMS setups).
• Scalability: Easily add more machines to a site or new sites without overhauling your sync architecture.

Critical Considerations #

• Row key design is make-or-break: Get this right to ensure data is properly sharded by company and replicated only to relevant sites. Avoid hotspots by ensuring row keys are distributed evenly.
• Consistency levels: Choose consistency levels based on your needs. For local offline operations, use LOCAL_QUORUM to ensure data consistency across local nodes. For cross-DC sync, ONE or LOCAL_ONE balances performance and durability.
• Monitoring: Use Cassandra’s built-in tools (like nodetool) to monitor replication status, especially for intermittent network environments.

Overall, Cassandra is an excellent fit for your scenario—it addresses all your requirements and solves the core limitation you encountered with your initial approach.

内容的提问来源于stack exchange，提问作者scornflake