Redis文檔解析

標籤：

1.複製1，Redis 使用非同步複製。2，功能不會阻塞主伺服器： 即使有一個或多個從伺服器進行中初次同步， 主伺服器也可以繼續處理命令請求。原理:  無論是初次串連還是重新串連， 當建立一個從伺服器時， 從伺服器都將向主伺服器發送一個 SYNC 命令。接到 SYNC 命令的主伺服器將開始執行 BGSAVE ， 並在儲存操作執行期間， 將所有新執行的寫入命令都儲存到一個緩衝區裡面。當 BGSAVE 執行完畢後， 主伺服器將執行儲存操作所得的 .rdb 檔案發送給從伺服器， 從伺服器接收這個 .rdb 檔案， 並將檔案中的資料載入到記憶體中。之後主伺服器會以 Redis 命令協議的格式， 將寫命令緩衝區中積累的所有內容都發送給從伺服器。你可以通過 telnet 命令來親自驗證這個同步過程： 首先連上一個正在處理命令請求的 Redis 伺服器， 然後向它發送 SYNC 命令， 過一陣子， 你將看到 telnet 會話（session）接收到伺服器發來的大段資料（.rdb 檔案）， 之後還會看到， 所有在伺服器執行過的寫命令， 都會重新發送到 telnet 會話來。即使有多個從伺服器同時向主伺服器發送 SYNC ， 主伺服器也只需執行一次 BGSAVE 命令， 就可以處理所有這些從伺服器的同步請求。在網路連接短暫性失效之後， 主從伺服器可以嘗試繼續執行原有的複製進程（process）， 而不一定要執行完整重同步操作。這個特性需要主伺服器為被發送的複製流建立一個記憶體緩衝區（in-memory backlog）， 並且主伺服器和所有從伺服器之間都記錄一個複製位移量（replication offset）和一個主伺服器 ID （master run id）， 當出現網路連接斷開時， 從伺服器會重新串連， 並且向主伺服器請求繼續執行原來的複製進程：

　　

2.通訊協定1,網路層用戶端和伺服器通過 TCP 串連來進行資料互動， 伺服器預設的連接埠號碼為 6379 。用戶端和伺服器發送的命令或資料一律以 \r\n （CRLF）結尾。2,回複狀態回複（status reply）的第一個位元組是 "+"錯誤回複（error reply）的第一個位元組是 "-"整數回複（integer reply）的第一個位元組是 ":"批量回複（bulk reply）的第一個位元組是 "$"多條批量回複（multi bulk reply）的第一個位元組是 "*"

　　

3.事務MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事務的基礎事務是一個單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他用戶端發送來的命令請求所打斷。事務是一個原子操作：事務中的命令要麼全部被執行，要麼全部都不執行。1.MULTIMULTI 命令用於開啟一個事務，它總是返回 OK 。MULTI 執行之後， 用戶端可以繼續向伺服器發送任意多條命令， 這些命令不會立即被執行， 而是被放到一個隊列中， 當 EXEC 命令被調用時， 所有隊列中的命令才會被執行。另一方面， 通過調用 DISCARD ， 用戶端可以清空事務隊列， 並放棄執行事務。MULTIOK> INCR fooQUEUED> INCR barQUEUED> EXEC1) (integer) 12) (integer) 1即使事務中有某條/某些命令執行失敗了， 事務隊列中的其他命令仍然會繼續執行 —— Redis 不會停止執行事務中的命令。Redis 在事務失敗時不進行復原，而是繼續執行餘下的命令2.DISCARD當執行 DISCARD 命令時， 事務會被放棄， 事務隊列會被清空， 並且用戶端會從事務狀態中退出：redis> SET foo 1OKredis> MULTIOKredis> INCR fooQUEUEDredis> DISCARDOKredis> GET foo"1"3.WATCH被 WATCH 的鍵會被監視，並會發覺這些鍵是否被改動過了。 如果有至少一個被監視的鍵在 EXEC 執行之前被修改了， 那麼整個事務都會被取消， EXEC 返回空多條批量回複（null multi-bulk reply）來表示事務已經失敗。

　　

Redis文檔解析