redis備忘錄

Redis 是一個基於內存的高性能key-value數據庫。
Redis本質上是一個Key-Value類型的內存數據庫，很像memcached，整個數據庫通通加載在內存當中進行操做，按期經過異步操做把數據庫數據flush到硬盤上進行保存。由於是純內存操做，Redis的性能很是出色，每秒能夠處理超過 10萬次讀寫操做，是已知性能最快的Key-Value DB。
Redis的出色之處不只僅是性能，Redis最大的魅力是支持保存多種數據結構，此外單個value的最大限制是1GB，不像 memcached只能保存1MB的數據，所以Redis能夠用來實現不少有用的功能，比方說用他的List來作FIFO雙向鏈表，實現一個輕量級的高性 能消息隊列服務，用他的Set能夠作高性能的tag系統等等。另外Redis也能夠對存入的Key-Value設置expire時間，所以也能夠被看成一 個功能增強版的memcached來用。
Redis的主要缺點是數據庫容量受到物理內存的限制，不能用做海量數據的高性能讀寫，所以Redis適合的場景主要侷限在較小數據量的高性能操做和運算上。

Redis經過Key-Value的單值不一樣類型來區分, 如下是支持的類型:
Strings
Lists
Sets 求交集、並集
Sorted Set
hashes

Redis是單進程單線程的
redis利用隊列技術將併發訪問變爲串行訪問，消除了傳統數據庫串行控制的開銷

redis支持主從的模式。原則：Master會將數據同步到slave，而slave不會將數據同步到master。Slave啓動時會鏈接master來同步數據。
這是一個典型的分佈式讀寫分離模型。咱們能夠利用master來插入數據，slave提供檢索服務。這樣能夠有效減小單個機器的併發訪問數量

使用Redis有哪些好處？

(1) 速度快，由於數據存在內存中，相似於HashMap，HashMap的優點就是查找和操做的時間複雜度都是O(1)

(2) 支持豐富數據類型，支持string，list，set，sorted set，hash

(3) 支持事務，操做都是原子性，所謂的原子性就是對數據的更改要麼所有執行，要麼所有不執行

(4) 豐富的特性：可用於緩存，消息，按key設置過時時間，過時後將會自動刪除

redis相比memcached有哪些優點？

(1) memcached全部的值均是簡單的字符串，redis做爲其替代者，支持更爲豐富的數據類型

(2) redis的速度比memcached快不少

(3) redis能夠持久化其數據

redis常見性能問題和解決方案：

(1) Master最好不要作任何持久化工做，如RDB內存快照和AOF日誌文件

(2) 若是數據比較重要，某個Slave開啓AOF備份數據，策略設置爲每秒同步一次

(3) 爲了主從複製的速度和鏈接的穩定性，Master和Slave最好在同一個局域網內

(4) 儘可能避免在壓力很大的主庫上增長從庫

(5) 主從複製不要用圖狀結構，用單向鏈表結構更爲穩定，即：Master <- Slave1 <- Slave2 <- Slave3...

這樣的結構方便解決單點故障問題，實現Slave對Master的替換。若是Master掛了，能夠馬上啓用Slave1作Master，其餘不變。

MySQL裏有2000w數據，redis中只存20w的數據，如何保證redis中的數據都是熱點數據

相關知識：redis 內存數據集大小上升到必定大小的時候，就會施行數據淘汰策略。redis 提供 6種數據淘汰策略：

voltile-lru：從已設置過時時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰

volatile-ttl：從已設置過時時間的數據集（server.db[i].expires）中挑選將要過時的數據淘汰

volatile-random：從已設置過時時間的數據集（server.db[i].expires）中任意選擇數據淘汰

allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰

allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰

no-enviction（驅逐）：禁止驅逐數據

Memcache與Redis的區別都有哪些？

1)、存儲方式

Memecache把數據所有存在內存之中，斷電後會掛掉，數據不能超過內存大小。

Redis有部份存在硬盤上，這樣能保證數據的持久性。

2)、數據支持類型

Memcache對數據類型支持相對簡單。

Redis有複雜的數據類型。

3)、使用底層模型不一樣

