Redis特性

Redis特性

1、多數據庫

1.概念

    一個Redis實例能夠包括多個數據庫，客戶端能夠指定鏈接某個Redis實例的指定數據庫 （與mysql多個數據庫相似） 。

    一個Redis實例最多能夠提供16個數據庫，下標從0到15，客戶端默認鏈接第0號數據庫，能夠經過 select 0-15命令選擇鏈接其餘數據庫。

2、服務器命令

1) move newkey 1 ：將當前庫的一個key移動（剪切）到1號庫中

2) ping ：返回pong則表示鏈接存活，不然返回錯誤信息

3) echo ：在命令行打印一些內容

4) select 0-15 ：選擇數據庫

5) quit ：退出鏈接

6) dbsize ：返回當前數據庫中key的數目

7) info ：獲取服務器的信息和統計

8) flushall ：刪除全部數據庫中的全部key及數據

3、消息訂閱與發佈

1) subscribe channel ：訂閱碰到，如：subscribe mychan,訂閱mychan這個頻道

2) psubscribe channel * ：批量訂閱頻道，如：psubscribe s*，訂閱以's'開頭的頻道

3) publish channel content ：在指定的頻道發佈消息，如：publish mychan today is a new day

4、Redis事務

1.概念

    和衆多其餘數據庫同樣，Redis做爲NoSQL數據庫也一樣提供了事務機制。在Redis中，MULTI/EXEC/DISCARD這三個命令是咱們實現事務的基石。

2.Redis事務特徵

(1)在事務中全部的命令都會被串行化的順序執行， 事務執行期間Redis不會再爲其餘客戶端的請求提供任何服務 ，保證了事務中全部命令被原子地執行。

(2)和關係型數據庫中的事務相比， 在Redis事務中若是有一條命令執行失敗，其後的命令仍然會被繼續執行。

(3)能夠經過MULTI命令開啓一個事務，至關於關係型數據庫的"BEGIN TRANSACTION"語句。在該語句以後執行的命令都將視爲事務以內的操做，最後經過執行EXEC/DISCARD命令來提交/回滾該事務內的全部操做。這兩個Redis命令至關於"COMMIT/ROLLBACK"語句。

(4)在事務開啓以前，若是客戶端與服務器之間出現通信故障致使網絡斷開，其後全部待執行的操做都不會被服務器所執行。但若網絡中斷時間是發生在客戶端執行EXEC命令以後的，該事務所與命令都會被服務器執行。

(5)當使用Append-Only模式時，Redis或經過調用系統函數write將該事務內的全部操做在本次調用中所有寫入磁盤。然而若是在寫入的過程當中出現系統崩潰，如電源故障致使的宕機，那麼此時也許只有部分數據被寫入磁盤，而另一部分數據卻已丟失。Redis服務器會在重啓時執行一系列必要的一致性檢測，一旦發現相似問題，將當即退出並給出相應錯誤信息提示。此時應充分利用Redis工具包中提供的redis-check-aof工具，幫助定位數據一致性的錯誤，並將寫入的部分數據進行回滾。而後再重啓Redis服務器。 

3.命令解釋

1)multi：開啓事務，用於標記事務的開始，其後執行的命令將被存入命令隊列，直至執行exec命令

2)exec：提交事務，相似"commit"
3)discard：回滾事務，相似"rollback"

4.嘗試

(1)提交事務： 注意錯誤的命令並無被執行，但錯誤命令後的正確命令被執行了

(2)回滾事務：

*Redis Incr 命令將 key 中儲存的數字值增一，若是 key 不存在，那麼 key 的值會先被初始化爲 0 ，而後再執行 INCR 操做。

*Redis Incrby 命令將 key 中儲存的數字加上指定的增量值，若是 key 不存在，那麼 key 的值會先被初始化爲 0 ，而後再執行 INCR 操做。

5、Redis的持久化

1.概述

    Redis的高性能是因爲其將全部數據都存儲到了內存中，爲了是Redis在重啓以後仍能保持數據不丟失，須要將數據從內容中同步到硬盤中，即數據的持久化。

     Redis支持兩種方式的持久化，一種是RDB方式，另外一種是AOF方式。 能夠單獨使用其中一種或結合使用 。

2.RDB持久化（默認支持，無需配置）

    該方式機制是在指定時間間隔內湛江內存中的數據集快照寫入磁盤。

優點：

(1)該方式使整個Redis數據庫之包含一個文件，易於備份和災難後恢復數據。

(2)性能最大化。對於Redis的服務進程而言，在開始RDB持久化時，只須要fork（分叉）出子進程由子進程完成持久化。這樣能夠極大的避免服務進程執行IO操做。

(3)相比AOF機制，若數據集很大，RDB方式啓動效率更高

劣勢：

(1)不能很好地保證數據的高可用性，即不能最大限度地避免數據丟失。若系統在定時持久化數據以前出現宕機，未寫入磁盤的數據都將丟失。

(2)因爲RDB是經過fork子進程來協助完成數據的持久化操做，當數據集較大時，可能致使服務器中止服務幾百毫秒到一秒。

3.AOF持久化

    該方式機制將以日誌的形式記錄服務器所處理的每個寫操做，在Redis服務器啓動之初會賭氣該文件來重構數據庫，以保證啓動後數據庫中的數據是完整的。

優點：

(1)該方式能夠帶來更高的數據安全性，即數據持久性。Redis中提供了三種同步策略： 每秒同步、每修改同步和不一樣步。事實上每秒同步也是異步完成的，效率也很是高，若系統出現宕機，則只會丟失這一秒內修改的數據。而每修改同步至關於同步持久化，即每次數據發生變化都會被當即記錄到磁盤中（實際上一秒鐘數據能夠變化不少次）。效率比較低。

(2)該機制對日誌文件的寫入操做採用的是append模式，所以在寫入過程當中即便是出現宕機現象，也不會破壞日誌文件中已存在的內容。若系統在寫入未完成的狀態下宕機，能夠在Redis下一次啓動前經過redis-check-aof工具來幫助解決數據一致性的問題。

(3)若日誌過大，Redis能夠自動啓用rewrite機制。Reids以append模式不斷地將修改數據寫入到舊文件中同時建立一個新文件用於記錄此期間有哪些修改命令被執行。因此在rewrite切換時能夠保持數據的安全性。

(4)AOF日誌文件能夠由開發者重構以重構數據庫。

劣勢：

(1)對於相同數量的數據集而言，AOF文件一般大於RDB文件。

(2)根據同步策略的不一樣，AOF在運行效率上每每會比RDB慢。

總之，每秒同步策略的效率是比較高且有效的。

*兩種方式的配置詳細內容見Redis入門筆記中的pdf附件

更改配置文件後須要重啓數據庫使配置生效