redis去中心化

❶ 如何搭建redis的雙主

這方面最具代表性的是dynamo和bigtable 2篇論文所闡述的思路。前者是一個完全無中心的設計，節點之間通過gossip方式傳遞集群信息，數據保證最終一致性
後者是一個中心化的方案設計，通過類似一個分布式鎖服務來保證強一致性,數據寫入先寫內存和redo log，然後定期compat歸並到磁碟上，將隨機寫優化為順序寫，提高寫入性能。

❷ Redis和Memcached的區別

Redis與Memcached的區別

傳統MySQL+ Memcached架構遇到的問題
實際MySQL是適合進行海量數據存儲的，通過Memcached將熱點數據載入到cache，加速訪問，很多公司都曾經使用過這樣的架構，但隨著業務數據量的不斷增加，和訪問量的持續增長，我們遇到了很多問題：
1.MySQL需要不斷進行拆庫拆表，Memcached也需不斷跟著擴容，擴容和維護工作占據大量開發時間。
2.Memcached與MySQL資料庫數據一致性問題。
3.Memcached數據命中率低或down機，大量訪問直接穿透到DB，MySQL無法支撐。
4.跨機房cache同步問題。
眾多NoSQL百花齊放，如何選擇
最近幾年，業界不斷涌現出很多各種各樣的NoSQL產品，那麼如何才能正確地使用好這些產品，最大化地發揮其長處，是我們需要深入研究和思考的問題，實際歸根結底最重要的是了解這些產品的定位，並且了解到每款產品的tradeoffs，在實際應用中做到揚長避短，總體上這些NoSQL主要用於解決以下幾種問題
1.少量數據存儲，高速讀寫訪問。此類產品通過數據全部in-momery 的方式來保證高速訪問，同時提供數據落地的功能，實際這正是Redis最主要的適用場景。
2.海量數據存儲，分布式系統支持，數據一致性保證，方便的集群節點添加/刪除。
3.這方面最具代表性的是dynamo和bigtable 2篇論文所闡述的思路。前者是一個完全無中心的設計，節點之間通過gossip方式傳遞集群信息，數據保證最終一致性，後者是一個中心化的方案設計，通過類似一個分布式鎖服務來保證強一致性,數據寫入先寫內存和redo log，然後定期compat歸並到磁碟上，將隨機寫優化為順序寫，提高寫入性能。
4.Schema free，auto-sharding等。比如目前常見的一些文檔資料庫都是支持schema-free的，直接存儲json格式數據，並且支持auto-sharding等功能，比如mongodb。
面對這些不同類型的NoSQL產品,我們需要根據我們的業務場景選擇最合適的產品。
Redis適用場景，如何正確的使用
前面已經分析過，Redis最適合所有數據in-momory的場景，雖然Redis也提供持久化功能，但實際更多的是一個disk-backed的功能，跟傳統意義上的持久化有比較大的差別，那麼可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那麼何時使用Memcached,何時使用Redis呢?

如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：

1 Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。

2 Redis支持數據的備份，即master-slave模式的數據備份。

3 Redis支持數據的持久化，可以將內存中的數據保持在磁碟中，重啟的時候可以再次載入進行使用。

拋開這些，可以深入到Redis內部構造去觀察更加本質的區別，理解Redis的設計。

在Redis中，並不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。Redis只會緩存所有的 key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據「swappability = age*log(size_in_memory)」計 算出哪些key對應的value需要swap到磁碟。然後再將這些key對應的value持久化到磁碟中，同時在內存中清除。這種特性使得Redis可以 保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由於Redis將內存 中的數據swap到磁碟中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個 操作，直到子線程完成swap操作後才可以進行修改。

使用Redis特有內存模型前後的情況對比：
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on: 300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on: 1 million keys, 256 bytes values: 160.09M used
VM on: 1 million keys, values as large as you want, still: 160.09M used

當 從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那麼Redis就需要從swap文件中載入相應數據，然後再返回給請求方。 這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件載入後才會相應。這種策略在客戶端的數量較小，進行 批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大並發的情況的。所以Redis運行我們設置I/O線程 池的大小，對需要從swap文件中載入相應數據的讀取請求進行並發操作，減少阻塞的時間。

如果希望在海量數據的環境中使用好Redis，我相信理解Redis的內存設計和阻塞的情況是不可缺少的。

補充的知識點：
memcached和redis的比較
1 網路IO模型
Memcached是多線程，非阻塞IO復用的網路模型，分為監聽主線程和worker子線程，監聽線程監聽網路連接，接受請求後，將連接描述字pipe 傳遞給worker線程，進行讀寫IO, 網路層使用libevent封裝的事件庫，多線程模型可以發揮多核作用，但是引入了cache coherency和鎖的問題，比如，Memcached最常用的stats 命令，實際Memcached所有操作都要對這個全局變數加鎖，進行計數等工作，帶來了性能損耗。

