Redis详解文档

## 1. 解析配置文件redis
拷贝出来单独执行。
### 1.1 units单位
- 只支持bytes,不支持bit
- 对大小写不敏感
### 1.2 INCLUDES包含
可以通过includes包含其他的文件配置。
### 1.3 GENERAL通用
- daemonize
- pidfile
- port
- tcp-backlog
设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和tcp_max_syn_backlog两个值来达到想要的效果。
- timeout
- bind
- tcp-keepalive
单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60。
- loglevel
- logfile
- syslog-enabled
是否把日志输出到syslog中。
- syslog-ident
指定syslog里的日志标志。
- syslog-facility
指定syslog设备，值可以是USER或LOCAL0-LOCAL7。
- databases
### 1.4 SNAPSHOTTING 快照
#### Save
- save秒钟 写操作次数
RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，
默认
是1分钟内改了1万次，
或5分钟内改了10次，
或15分钟内改了1次。
- 禁用
如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以。
#### stop-writes-on-bgsave-error
如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制。
#### rdbcompression
对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用
LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。
#### rdbchecksum
在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约
10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
#### dbfilename
#### dir
### 1.5 REPLICATION复制
### 1.6 SECURITY安全
访问密码的查看、设置和取消
### 1.7 LIMITS限制
#### maxclients
设置redis同时可以与多少个客户端进行连接。默认情况下为10000个客户端。当你无法设置进程文件句柄限制时，redis会设置为当前的文件句柄限制值减去32，因为redis会为自
身内部处理逻辑留一些句柄出来。如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。
#### maxmemory
设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。
#### maxmemory-policy
（1）volatile-lru：使用LRU算法移除key，只对设置了过期时间的键
（2）allkeys-lru：使用LRU算法移除key
（3）volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键
（4）allkeys-random：移除随机的key
（5）volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key
（6）noeviction：不进行移除。针对写操作，只是返回错误信息
#### maxmemory-samples
设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个。
### 1.8 APPEND ONLY MODE追加
#### appendonly
#### appendfilename
#### appendfsync
- always:同步持久化，每次发生数据变更会被立即记录到操盘，性能较差数据完整性比较好。
- everysec:出厂默认推荐，异步操作，每秒记录，如果宕机，有数据丢失
- no
#### no-appendfsync-on-rewrite
重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。
#### auto-aof-rewrite-min-size
设置重写的基准值
#### auto-aof-rewrite-percetage
设置重写的基准值
### 1.9 常见配置redis.conf介绍
参数说明
redis.conf 配置项说明如下：
1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
  daemonize no
2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
  pidfile /var/run/redis.pid
3. 指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字
  port 6379
4. 绑定的主机地址
  bind 127.0.0.1
5.当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
  timeout 300
6. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
  loglevel verbose
7. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
  logfile stdout
8. 设置数据库的数量，默认数据库为0，可以使用SELECT <dbid>命令在连接上指定数据库id
  databases 16
9. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
  save <seconds> <changes>
  Redis默认配置文件中提供了三个条件：
  save 900 1
  save 300 10
  save 60 10000
  分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。
 
10. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
  rdbcompression yes
11. 指定本地数据库文件名，默认值为dump.rdb
  dbfilename dump.rdb
12. 指定本地数据库存放目录
  dir ./
13. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
  slaveof <masterip> <masterport>
14. 当master服务设置了密码保护时，slav服务连接master的密码
  masterauth <master-password>
15. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭
  requirepass foobared
16. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
  maxclients 128
17. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
  maxmemory <bytes>
18. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
  appendonly no
19. 指定更新日志文件名，默认为appendonly.aof
   appendfilename appendonly.aof
20. 指定更新日志条件，共有3个可选值： 
  no：表示等操作系统进行数据缓存同步到磁盘（快） 
  always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全） 
  everysec：表示每秒同步一次（折衷，默认值）
  appendfsync everysec
 
21. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
   vm-enabled no
22. 虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
   vm-swap-file /tmp/redis.swap
23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
   vm-max-memory 0
24. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
   vm-page-size 32
25. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
   vm-pages 134217728
26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
   vm-max-threads 4
27. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
  glueoutputbuf yes
28. 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
  hash-max-zipmap-entries 64
  hash-max-zipmap-value 512