它們之間底層實現方式 以及與客戶端之間通訊的應用協議不同。

Redis直接本身構建了VM 機制 ，由於通常的系統調用系統函數的話，會浪費必定的時間去移動和請求。

4），value大小

redis最大能夠達到1GB，而memcache只有1MB

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支持數據的持久化，能夠將內存中的數據保持在磁盤中，重啓的時候能夠再次加載進行使用。

（1）、會話緩存（Session Cache）

最經常使用的一種使用Redis的情景是會話緩存（session cache）。用Redis緩存會話比其餘存儲（如Memcached）的優點在於：Redis提供持久化。當維護一個不是嚴格要求一致性的緩存時，若是用戶的購物車信息所有丟失，大部分人都會不高興的，如今，他們還會這樣嗎？

幸運的是，隨着 Redis 這些年的改進，很容易找到怎麼恰當的使用Redis來緩存會話的文檔。甚至廣爲人知的商業平臺Magento也提供Redis的插件。

（2）、全頁緩存（FPC）

除基本的會話token以外，Redis還提供很簡便的FPC平臺。回到一致性問題，即便重啓了Redis實例，由於有磁盤的持久化，用戶也不會看到頁面加載速度的降低，這是一個極大改進，相似PHP本地FPC。

再次以Magento爲例，Magento提供一個插件來使用Redis做爲全頁緩存後端。

此外，對WordPress的用戶來講，Pantheon有一個很是好的插件 wp-redis，這個插件能幫助你以最快速度加載你曾瀏覽過的頁面。

（3）、隊列

Reids在內存存儲引擎領域的一大優勢是提供 list 和 set 操做，這使得Redis能做爲一個很好的消息隊列平臺來使用。Redis做爲隊列使用的操做，就相似於本地程序語言（如Python）對 list 的 push/pop 操做。

若是你快速的在Google中搜索「Redis queues」，你立刻就能找到大量的開源項目，這些項目的目的就是利用Redis建立很是好的後端工具，以知足各類隊列需求。例如，Celery有一個後臺就是使用Redis做爲broker，你能夠從這裏去查看。

（4），排行榜/計數器

Redis在內存中對數字進行遞增或遞減的操做實現的很是好。集合（Set）和有序集合（Sorted Set）也使得咱們在執行這些操做的時候變的很是簡單，Redis只是正好提供了這兩種數據結構。因此，咱們要從排序集合中獲取到排名最靠前的10個用戶–咱們稱之爲「user_scores」，咱們只須要像下面同樣執行便可：

固然，這是假定你是根據你用戶的分數作遞增的排序。若是你想返回用戶及用戶的分數，你須要這樣執行：

ZRANGE user_scores 0 10 WITHSCORES

Agora Games就是一個很好的例子，用Ruby實現的，它的排行榜就是使用Redis來存儲數據的，你能夠在這裏看到。

（5）、發佈/訂閱

最後（但確定不是最不重要的）是Redis的發佈/訂閱功能。發佈/訂閱的使用場景確實很是多。我已看見人們在社交網絡鏈接中使用，還可做爲基於發佈/訂閱的腳本觸發器，甚至用Redis的發佈/訂閱功能來創建聊天系統！（不，這是真的，你能夠去核實）。

Redis提供的全部特性中，我感受這個是喜歡的人最少的一個，雖然它爲用戶提供若是此多功能。

Redis 提供了多種不一樣級別的持久化方式：
RDB 持久化能夠在指定的時間間隔內生成數據集的時間點快照（point-in-time snapshot）。
AOF 持久化記錄服務器執行的全部寫操做命令，並在服務器啓動時，經過從新執行這些命令來還原數據集。 AOF 文件中的命令所有以 Redis 協議的格式來保存，新命令會被追加到文件的末尾。 Redis 還能夠在後臺對 AOF 文件進行重寫（rewrite），使得 AOF 文件的體積不會超出保存數據集狀態所需的實際大小。
Redis 還能夠同時使用 AOF 持久化和 RDB 持久化。 在這種狀況下， 當 Redis 重啓時， 它會優先使用 AOF 文件來還原數據集， 由於 AOF 文件保存的數據集一般比 RDB 文件所保存的數據集更完整。
你甚至能夠關閉持久化功能，讓數據只在服務器運行時存在。