(Memcached網路IO模型)
Redis使用單線程的IO復用模型，自己封裝了一個簡單的AeEvent事件處理框架，主要實現了epoll、kqueue和select，對於單純只有IO操作來說，單線程可以將速度優勢發揮到最大，但是Redis也提供了一些簡單的計算功能，比如排序、聚合等，對於這些操作，單線程模型實際會嚴重影響整體吞吐量，CPU計算過程中，整個IO調度都是被阻塞住的。
2.內存管理方面
Memcached使用預分配的內存池的方式，使用slab和大小不同的chunk來管理內存，Item根據大小選擇合適的chunk存儲，內存池的方式可以省去申請/釋放內存的開銷，並且能減小內存碎片產生，但這種方式也會帶來一定程度上的空間浪費，並且在內存仍然有很大空間時，新的數據也可能會被剔除，原因可以參考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/
Redis使用現場申請內存的方式來存儲數據，並且很少使用free-list等方式來優化內存分配，會在一定程度上存在內存碎片，Redis跟據存儲命令參數，會把帶過期時間的數據單獨存放在一起，並把它們稱為臨時數據，非臨時數據是永遠不會被剔除的，即便物理內存不夠，導致swap也不會剔除任何非臨時數據(但會嘗試剔除部分臨時數據)，這點上Redis更適合作為存儲而不是cache。
3.數據一致性問題
Memcached提供了cas命令，可以保證多個並發訪問操作同一份數據的一致性問題。 Redis沒有提供cas 命令，並不能保證這點，不過Redis提供了事務的功能，可以保證一串 命令的原子性，中間不會被任何操作打斷。
4.存儲方式及其它方面
Memcached基本只支持簡單的key-value存儲，不支持枚舉，不支持持久化和復制等功能
Redis除key/value之外，還支持list,set,sorted set,hash等眾多數據結構，提供了KEYS
進行枚舉操作，但不能在線上使用，如果需要枚舉線上數據，Redis提供了工具可以直接掃描其mp文件，枚舉出所有數據，Redis還同時提供了持久化和復制等功能。
5.關於不同語言的客戶端支持
在不同語言的客戶端方面，Memcached和Redis都有豐富的第三方客戶端可供選擇，不過因為Memcached發展的時間更久一些，目前看在客戶端支持方面，Memcached的很多客戶端更加成熟穩定，而Redis由於其協議本身就比Memcached復雜，加上作者不斷增加新的功能等，對應第三方客戶端跟進速度可能會趕不上，有時可能需要自己在第三方客戶端基礎上做些修改才能更好的使用。
根據以上比較不難看出，當我們不希望數據被踢出，或者需要除key/value之外的更多數據類型時，或者需要落地功能時，使用Redis比使用Memcached更合適。
關於Redis的一些周邊功能
Redis除了作為存儲之外還提供了一些其它方面的功能，比如聚合計算、pubsub、scripting等，對於此類功能需要了解其實現原理，清楚地了解到它的局限性後，才能正確的使用，比如pubsub功能，這個實際是沒有任何持久化支持的，消費方連接閃斷或重連之間過來的消息是會全部丟失的，又比如聚合計算和scripting等功能受Redis單線程模型所限，是不可能達到很高的吞吐量的，需要謹慎使用。
總的來說Redis作者是一位非常勤奮的開發者，可以經常看到作者在嘗試著各種不同的新鮮想法和思路，針對這些方面的功能就要求我們需要深入了解後再使用。
總結：
1.Redis使用最佳方式是全部數據in-memory。
2.Redis更多場景是作為Memcached的替代者來使用。
3.當需要除key/value之外的更多數據類型支持時，使用Redis更合適。
4.當存儲的數據不能被剔除時，使用Redis更合適。

❸ Redis適合存儲海量小文件嗎

