What Is a Distributed Database?什么是分布式数据库？
For the full topic map and the neighboring methods that support this workflow, continue with the federated queries and data virtualization guide.
如需查看完整主题结构以及支撑本流程的相邻方法，请继续阅读联邦查询与数据虚拟化指南。
A distributed database is one logical database whose data and processing are placed across multiple networked nodes, while a distributed database management system coordinates metadata, routing, reads, writes, transactions, replication, failure and recovery. Users may see one database endpoint even though a request crosses machines, zones or regions.
分布式数据库是一个逻辑数据库，其数据与处理被放置在多个联网节点上，同时由分布式数据库管理系统协调元数据、路由、读写、事务、复制、故障与恢复。即使一个请求跨越机器、可用区或地域，用户仍可能只看到一个数据库端点。
Distribution is not a guarantee of speed, availability or unlimited scale. Each claimed benefit depends on where records and replicas live, how requests are routed, which failures the replica layout can survive, when a write is acknowledged, and what the application sees during delay or partition. The useful unit of evaluation is an observable contract, not the word “distributed.”
“分布式”并不保证速度、可用性或无限扩展。每一项收益都取决于记录与副本的位置、请求路由方式、副本布局能承受哪些故障、写入何时确认，以及延迟或网络分区时应用会看到什么。真正有用的评估单位是可观察契约，而不是“分布式”这个标签。
Quick test: if removing one node changes only capacity or availability—not the identity of the logical database—you are probably examining a distributed database. If each database retains a separate owner, schema and lifecycle and is only queried through a shared view, the pattern is closer to federation.
快速判断：如果移除一个节点只改变容量或可用性，而不改变逻辑数据库的身份，那么它很可能是分布式数据库。如果每个数据库保留不同所有者、Schema与生命周期，只通过共享视图查询，则更接近联邦模式。
Distributed Database vs Sharding, Replication and Federation分布式数据库与分片、复制及联邦的区别
| Pattern模式 | What is distributed分布对象 | Main control model主要控制模型 | Key question关键问题 |
|---|---|---|---|
| Distributed database分布式数据库 | One logical database, data, replicas and execution一个逻辑数据库及其数据、副本与执行 | Coordinated DDBMS or managed service协调式DDBMS或托管服务 | What guarantees survive node and network failure?节点与网络故障下哪些保证仍成立？ |
| Sharding分片 | Distinct key ranges or hash buckets不同键范围或哈希桶 | Shard map, router and placement rules分片映射、路由与放置规则 | Does the key target a shard or broadcast?分片键能否定向路由，还是必须广播？ |
| Replication复制 | Copies of the same data相同数据的多个副本 | Leader, quorum or another replica protocolLeader、Quorum或其他副本协议 | When is a write durable and visible?写入何时持久且可见？ |
| Federated database联邦数据库 | Access across autonomous component databases跨自治组件数据库的访问 | Local owners plus a mediation layer本地所有者加中介层 | How is autonomy preserved?如何保留自治？ |
| Data integration数据集成 | Data movement and transformation between systems系统间的数据移动与转换 | Pipelines, mappings and target models管道、映射与目标模型 | How is data delivered and reconciled?数据如何交付与核对？ |
These categories overlap. A distributed database may shard and replicate every partition. A replicated database can distribute copies without partitioning the dataset. A distributed database can be relational or non-relational, and one distributed cluster can participate as a component in a database federation. Compare exact data ownership, placement, transaction and failure behavior.
这些类别可以重叠。分布式数据库可以对每个分区同时进行分片与复制；复制数据库可以分布副本但不分割数据集；分布式数据库可以是关系型或非关系型，一个分布式集群也能作为数据库联邦中的组件。应比较准确的数据所有权、位置、事务与故障行为。
How Distributed Database Architecture Works分布式数据库架构如何工作
- A client reaches a stable endpoint.客户端访问稳定端点。
A driver, load balancer, gateway or database router authenticates the caller and selects an available node. “Any node” access still requires documented routing and session behavior.
驱动、负载均衡器、网关或数据库路由器验证调用者并选择可用节点。“任意节点”访问仍需要明确的路由与Session行为。
- Metadata resolves data placement.元数据解析数据位置。
A partition map or catalog identifies which range, shard, tablet or replica group owns the requested key space. Stale metadata must refresh safely.
分区映射或目录识别哪个Range、Shard、Tablet或副本组负责请求键空间。陈旧元数据必须安全刷新。
- The request is routed and decomposed.请求被路由与分解。
Single-partition work can target one group; multi-partition queries may fan out and merge results. Distributed transactions add coordination before commit.
单分区工作可定向一个组；跨分区查询可能扇出并合并结果。分布式事务会在提交前增加协调。
- Replicas agree according to the write contract.副本按写入契约达成一致。
Depending on the system, a leader, quorum or another protocol determines whether a mutation is accepted and when it becomes durable and readable.
根据系统不同，Leader、Quorum或其他协议决定变更是否被接受，以及何时变得持久和可读。
- The coordinator returns explicit semantics.协调器返回明确语义。
The response should distinguish committed, rejected, retriable and unknown outcomes. A timeout does not by itself prove that a write failed.
响应应区分已提交、已拒绝、可重试与结果未知。超时本身不能证明写入失败。
- Control loops repair and rebalance.控制循环修复并再平衡。
Background services detect failed nodes, restore replica counts, split or move partitions and publish evidence. Movement must preserve correctness and capacity headroom.
后台服务检测失败节点、恢复副本数、拆分或移动分区并发布证据。数据移动必须保持正确性与容量余量。
The CockroachDB architecture overview is one concrete example: SQL requests become operations over distributed ranges, ranges are replicated, and writes use consensus. MongoDB uses routers, config metadata and replica-set shards. These illustrate different implementations; neither defines every distributed database.
CockroachDB架构概览提供了一个具体示例：SQL请求转换为针对分布式Range的操作，Range被复制，写入使用共识。MongoDB则使用路由器、配置元数据和Replica Set分片。它们展示不同实现，但都不能定义所有分布式数据库。
Design Partition Keys Around Real Access Patterns围绕真实访问模式设计分区键
A partition key determines placement and often routing. Hash distribution can spread writes but disrupt range locality. Range distribution supports ordered access but can concentrate monotonically increasing keys. Geographic or tenant placement can improve locality and residency control but creates capacity-skew and failover questions. Composite keys may balance these goals if queries include the useful prefix.
分区键决定数据位置，并常常决定路由。哈希分布可分散写入，却会破坏范围就近性；范围分布支持有序访问，但单调递增键可能集中负载；地域或租户放置可改善就近访问与驻留控制，却会产生容量倾斜和故障转移问题。如果查询包含有效前缀，复合键可以平衡这些目标。
Start with measured operations: read and write rate by key, cardinality, value frequency, range scans, joins, transaction boundaries, tenant size, geographic demand and growth. Model the worst popular key—not just the average. The MongoDB sharding documentation shows why targeted queries are more efficient than scatter/gather and why shard-key choice affects balance and routing.
应从测量到的操作开始：按键统计读写速率、基数、值频率、范围扫描、连接、事务边界、租户规模、地域需求与增长。应建模最热门键，而不是只看平均值。MongoDB分片文档说明了为何定向查询通常比Scatter/Gather更高效，以及分片键如何影响均衡与路由。
Do not shard only because the database is large. Identify the exhausted resource, confirm vertical and workload fixes are insufficient, and prove that the proposed key distributes the constrained operation. Distribution adds coordination even when it solves capacity.
不要只因为数据库很大就分片。先识别耗尽的资源，确认纵向扩展与负载优化不足，再证明候选键能够分散受限操作。分布解决容量问题的同时也会增加协调。
Replication Defines Failure Tolerance—not Just Copy Count复制定义故障容忍，而不只是副本数量
Document each replica's role, placement and acknowledgement rule. A write accepted by one node, a majority, every synchronous replica or an asynchronous log has different durability and latency. Specify which combinations of node, disk, rack, zone and region loss remain writable or readable. “Three replicas” means little if all three share a failure domain.
应记录每个副本的角色、位置与确认规则。由一个节点、多数副本、所有同步副本或异步日志接受的写入具有不同持久性与延迟。必须明确丢失哪些节点、磁盘、机架、可用区或地域组合时仍可写或可读。如果三个副本共享同一故障域，“三个副本”几乎没有意义。
Consensus and quorum protocols coordinate agreement, but they do not replace backups. Replicas can faithfully reproduce deletion, corruption or a bad application write. Keep independent backup and point-in-time recovery controls, test restore into an isolated environment, and verify that metadata, encryption keys and access rules are recoverable too. Google Cloud's Spanner replication documentation illustrates how replica roles and geographic placement shape reads, writes and availability.
共识与Quorum协议协调一致，但不能替代备份。副本会忠实复制删除、损坏或错误应用写入。应保留独立备份与时间点恢复控制，在隔离环境中测试恢复，并验证元数据、加密密钥与访问规则同样可恢复。Google Cloud的Spanner复制文档展示了副本角色与地域位置如何影响读、写与可用性。
Choose Consistency and Transaction Guarantees Per Invariant按业务不变量选择一致性与事务保证
Name the guarantee precisely: linearizable reads, serializable transactions, snapshot isolation, session or causal consistency, bounded staleness, eventual convergence, or a product-specific mode. Then map it to business invariants such as unique allocation, non-negative balance, order state, inventory reservation and read-your-writes. A global label like “strong consistency” is insufficient without scope and failure behavior.
应准确命名保证：线性一致读取、可串行化事务、快照隔离、Session或因果一致性、有界陈旧、最终收敛，或产品专属模式。再把保证映射到业务不变量，例如唯一分配、余额非负、订单状态、库存预留与读己之写。缺少范围和故障行为时，“强一致”这样的全局标签并不充分。
Cross-partition transactions usually require more communication and may retry or abort under contention. Keep atomic units small and place data that changes together near the same partition when the model permits. Treat transaction callbacks as repeatable: external email, payment or queue side effects need an outbox, idempotency key or another explicit protocol because database retry does not undo an outside effect.
跨分区事务通常需要更多通信，并可能在争用下重试或中止。应缩小原子单元，并在模型允许时把共同变化的数据放在同一分区附近。事务回调必须可重复执行：外部邮件、支付或队列副作用需要Outbox、幂等键或其他明确协议，因为数据库重试不能撤销外部影响。
The Gilbert–Lynch CAP theorem publication record concerns simultaneous consistency and availability guarantees during a network partition in an asynchronous model. It does not say that every system permanently selects two letters. Test the exact read and write operation during partition, quorum loss and recovery.
Gilbert–Lynch的CAP定理论文记录讨论异步模型中发生网络分区时能否同时提供一致性与可用性保证。它并不意味着每个系统永久选择两个字母。应针对准确读写操作测试网络分区、Quorum丢失与恢复行为。
When a Distributed Database Fits—and When It Does Not分布式数据库何时适用、何时不适用
| Requirement需求 | Distributed fit signal适用信号 | Caution or alternative注意或替代方案 |
|---|---|---|
| Capacity容量 | Measured reads, writes, storage or I/O exceed one practical node and a key can divide the load实测读、写、存储或I/O超出单节点实际能力，且某个键能分散负载 | First fix indexes, queries, retention and vertical limits先优化索引、查询、留存与纵向上限 |
| Locality就近访问 | Users or regulated data require deliberate regional placement用户或受监管数据需要明确地域放置 | Cross-region writes still pay network and coordination cost跨地域写入仍承担网络与协调成本 |
| Availability可用性 | Documented replica placement survives the required failure domains记录明确的副本放置可承受所需故障域 | A simpler primary–standby design may meet the objective更简单的主备设计可能已经满足目标 |
| Transactions事务 | The system proves required isolation and atomic scope at acceptable contention系统在可接受争用下证明所需隔离与原子范围 | Frequent global transactions may erase scaling gains频繁全局事务可能抵消扩展收益 |
| Operations运维 | The team can operate upgrades, repair, rebalancing, backup and incidents团队能够运营升级、修复、再平衡、备份与事件 | Use a managed service or keep a centralized database if complexity exceeds value若复杂度超过价值，应采用托管服务或保留集中式数据库 |
A distributed database is a poor default for small stable workloads, strict single-site latency, schemas with no useful partition key, transactions that touch most partitions, or teams without capacity and recovery discipline. Distribution moves complexity into the database and network; it does not remove it.
对于小型稳定负载、严格单站点延迟、缺少有效分区键的Schema、触及多数分区的事务，或缺少容量与恢复纪律的团队，分布式数据库通常不是合适默认方案。分布把复杂度移入数据库与网络，并没有消除复杂度。
How to Implement a Distributed Database Safely如何安全实施分布式数据库
- Define one bounded workload and pass conditions.定义一个有边界负载与通过条件。
State operations, invariants, scale, latency, availability, RPO/RTO, regions and prohibited outcomes.
明确操作、不变量、规模、延迟、可用性、RPO/RTO、地域与禁止结果。
- Baseline the existing database.建立现有数据库基线。
Measure query plans, locks, hot keys, I/O, storage, failover and recovery before attributing every problem to one node.
测量查询计划、锁、热点键、I/O、存储、故障转移与恢复，避免把所有问题都归因于单节点。
- Choose the data and replication layout.选择数据与复制布局。
Model hash, range, tenant or geographic keys; place replicas across independent failure domains; calculate quorum behavior.
建模哈希、范围、租户或地域键；跨独立故障域放置副本；计算Quorum行为。
- Map consistency to each operation.为每项操作映射一致性。
Record read freshness, isolation, atomic scope, conflict handling, retry and unknown-outcome behavior.
记录读取新鲜度、隔离、原子范围、冲突处理、重试与结果未知行为。
- Build a representative pilot.构建代表性试点。
Use production-shaped keys, skew, transactions and payloads without exposing uncontrolled production data.
使用接近生产的键、倾斜、事务与Payload，同时避免暴露不受控生产数据。
- Migrate with reconciliation and rollback.通过核对与回滚迁移。
Backfill, capture changes, validate counts and invariants, rehearse cutover and keep a bounded rollback path.
执行回填、捕获变化、验证数量与不变量、演练切换并保留有边界回滚路径。
- Inject node, network and dependency failures.注入节点、网络与依赖故障。
Observe reads, writes, commits, retries, lag, alerts, repair and operator decisions—not merely cluster health.
观察读、写、提交、重试、延迟、告警、修复与操作员决策，而不只是集群健康。
- Operate lifecycle and exit.运营生命周期与退出。
Test upgrades, certificate rotation, resharding, backup restore, region evacuation, decommissioning and data deletion.
测试升级、证书轮换、重新分片、备份恢复、地域撤离、退役与数据删除。
Distributed Database Example: Regional Order Placement分布式数据库示例：地域化订单处理
This is a hypothetical architecture example, not a customer case; all numbers are illustrative. An order service has customers in three regions. Its measured constraint is write latency and capacity during regional peaks, while the key invariant is that one order identifier can be created only once. Most reads and writes use customer and order identifiers; a smaller settlement workflow spans regions.
这是一个假设架构示例，不是客户案例；所有数字仅用于说明。某订单服务在三个地域拥有客户。实测约束是地域峰值期间的写入延迟与容量，关键不变量是一个订单标识只能创建一次。多数读写使用客户与订单标识，较小的结算流程会跨越地域。
The pilot tests a composite placement key that keeps a customer's orders local while spreading large tenants. Each partition has replicas in independent zones; the exact voting and read policy comes from the selected product. The service uses database-enforced uniqueness, idempotency keys for retried order creation, and an outbox for events. Global settlement remains a separate bounded transaction path.
试点测试一个复合放置键，使客户订单保持就近，同时分散大型租户。每个分区的副本位于独立可用区；准确投票与读取策略取决于所选产品。服务使用数据库强制唯一性、针对订单创建重试的幂等键，以及用于事件的Outbox。全球结算保留为独立且有边界的事务路径。
The design passes only if skewed load stays within defined per-node headroom, duplicate retry requests create one order, a zone failure preserves the documented operations, a network partition produces the expected rejection or degraded behavior, repair restores replica health, and backup restore reconciles orders and metadata. If cross-region transactions dominate, the team must redesign ownership or reject the topology rather than hide coordination cost.
只有当倾斜负载保持在定义的单节点余量内、重复重试请求只创建一个订单、可用区故障保留文档规定的操作、网络分区产生预期拒绝或降级行为、修复恢复副本健康，且备份恢复能够核对订单与元数据时，设计才通过。如果跨地域事务占主导，团队必须重新设计所有权或否决该拓扑，而不能隐藏协调成本。
Distributed Database Production Test Matrix分布式数据库生产测试矩阵
| Test测试 | Pass condition通过条件 | Evidence证据 |
|---|---|---|
| Correctness and isolation正确性与隔离 | Golden transactions preserve stated invariants under concurrency and retry黄金事务在并发与重试下保持声明的不变量 | History, transaction result, conflicts and invariant checks历史、事务结果、冲突与不变量检查 |
| Distribution and hotspots分布与热点 | Keys, bytes, operations and tail latency remain inside skew and headroom limits键、字节、操作与尾部延迟保持在倾斜和余量限制内 | Per-partition and per-node histograms按分区和节点的直方图 |
| Node and zone failure节点与可用区故障 | Documented reads and writes continue or reject safely; repair meets target文档规定的读写继续或安全拒绝；修复达到目标 | Fault timeline, quorum, client outcome and repair state故障时间线、Quorum、客户端结果与修复状态 |
| Network partition网络分区 | Each side follows the selected consistency and availability contract without split-brain corruption分区两侧遵循选定的一致性与可用性契约，且无脑裂损坏 | Packet fault, operations, errors, recovery and reconciliation网络故障、操作、错误、恢复与核对 |
| Rebalancing and schema change再平衡与Schema变化 | Movement preserves correctness and stays within latency and capacity budgets移动保持正确性，并处于延迟与容量预算内 | Movement rate, queue, latency, version and error evidence移动速率、队列、延迟、版本与错误证据 |
| Backup and recovery备份与恢复 | Isolated restore meets RPO/RTO and reconciles data, metadata, keys and access隔离恢复满足RPO/RTO，并核对数据、元数据、密钥与访问 | Restore log, timestamps, checksums and application validation恢复日志、时间戳、校验和与应用验证 |
Common Distributed Database Design Failures分布式数据库常见设计失败
- Hot partition: a low-cardinality, monotonically increasing or celebrity key concentrates writes. Revisit the key or isolate the workload.热点分区：低基数、单调递增或“明星”键集中写入。应调整分区键或隔离负载。
- Scatter/gather by default: queries omit the routing key and touch every partition. Add targeted access paths or materialize the analytic workload.默认Scatter/Gather：查询缺少路由键并触及全部分区。应增加定向访问路径或物化分析负载。
- Replica count mistaken for durability: correlated placement leaves all copies exposed to one failure domain. Test actual placement and quorum loss.把副本数误当成持久性：相关放置使所有副本暴露于同一故障域。应测试真实位置与Quorum丢失。
- Blind timeout retry: the first write may have committed. Use idempotency and result lookup. AWS's idempotent API guidance explains why request identity matters.盲目重试超时：第一次写入可能已提交。应使用幂等性与结果查询。AWS的幂等API指南解释了请求身份的重要性。
- Global transaction creep: local operations gradually gain cross-partition checks. Track fan-out and redesign ownership before coordination dominates.全局事务蔓延：本地操作逐渐增加跨分区检查。应跟踪扇出，并在协调成本占主导前重新设计所有权。
- Untested repair: normal load plus replica recovery, resharding or upgrade exhausts headroom. Test background work under peak-shaped traffic.未测试修复：正常负载叠加副本恢复、重新分片或升级耗尽余量。应在峰值形态流量下测试后台工作。
- Replica-only recovery: corruption or deletion reaches every copy. Maintain and restore independent backups.仅依赖副本恢复：损坏或删除会传播到每个副本。必须维护并恢复独立备份。
Where InfiniSynapse Fits in a Distributed Database EvaluationInfiniSynapse在分布式数据库评估中的位置
InfiniSynapse's public website describes direct connections to supported databases and multi-source joint analysis. An approved team can use that scope to inspect representative connected data or reconcile bounded analytical results while evaluating a database topology. The public page does not establish InfiniSynapse as a distributed database, DDBMS, shard router, replication engine, consensus service, transaction coordinator, failover manager or backup system.
InfiniSynapse官网描述了对受支持数据库的直接连接与多源联合分析。获批团队可在评估数据库拓扑时，使用这一能力范围检查代表性已连接数据或核对有边界的分析结果。公开页面并未证明InfiniSynapse是分布式数据库、DDBMS、分片路由器、复制引擎、共识服务、事务协调器、故障转移管理器或备份系统。
Keep placement, consistency, transactions, access control, encryption, workload isolation, backup, recovery and operations in the responsible database platform. Before connected analysis, prepare approved endpoints, supported connection details, permitted schemas, keys and grain, representative queries, expected filters, observation times and a known reconciliation sample.
数据位置、一致性、事务、访问控制、加密、负载隔离、备份、恢复与运维应留在负责的数据库平台中。进行已连接分析前，请准备获批端点、受支持的连接信息、允许的Schema、键与粒度、代表性查询、预期过滤、观察时间与已知核对样本。
When those controls and inputs are ready, use the InfiniSynapse Web App for supported connected-source analysis and result reconciliation. It does not create or operate the distributed database.
当这些控制与输入准备就绪后，可使用InfiniSynapse Web App执行受支持的已连接来源分析与结果核对。它不会创建或运营分布式数据库。
Evaluate connected data评估已连接数据Distributed Database FAQ分布式数据库常见问题
What is a distributed database?
什么是分布式数据库？
A distributed database is one logical database whose data and processing are placed across multiple networked nodes while a distributed database management system coordinates metadata, routing, reads, writes, transactions, replication, failure and recovery. The exact placement and guarantees depend on the product and configuration.
分布式数据库是一个逻辑数据库，其数据与处理被放置在多个联网节点上，同时由分布式数据库管理系统协调元数据、路由、读写、事务、复制、故障与恢复。准确的数据位置与保证取决于具体产品及配置。
How does a distributed database work?
分布式数据库如何工作？
A client sends a request through a database endpoint or router. The system resolves metadata, identifies the responsible partition and replicas, routes work to the required nodes, coordinates consistency and transactions, combines results, and returns an outcome with success or failure semantics. Writes may require a leader, quorum or another agreement protocol before commitment.
客户端通过数据库端点或路由器发送请求。系统解析元数据，识别负责的分区与副本，把工作路由到所需节点，协调一致性与事务，组合结果，并以明确的成功或失败语义返回。写入可能需要Leader、Quorum或其他一致协议确认后才能提交。
What is the difference between a distributed and centralized database?
分布式数据库与集中式数据库有什么区别？
A centralized database keeps the primary database service and data on one main system or tightly bounded deployment. A distributed database coordinates data and work across multiple nodes. Distribution can add capacity, locality and failure tolerance, but also adds network latency, partial failures, rebalancing and consistency complexity.
集中式数据库把主要数据库服务与数据保留在一个主系统或边界紧密的部署中；分布式数据库则跨多个节点协调数据与工作。分布可以增加容量、就近访问与故障容忍，但也会增加网络延迟、部分故障、再平衡和一致性复杂度。
Is sharding the same as a distributed database?
分片等同于分布式数据库吗？
No. Sharding partitions a dataset so different key ranges or hash buckets reside on different machines. A distributed database may use sharding, but the complete system also needs metadata, routing, replication, consistency, transaction, security, observability, backup and recovery behavior. Replication without sharding can also be distributed.
不等同。分片把数据集分区，让不同键范围或哈希桶位于不同机器。分布式数据库可以使用分片，但完整系统还需要定义元数据、路由、复制、一致性、事务、安全、可观测性、备份与恢复行为。只有复制而没有分片的数据库也可以是分布式的。
Can a distributed database be relational?
分布式数据库可以是关系型数据库吗？
Yes. Distribution and relational modeling are different dimensions. Distributed SQL systems provide relational schemas and SQL over distributed storage and transactions, while other distributed databases use document, key-value, wide-column or graph models. Verify actual SQL compatibility, constraints, isolation and transaction scope.
可以。分布方式与关系模型是两个不同维度。分布式SQL系统在分布式存储与事务之上提供关系Schema和SQL；其他分布式数据库可采用文档、键值、宽列或图模型。必须验证真实SQL兼容性、约束、隔离级别与事务范围。
Does the CAP theorem mean a distributed database must always choose only two properties?
CAP定理是否意味着分布式数据库始终只能选择两个属性？
No. The Gilbert–Lynch result concerns the guarantees possible during a network partition in an asynchronous model. In practice, systems make operation-specific choices about whether to reject, delay or accept reads and writes, and may offer several consistency modes. CAP is not a complete product score or a substitute for testing latency, durability, transactions and recovery.
不是。Gilbert–Lynch结论讨论异步模型中发生网络分区时能够同时提供的保证。实际系统会按操作决定拒绝、延迟或接受读写，也可能提供多种一致性模式。CAP不是完整的产品评分，也不能替代对延迟、持久性、事务与恢复的测试。
How should a distributed database be tested before production?
分布式数据库上线前应如何测试？
Test result and transaction correctness, shard-key distribution, hotspots, replica lag, quorum loss, node and zone failure, network partition, retry and idempotency, cross-partition work, rebalancing, schema change, backup and point-in-time recovery, credential rotation, load, latency and observability. Define pass conditions from application invariants and recovery objectives.
应测试结果与事务正确性、分片键分布、热点、副本延迟、Quorum丢失、节点和可用区故障、网络分区、重试与幂等、跨分区工作、再平衡、Schema变化、备份与时间点恢复、凭据轮换、负载、延迟及可观测性，并根据应用不变量与恢复目标定义通过条件。
Official and Primary Sources官方与第一方来源
- Google Research: Spanner, Google's globally distributed databaseGoogle Research：Spanner全球分布式数据库论文
- Google Cloud Spanner documentation: replication and replica rolesGoogle Cloud Spanner文档：复制与副本角色
- Google Cloud Spanner documentation: transaction behavior and distributed executionGoogle Cloud Spanner文档：事务行为与分布式执行
- CockroachDB documentation: distributed SQL architecture overviewCockroachDB文档：分布式SQL架构概览
- MongoDB documentation: sharded cluster, routing, shard keys and scatter/gatherMongoDB文档：分片集群、路由、分片键与Scatter/Gather
- AWS DynamoDB documentation: partitions and data distributionAWS DynamoDB文档：Partition与数据分布
- MIT publication record for Gilbert and Lynch's CAP theorem paperMIT关于Gilbert与Lynch CAP定理论文的出版记录
- AWS Builders' Library: making retries safe with idempotent APIsAWS Builders' Library：通过幂等API实现安全重试
- InfiniSynapse public product page for direct database connections and multi-source analysis scopeInfiniSynapse公开产品页：直接数据库连接与多源分析范围
The product documents describe specific implementations, not one universal distributed-database standard. Verify the current edition, topology, region, node type, driver, schema and SQL compatibility, consistency, isolation, transaction scope, replica policy, failure behavior, backup, quotas, limits, licensing and support terms for the exact candidate.
这些产品文档描述的是特定实现，而不是一个通用分布式数据库标准。必须针对准确候选方案验证当前版本、拓扑、地域、节点类型、驱动、Schema与SQL兼容性、一致性、隔离、事务范围、副本策略、故障行为、备份、配额、限制、许可与支持条款。