RDB 的優勢
RDB 是一個很是緊湊（compact）的文件，它保存了 Redis 在某個時間點上的數據集。 這種文件很是適合用於進行備份： 好比說，你能夠在最近的 24 小時內，每小時備份一次 RDB 文件，而且在每月的每一天，也備份一個 RDB 文件。 這樣的話，即便趕上問題，也能夠隨時將數據集還原到不一樣的版本。
RDB 很是適用於災難恢復（disaster recovery）：它只有一個文件，而且內容都很是緊湊，能夠（在加密後）將它傳送到別的數據中心，或者亞馬遜 S3 中。
RDB 能夠最大化 Redis 的性能：父進程在保存 RDB 文件時惟一要作的就是 fork 出一個子進程，而後這個子進程就會處理接下來的全部保存工做，父進程無須執行任何磁盤 I/O 操做。
RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。
RDB 的缺點
若是你須要儘可能避免在服務器故障時丟失數據，那麼 RDB 不適合你。 雖然 Redis 容許你設置不一樣的保存點（save point）來控制保存 RDB 文件的頻率， 可是， 由於RDB 文件須要保存整個數據集的狀態， 因此它並非一個輕鬆的操做。 所以你可能會至少 5 分鐘才保存一次 RDB 文件。 在這種狀況下， 一旦發生故障停機， 你就可能會丟失好幾分鐘的數據。
每次保存 RDB 的時候，Redis 都要 fork() 出一個子進程，並由子進程來進行實際的持久化工做。 在數據集比較龐大時， fork() 可能會很是耗時，形成服務器在某某毫秒內中止處理客戶端； 若是數據集很是巨大，而且 CPU 時間很是緊張的話，那麼這種中止時間甚至可能會長達整整一秒。 雖然 AOF 重寫也須要進行 fork() ，但不管 AOF 重寫的執行間隔有多長，數據的耐久性都不會有任何損失。

AOF 的優勢
使用 AOF 持久化會讓 Redis 變得很是耐久（much more durable）：你能夠設置不一樣的 fsync 策略，好比無 fsync ，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync 。 AOF 的默認策略爲每秒鐘 fsync 一次，在這種配置下，Redis 仍然能夠保持良好的性能，而且就算髮生故障停機，也最多隻會丟失一秒鐘的數據（ fsync 會在後臺線程執行，因此主線程能夠繼續努力地處理命令請求）。
AOF 文件是一個只進行追加操做的日誌文件（append only log）， 所以對 AOF 文件的寫入不須要進行 seek ， 即便日誌由於某些緣由而包含了未寫入完整的命令（好比寫入時磁盤已滿，寫入中途停機，等等）， redis-check-aof 工具也能夠輕易地修復這種問題。
Redis 能夠在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操做是絕對安全的，由於 Redis 在建立新 AOF 文件的過程當中，會繼續將命令追加到現有的 AOF 文件裏面，即便重寫過程當中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件建立完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操做。
AOF 文件有序地保存了對數據庫執行的全部寫入操做， 這些寫入操做以 Redis 協議的格式保存， 所以 AOF 文件的內容很是容易被人讀懂， 對文件進行分析（parse）也很輕鬆。 導出（export） AOF 文件也很是簡單： 舉個例子， 若是你不當心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那麼只要中止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 並重啓 Redis ， 就能夠將數據集恢復到 FLUSHALL 執行以前的狀態。
AOF 的缺點
對於相同的數據集來講，AOF 文件的體積一般要大於 RDB 文件的體積。
根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在通常狀況下， 每秒 fsync 的性能依然很是高， 而關閉 fsync 可讓 AOF 的速度和 RDB 同樣快， 即便在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 能夠提供更有保證的最大延遲時間（latency）。
AOF 在過去曾經發生過這樣的 bug ： 由於個別命令的緣由，致使 AOF 文件在從新載入時，沒法將數據集恢復成保存時的原樣。 （舉個例子，阻塞命令 BRPOPLPUSH 就曾經引發過這樣的 bug 。） 測試套件裏爲這種狀況添加了測試： 它們會自動生成隨機的、複雜的數據集， 並經過從新載入這些數據來確保一切正常。 雖然這種 bug 在 AOF 文件中並不常見， 可是對比來講， RDB 幾乎是不可能出現這種 bug 的。

