Redis 4.0 功能簡介

本文將對 Redis 4.0 的各項主要新功能作一個簡單的介紹。

模塊系統 Redis 4.0 發生的最大變化就是加入了模塊系統， 這個系統可讓用戶經過本身編寫的代碼來擴展和實現 Redis
自己並不具有的功能， 具體使用方法能夠參考 antirez 的博文《Redis Loadable Module System》：
http://antirez.com/news/106

由於模塊系統是經過高層次 API 實現的， 它與 Redis 內核自己徹底分離、互不干擾， 因此用戶能夠在有須要的狀況下才啓用這個功能， 如下是 redis.conf 中記載的模塊載入方法：

MODULES

Load modules at startup. If the server is not able to load modules 
 it will abort. It is possible to use multiple loadmodule directives. 
 loadmodule /path/to/my_module.so  
 loadmodule /path/to/other_module.so

目前已經有人使用這個功能開發了各類各樣的模塊， 好比 Redis Labs 開發的一些模塊就能夠在 http://redismodules.com 看到， 此外 antirez 本身也使用這個功能開發了一個神經網絡模塊： https://github.com/antirez/ne...

模塊功能使得用戶能夠將 Redis 用做基礎設施， 並在上面構建更多功能， 這給 Redis 帶來了無數新的可能性。

PSYNC 2.0

新版本的 PSYNC 命令解決了舊版本的 Redis 在複製時的一些不夠優化的地方：

在舊版本 Redis 中， 若是一個從服務器在 FAILOVER 以後成爲了新的主節點， 那麼其餘從節點在複製這個新主的時候就必須進行全量複製。 在 Redis 4.0 中， 新主和從服務器在處理這種狀況時， 將在條件容許的狀況下使用部分複製。
在舊版本 Redis 中， 一個從服務器若是重啓了， 那麼它就必須與主服務器從新進行全量複製， 在 Redis 4.0 中， 只要條件容許， 主從在處理這種狀況時將使用部分複製。
緩存驅逐策略優化
新添加了 Last Frequently Used 緩存驅逐策略， 具體信息見 antirez 的博文《Random notes on improving the Redis LRU algorithm》： http://antirez.com/news/109

另外 Redis 4.0 還對已有的緩存驅逐策略進行了優化， 使得它們可以更健壯、高效、快速和精確。

非阻塞 DEL 、 FLUSHDB 和 FLUSHALL

在 Redis 4.0 以前， 用戶在使用 DEL 命令刪除體積較大的鍵， 又或者在使用 FLUSHDB 和 FLUSHALL 刪除包含大量鍵的數據庫時， 均可能會形成服務器阻塞。

爲了解決以上問題， Redis 4.0 新添加了 UNLINK 命令， 這個命令是 DEL 命令的異步版本， 它能夠將刪除指定鍵的操做放在後臺線程裏面執行， 從而儘量地避免服務器阻塞：

redis> UNLINK fruits
(integer) 1

由於一些歷史緣由， 執行同步刪除操做的 DEL 命令將會繼續保留。

此外， Redis 4.0 中的 FLUSHDB 和 FLUSHALL 這兩個命令都新添加了 ASYNC 選項， 帶有這個選項的數據庫刪除操做將在後臺線程進行：

redis> FLUSHDB ASYNC
OK

redis> FLUSHALL ASYNC
OK

交換數據庫

Redis 4.0 對數據庫命令的另一個修改是新增了 SWAPDB 命令， 這個命令能夠對指定的兩個數據庫進行互換： 好比說， 經過執行命令 SWAPDB 0 1 ， 咱們能夠將原來的數據庫 0 變成數據庫 1 ， 而原來的數據庫 1 則變成數據庫 0 。

如下是一個使用 SWAPDB 的例子：

redis> SET your_name "huangz"  -- 在數據庫 0 中設置一個鍵
OK

redis> GET your_name
"huangz"

redis> SWAPDB 0 1  -- 互換數據庫 0 和數據庫 1
OK

redis> GET your_name  -- 如今的數據庫 0 已經沒有以前設置的鍵了
(nil)

redis> SELECT 1  -- 切換到數據庫 1
OK

redis[1]> GET your_name -- 以前在數據庫 0 設置的鍵如今能夠在數據庫 1 找到
"huangz" -- 證實兩個數據庫已經互換

混合 RDB-AOF 持久化格式

