1：Aerospike數據庫是Shared-Nothing架構，集群中的每個節點都是相同的，不會出現單點故障。
Aerospike有智能分區算法，即把用戶輸入的key在內部根據RIPEMD-160算法，重新hash出一個key並取前20位，然后相對均衡的把數據分布到各個節點之上。並且滿足namespace配置文件的配置（例如保存多少個備份、是存在磁盤還是存在內存中）。官方說：隨機分布函數可以保證數據分布誤差在1-2%之間。（這里有個坑，后續再討論）
如上，一個4個節點的集群，每個節點存儲1/4數據的主節點，同時也存儲1/4數據的副本。如果節點1不可訪問，節點1的副本將被拷貝到其他節點上。
復制因子（ replication factor）是一個配置參數，不能超過集群節點數。副本越多可靠性越高。但是作為必須經過所有數據副本的寫請求也越高。實踐中，大部分部署使用的數據因子為2（一份主數據和一個副本）。
同步復制保證即時一致性，沒有數據丟失。在提交數據並返回結果給客戶端之前，寫事務被傳播到所有副本。個別案例中，在集群重新配置期間，當Aerospike智能終端發送請求到那些短暫過時的錯誤節點時，Aerospike智能集群會透明的代理請求至正確的節點。最后，當集群正在從分區中恢復，它解決所有發生在不同副本之間的沖突。解析可以配置為自動的，在這種情況下擁有最新的時間戳的數據被視為標准。或者為了在更高層次解析，所有數據副本可以被返回應用程序。
namespace是Aerospike數據庫以相同方式存儲的數據的集合。每個namespace分為4096個分區，分區被均等的分到集群中的節點。意味着如果集群中有n個節點，每節點約存儲1/n的數據
用非常隨機數哈希方法保證分區均勻分布。我們已經在這個領域的許多案例中測試過我們的方法，數據分布誤差在1-2%。
因為數據均勻且隨機的分布於節點，不會出現熱點和瓶頸。也不會出現明顯的某個節點比其他節點處理請求多的情況。
例如，在美國很多的姓以R開頭。如果數據按照字母排序存儲，存儲以R開頭的服務器其通訊量會遠遠大於存儲以X，Y或Z開頭的服務器。數據隨機分配保證服務器負載均衡。
下一步，無須人工分片。集群節點間均等的划分分區。客戶端發現集群變化並發送請求到正確的節點。定節點被添加或移除，集群自動再平衡。集群中所有節點是均等的-沒有單獨的master節點失敗而導致整個數據庫宕掉。
當數據庫create一個條記錄，記錄key的哈希值被用來分配記錄到某一分區，哈希算法是確定的-哈希算法總是將記錄映射到同樣分區。在記錄的整個生命周期它駐留在同一節點上。分區可能從一個節點移動到其他節點。但是分區不會分裂或者重新分配記錄到其他分區
集群中每個節點有一個配置文件。每個節點上的namespace配置參數必須一致。
考慮4節點集群的情況。Aerospike數據庫中，無復制數據需要設置復制因子為1（replication factor = 1），意思是數據庫中只存在一個副本。
因為所有4096個分區在一個4節點集群中，每個節點有1/4的數據-隨機分配的1024個分區。集群看起來如下圖，每個節點管理一個分區集合（簡單起見，只展示兩個節點的分區）：
每個節點是1/4數據分區的主數據節點-如果節點是數據的主讀寫源，那么它就是主數據節點。
客戶端對數據有位置感知能力-客戶端知道每個分區的位置-索引數據可以單跳從節點返回。每個讀寫請求發送至主數據節點處理。當智能節點讀某條記錄時，它發送請求到記錄的主數據節點。
現在考慮一下帶數據復制的情況。大多數情況是維護兩個數據副本，主數據和副本。Aerospike數據庫中，需要指定復制因子為2（replication factor = 2）。
在這個例子中，每個節點擁有1/4的主數據（1024個分區）和1/4的數據副本（1024個分區）。看起來像這樣（簡單起見，顯示兩個節點的細節）
注意，每個節點的主數據作為副本被分布到所有的其他節點。例如，節點#1的主數據分區副本橫跨其他節點分布。當節點#1不可用，節點#1的數據副本延伸至跨其他數據節點。
與先前提到的無副本的例子一樣，客戶端發送請求至主數據。
與無復制的情況一樣，讀請求通過智能客戶端發送至正確的節點，寫請求也被發送至正確的節點。當節點收到寫請求，它保存數據並轉發寫請求到副本節點。一旦副本節點確認數據寫成功並且主數據節點本身也完成寫動作，然后確認被發送至客戶端，寫操作成功。
復制因子不能超過集群中節點的數量。越多副本越可靠，但是對於穿越所有副本的寫請求的需求也越高。實踐中，多數數據庫復制因子為2。
Aerospike數據再平衡算法保證請求量在所有節點間均勻分布，在再平衡期間節點失敗發生時，算法依舊健壯。系統被設計為持續可用，所有數據再平衡不影響集群行為。事務算法與數據分布系統集成，只有一個一致投票來協調集群變化。當客戶端發現新的集群配置時，利用集群內部重定向算法，只有一個小的間隔。這樣，在一個可伸縮的無共享機制優化事務簡單環境,同時保ACID特征。
Aerospike允許配置選項指定有多少可用的操作開銷應該用於管理任務,例如與運行客戶端事務相比有多少用於節點間再平衡。在首選事務放緩的情況下，集群愈合更快。在交易量和速度必須維持的情況下，集群再平衡會很慢。
在某些集群因子不能滿足的情況下。集群可以配置為減少配置因子以保持所有數據，或者清除哪些標記為可丟棄的就數據。如果集群不成接受更多數據，集群將在read-only模式下操作，直到新的擴容可用-節點會自動變為可以接受應用程序的寫操作。
不需要操作員干預，甚至在要求的時間內，集群將自愈。在客戶部署中，提取8節點集群中的一個會讓整個回路被打斷。這就需要無人工干預。即使數據中心在高峰時宕機，事務依舊保持精確的ACID。幾小時內，當錯誤被修復，操作者不需要執行特殊步驟來維護集群。
我們的擴容計划和系統監控，為你提供處理不可預見的錯誤的能力，而且無服務丟失。你可以配置硬件容量、設置復制/同步策略，這樣數據庫恢復時可以對用戶無影響。
http://www.aerospike.com/docs/architecture/data-distribution.html