Couchbase 架構

    在我們轉向用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 中完成此任務。