Redis 4.0 新增了 RDB-AOF 混合持久化格式， 這是一個可選的功能， 在開啓了這個功能以後， AOF 重寫產生的文件將同時包含 RDB 格式的內容和 AOF 格式的內容， 其中 RDB 格式的內容用於記錄已有的數據， 而 AOF 格式的內存則用於記錄最近發生了變化的數據， 這樣 Redis 就能夠同時兼有 RDB 持久化和 AOF 持久化的優勢 —— 既可以快速地生成重寫文件， 也可以在出現問題時， 快速地載入數據。

這個功能能夠經過 aof-use-rdb-preamble 選項進行開啓， redis.conf 文件中記錄了這個選項的使用方法：

# When rewriting the AOF file, Redis is able to use an RDB preamble in the
# AOF file for faster rewrites and recoveries. When this option is turned
# on the rewritten AOF file is composed of two different stanzas:
#
#   [RDB file][AOF tail]
#
# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
#
# This is currently turned off by default in order to avoid the surprise
# of a format change, but will at some point be used as the default.
aof-use-rdb-preamble no

內存命令

新添加了一個 MEMORY 命令， 這個命令能夠用於視察內存使用狀況， 並進行相應的內存管理操做：

redis> MEMORY HELP
1) "MEMORY USAGE <key> [SAMPLES <count>] - Estimate memory usage of key"
2) "MEMORY STATS                         - Show memory usage details"
3) "MEMORY PURGE                         - Ask the allocator to release memory"
4) "MEMORY MALLOC-STATS                  - Show allocator internal stats"

其中， 使用 MEMORY USAGE 子命令能夠估算儲存給定鍵所需的內存：

redis> SET msg "hello world"
OK

redis> SADD fruits apple banana cherry
(integer) 3

redis> MEMORY USAGE msg
(integer) 62

redis> MEMORY USAGE fruits
(integer) 375
使

用 MEMORY STATS 子命令能夠查看 Redis 當前的內存使用狀況：

redis> MEMORY STATS
1) "peak.allocated"
2) (integer) 1014480
3) "total.allocated"
4) (integer) 1014512
5) "startup.allocated"
6) (integer) 963040
7) "replication.backlog"
8) (integer) 0
9) "clients.slaves"
10) (integer) 0
11) "clients.normal"
12) (integer) 49614
13) "aof.buffer"
14) (integer) 0
15) "db.0"
16) 1) "overhead.hashtable.main"
    2) (integer) 264
    3) "overhead.hashtable.expires"
    4) (integer) 32
17) "overhead.total"
18) (integer) 1012950
19) "keys.count"
20) (integer) 5
21) "keys.bytes-per-key"
22) (integer) 10294
23) "dataset.bytes"
24) (integer) 1562
25) "dataset.percentage"
26) "3.0346596240997314"
27) "peak.percentage"
28) "100.00315093994141"
29) "fragmentation"
30) "2.1193723678588867"

使用 MEMORY PURGE 子命令能夠要求分配器釋放更多內存：

redis> MEMORY PURGE
OK
使用 MEMORY MALLOC-STATS 子命令能夠展現分配器內部狀態：

redis> MEMORY MALLOC-STATS
Stats not supported for the current allocator

兼容 NAT 和 Docker

Redis 4.0 將兼容 NAT 和 Docker ， 具體的使用方法在 redis.conf 中有記載：

CLUSTER DOCKER/NAT support

# In certain deployments, Redis Cluster nodes address discovery fails, because
# addresses are NAT-ted or because ports are forwarded (the typical case is
# Docker and other containers).
#
# In order to make Redis Cluster working in such environments, a static
# configuration where each node known its public address is needed. The
# following two options are used for this scope, and are:
#
# * cluster-announce-ip
# * cluster-announce-port
# * cluster-announce-bus-port
#
# Each instruct the node about its address, client port, and cluster message
# bus port. The information is then published in the header of the bus packets
# so that other nodes will be able to correctly map the address of the node
# publishing the information.
#
# If the above options are not used, the normal Redis Cluster auto-detection
# will be used instead.
#
# Note that when remapped, the bus port may not be at the fixed offset of
# clients port + 10000, so you can specify any port and bus-port depending
# on how they get remapped. If the bus-port is not set, a fixed offset of
# 10000 will be used as usually.
#
# Example:
#
# cluster-announce-ip 10.1.1.5
# cluster-announce-port 6379
# cluster-announce-bus-port 6380