RDB 和 AOF ，我應該用哪個？
通常來講， 若是想達到足以媲美 PostgreSQL 的數據安全性， 你應該同時使用兩種持久化功能。

若是你很是關心你的數據， 但仍然能夠承受數分鐘之內的數據丟失， 那麼你能夠只使用 RDB 持久化。

有不少用戶都只使用 AOF 持久化， 但咱們並不推薦這種方式： 由於定時生成 RDB 快照（snapshot）很是便於進行數據庫備份， 而且 RDB 恢復數據集的速度也要比 AOF 恢復的速度要快， 除此以外， 使用 RDB 還能夠避免以前提到的 AOF 程序的 bug 。

RDB 快照
在默認狀況下， Redis 將數據庫快照保存在名字爲 dump.rdb 的二進制文件中。

你能夠對 Redis 進行設置， 讓它在「 N 秒內數據集至少有 M 個改動」這一條件被知足時， 自動保存一次數據集。

你也能夠經過調用 SAVE 或者 BGSAVE ， 手動讓 Redis 進行數據集保存操做。

好比說， 如下設置會讓 Redis 在知足「 60 秒內有至少有 1000 個鍵被改動」這一條件時， 自動保存一次數據集：

save 60 1000
這種持久化方式被稱爲快照（snapshot）。
快照的運做方式
當 Redis 須要保存 dump.rdb 文件時， 服務器執行如下操做：

Redis 調用 fork() ，同時擁有父進程和子進程。
子進程將數據集寫入到一個臨時 RDB 文件中。
當子進程完成對新 RDB 文件的寫入時，Redis 用新 RDB 文件替換原來的 RDB 文件，並刪除舊的 RDB 文件。
這種工做方式使得 Redis 能夠從寫時複製（copy-on-write）機制中獲益。

只進行追加操做的文件（append-only file，AOF）
快照功能並非很是耐久（durable）： 若是 Redis 由於某些緣由而形成故障停機， 那麼服務器將丟失最近寫入、且仍未保存到快照中的那些數據。

儘管對於某些程序來講， 數據的耐久性並非最重要的考慮因素， 可是對於那些追求徹底耐久能力（full durability）的程序來講， 快照功能就不太適用了。

從 1.1 版本開始， Redis 增長了一種徹底耐久的持久化方式： AOF 持久化。

你能夠經過修改配置文件來打開 AOF 功能：

appendonly yes
從如今開始， 每當 Redis 執行一個改變數據集的命令時（好比 SET）， 這個命令就會被追加到 AOF 文件的末尾。

這樣的話， 當 Redis 從新啓時， 程序就能夠經過從新執行 AOF 文件中的命令來達到重建數據集的目的。

AOF 重寫
由於 AOF 的運做方式是不斷地將命令追加到文件的末尾， 因此隨着寫入命令的不斷增長， AOF 文件的體積也會變得愈來愈大。

舉個例子， 若是你對一個計數器調用了 100 次 INCR ， 那麼僅僅是爲了保存這個計數器的當前值， AOF 文件就須要使用 100 條記錄（entry）。

然而在實際上， 只使用一條 SET 命令已經足以保存計數器的當前值了， 其他 99 條記錄實際上都是多餘的。

爲了處理這種狀況， Redis 支持一種有趣的特性： 能夠在不打斷服務客戶端的狀況下， 對 AOF 文件進行重建（rebuild）。

執行 BGREWRITEAOF 命令， Redis 將生成一個新的 AOF 文件， 這個文件包含重建當前數據集所需的最少命令。

Redis 2.2 須要本身手動執行 BGREWRITEAOF 命令； Redis 2.4 則能夠自動觸發 AOF 重寫， 具體信息請查看 2.4 的示例配置文件。

AOF 有多耐久？
你能夠配置 Redis 多久纔將數據 fsync 到磁盤一次。

有三個選項：

