我们将会在后面的几章中详细学习 Couchbase SDK 以及相关 APIs。但是要结束我们在 balancing 和 rebalancing 上的讨论，理解从客户端到集群的过程是有用的。当一个SDK在客户端应用中初始化后，它就会在一个 RESTful API 之上建立起到集群的一个持久化连接。该API广播一个JSON消息，其中包含了集群的拓扑。当被加进来或移除掉，集群会发送一个新的消息，里面带的是更新过的拓扑。
This behavior sets Couchbase apart from other databases，不管是关系型的或是非关系型的。大多数数据库系统都有一个中心交互点负责客户端交互。Couchbase owes some of its massive throughput to its smart clients。Eliminating the bottleneck of a man-in-the-middle allows performance levels to reach a massive scale。在一个只有4个节点的集群中，Couchbase 能够实现几乎每秒1百万个操作。
再回到 the idea of balancing data across nodes，有一个额外的细节，我没有提到。集群维护了一个抽象，叫 vBuckets，它用于指引某个key到正确的服务器上去。而不是将key直接映射到一个节点上，Couchbase SDKs 将 key 映射到某个 vBucket。The endpoint for a bucket is provided to the client as part of its topology message from the cluster。不管节点的数量是多少，vBuckets的数量保持一样。The keys always hash to the same vBucket, even if the cluster changes the endpoint of the vBucket。
虽然你通常不需要担心 vBuckets 的存在，但理解集群改变了它的拓扑时，客户端这边都会发生什么是很重要的。客户端维护了 vBuckets 到 nodes 的一个映射。如果由于一个节点故障而使得map变了，brief client failures may appear while the map is updated。
【
唯一的情况，你可能会担心 vBuckets，是如果你用的是 mac os x 在开发应用。在此平台上，Couchbase server 用的是 64 vBuckets，而不是标准的 1024。虽然这个区别通常不会影响你的开发，但它会影响你将数据从你的本地服务器移植到运行Linux或Windows的集群中。
】