在我们转向用Couchbase开发之前，理解大体的 Couchbase 架构是很有用的。虽然，在单节点集群上编码应当通常和在10个节点的集群上没什么不同，支撑一个产品应用确实需要深入理解当你的应用需要横向扩展时，会有什么问题发生。下面的章节中，我将详细阐述一些我们已经看到的概念，以及关于 Couchbase 集群是如何工作的一些基础知识。
1、Couchbase 集群
对于所有的 Couchbase 部署来说，集群是一个基础的概念。它在 NoSQL 世界中是一个常见的术语，通常就是指一组节点相互协调地在数据存储上执行操作。然而，不同的 NoSQL 产品，集群中节点是如何表现的变化很大。在一些系统中，所有的节点 are peers（平辈，同事），没有区别。在其他一些系统中，集群是通过主从配置建立起来的。
在一个 Couchbase cluster 中，节点间是相互可交换信息的。每一个节点都包含了一个集群管理器负责了解集群中其他节点的状态，也让其他节点了解自己的状态。因为每个节点都有自己的集群管理器组件，this allows Couchbase Server to scale out linearly with no single point of failure。
2、复制
集群管理器的最重要的任务之一就是确保所有的数据对于客户端来说都是可用的。Couchbase Server 复制是这么工作的：让一个节点成为某个文档的主节点，最多3个从节点维护那个文档的一个副本。当集群管理器检测到一个节点故障，它就会负责将 replicas 提升为主节点。
3、Balancing and rebalancing
Sharding 就是将数据均匀地分散到集群中的节点上。在大多数 sharded systems，管理员负责选择一个 shard key 用于数据分发。例如，a Users table might be sharded on a Username field。如果这个 shard key 被证实 to be poorly distributed(imagine 30 percent of users having usernames starting with T)，then the nodes will not be well balanced。
Couchbase，相反，是 auto-sharded 并保证了 balance。还记得 Couchbase documents 是使用 key/value 方式存储的。尽管用户提供 key，Couchbase SDKs 在每个key上使用一个strong and cryptographic hash 来保证这些key将会均匀地分布在集群中。该 hasing 动作考虑了集群的拓扑，这就意味着，不管是2个还是20个节点，这些key仍然是balanced。
即使 SDKs 以及 服务器一起确保正确的sharding，如果一个节点（或多个节点）脱机了（goes offline），这样的balance将会临时被打破。这是因为 replicas 被提升了。当有节点被添加或移除时，集群管理器将会 reblance the data across the nodes。一个新添加的节点可能没有准备好完全加入到集群中，直到执行了一个 rebalance。前面说过，可以在 Couchbase Console 中完成此任务。