每次有新命令追加到 AOF 文件時就執行一次 fsync ：很是慢，也很是安全。
每秒 fsync 一次：足夠快（和使用 RDB 持久化差很少），而且在故障時只會丟失 1 秒鐘的數據。
從不 fsync ：將數據交給操做系統來處理。更快，也更不安全的選擇。
推薦（而且也是默認）的措施爲每秒 fsync 一次， 這種 fsync 策略能夠兼顧速度和安全性。

老是 fsync 的策略在實際使用中很是慢， 即便在 Redis 2.0 對相關的程序進行了改進以後還是如此 —— 頻繁調用 fsync 註定了這種策略不可能快得起來。

若是 AOF 文件出錯了，怎麼辦？
服務器可能在程序正在對 AOF 文件進行寫入時停機， 若是停機形成了 AOF 文件出錯（corrupt）， 那麼 Redis 在重啓時會拒絕載入這個 AOF 文件， 從而確保數據的一致性不會被破壞。

當發生這種狀況時， 能夠用如下方法來修復出錯的 AOF 文件：

爲現有的 AOF 文件建立一個備份。
使用 Redis 附帶的 redis-check-aof 程序，對原來的 AOF 文件進行修復。
$ redis-check-aof --fix
（可選）使用 diff -u 對比修復後的 AOF 文件和原始 AOF 文件的備份，查看兩個文件之間的不一樣之處。
重啓 Redis 服務器，等待服務器載入修復後的 AOF 文件，並進行數據恢復。

AOF 的運做方式
AOF 重寫和 RDB 建立快照同樣，都巧妙地利用了寫時複製機制。

如下是 AOF 重寫的執行步驟：

Redis 執行 fork() ，如今同時擁有父進程和子進程。
子進程開始將新 AOF 文件的內容寫入到臨時文件。
對於全部新執行的寫入命令，父進程一邊將它們累積到一個內存緩存中，一邊將這些改動追加到現有 AOF 文件的末尾： 這樣即便在重寫的中途發生停機，現有的 AOF 文件也仍是安全的。
當子進程完成重寫工做時，它給父進程發送一個信號，父進程在接收到信號以後，將內存緩存中的全部數據追加到新 AOF 文件的末尾。
搞定！如今 Redis 原子地用新文件替換舊文件，以後全部命令都會直接追加到新 AOF 文件的末尾。

怎麼從 RDB 持久化切換到 AOF 持久化
在 Redis 2.2 或以上版本，能夠在不重啓的狀況下，從 RDB 切換到 AOF ：

爲最新的 dump.rdb 文件建立一個備份。
將備份放到一個安全的地方。
執行如下兩條命令：
redis-cli> CONFIG SET appendonly yes

redis-cli> CONFIG SET save ""
確保命令執行以後，數據庫的鍵的數量沒有改變。
確保寫命令會被正確地追加到 AOF 文件的末尾。
步驟 3 執行的第一條命令開啓了 AOF 功能： Redis 會阻塞直到初始 AOF 文件建立完成爲止， 以後 Redis 會繼續處理命令請求， 並開始將寫入命令追加到 AOF 文件末尾。

步驟 3 執行的第二條命令用於關閉 RDB 功能。 這一步是可選的， 若是你願意的話， 也能夠同時使用 RDB 和 AOF 這兩種持久化功能。

別忘了在 redis.conf 中打開 AOF 功能！ 不然的話， 服務器重啓以後， 以前經過 CONFIG SET 設置的配置就會被遺忘， 程序會按原來的配置來啓動服務器。

RDB 和 AOF 之間的相互做用
在版本號大於等於 2.4 的 Redis 中， BGSAVE 執行的過程當中， 不能夠執行 BGREWRITEAOF 。 反過來講， 在 BGREWRITEAOF 執行的過程當中， 也不能夠執行 BGSAVE 。

這能夠防止兩個 Redis 後臺進程同時對磁盤進行大量的 I/O 操做。

若是 BGSAVE 正在執行， 而且用戶顯示地調用 BGREWRITEAOF 命令， 那麼服務器將向用戶回覆一個 OK 狀態， 並告知用戶， BGREWRITEAOF 已經被預約執行： 一旦 BGSAVE 執行完畢， BGREWRITEAOF 就會正式開始。

