Redis

下载和编译过程：

$ curl -O http://download.redis.io/releases/redis-4.0.0.tar.gz
$ tar xzf redis-4.0.0.tar.gz
$ cd redis-4.0.10
$ make

上面命令成功完成后，会在 src 目录中生成下面这些可执行程序：

redis-server       # Redis服务器
redis-cli          # Redis命令行客户端
redis-benchmark    # Redis性能测试工具
redis-check-aof    # AOF文件检测工具
redis-check-rdb    # RDB文件检测工具
redis-sentinel     # Sentinel服务器，4.0开始和redis-server是同一文件，使用--sentinel指定为哨兵

使用 help COMMAND 可以查看命令的在线帮助文档。如：

127.0.0.1:6379> help del

  DEL key [key ...]
  summary: Delete a key
  since: 1.0.0
  group: generic

使用 help @GROUP 可以查看一组命令的相关帮助文档。如：

127.0.0.1:6379> help @hash

  HDEL key field [field ...]
  summary: Delete one or more hash fields
  since: 2.0.0

  HEXISTS key field
  summary: Determine if a hash field exists
  since: 2.0.0

  HGET key field
  summary: Get the value of a hash field
  since: 2.0.0

......

下面一些 GROUP 名称：

generic         # 一般命令
string          # 字符串类型命令
list            # 列表类型命令
set             # 集合类型命令
sorted_set      # 有序集合命令
hash            # hash操作命令
pubsub          # 发布命令
transactions    # 事务操作命令
connection      # 连接相关命令
server          # 服务器相关命令
scripting       # 脚本相关命令
hyperloglog     # hyperloglog类型命令
cluster         # 集群相关命令
geo             # 经纬度相关命令

Redis 应用场景很广泛，如缓存、分布式集群中的 session 共享、统计排行榜（使用 Sorted Sets）、网站点击量统计等等。

相比于 Memcached，Redis 主要有下面优点：

• 提供了丰富的数据类型；
  
• 可以持久化内存数据到磁盘，提供了 AOF 和 RDB 两种持久化机制（Memcached 不支持持久化）。
  

String 是 Redis 中最基本的类型，且它是二进制安全的（可以保存二进制数据，如图片等）。

Redis List 的常用操作如表 1 所示。

参考：
https://redis.io/commands#list

Redis Hash 常用操作如表 2 所示。

参考：
https://redis.io/commands#hash

Set 是 Strings 的集合（无序的），它的常用操作如表 3 所示。

参考：
https://redis.io/commands#set

Sorted Set 是 Strings 的有序集合，它的常用操作如表 4 所示。

参考：
https://redis.io/commands#sorted_set

位图（Bitmap）不是一个“新数据类型”，它用 String 实现，用 String 的每一个“比特位”来表示元素的一种状态。Redis 中 String 的最大长度为 512 MB，即有 \(512 \times 1024 \times 1024 \times 8 = 2^32\) 个（这个数大于 42 亿）比特位。

由于以比特为单位来存储数据，所有它非常节省内存。比如， 我们要记录 42 亿用户的在线状态，使用 512 MB 内存就足够了（每个用户占用一个比特位，比特位上用 0 和 1 分别表示“不在线”和“在线”）。

Bitmap 的常用操作如表 5 所示。

HyperLogLog 是一种“Probabilistic Data Structure”，它用于“估计集合中元素的个数”。 集合中元素个数直接使用 Redis 命令 SCARD 不就行了吗？SCARD 不仅时间复杂度为 \(O(1)\) ，而且计算还是精确的。

HyperLogLog 主要用于“大数据”场景。当集合元素非常多时，内存中可能根本放不下这么多的元素，所以无法使用 HashMap 等数据结构，甚至 BitMap 占用的内存也太大而无法使用。这时如果不要求统计绝对精确，则可以使用 HyperLogLog 。

HyperLogLog 有下面特点：
1、极少的内存可以统计极大的数据。在 Redis 的 HyperLogLog 实现中，只需要 12K 内存就能统计出实际应用中任意大集合（其实是不超时 \(2^{64}\) ，基本上不会有集合超过这个限制）中的元素个数。
2、统计不是精确的，误差率整体较低，标准误差为 0.81%。

HyperLogLog 的常用操作如表 6 所示。

注：上面命令都有前缀“PF”，它是 HyperLogLog 算法发明者 Philippe Flajolet 的首字母缩写。

Redis Best Practices 中有一个 HyperLogLog 的应用实例，请参考：https://redislabs.com/redis-best-practices/counting/hyperloglog/

Redis 事务具有原子性，一个事务中的命令要么都执行，要么都不执行。