一共有15項內容，內存使用量均以字節爲單位，咱們一個一個來看：

1. peak.allocated

redis啓動到如今，最多使用過多少內存。

2. total.allocated

當前使用的內存總量。

3. startup.allocated

redis啓動初始化時使用的內存，有不少讀者會比較奇怪，爲何個人redis啓動之後什麼都沒作就已經佔用了幾十MB的內存？
這是由於redis自己不只存儲key-value，還有其餘的內存消耗，好比共享變量、主從複製、持久化和db元信息，下面各項會有詳細介紹。

4. replication.backlog

主從複製backlog使用的內存，默認10MB，backlog只在主從斷線重連時發揮做用，主從複製自己並不依賴此項。

5. clients.slaves

主從複製中全部slave的讀寫緩衝區，包括output-buffer（也即輸出緩衝區）使用的內存和querybuf（也即輸入緩衝區），這裏簡單介紹一下主從複製：

redis把一次事件循環中，全部對數據庫發生更改的內容先追加到slave的output-buffer中，在事件循環結束後統一發送給slave。
那麼主從之間就不免會有數據的延遲，若是主從之間鏈接斷開，重連時爲了保證數據的一致性就要作一次全量同步，這顯然是不夠高效的。backlog就是爲此而設計，master在backlog中緩存一部分主從複製的增量數據，斷線重連時若是slave的偏移量在backlog中，那就能夠只把偏移量以後的增量數據同步給slave便可，避免了全量同步的開銷。

6. clients.normal

除slave外全部其餘客戶端的讀寫緩衝區。
有時候一些客戶端讀取不及時，就會形成output-buffer積壓佔用內存過多的狀況，能夠經過配置項client-output-buffer-limit來限制，當超過閾值以後redis就會主動斷開鏈接以釋放內存，slave亦是如此。

7. aof.buffer

此項爲aof持久化使用的緩存和aofrewrite時產生的緩存之和，固然若是關閉了appendonly那這項就一直爲0：

redis並非在有寫入時就當即作持久化的，而是在一次事件循環內把全部的寫入數據緩存起來，待到事件循環結束後再持久化到磁盤。
aofrewrite時緩存增量數據使用的內存，只在aofrewrite時纔會使用，aofrewrite機制能夠參考以前的文章《redis4.0之利用管道優化aofrewrite》。

能夠看出這一項的大小與寫入流量成正比。

8. db.0

redis每一個db的元信息使用的內存，這裏只使用了db0，因此只打印了db0的內存使用狀態，當使用其餘db時也會有相應的信息。

db的元信息有如下三項：

a) redis的db就是一張hash表，首先就是這張hash表使用的內存（redis使用鏈式hash，hash表中存放全部鏈表的頭指針）；

b) 每個key-value對都有一個dictEntry來記錄他們的關係，元信息便包含該db中全部dictEntry使用的內存；

c) redis使用redisObject來描述value所對應的不一樣數據類型（string、list、hash、set、zset），那麼redisObject佔用的空間也計算在元信息中。

overhead.hashtable.main：

    db的元信息也便是以上三項之和，計算公式爲：

hashtable + dictEntry + redisObject

overhead.hashtable.expires:

對於key的過時時間，redis並無把它和value放在一塊兒，而是單獨用一個hashtable來存儲，可是expires這張hash表記錄的是key-expire信息，因此不須要`redisObject`來描述value，其元信息也就少了一項，計算公式爲：

hashtable + dictEntry

9. overhead.total

3-8項之和：startup.allocated+replication.backlog+clients.slaves+clients.normal+aof.buffer+dbx

10. dataset.bytes

全部數據所使用的內存——也即total.allocated - overhead.total——當前內存使用量減去管理類內存使用量。

11. dataset.percentage

全部數據佔比，這裏並無直接使用total.allocated作分母，而是除去了redis啓動初始化的內存，計算公式爲：

100 * dataset.bytes / (total.allocated - startup.allocated)

12. keys.count

redis當前存儲的key總量

13. keys.bytes-per-key

平均每一個key的內存大小，直覺上應該是用dataset.bytes除以keys.count便可，可是redis並無這麼作，而是把管理類內存也平攤到了每一個key的內存使用中，計算公式爲：

    (total.allocated - startup.allocated) / keys.count

14. peak.percentage

當前使用內存與歷史最高值比例

