Redis 學習之持久化機制、發佈訂閱、虛擬記憶體

該問使用centos6.5 64位  redis3.2.8

一、持久化機制

Redis是一個支持持久化的記憶體資料庫，redis會經常將記憶體中的數據同步到硬碟上來保證數據持久化，從而避免伺服器宕機數據丟失問題，或者減少伺服器記憶體消耗提高性能。

持久化方式：

1、Snapshotting：快照，redis預設持久化方式，這種方式是將記憶體中的數據以快照的方式寫入到二進位文件中，預設的文件名為dump.rdb。可以通過配置設置自動做快照持久化的方式。我們可以配置redis在n秒內如果超過m個key被修改就自動做快照。

Save 900 1 #900秒內如果有超過1個key被修改，則發起快照保存。

Save 300 10 #300秒內如果有超過10個key被修改，則發起快照保存。

Save 60 1000 #60秒內如果有超過1000個 key被修改，則發起快照保存。

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

註意：該方式每次做快照都有一個時間間隔，如果伺服器在間隔內宕機，那在間隔內修改的數據將不能持久化到磁碟中。建議使用 aof方式。

2、Append-only file ：aof方式

Aof方式原理：redis會將每一個收到的寫命令都通過write函數追加到文件中（aof文件），當redis重啟時會通過重新執行該文件保存的寫命令來在記憶體中重建整個資料庫的內容。由於操作系統 OS 會在內核中緩存write做的修改，所以可能不會立即寫到磁碟中。這樣aof方式的持久化也還是可能丟失數據。但我們可以通過配置文件告訴redis我們想通過fsync函數強制os寫入到磁碟中。

配置aof：

Appendonly yes #啟用aof持久化方式

Appendfsync always #收到寫入命令就立即寫入磁碟，效率最慢，但會保證完全的數據次持久化

Appendfsync everysec #每秒中寫入磁碟一次，在性能和持久化之間做了很好的折中。

Appendfsync no # 完全以來OS，性能最好，但在持久化方面沒保證。

實例：

appendonly yes

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

測試aof是否成功：

重啟redis：

[root@localhost etc]# pkill redis-server

[root@localhost etc]# cd ../bin

[root@localhost bin]#  ./redis-server /usr/local/redis/etc/redis.conf

鏈接客戶端：

[root@localhost bin]# ./redis-cli -a jalja

127.0.0.1:6379> set addr bj

OK

查看 bin下是否存在aof文件

[root@localhost bin]# ll

總用量 26356

-rw-r--r--. 1 root root      54 2月  18 22:56 appendonly.aof

-rw-r--r--. 1 root root      97 2月  18 22:55 dump.rdb

-rw-r--r--. 1 root root     566 2月  17 22:51 mkreleasehdr.sh

-rw-r--r--. 1 root root 5578343 2月  17 22:52 redis-benchmark

-rw-r--r--. 1 root root   22217 2月  17 22:51 redis-check-aof

-rw-r--r--. 1 root root 7827978 2月  17 22:52 redis-check-rdb

-rwxr-xr-x. 1 root root 5707211 2月  17 22:52 redis-cli

-rwxr-xr-x. 1 root root 7827978 2月  17 22:52 redis-server

在這裡出現了appendonly.aof文件打開該文件

[root@localhost bin]# cat appendonly.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$4
addr
$2
bj

 二、發佈及訂閱消息

發佈訂閱(pub/sub)是一種消息通信模式，主要的目的是解耦消息發佈者和消息訂閱者之間的耦合，這點和設計模式中的觀察者模式比較相似。pub /sub不僅僅解決發佈者和訂閱者直接代碼級別耦合也解決兩者在物理部署上的耦合。redis作為一個pub/sub server，在訂閱者和發佈者之間起到了消息路由的功能。訂閱者可以通過subscribe和psubscribe命令向redis server訂閱自己感興趣的消息類型，redis將消息類型稱為通道(channel)。當發佈者通過publish命令向redis server發送特定類型的消息時。訂閱該消息類型的全部client都會收到此消息。這裡消息的傳遞是多對多的。一個client可以訂閱多個 channel,也可以向多個channel發送消息。

1、開啟兩個訂閱session

session1：

127.0.0.1:6379> subscribe tv1   訂閱頻道tv1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"  
2) "tv1"
3) (integer) 1

session2：

127.0.0.1:6379> subscribe tv1 tv2   訂閱頻道tv1和tv2
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "tv1"
3) (integer) 1
1) "subscribe"
2) "tv2"
3) (integer) 2

2、開啟發佈session      在這裡我們發佈兩個頻道的信息

127.0.0.1:6379> publish tv1 "Hello word"  #給頻道tv1發佈信息
(integer) 2     # tv1的訂閱者2位
127.0.0.1:6379> publish tv2 "Hello tv2"   #給頻道tv2發佈信息
(integer) 1    # tv2的訂閱者1位
127.0.0.1:6379> 

3、再次查看兩個訂閱頻道

session1：

127.0.0.1:6379> subscribe tv1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "tv1"
3) (integer) 1
1) "message"     #獲取了tv1發佈的信息
2) "tv1"
3) "Hello word"

session2：

127.0.0.1:6379> subscribe tv1 tv2
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "tv1"
3) (integer) 1
1) "subscribe"
2) "tv2"
3) (integer) 2
1) "message"   #獲取了tv1發佈的信息
2) "tv1"
3) "Hello word"
1) "message"  #獲取了tv2發佈的信息
2) "tv2"
3) "Hello tv2"

三、虛擬記憶體的使用

　　Redis的虛擬記憶體與操作系統中的虛擬記憶體不是一回事，但思路相同。就是將不經常訪問的數據從記憶體交換到磁碟中，從而騰出寶貴的記憶體空間用戶其他需要訪問的數據，這對於redis這樣的記憶體資料庫來說很重要，除了可以將數據分割到多個redis server外。另外能夠提高資料庫容量的方式就是使用虛擬記憶體把哪些不經常訪問的數據交換到磁碟上。

配置方式( redis.conf)：

Vm-enable yse #開啟虛擬記憶體

Vm-swap-file /tmp/redis.swap #交換出來的value保存文件路徑

Vm-max-memory 1000000 #redis使用最大記憶體的上限

Vm-page-size 32 #每個頁面的大小32位元組

Vm-pages 134217728 #最多使用多少個頁面

Vm-max-threads 4#用於執行value對象換入緩存的工作線程數量