如果一个事务中的某个命令执行出错，Redis 会怎样处理呢？要分情况讨论。
1、 某个命令出错是语法错误，这时所有命令都不执行。 语法错误表示命令不存在或者参数错误，这种情况需要区分 Redis 的版本，Redis 2.6.5 之前的版本会忽略错误的命令，执行其他正确的命令，2.6.5 之后的版本会忽略这个事务中的所有命令，都不执行。
2、 某个命令出错是运行错误，这时所有命令还是会都执行。 运行错误表示命令在执行过程中出现错误，比如用 GET 命令获取一个 Hash 类型的键值（注：GET 操作 string 类型，Hash 类型应该使用 HGET）。这种错误在命令执行之前 Redis 是无法发现的，所以在事务里这样的命令会被 Redis 接受并执行。如果事务里有一条命令执行错误，其他命令依旧会执行（包括出错之后的命令）。

Redis 中的事务没有回滚（rollback）功能，对于上面的情况 2，使用者必须自己收拾剩下的烂摊子。

Redis 的事务能保证一个事务中的几个命令会依次执行而不会被其他命令插入。试想一个客户端 A 需要执行几条命令，同时客户端 B 发送了几条命令，如果不使用事务，则客户端 B 的命令有可能会插入到客户端 A 的几条命令中，如果想避免这种情况发生，也可以使用事务。

WATCH 命令为 Redis 事务提供了 CAS（check-and-set）语义。

假设我们要实现一个 value“原子地增加 1”（假设 Redis 中还没有 INCR 命令），自然地可以想到下面伪代码：

val = GET mykey
val = val + 1
SET mykey $val

上面代码，当存在多个 client 同时执行时会出问题。比如 client A 和 client B 都执行上面代码，且两个 client 执行完第一行语句后（读到的 mykey 值相同，假设为 10）才执行第二条语句，则两个 client 结束后 mykey 会为 11，而我们希望的结果却是 12。

有了 WATCH 命令，我们可以安全地完成上面任务了：

WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC

WATCH 可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到 EXEC 命令。注：事务中的命令是在 EXEC 之后才执行的，EXEC 命令执行完之后被监控的键会自动被 UNWATCH。

对于前面说到的两个 client 同时执行的情况，并发时，有一个事务不会执行。

下面是 watch 的演示实例：

127.0.0.1:6379> set key1 100
OK
127.0.0.1:6379> watch key1
OK
127.0.0.1:6379> set key1 200  # 它会导致下面的事务不会执行（这个set命令也可以来自其它client）
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key1 300
QUEUED
127.0.0.1:6379> exec          # exec返回了nil，说明事务中的命令set key1 300并没有执行
(nil)
127.0.0.1:6379> get key1
"200"

上面的例子中，由于 watch 的键 key1 在事务执行之前被修改了，所以事务中所有命令都不会执行。

UNWATCH 命令可以在 WATCH 命令执行之后、MULTI 命令执行之前取消对某个键的监控。如：

127.0.0.1:6379> set key1 100
OK
127.0.0.1:6379> watch key1
OK
127.0.0.1:6379> set key1 200
OK
127.0.0.1:6379> unwatch
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key1 300
QUEUED
127.0.0.1:6379> exec
1) OK
127.0.0.1:6379> get key1
"300"

上面的例子中，首先设置 key1 的键值为 100，然后使用 WATCH 命令监控 key1，随后更改 key1 的值为 200，然后取消对 key1 的监控，再进入事务，事务中设置 key1 的值为 300，然后执行 EXEC 运行事务中的命令，最后使用 get 命令查看 key1 的值（是 300），也就是说事务中的命令运行成功。

注：UNWATCH 命令的使用场景比较少，因为 在执行 EXEC 或者 DISCARD 命令后，被监控的键会被自动 UNWATCH。

DISCARD 命令可以在 MULTI 命令执行之后，EXEC 命令执行之前取消 WATCH 命令并清空事务队列，然后从事务状态中退出。

执行 DISCARD 前，当前环境要在事务状态中（即之前需要执行过 MULTI）；执行完 DISCARD 后，已经了退出了事务状态，不能再执行 EXEC 命令了。

DB 相关命令如表 7 所示。

使用 keys pattern 命令可以查看满足 pattern 的所有 key。如 keys * 可以查看当前 DB 的所有 key。

使用 client list 命令可以显示所有连接的客户端，如：

127.0.0.1:6379> client list
id=635 addr=127.0.0.1:63611 fd=8 name= age=1068 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client
id=669 addr=127.0.0.1:63920 fd=9 name= age=3 idle=3 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
id=670 addr=127.0.0.1:63921 fd=10 name= age=3 idle=3 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=psetex
id=671 addr=127.0.0.1:63922 fd=11 name= age=3 idle=3 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL

使用 info memory 命令可以显示内存使用情况，如：

