一、redis
1 redis資料庫完全在記憶體中，因此處理速度非常快，每秒能執行約11萬集合，每秒約81000+條記錄；
2 redis的資料能確保一致性——所有redis操作是原子性（atomicity，意味著操作的不可再分，要麼執行要麼不執行）的，這保證了如果兩個客戶端同時訪問的redis伺服器將獲得更新後的值。
優點：1. 非常豐富的資料結構；
2. redis提供了事務的功能，可以保證一串 命令的原子性，中間不會被任何操作打斷；
3. 資料存在記憶體中，讀寫非常的高速，可以達到10w/s的頻率。
缺點：1. redis3.0後才出來官方的集群方案，但仍存在一些架構上的問題（出處）；
2. 持久化功能體驗不佳——通過快照方法實現的話，需要每隔一段時間將整個資料庫的資料寫到磁碟上，代價非常高；而aof方法只追蹤變化的資料，類似於mysql的binlog方法，但追加log可能過大，同時所有操作均要重新執行一遍，恢復速度慢；
3. 由於是記憶體資料庫，所以，單台機器，儲存的資料量，跟機器本身的記憶體大小。雖然redis本身有key過期策略，但是還是需要提前預估和節約記憶體。如果記憶體增長過快，需要定期刪除資料。
適用場景：
適用於資料變化快且資料庫大小可遇見（適合記憶體容量）的應用程式。
couchbase
couchbase server 是個面向文件的資料庫（其所用的技術來自於apache couchdb專案），能夠實現水平伸縮，並且對於資料的讀寫來說都能提供低延遲的訪問（這要歸功於membase技術）。
1.特點
1.1 資料格式
couchbase 跟 mongodb 一樣都是面向文件的資料庫，不過在往 couchbase 插入資料前，需要先建立 bucket —— 可以把它理解為「庫」或「表」。
因為 couchbase 資料基於 bucket 而導致缺乏表結構的邏輯，故如果需要查詢資料，得先建立 view（跟rdbms的檢視不同，view是將資料轉換為特定格式結構的資料形式如json）來執行。
bucket的意義 —— 在於將資料進行分隔，比如：任何 view 就是基於乙個 bucket 的，僅對 bucket 內的資料進行處理。乙個server上可以有多個bucket，每個bucket的儲存型別、內容占用、資料複製數量等，都需要分別指定。從這個意義上看，每個bucket都相當於乙個獨立的例項。在集群狀態下，我們需要對server進行集群設定，bucket只側重資料的保管。
每當views建立時， 就會建立indexes， index的更新和以往的資料庫索引更新區別很大。 比如現在有1w資料，更新了200條，索引只需要更新200條，而不需要更新所有資料，map/reduce功能基於index的懶更新行為，大大得益。
要留意的是，對於所有檔案，couchbase 都會建立乙個額外的 56byte 的 metadata，這個 metadata 功能之一就是表明資料狀態，是否活動在記憶體中。同時檔案的 key 也作為識別符號和 metadata 一起長期活動在記憶體中。
1.2 效能
couchbase 的精髓就在於依賴記憶體最大化降低硬碟i/o對吞吐量的負面影響，所以其讀寫速度非常快，可以達到亞毫秒級的響應。
couchbase在對資料進行增刪時會先體現在記憶體中，而不會立刻體現在硬碟上，從記憶體的修改到硬碟的修改這一步驟是由 couchbase 自動完成，等待執行的硬碟操作會以write queue的形式排隊等待執行，也正是通過這個方法，硬碟的i/o效率在 write queue 滿之前是不會影響 couchbase 的吞吐效率的。
鑑於記憶體資源肯定遠遠少於硬碟資源，所以如果資料量小，那麼全部資料都放在記憶體上自然是最優選擇，這時候couchbase的效率也是異常高。
但是資料量大的時候過多的資料就會被放在硬碟之中。當然，最終所有資料都會寫入硬碟，不過有些頻繁使用的資料提前放在記憶體中自然會提高效率。
1.3 持久化
其前身之一 memcached 是完全不支援持久化的，而 couchbase 新增了對非同步持久化的支援：
couchbase提供兩種核心型別的buckets —— couchbase 型別和 memcached 型別。其中 couchbase 型別提供了高可用和動態重配置的分布式資料儲存，提供持久化儲存和復**務。
couchbase bucket 具有永續性 —— 資料單元非同步從記憶體寫往磁碟，防範服務重啟或較小的故障發生時資料丟失。永續性屬性是在 bucket 級設定的。
couchbase 群集所有點都是對等的，只是在建立群或者加入集群時需要指定乙個主節點，一旦結點成功加入集群，所有的結點對等。
對等網的優點是，集群中的任何節點失效，集群對外提供服務完全不會中斷，只是集群的容量受影響。
由於 couchbase 是對等網集群，所有的節點都可以同時對客戶端提供服務，這就需要有方法把集群的節點資訊暴露給客戶端，couchbase 提供了一套機制，客戶端可以獲取所有節點的狀態以及節點的變動，由客戶端根據集群的當前狀態計算 key 所在的位置。
▲小塊資料，小資料量下redis以更小的資源消耗提供了更高的ops和更快的服務速度，因其介面設計不同，相較couchbase還減少了網路傳輸。因此，redis更適合作為乙個更輕更快的元件整合到整個系統中。
▲小資料塊，大資料量下
redis以更低的資源消耗提供了和couchbase相當的資料寫入ops，但此時的服務速度已經明顯落後於couchbase；資料讀取操作上couchbase以更低的響應時間提供了幾乎三倍於redis的ops（配置了view index，4.0以後的n1ql能進一步提高查詢效能）。因此對於擁有一定的資料規模，且寫少查多的場景，couchbase無疑是更加合適的選擇。
▲大塊資料，小資料量下
在同樣未經優化的情況下，redis集群不發生崩潰已經是幸事(後續我們會推出針對性的優化建議以及實測報告)，如果你需要進行整頁快取，或檔案儲存，又沒有足夠的精力去完成集群優化管理和異常分析處理，建議選擇couchbase。
▲大塊資料，大資料量下
二選一的情況下，直接選擇couchbase。
Couchbase 集群小實踐
區域網 兩台機 192.168.1.2 我們稱為a機器 192.168.1.3 我們稱為b機器 配置集群的時候,從a或者是b的web後台都可以新增,在這裡 我們以 a機器為主 目前a機器裡面 有桶乙個 default 資料不多 目前b機器裡面 有桶2個 分別是 default 和 needpwd 我...
Couchbase 集群小實踐
區域網 兩台機 192.168.1.2 我們稱為a機器 192.168.1.3 我們稱為b機器 配置集群的時候,從a或者是b的web後台都可以新增,在這裡 我們以 a機器為主 目前a機器裡面 有桶乙個 default 資料不多 目前b機器裡面 有桶2個 分別是 default 和 needpwd 我...
安裝 Couchbase 伺服器
選擇 windows 的版本。如果你選 32 位版，那麼檔案為 couchbase server enterprise 2.5.0 x86.setup.exe，而 64 位版的安裝檔案為 couchbase server enterprise 2.5.0 x86 64.setup.exe，看來已經包...