最近學習下redis，作為一個高性能的k/v資料庫，如果數據不用swap的話，redis的性能是無以倫比的。最近在做一個系統附件的緩存，試著把附件放到redis試試，寫了個保存文件的方法。public class TestRedis{ Jedis redis = new Jedis("localhost");...

❹ redis能解決什麼問題

redis是內存資料庫，訪問速度非常快，所以能夠解決的也都是些緩存類型的問題，如下：
1、會話緩存（Session Cache）
2、全頁緩存（FPC）
3、隊列
4、排行榜/計數器
5、發布/訂閱

❺ 如何實現高可用的 redis 集群

Redis 因具有豐富的數據結構和超高的性能以及簡單的協議，使其能夠很好的作為資料庫的上游緩存層。但在大規模的 Redis 使用過程中，會受限於多個方面：單機內存有限、帶寬壓力、單點問題、不能動態擴容等。

基於以上， Redis 集群方案顯得尤為重要。通常有 3 個途徑：官方 Redis Cluster ；通過 Proxy 分片；客戶端分片 (Smart Client) 。以上三種方案各有利弊。

Redis Cluster( 官方 ) ：雖然正式版發布已經有一年多的時間，但還缺乏最佳實踐；對協議進行了較大修改，導致主流客戶端也並非都已支持，部分支持的客戶端也沒有經過大規模生產環境的驗證；無中心化設計使整個系統高度耦合，導致很難對業務進行無痛的升級。

Proxy ：現在很多主流的 Redis 集群都會使用 Proxy 方式，例如早已開源的 Codis 。這種方案有很多優點，因為支持原聲 redis 協議，所以客戶端不需要升級，對業務比較友好。並且升級相對平滑，可以起多個 Proxy 後，逐個進行升級。但是缺點是，因為會多一次跳轉，平均會有 30% 左右的性能開銷。而且因為原生客戶端是無法一次綁定多個 Proxy ，連接的 Proxy 如果掛了還是需要人工參與。除非類似 Smart Client 一樣封裝原有客戶端，支持重連到其他 Proxy ，但這也就帶來了客戶端分片方式的一些缺點。並且雖然 Proxy 可以使用多個，並且可以動態增加 proxy 增加性能，但是所有客戶端都是共用所有 proxy ，那麼一些異常的服務有可能影響到其他服務。為每個服務獨立搭建 proxy ，也會給部署帶來額外的工作。

而我們選擇了第三種方案，客戶端分片 (Smart Client) 。客戶端分片相比 Proxy 擁有更好的性能，及更低的延遲。當然也有缺點，就是升級需要重啟客戶端，而且我們需要維護多個語言的版本，但我們更愛高性能。

下面我們來介紹一下我們的Redis集群：

概貌：

如圖0所示，

我們的 Redis 集群一共由四個角色組成:

Zookeeper ：保存所有 redis 集群的實例地址， redis 實例按照約定在特定路徑寫入自身地址，客戶端根據這個約定查找 redis 實例地址，進行讀寫。

Redis 實例：我們修改了 redis 源碼，當 redis 啟動或主從切換時，按照約定自動把地址寫到 zookeeper 特定路徑上。

Sentinel ： redis 自帶的主從切換工具，我們通過 sentinel 實現集群高可用。

客戶端（ Smart Client ）：客戶端通過約定查找 redis 實例在 ZooKeeper 中寫入的地址。並且根據集群的 group 數，進行一致性哈希計算，確定 key 唯一落入的 group ，隨後對這個 group 的主庫進行操作。客戶端會在Z ooKeeper 設置監視，當某個 group 的主庫發生變化時，Z ooKeeper 會主動通知客戶端，客戶端會更新對應 group 的最新主庫。

我們的Redis 集群是以業務為單位進行劃分的，不同業務使用不同集群（即業務和集群是一對一關系）。一個 Redis 集群會由多個 group 組成 ( 一個 group 由一個主從對 redis 實例組成 ) 。即 group 越多，可以部署在更多的機器上，可利用的內存、帶寬也會更多。在圖0中，這個業務使用的 redis 集群由 2 個 group 組成，每個 group 由一對主從實例組成。

Failover

如圖1所示，

當 redis 啟動時，會 把自己的 IP:Port 寫入到 ZooKeeper 中。其中的 主實例模式啟動時會在 /redis/ 業務名 / 組名 永久節點寫入自己的 IP:Port （如果節點不存在則創建）。由 主模式 變成 從模式 時，會創建 /redis/ 業務名 / 組名 /slaves/ip:port 臨時節 點，並寫入自己的 IP:Port （如果相同節點已經存在，則先刪除，再創建）。而從實例 模式 啟動時會創建 /redis/ 業務名 / 組名 /slaves/ip:port 臨時節點，並寫入自己的 ip:port （如果相同節點已經存在，則先刪除，再創建）。由 從模式 變成 主模式 時，先刪除 /redis/ 業務名 / 組名 /slaves/ip:port 臨時節點，並在 /redis/ 業務名 / 組名 永久節點寫入自己的 IP:Port 。

ZooKeeper 會一直保存當前有效的 主從實例 IP:Port 信息。至於主從自動切換過程，使用 redis 自帶的 sentinel 實現，現設置為超過 30s 主 server 無響應，則由 sentinel 進行主從實例的切換，切換後就會觸發以主、從實例通過以上提到的一系列動作，從而完成最終的切換。

而客戶端側通過給定業務名下的所有 groupName 進行一致性哈希計算，確定 key 落入哪個組。 客戶端啟動時，會從 ZooKeeper 獲取指定業務名下所有 group 的 主從 IP:Port ，並在 ZooKeeper 中設置監視（監視的作用是當 ZooKeeper 的節點發生變化時，會主動通知客戶端）。若客戶端從 Zookeeper 收到節點變化通知，會重新獲取最新的 主從 I:Port ，並重新設置監視（ ZooKeeper 監視是一次性的）。通過此方法，客戶端可以實時獲知當前可訪問最新的 主從 IP:Port 信息。

因為我們的所有 redis 實例信息都按照約定保存在 ZooKeeper 上，所以不需要針對每個實例部署監控，我們編寫了一個可以自動通過 ZooKeeper 獲取所有 redis 實例信息，並且監控 cpu 、 qps 、內存、主從延遲、主從切換、連接數等的工具。

發展：

現在 redis 集群在某些業務內存需求超過預期很多後，無法通過動態擴容進行擴展。所以我們正在做動態擴容的支持。原先的客戶端我們是通過一致性哈希進行 key 的
路由策略，但這種方式在動態擴容時會略顯復雜，所以我們決定採用實現起來相對簡單的預分片方式。一致性哈希的好處是可以無限擴容，而預分片則不是。預分片
時我們會在初始化階段指定一個集群的所有分片數量，這個數量一旦指定就不能再做改變，這個預分片數量就是後續可以擴容到最大的 redis 實例數。假設預分片 128 個 slot ，每個實例 10G 也可以達到 TB 級別的集群，對於未來數據增長很大的集群我們可以預分片 1024 ，基本可以滿足所有大容量內存需求了。

原先我們的 redis 集群有四種角色， Smart Client, redis ， sentinel ， ZooKeeper 。為了支持動態擴容，我們增加了一個角色， redis_cluster_manager （以下簡稱 manager ），用於管理 redis 集群。主要工作是初始化集群（即預分片），增加實例後負責修改Z ooKeeper 狀態，待客戶端做好准備後遷移數據到新增實例上。為了盡量減少數據遷移期間對現性能帶來的影響，我們每次只會遷移一個分片的數據，待遷移完成，再進行下一個分片的遷移。

如圖2所示

相比原先的方案，多了 slots 、M anager Lock 、 clients 、M igrating Clients 節點。

Slots: 所有分片會把自身信息寫入到 slots 節點下面。 Manager 在初始化集群時，根據設置的分片數，以及集群下的 group 數，進行預分片操作，把所有分片均勻分配給已有 group 。分片的信息由一個 json 串組成，記錄有分片的狀態 (stats) ，當前擁有此分片的 group(src) ，需要遷移到的 group(dst) 。分片的狀態一共有三種： online 、 pre_migrate 、 migrating 。

Online 指這個分片處於正常狀態，這時 dst 是空值，客戶端根據 src 的 group 進行讀寫。

Pre_migrate 是指這個分片被 manager 標記為需要遷移，此時 dst 仍然為空， manager 在等所有 client 都已經准備就緒，因為 ZooKeeper 回掉所有客戶端有時間差，所以如果某些 client 沒有準備就緒的時候 manager 進行了數據遷移，那麼就會有數據丟失。

Migrating 是 manager 確認了所有客戶端都已經做好遷移准備後，在 dst 寫入此分片需要遷移的目標 group 。待遷移完成，會在 src 寫入目標 group_name ， dst 設為空， stats 設為 online 。

Manager Lock： 因為我們是每次只允許遷移一個 slot ，所以不允許超過一個 manager 操作一個集群。所以 manager 在操作集群前，會在M anager Lock 下注冊臨時節點，代表這個集群已經有 manager 在操作了，這樣其他 manager 想要操作這個集群時就會自動退出。

Clients 和M igrating Clients 是為了讓 manager 知道客戶端是否已經准備就緒的節點。客戶端通過 uid 代表自己，格式是 客戶端語言 _ 主機名 _pid 。當集群沒有進行遷移，即所有分片都是 online 的時候，客戶端會在 clients 下創建 uid 的臨時節點。

當某個 slot 從 online 變成 pre_migrate 後，客戶端會刪除 clients 下的 uid 臨時節點，然後在M igrating Clients 創建 uid 臨時節點。注意，因為需要保證數據不丟失，從 pre_migrate 到 migrating 期間，這個 slot 是被鎖定的，即所有對這個 slot 的讀寫都會被阻塞。所以 mananger 會最多等待 10s ，確認所有客戶端都已經切換到准備就緒狀態，如果發現某個客戶端一直未准備就緒，那麼 mananger 會放棄此次遷移，把 slot 狀態由 pre_migrate 改為 online 。如果客戶端發現 slot 狀態由 pre_migrate 變成 online 了，那麼會刪除 migrating_clients 下的 uid 節點，在 clients 下重新創建 uid 節點。還需要注意的一點是，有可能一個客戶剛啟動，並且正在往 clients 下創建 uid 節點，但是因為網路延遲還沒創建完成，導致 manager 未確認到這個 client 是否准備就緒，所以 mananger 把 slot 改為 pre_migrate 後會等待 1s 再確認所有客戶端是否准備就緒。

如果 Manager 看到 clients 下已經沒有客戶端的話（都已經准備就緒），會把 slot 狀態改為 migrating 。 Slot 變成 migrating 後，鎖定也隨之解除， manager 會遍歷 src group 的數據，把對應 slot 的數據遷移到 dst group 里。客戶端在 migrating 期間如果有讀寫 migrating slot 的 key ，那麼客戶端會先把這個 key 從 src group 遷移到 dst group ，然後再做讀寫操作。即這期間客戶端性能會有所下降。這也是為什麼每次只遷移一個 slot 的原因。這樣即使只有 128 個分片的集群，在遷移期間受到性能影響的 key 也只有 1/128 ，是可以接受的。

Manager 發現已經把 slot 已經遷移完畢了，會在 src 寫入目標 group_name ， dst 設為空， stats 設為 online 。客戶端也刪除 migrating_clients 下的 uid ，在 clients 下創建 uid 節點。

❻ redis集群中master和salve是怎麼設置的

redis cluster在設計的時候，就考慮到了去中心化，去中間件，也就是說，集群中的每個節點都是平等的關系，都是對等的，每個節點都保存各自的數據和整個集群的狀態。
每個節點都和其他所有節點連接，而且這些連接保持活躍，這樣就保證了我們只需要連接集群中的任意一個節點，就可以獲取到其他節點的數據。

❼ 如何利用Redis擴展數據服務，實現分片及高可用

應用Redis實現數據的讀寫，同時利用隊列處理器定時將數據寫入mysql。同時要注意避免沖突，在redis啟動時去mysql讀取所有表鍵值存入redis中，往redis寫數據時，對redis主鍵自增並進行讀取，若mysql更新失敗，則需要及時清除緩存及同步redis主鍵。這樣處理，主要是實時讀寫redis，而mysql數據則通過隊列非同步處理，緩解mysql壓力，不過這種方法應用場景主要基於高並發，而且redis的高可用集群架構相對更復雜，一般不是很推薦。

❽ 如何實現高可用的redis集群

基於以上，Redis集群方案顯得尤為重要。通常有3個途徑：官方Redis Cluster；通過Proxy分片；客戶端分片(Smart Client)。以上三種方案各有利弊。

Redis Cluster(官方)：雖然正式版發布已經有一年多的時間，但還缺乏最佳實踐；對協議進行了較大修改，導致主流客戶端也並非都已支持，部分支持的客戶端也沒有經過大規模生產環境的驗證；無中心化設計使整個系統高度耦合，導致很難對業務進行無痛的升級。

Proxy：現在很多主流的Redis集群都會使用Proxy方式，例如早已開源的Codis。這種方案有很多優點，因為支持原聲redis協議，所以客戶端不需要升級，對業務比較友好。並且升級相對平滑，可以起多個Proxy後，逐個進行升級。但是缺點是，因為會多一次跳轉，平均會有30%左右的性能開銷。而且因為原生客戶端是無法一次綁定多個Proxy，連接的Proxy如果掛了還是需要人工參與。除非類似Smart Client一樣封裝原有客戶端，支持重連到其他Proxy，但這也就帶來了客戶端分片方式的一些缺點。並且雖然Proxy可以使用多個，並且可以動態增加proxy增加性能，但是所有客戶端都是共用所有proxy，那麼一些異常的服務有可能影響到其他服務。為每個服務獨立搭建proxy，也會給部署帶來額外的工作。

❾ redis和memcached的區別

Redis的作者Salvatore Sanfilippo曾經對這兩種基於內存的數據存儲系統進行過比較：

1、Redis支持伺服器端的數據操作：Redis相比Memcached來說，擁有更多的數據結構和並支持更豐富的數據操作，通常在Memcached里，你需要將數據拿到客戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和數據體積。在Redis中，這些復雜的操作通常和一般的GET/SET一樣高效。所以，如果需要緩存能夠支持更復雜的結構和操作，那麼Redis會是不錯的選擇。

2、內存使用效率對比：使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis採用hash結構來做key-value存儲，由於其組合式的壓縮，其內存利用率會高於Memcached。

3、性能對比：由於Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。

具體為什麼會出現上面的結論，以下為收集到的資料：

1、數據類型支持不同

與Memcached僅支持簡單的key-value結構的數據記錄不同，Redis支持的數據類型要豐富得多。最為常用的數據類型主要由五種：String、Hash、List、Set和Sorted Set。Redis內部使用一個redisObject對象來表示所有的key和value。redisObject最主要的信息如圖所示：

type代表一個value對象具體是何種數據類型，encoding是不同數據類型在redis內部的存儲方式，比如：type=string代表value存儲的是一個普通字元串，那麼對應的encoding可以是raw或者是int，如果是int則代表實際redis內部是按數值型類存儲和表示這個字元串的，當然前提是這個字元串本身可以用數值表示，比如:」123″ 「456」這樣的字元串。只有打開了Redis的虛擬內存功能，vm欄位欄位才會真正的分配內存，該功能默認是關閉狀態的。

1）String

• 常用命令：set/get/decr/incr/mget等；

• 應用場景：String是最常用的一種數據類型，普通的key/value存儲都可以歸為此類；

• 實現方式：String在redis內部存儲默認就是一個字元串，被redisObject所引用，當遇到incr、decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。

2）Hash

• 常用命令：hget/hset/hgetall等

• 應用場景：我們要存儲一個用戶信息對象數據，其中包括用戶ID、用戶姓名、年齡和生日，通過用戶ID我們希望獲取該用戶的姓名或者年齡或者生日；

• 實現方式：Redis的Hash實際是內部存儲的Value為一個HashMap，並提供了直接存取這個Map成員的介面。如圖所示，Key是用戶ID, value是一個Map。這個Map的key是成員的屬性名，value是屬性值。這樣對數據的修改和存取都可以直接通過其內部Map的Key(Redis里稱內部Map的key為field), 也就是通過 key(用戶ID) + field(屬性標簽) 就可以操作對應屬性數據。當前HashMap的實現有兩種方式：當HashMap的成員比較少時Redis為了節省內存會採用類似一維數組的方式來緊湊存儲，而不會採用真正的HashMap結構，這時對應的value的redisObject的encoding為zipmap，當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht。

3）List

• 常用命令：lpush/rpush/lpop/rpop/lrange等；

• 應用場景：Redis list的應用場景非常多，也是Redis最重要的數據結構之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現；

• 實現方式：Redis list的實現為一個雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，Redis內部的很多實現，包括發送緩沖隊列等也都是用的這個數據結構。

4）Set

• 常用命令：sadd/spop/smembers/sunion等；

• 應用場景：Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重復數據時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的；

• 實現方式：set 的內部實現是一個 value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。

5）Sorted Set

• 常用命令：zadd/zrange/zrem/zcard等；

• 應用場景：Redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過用戶額外提供一個優先順序(score)的參數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重復的集合列表，那麼可以選擇sorted set數據結構，比如twitter 的public timeline可以以發表時間作為score來存儲，這樣獲取時就是自動按時間排好序的。

• 實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap里放的是成員到score的映射，而跳躍表裡存放的是所有的成員，排序依據是HashMap里存的score,使用跳躍表的結構可以獲得比較高的查找效率，並且在實現上比較簡單。

2、內存管理機制不同

在Redis中，並不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。當物理內存用完時，Redis可以將一些很久沒用到的value交換到磁碟。Redis只會緩存所有的key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據「swappability = age*log(size_in_memory)」計算出哪些key對應的value需要swap到磁碟。然後再將這些key對應的value持久化到磁碟中，同時在內存中清除。這種特性使得Redis可以保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由於Redis將內存中的數據swap到磁碟中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個操作，直到子線程完成swap操作後才可以進行修改。當從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那麼Redis就需要從swap文件中載入相應數據，然後再返回給請求方。 這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件載入後才會相應。這種策略在客戶端的數量較小，進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大並發的情況的。所以Redis運行我們設置I/O線程池的大小，對需要從swap文件中載入相應數據的讀取請求進行並發操作，減少阻塞的時間。

對於像Redis和Memcached這種基於內存的資料庫系統來說，內存管理的效率高低是影響系統性能的關鍵因素。傳統C語言中的malloc/free函數是最常用的分配和釋放內存的方法，但是這種方法存在著很大的缺陷：首先，對於開發人員來說不匹配的malloc和free容易造成內存泄露；其次頻繁調用會造成大量內存碎片無法回收重新利用，降低內存利用率；最後作為系統調用，其系統開銷遠遠大於一般函數調用。所以，為了提高內存的管理效率，高效的內存管理方案都不會直接使用malloc/free調用。Redis和Memcached均使用了自身設計的內存管理機制，但是實現方法存在很大的差異，下面將會對兩者的內存管理機制分別進行介紹。

Memcached默認使用Slab Allocation機制管理內存，其主要思想是按照預先規定的大小，將分配的內存分割成特定長度的塊以存儲相應長度的key-value數據記錄，以完全解決內存碎片問題。Slab Allocation機制只為存儲外部數據而設計，也就是說所有的key-value數據都存儲在Slab Allocation系統里，而Memcached的其它內存請求則通過普通的malloc/free來申請，因為這些請求的數量和頻率決定了它們不會對整個系統的性能造成影響Slab Allocation的原理相當簡單。 如圖所示，它首先從操作系統申請一大塊內存，並將其分割成各種尺寸的塊Chunk，並把尺寸相同的塊分成組Slab Class。其中，Chunk就是用來存儲key-value數據的最小單位。每個Slab Class的大小，可以在Memcached啟動的時候通過制定Growth Factor來控制。假定圖中Growth Factor的取值為1.25，如果第一組Chunk的大小為88個位元組，第二組Chunk的大小就為112個位元組，依此類推。

當Memcached接收到客戶端發送過來的數據時首先會根據收到數據的大小選擇一個最合適的Slab Class，然後通過查詢Memcached保存著的該Slab Class內空閑Chunk的列表就可以找到一個可用於存儲數據的Chunk。當一條資料庫過期或者丟棄時，該記錄所佔用的Chunk就可以回收，重新添加到空閑列表中。從以上過程我們可以看出Memcached的內存管理制效率高，而且不會造成內存碎片，但是它最大的缺點就是會導致空間浪費。因為每個Chunk都分配了特定長度的內存空間，所以變長數據無法充分利用這些空間。如圖 所示，將100個位元組的數據緩存到128個位元組的Chunk中，剩餘的28個位元組就浪費掉了。

Redis的內存管理主要通過源碼中zmalloc.h和zmalloc.c兩個文件來實現的。Redis為了方便內存的管理，在分配一塊內存之後，會將這塊內存的大小存入內存塊的頭部。如圖所示，real_ptr是redis調用malloc後返回的指針。redis將內存塊的大小size存入頭部，size所佔據的內存大小是已知的，為size_t類型的長度，然後返回ret_ptr。當需要釋放內存的時候，ret_ptr被傳給內存管理程序。通過ret_ptr，程序可以很容易的算出real_ptr的值，然後將real_ptr傳給free釋放內存。

Redis通過定義一個數組來記錄所有的內存分配情況，這個數組的長度為ZMALLOC_MAX_ALLOC_STAT。數組的每一個元素代表當前程序所分配的內存塊的個數，且內存塊的大小為該元素的下標。在源碼中，這個數組為zmalloc_allocations。zmalloc_allocations[16]代表已經分配的長度為16bytes的內存塊的個數。zmalloc.c中有一個靜態變數used_memory用來記錄當前分配的內存總大小。所以，總的來看，Redis採用的是包裝的mallc/free，相較於Memcached的內存管理方法來說，要簡單很多。

3、數據持久化支持

Redis雖然是基於內存的存儲系統，但是它本身是支持內存數據的持久化的，而且提供兩種主要的持久化策略：RDB快照和AOF日誌。而memcached是不支持數據持久化操作的。

1）RDB快照

Redis支持將當前數據的快照存成一個數據文件的持久化機制，即RDB快照。但是一個持續寫入的資料庫如何生成快照呢？Redis藉助了fork命令的 on write機制。在生成快照時，將當前進程fork出一個子進程，然後在子進程中循環所有的數據，將數據寫成為RDB文件。我們可以通過Redis的save指令來配置RDB快照生成的時機，比如配置10分鍾就生成快照，也可以配置有1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置文件中，你也可以通過Redis的CONFIG SET命令在Redis運行時設置規則，不需要重啟Redis。

Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然後通過原子性rename系統調用將臨時文件重命名為RDB文件，這樣在任何時候出現故障，Redis的RDB文件都總是可用的。同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。RDB有他的不足，就是一旦資料庫出現問題，那麼我們的RDB文件中保存的數據並不是全新的，從上次RDB文件生成到Redis停機這段時間的數據全部丟掉了。在某些業務下，這是可以忍受的。

2）AOF日誌

AOF日誌的全稱是append only file，它是一個追加寫入的日誌文件。與一般資料庫的binlog不同的是，AOF文件是可識別的純文本，它的內容就是一個個的Redis標准命令。只有那些會導致數據發生修改的命令才會追加到AOF文件。每一條修改數據的命令都生成一條日誌，AOF文件會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程中，所有的寫操作日誌還是會寫到原來老的AOF文件中，同時還會記錄在內存緩沖區中。當重完操作完成後，會將所有緩沖區中的日誌一次性寫入到臨時文件中。然後調用原子性的rename命令用新的AOF文件取代老的AOF文件。

AOF是一個寫文件操作，其目的是將操作日誌寫到磁碟上，所以它也同樣會遇到我們上面說的寫操作的流程。在Redis中對AOF調用write寫入後，通過appendfsync選項來控制調用fsync將其寫到磁碟上的時間，下面appendfsync的三個設置項，安全強度逐漸變強。

• appendfsync no 當設置appendfsync為no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁碟，所以這一切就完全依賴於操作系統的調試了。對大多數Linux操作系統，是每30秒進行一次fsync，將緩沖區中的數據寫到磁碟上。

• appendfsync everysec 當設置appendfsync為everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩沖區中的數據寫到磁碟。但是當這一次的fsync調用時長超過1秒時。Redis會採取延遲fsync的策略，再等一秒鍾。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由於在fsync時文件描述符會被阻塞，所以當前的寫操作就會阻塞。所以結論就是，在絕大多數情況下，Redis會每隔一秒進行一次fsync。在最壞的情況下，兩秒鍾會進行一次fsync操作。這一操作在大多數資料庫系統中被稱為group commit，就是組合多次寫操作的數據，一次性將日誌寫到磁碟。

• appednfsync always 當設置appendfsync為always時，每一次寫操作都會調用一次fsync，這時數據是最安全的，當然，由於每次都會執行fsync，所以其性能也會受到影響。

對於一般性的業務需求，建議使用RDB的方式進行持久化，原因是RDB的開銷並相比AOF日誌要低很多，對於那些無法忍數據丟失的應用，建議使用AOF日誌。

4、集群管理的不同

Memcached是全內存的數據緩沖系統，Redis雖然支持數據的持久化，但是全內存畢竟才是其高性能的本質。作為基於內存的存儲系統來說，機器物理內存的大小就是系統能夠容納的最大數據量。如果需要處理的數據量超過了單台機器的物理內存大小，就需要構建分布式集群來擴展存儲能力。

Memcached本身並不支持分布式，因此只能在客戶端通過像一致性哈希這樣的分布式演算法來實現Memcached的分布式存儲。下圖給出了Memcached的分布式存儲實現架構。當客戶端向Memcached集群發送數據之前，首先會通過內置的分布式演算法計算出該條數據的目標節點，然後數據會直接發送到該節點上存儲。但客戶端查詢數據時，同樣要計算出查詢數據所在的節點，然後直接向該節點發送查詢請求以獲取數據。

相較於Memcached只能採用客戶端實現分布式存儲，Redis更偏向於在伺服器端構建分布式存儲。最新版本的Redis已經支持了分布式存儲功能。Redis Cluster是一個實現了分布式且允許單點故障的Redis高級版本，它沒有中心節點，具有線性可伸縮的功能。下圖給出Redis Cluster的分布式存儲架構，其中節點與節點之間通過二進制協議進行通信，節點與客戶端之間通過ascii協議進行通信。在數據的放置策略上，Redis Cluster將整個key的數值域分成4096個哈希槽，每個節點上可以存儲一個或多個哈希槽，也就是說當前Redis Cluster支持的最大節點數就是4096。Redis Cluster使用的分布式演算法也很簡單：crc16( key ) % HASH_SLOTS_NUMBER。

為了保證單點故障下的數據可用性，Redis Cluster引入了Master節點和Slave節點。在Redis Cluster中，每個Master節點都會有對應的兩個用於冗餘的Slave節點。這樣在整個集群中，任意兩個節點的宕機都不會導致數據的不可用。當Master節點退出後，集群會自動選擇一個Slave節點成為新的Master節點。

❿ redis2 和 redis3 的區別

前者是一個完全無中心的設計，節點之間通過gossip方式傳遞集群信息，數據保證最終一致性
後者是一個中心化的方案設計，通過類似一個分布式鎖服務來保證強一致性,數據寫入先寫內存和redo log，然後定期compat歸並到磁碟上，將隨機寫優化為順序寫，提高寫入性能。