127.0.0.1:6379> info memory
# Memory
used_memory:1003696
used_memory_human:980.17K
used_memory_rss:7766016
used_memory_rss_human:7.41M
used_memory_peak:6791984
used_memory_peak_human:6.48M
used_memory_peak_perc:14.78%
used_memory_overhead:885286
used_memory_startup:513536
used_memory_dataset:118410
used_memory_dataset_perc:24.16%
allocator_allocated:1188072
allocator_active:1552384
allocator_resident:8290304
total_system_memory:8200540160
total_system_memory_human:7.64G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.31
allocator_frag_bytes:364312
allocator_rss_ratio:5.34
allocator_rss_bytes:6737920
rss_overhead_ratio:0.94
rss_overhead_bytes:18446744073709027328
mem_fragmentation_ratio:8.43
mem_fragmentation_bytes:6844288
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:369998
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

MONITOR 命令可以输出 redis 服务器收到的命令，这在调试时很方便。如：

$ redis-cli monitor
1339518083.107412 [0 127.0.0.1:60866] "keys" "*"
1339518087.877697 [0 127.0.0.1:60866] "dbsize"
1339518090.420270 [0 127.0.0.1:60866] "set" "x" "6"
1339518096.506257 [0 127.0.0.1:60866] "get" "x"
1339518099.363765 [0 127.0.0.1:60866] "del" "x"
1339518100.544926 [0 127.0.0.1:60866] "get" "x"

这个命令也可以在 telnet 中使用（这在手头没有安装 redis 客户端时会很方便），如：

$ telnet localhost 6379
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
MONITOR
+OK
+1339518083.107412 [0 127.0.0.1:60866] "keys" "*"
+1339518087.877697 [0 127.0.0.1:60866] "dbsize"
+1339518090.420270 [0 127.0.0.1:60866] "set" "x" "6"
+1339518096.506257 [0 127.0.0.1:60866] "get" "x"
+1339518099.363765 [0 127.0.0.1:60866] "del" "x"
+1339518100.544926 [0 127.0.0.1:60866] "get" "x"
QUIT
+OK
Connection closed by foreign host.

注：为了安全考虑，像 CONFIG 这样的命令并不会出现在 MONITOR 的输出中。

下面以命令 keys * 为例，介绍如何把输出导出到文件中：

$ redis-cli keys '*'          # 显示所有keys
$ redis-cli keys '*' > 1.log  # 把命令（keys *）的输出导出到文件1.log

上一节讨论的 Redis 锁基于前提：Redis 工作于单机模式。这已经满足了大部分场景的需求，如果 Redis 是集群模式，有多个 Master 节点，则推荐使用 Redis 作者 Antirez 写的 Redlock。这里不详细介绍，请参考：https://redis.io/topics/distlock

Martin 在文章 How to do distributed locking 指出 Redis 实现分布式锁存在很多安全问题。如图 1 所示，由 GC 的 STW 可能导致的锁失效。

初看上去，有人可能会说，既然客户端 1 从 GC pause 中恢复过来以后不知道自己持有的锁已经过期了，那么它可以在访问共享资源之前先判断一下锁是否过期。但仔细想想，这丝毫也没有帮助。因为 GC pause 可能发生在任意时刻，也许恰好在判断完之后。也有人会说，如果客户端使用没有 GC 的语言来实现，是不是就没有这个问题呢？Martin 指出，系统环境太复杂，仍然有很多原因导致进程的 pause，比如虚存造成的缺页故障(page fault)，再比如 CPU 资源的竞争。即使不考虑进程 pause 的情况，网络延迟也仍然会造成类似的结果。

在 Martin 的这篇文章中，还有一个很有见地的观点，就是对锁的用途的区分。他把锁的用途分为两种：

1、为了效率(efficiency)，协调各个客户端避免做重复的工作。即使锁偶尔失效了，只是可能把某些操作多做一遍而已，不会产生其它的不良后果。比如重复发送了一封同样的 email。
2、为了正确性(correctness)。在任何情况下都不允许锁失效的情况发生，因为一旦发生，就可能意味着数据不一致(inconsistency)，数据丢失，文件损坏，或者其它严重的问题。

最后，Martin 得出了如下的结论：
1、 如果是为了效率(efficiency)而使用分布式锁，允许锁的偶尔失效，那么使用单 Redis 节点的锁方案就足够了，简单而且效率高。Redlock 则是个过重的实现(heavyweight)。
2、 如果是为了正确性(correctness)在很严肃的场合使用分布式锁，那么不要使用 Redlock。它不是建立在异步模型上的一个足够强的算法，它对于系统模型的假设中包含很多危险的成分。那应该使用什么技术呢？Martin 认为，应该考虑类似 Zookeeper 的方案，或者支持事务的数据库。

参考：
http://zhangtielei.com/posts/blog-redlock-reasoning.html
http://zhangtielei.com/posts/blog-redlock-reasoning-part2.html