29. 指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
  activerehashing yes
30. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
  include /path/to/local.conf


## 2. Redis的持久化
### 2.1 RDB(Redis DataBase)
#### 概念
- 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
- Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作，这就确保了极高的性能，如果需要进行大规模的数据恢复u，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能会丢失。
#### Fork
fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数据都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
#### rdb保存的是dump.rdb文件
#### 如何触发RDB快照
- 配置文件中默认的快照配置
- 命令save或者是bgsave
Save:save时只管保存，其他不管，全部阻塞
BGSAVE:Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsvae命令获取最后一次成功执行快照的时间。
- 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义
#### 如何恢复
- 将备份文件（dump.rdb）移动到redis安装目录并启动服务即可。
- CONFIG GET DIR获取目录
#### 优势
- 适合规模的数据恢复。
- 对数据完整性和一致性要求不高。
#### 劣势
- 在一定的间隔时间做一次备份，所以如果redis意外挂掉的话，就会丢失最后一次快照后的所有修改。
- fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
#### 如何停止
动态所用停止RDB保存规则的方法：redis-cli config set save ""
### 2.2 AOF(Append Only File)
#### 概念
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取文件重新构建数据，换言之，reids重启的话，就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
#### AOF保存的是appendonly.aof文件
#### AOF启动/修复/恢复
##### 正常恢复
- 启动：设置成yes
修改默认的appendonly no 改为yes 
- 将所有数据的aof文件复制一份保存到对应目录（config get dir）
- 恢复
重启redis，然后重新加载
##### 异常恢复
- 启动：设置成yes
修改默认的appendonly no 改为yes 
- 备份被写坏的AOF文件
- 修复
redis-check-aof --fix进行修复
- 恢复
重启redis，然后重新加载
#### rewrite
##### 概念
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令bfrewriteaof
##### 重写原理
AOF文件持续增长而过大时，会fork出一条新的进程来将文件重写（也是先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条的Set语句。重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据内容用命令的方式重写一个新的AOF文件。这点和快照有点类似。
##### 触发机制
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
#### 优势
- 每修改同步：appendfsync always同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好。
- 每秒同步：appendfsync everysec 异步操作，每秒记录，如果一秒钟内宕机，有数据丢失。
- 不同步：appendfsync no 从不同步。
#### 劣势
- 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
- aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同。
### 2.3 总结
- RDB持久化方式能够在指定的时间间隔内对数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新进行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
- 只作缓存：如果业务只希望数据在服务器运行的时候存在，也可以不使用任何的持久化方式。
- 同时开启两种持久化方式
（1）在这种情况下，当redis重启的时候后优先载入aof文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
（2）RDB的数据不实时，同时使用两者时服务器重启也只会找aof文件。
那么要不要只使用aof呢？
作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的bug,留作为一个万一的手段。
- 性能建议
（1）因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
（2）如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
（3）如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时挂掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构。


## 3. Redis的事务
- 开启：以MULTI开始一个事务。
- 入列：将多个命令入列到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面。
- 执行：有EXEC命令触发事务。


特性：
- 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
- 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题。
- 不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。


## 4 Redis的发布订阅


## 5. Redis的复制
### 5.1 概念
就是主从复制，主机数据更新后根据配置和策略，自动同步到备机得master/slaver机制。
### 5.2 作用
容灾备份
### 5.3 怎么玩
#### 集群创建
#### 添加从节点
#### 修改配置文件细节操作
- 拷贝多个redis.conf文件
- 开启daemonize yes
- pid文件名字
- 指定端口
- log文件名字
- dump.rdb名字
##### 一主二仆
一个Master两个Slave。
主从问题：
1 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123是否也可以复制


2 从机是否可以写？set可否？


3 主机shutdown后情况如何？从机是上位还是原地待命


4 主机又回来了后，主机新增记录，从机还能否顺利复制？