15. fragmentation

內存碎片率

2. MEMORY USAGE

相信全部redis用戶都但願對每個key-value的內存使用瞭如指掌，然而4.0以前redis並無提供一個明確的方法來進行內存評估，不過從4.0開始，MEMORY命令實現了這一功能。

首先看下使用方法：MEMORY usage [samples]

命令參數很少，經過字面意思也能夠看出來是評估指定key的內存使用狀況。samples是可選參數默認爲5，以hash爲例看下其若是工做：

首先相似於上一節中的overhead.hashtable.main，要計算hash的元信息內存，包括hash表的大小以及全部dictEntry的內存佔用信息。
與overhead.hashtable.main不一樣的是，每一個dictEntry中key-value都是字符串，因此沒redisObject的額外消耗。在評估真正的數據內存大小時redis並無去遍歷全部key，而是採用的抽樣估算：隨機抽取samples個key-value對計算其平均內存佔用，再乘以key-value對的個數即獲得結果。試想一下若是要精確計算內存佔用，那麼就須要遍歷全部的元素，當元素不少時就是使redis阻塞，因此請合理設置samples的大小。

其餘數據結構的計算方式相似於hash，此處就再也不贅述。

3. MEMORY DOCTOR

此項子命令是做者給出的關於redis內存使用方面的建議，在不一樣的容許狀態下會有不一樣的分析結果：
首先是沒問題的狀況

運行狀態良好：

Hi Sam, I can't find any memory issue in your instance. I can only account for what occurs on this base.

redis的數據量很小，暫無建議：

Hi Sam, this instance is empty or is using very little memory, my issues detector can't be used in these conditions. Please, leave for your mission on Earth and fill it with some data. The new Sam and I will be back to our programming as soon as I finished rebooting.

接下來出現的結果就須要注意了

內存使用峯值1.5倍於目前內存使用量，此時內存碎片率可能會比較高，須要注意：

Peak memory: In the past this instance used more than 150% the memory that is currently using. The allocator is normally not able to release memory after a peak, so you can expect to see a big fragmentation ratio, however this is actually harmless and is only due to the memory peak, and if the Redis instance Resident Set Size (RSS) is currently bigger than expected, the memory will be used as soon as you fill the Redis instance with more data. If the memory peak was only occasional and you want to try to reclaim memory, please try the MEMORY PURGE command, otherwise the only other option is to shutdown and restart the instance.

內存碎片率太高超過1.4，須要注意：

High fragmentation: This instance has a memory fragmentation greater than 1.4 (this means that the Resident Set Size of the Redis process is much larger than the sum of the logical allocations Redis performed). This problem is usually due either to a large peak memory (check if there is a peak memory entry above in the report) or may result from a workload that causes the allocator to fragment memory a lot. If the problem is a large peak memory, then there is no issue. Otherwise, make sure you are using the Jemalloc allocator and not the default libc malloc.
每一個slave緩衝區的平均內存超過10MB，緣由多是master寫入流量太高，也有多是主從同步的網絡帶寬不足或者slave處理較慢：

Big slave buffers: The slave output buffers in this instance are greater than 10MB for each slave (on average). This likely means that there is some slave instance that is struggling receiving data, either because it is too slow or because of networking issues. As a result, data piles on the master output buffers. Please try to identify what slave is not receiving data correctly and why. You can use the INFO output in order to check the slaves delays and the CLIENT LIST command to check the output buffers of each slave.

普通客戶端緩衝區的平均內存超過200KB，緣由多是pipeline使用不當或者Pub/Sub客戶端處理消息不及時致使：

Big client buffers: The clients output buffers in this instance are greater than 200K per client (on average). This may result from different causes, like Pub/Sub clients subscribed to channels bot not receiving data fast enough, so that data piles on the Redis instance output buffer, or clients sending commands with large replies or very large sequences of commands in the same pipeline. Please use the CLIENT LIST command in order to investigate the issue if it causes problems in your instance, or to understand better why certain clients are using a big amount of memory.

4. MEMORY MALLOC-STATS

打印內存分配器狀態，只在使用jemalloc時有用。

5. MEMORY PURGE

請求分配器釋放內存，一樣只對jemalloc生效。

結語
關於 Redis 4.0 的主要更新就介紹到這裏， 想要詳細瞭解 Redis 4.0 各項修改的讀者能夠參考 Release Note ： https://raw.githubusercontent...