當 Redis 啓動時， 若是 RDB 持久化和 AOF 持久化都被打開了， 那麼程序會優先使用 AOF 文件來恢復數據集， 由於 AOF 文件所保存的數據一般是最完整的。

備份 Redis 數據
在閱讀這個小節前， 先將下面這句話銘記於心： 必定要備份你的數據庫！

磁盤故障， 節點失效， 諸如此類的問題均可能讓你的數據消失不見， 不進行備份是很是危險的。

Redis 對於數據備份是很是友好的， 由於你能夠在服務器運行的時候對 RDB 文件進行復制： RDB 文件一旦被建立， 就不會進行任何修改。 當服務器要建立一個新的 RDB 文件時， 它先將文件的內容保存在一個臨時文件裏面， 當臨時文件寫入完畢時， 程序才使用 rename(2) 原子地用臨時文件替換原來的 RDB 文件。

這也就是說， 不管什麼時候， 複製 RDB 文件都是絕對安全的。

如下是咱們的建議：

建立一個按期任務（cron job）， 每小時將一個 RDB 文件備份到一個文件夾， 而且天天將一個 RDB 文件備份到另外一個文件夾。
確保快照的備份都帶有相應的日期和時間信息， 每次執行按期任務腳本時， 使用 find 命令來刪除過時的快照： 好比說， 你能夠保留最近 48 小時內的每小時快照， 還能夠保留最近一兩個月的每日快照。
至少天天一次， 將 RDB 備份到你的數據中心以外， 或者至少是備份到你運行 Redis 服務器的物理機器以外。

redis主從複製
1、Redis的Replication：

這裏首先須要說明的是，在Redis中配置Master-Slave模式真是太簡單了。相信在閱讀完這篇Blog以後你也能夠輕鬆作到。這裏咱們仍是先列出一些理論性的知識，後面給出實際操做的案例。
下面的列表清楚的解釋了Redis Replication的特色和優點。
1). 同一個Master能夠同步多個Slaves。
2). Slave一樣能夠接受其它Slaves的鏈接和同步請求，這樣能夠有效的分載Master的同步壓力。所以咱們能夠將Redis的Replication架構視爲圖結構。
3). Master Server是以非阻塞的方式爲Slaves提供服務。因此在Master-Slave同步期間，客戶端仍然能夠提交查詢或修改請求。
4). Slave Server一樣是以非阻塞的方式完成數據同步。在同步期間，若是有客戶端提交查詢請求，Redis則返回同步以前的數據。
5). 爲了分載Master的讀操做壓力，Slave服務器能夠爲客戶端提供只讀操做的服務，寫服務仍然必須由Master來完成。即使如此，系統的伸縮性仍是獲得了很大的提升。
6). Master能夠將數據保存操做交給Slaves完成，從而避免了在Master中要有獨立的進程來完成此操做。

2、Replication的工做原理：

在Slave啓動並鏈接到Master以後，它將主動發送一個SYNC命令。此後Master將啓動後臺存盤進程，同時收集全部接收到的用於修改數據集的命令，在後臺進程執行完畢後，Master將傳送整個數據庫文件到Slave，以完成一次徹底同步。而Slave服務器在接收到數據庫文件數據以後將其存盤並加載到內存中。此後，Master繼續將全部已經收集到的修改命令，和新的修改命令依次傳送給Slaves，Slave將在本次執行這些數據修改命令，從而達到最終的數據同步。
若是Master和Slave之間的連接出現斷連現象，Slave能夠自動重連Master，可是在鏈接成功以後，一次徹底同步將被自動執行。

3、如何配置Replication：