5 其中一台从机down后情况如何？依照原有它能跟上大部队吗？
### 5.4 复制原理
（1）slave启动成功连接到master后会发送一个sync命令。
（2）Master接到命令后启动后台存盘进程，同时收集所有接收到的用于修复数据集合命令，在后台进程执行完毕后，master将传送整个数据文件到slave，已完成一次完全同步。
（3）全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
（4）增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步。
（5）但是只要是重新连接Master，一次完全同步（全量复制）将被自动执行。
### 5.5 哨兵模式（sentinel）
#### 概念
能够后台监控主机是否故障，如果故障了根据投票数自动将从库换为主库。
#### 玩法
##### 在相应的目录下新建sentinel.conf文件，名字绝对不能错。
##### 配置哨兵，填写内容
（1）sentinel monitor被监控数据库名字（自己起名字）10.100.10.92:6379 1
（2）最后的数字1，表示当主机挂掉后，slave投票看让谁接替主机，得票数多的成为主机
##### 启动哨兵
redis-sentinel 文件路径/sentinel.conf
##### 问题：如果之前的master重启回来了，会不会双master冲突？
#### 一组sentinel能同时监控多个Master
### 5.6 复制的缺点
复制延时
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。


## 6. Redis的Java客户端Jedis
### 6.1 配置总结
JedisPool的配置参数大部分是由JedisPoolConfig的对应项来赋值的。
maxActive：控制一个pool可分配多少个jedis实例，通过pool.getResource()来获取；如果赋值为-1，则表示不限制；如果pool已经分配了maxActive个jedis实例，则此时pool的状态为exhausted。
maxIdle：控制一个pool最多有多少个状态为idle(空闲)的jedis实例；
whenExhaustedAction：表示当pool中的jedis实例都被allocated完时，pool要采取的操作；默认有三种。
 WHEN_EXHAUSTED_FAIL --> 表示无jedis实例时，直接抛出NoSuchElementException；
 WHEN_EXHAUSTED_BLOCK --> 则表示阻塞住，或者达到maxWait时抛出JedisConnectionException；
 WHEN_EXHAUSTED_GROW --> 则表示新建一个jedis实例，也就说设置的maxActive无用；
maxWait：表示当borrow一个jedis实例时，最大的等待时间，如果超过等待时间，则直接抛JedisConnectionException；
testOnBorrow：获得一个jedis实例的时候是否检查连接可用性（ping()）；如果为true，则得到的jedis实例均是可用的；
testOnReturn：return 一个jedis实例给pool时，是否检查连接可用性（ping()）；
testWhileIdle：如果为true，表示有一个idle object evitor线程对idle object进行扫描，如果validate失败，此object会被从pool中drop掉；这一项只有在timeBetweenEvictionRunsMillis大于0时才有意义；
timeBetweenEvictionRunsMillis：表示idle object evitor两次扫描之间要sleep的毫秒数；
numTestsPerEvictionRun：表示idle object evitor每次扫描的最多的对象数；
minEvictableIdleTimeMillis：表示一个对象至少停留在idle状态的最短时间，然后才能被idle object evitor扫描并驱逐；这一项只有在timeBetweenEvictionRunsMillis大于0时才有意义；
softMinEvictableIdleTimeMillis：在minEvictableIdleTimeMillis基础上，加入了至少minIdle个对象已经在pool里面了。如果为-1，evicted不会根据idle time驱逐任何对象。如果minEvictableIdleTimeMillis>0，则此项设置无意义，且只有在timeBetweenEvictionRunsMillis大于0时才有意义；
lifo：borrowObject返回对象时，是采用DEFAULT_LIFO（last in first out，即类似cache的最频繁使用队列），如果为False，则表示FIFO队列；


其中JedisPoolConfig对一些参数的默认设置如下：
testWhileIdle=true
minEvictableIdleTimeMills=60000
timeBetweenEvictionRunsMillis=30000
numTestsPerEvictionRun=-1


## 7. Redis集群优化
- vm-enabled no 关闭虚拟内存功能
- maxmemory 当大于所设定的物理内存后就开始拒绝后续的写入请求
- hash-max-zipmap-entries 当value内部有64个以下的成员就使用线性紧凑存储（省去了大量指针的内存开销），超过该值自动转成真正的HashMap。
- hash-max-zipmap-value 当value这个Map内部的每个成员值长度不超过多少个字节就会采用线性紧凑存储来节省空间。
```
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
```
当然这值也不是越大越好，HashMap的优势是查找和操作的时间复杂度都是O(1)，而放弃Hash采用一维存储则是O(n)的时间复杂度。
- list-max-ziplist-entries 512
- list-max-ziplist-value 64
- set-max-intset-entries 512