RDB（Redis DataBase）基本原理是在不同的时间点，将 Redis 存储的数据生成快照并存储到磁盘等介质上。

使用命令 save （不带参数时可以直接生成快照，生成快照时不会响应客户端请求，带参数时可以配置生成快照的策略）和 bgsave （创建子进程生成快照，可以响应客户端请求）可以创建快照。

使用 bgsave 命令创建快照的原理（利用了 fork 的 copy-on-write 特性）：
1、Redis 调用 fork 创建子进程。
2、父进程继续处理 client 的请求，子进程负责将内存内容写入到临时文件。由于 fork 的写时复制机制（copy-onwrite）父子进程会共享相同的物理页面，当父进程处理写请求时操作系统会为父进程要修改的页面创建副本，而不是写共享的页面。所以 子进程的地址空间内的数据是 fork 时刻整个数据库的一个快照。
3、当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

AOF（Append Only File）原理：把执行过的写指令记录到文件（appendonly.aof）中，在数据恢复时按照从前到后的顺序再将指令都执行一遍。

下面是查看和打开 AOF 的方法（修改配置时最好保存到 redis.conf 文件中，否则重启 Redis 时会丢失配置）：

127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379> config set appendonly yes
OK
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "yes"

把写指令同步到 appendonly.aof 文件中，有 3 种策略（默认为第 2 种策略，即每秒钟同步一次）：

1. appendfsync always: fsync every time a new command is appended to the AOF. Very very slow, very safe.
   
2. appendfsync everysec: fsync every second. Fast enough (in 2.4 likely to be as fast as snapshotting), and you can lose 1 second of data if there is a disaster.
   
3. appendfsync no: Never fsync, just put your data in the hands of the Operating System. The faster and less safe method. Normally Linux will flush data every 30 seconds with this configuration, but it's up to the kernel exact tuning.
   

RDB 的缺点：对数据的完整性非常敏感时，RDB 方式不太适合你，因为即使你每 5 分钟都持久化一次，当 Redis 故障时，仍然会有近 5 分钟的数据丢失。这种情况下，AOF 更适合你。

AOF 也有缺点：（1）在同样数据规模的情况下，AOF 文件要比 RDB 文件的体积大；（2）AOF 方式的恢复速度也要慢于 RDB 方式。

Redis 可以配置为主从模式：即一个主库，一个或多个从库。主库支持“读写”，默认从库只支持“读”（可以把 replica-read-only 设置为 no 从而让从库也支持写，但不推荐这样做，它可能造成主从不一致的情况）。

主从配置很简单。把想设置为从库的 Redis 服务器配置文件 redis.conf 中增加下面配置即可：

# replicaof <masterip> <masterport>
replicaof 192.168.1.1 6379

参考：Redis Replication

Sentinel（哨兵）：由多个 Sentinel 节点（要实现高可用，Sentinel 节点的个数应该为奇数，至少三个）组成的 Sentinel 系统可以监视任意多个主节点，以及这些主节点属下的所有从节点，并当被监视的主节点进入下线状态时，自动下线主节点，并将主节点下的某个从节点升级为的主节点，然后由的主节点代替已下线的主节点处理命令请求。

哨兵模式克服了主从模式中遇到故障需要人为干预的缺点。

要启动哨兵节点，有两种方式，一是启动 redis-sentinel ，二是 redis-server 启动时增加参数 --sentinel 。

参考：Redis Sentinel Documentation

Redis 集群是 Redis 提供的分布式解决方案，集群通过分片（sharding）来进行数据共享，并提供复制和故障转移功能。

参考：
Redis Cluster Tutorial
Redis Cluster Specification

默认，在 64 位系统下，Redis 不会限制内存使用。通过配置 maxmemory 可以限制最大的使用内存。当内存到达限制时，默认策略是报错，通过配置 maxmemory-policy 可以设置内存到达限制后的策略，支持表 8 所示的策略。

Redis 服务器提供了两个配置用于记录执行时间过长的命令：
1、 slowlog-log-slower-than 这是阈值，单位为微秒，执行时间长于这个值的命令将被记录下来；
2、 slowlog-max-len 最大记录多少条慢日志。

通过命令 slowlog get 可以查看当前的慢日志，如：

127.0.0.1:6379> slowlog get
1) 1) (integer) 6
   2) (integer) 1558142539        # 命令执行时的 UNIX 时间戳
   3) (integer) 44816             # 命令执行的时长（单位为微秒）
   4) 1) "info"
   5) "127.0.0.1:62511"
   6) ""
2) 1) (integer) 5
   2) (integer) 1558642246
   3) (integer) 122096
   4) 1) "CONFIG"
      2) "GET"
      3) "slowlog-log-slower-than"
   5) "127.0.0.1:62265"
   6) ""