見以下步驟：
1). 同時啓動兩個Redis服務器，能夠考慮在同一臺機器上啓動兩個Redis服務器，分別監聽不一樣的端口，如6379和6380。
2). 在Slave服務器上執行一下命令：
/> redis-cli -p 6380 #這裏咱們假設Slave的端口號是6380
redis 127.0.0.1:6380> slaveof 127.0.0.1 6379 #咱們假設Master和Slave在同一臺主機，Master的端口爲6379
OK
上面的方式只是保證了在執行slaveof命令以後，redis_6380成爲了redis_6379的slave，一旦服務(redis_6380)從新啓動以後，他們之間的複製關係將終止。
若是但願長期保證這兩個服務器之間的Replication關係，能夠在redis_6380的配置文件中作以下修改：
/> cd /etc/redis #切換Redis服務器配置文件所在的目錄。
/> ls
6379.conf 6380.conf
/> vi 6380.conf
將
# slaveof <masterip> <masterport>
改成
slaveof 127.0.0.1 6379
保存退出。
這樣就能夠保證Redis_6380服務程序在每次啓動後都會主動創建與Redis_6379的Replication鏈接了。

4、應用示例：

這裏咱們假設Master-Slave已經創建。
#啓動master服務器。
[root@Stephen-PC redis]# redis-cli -p 6379
redis 127.0.0.1:6379>
#狀況Master當前數據庫中的全部Keys。
redis 127.0.0.1:6379> flushdb
OK
#在Master中建立新的Keys做爲測試數據。
redis 127.0.0.1:6379> set mykey hello
OK
redis 127.0.0.1:6379> set mykey2 world
OK
#查看Master中存在哪些Keys。
redis 127.0.0.1:6379> keys *
1) "mykey"
2) "mykey2"

#啓動slave服務器。
[root@Stephen-PC redis]# redis-cli -p 6380
#查看Slave中的Keys是否和Master中一致，從結果看，他們是相等的。
redis 127.0.0.1:6380> keys *
1) "mykey"
2) "mykey2"

#在Master中刪除其中一個測試Key，並查看刪除後的結果。
redis 127.0.0.1:6379> del mykey2
(integer) 1
redis 127.0.0.1:6379> keys *
1) "mykey"

#在Slave中查看是否mykey2也已經在Slave中被刪除。
redis 127.0.0.1:6380> keys *
1) "mykey"

純內存存儲/IO多路複用技術/單線程架構是造就Redis高性能的三個因素。
因爲Redis的單線程架構，因此須要每一個命令能被快速執行完，不然會存在阻塞Redis的可能。批量操做（mget,mset,hmset)可以有效提升命令執行的效率，但要注意每次批量操做的個數和字節數。
瞭解每一個名流的時間複雜度在開發中相當重要，例如在使用keys/hgetall,smembers/zrange等時間複雜度較高的命令時，須要考慮數據規模對於Redis的影響。
migrate命令用原子性的方式實現了dump+restore,而且支持批量操做，是Redis Cluster實現水平擴容的重要工具。
scan命令能夠解決keys命令可能帶來的阻塞問題，同時Redis還提供了hscan,sscan,zscan漸進式遍歷hash,set,zset.
scan採用漸進式遍歷的方式解決keys命令帶來的阻塞問題。

Redis集羣架構
藍色的爲Redis集羣中的每一個node節點，節點之間經過ping 命令，測試相互是否鏈接正常，普通集羣沒有主從區分，鏈接任何一個節點操做，均可以轉發到其餘任意一個節點。
一、Redis 容錯機制
每Redis提供了節點之間相互發送的ping命令，用於測試每一個節點的健康狀態，集羣中鏈接正常的節點接收到其餘節點發送的ping命令時，會返回一個pong字符串。
Redis投票機制：若是一個節點A給B發送ping沒有獲得pong返回，那麼A就會通知其餘節點再次給B發送ping，若是集羣中超過一半的節點給B發送ping都沒有獲得返回，那麼B就被坐實game over了，因此爲了不單點故障，通常都會爲Redis的每一個節點提供一個備份節點，B節點掛掉了立馬啓動B的備份節點服務器。

Redis 集羣存儲原理每一個節點上的數據都不同，（同樣就是主備了）把數據都分散存放到各個節點上進行存儲。如何肯定哪些類型數據存入哪一個節點呢？Redis中槽slot就用於圈定當前節點的存儲範圍，分散存儲使用hash算法，肯定什麼值放到哪一個槽裏。 因此在建立Redis集羣時，會首先爲每一個節點建立槽容量，例如從1~2000，指定數據存儲區域。