[Redis入门到精通day03]redis配置、持久化及事务详解

Redis入门到精通day03

一、解析配置文件

1.通用配置

#是否设置为守护模式yes/no
daemonize yes
#设置进程锁文件	
pidfile /usr/local/redis/redis.pid					
#设置端口
port 6379			  
#TCP 监听的最大容纳数量，默认511
tcp-backlog 511	
#客户端超时时间默认为0永不超时
timeout 0			
bind 
#心跳检测，默认值为0
tcp-keepalive			
#日志级别，debug（测试开发阶段）、verbose（存储一些有用的Info）、notice（生产环境）和warning（仅记录重要信息）
loglevel				
#配置log文件地址
logfile "/data/logs/redis/redis.log"					
#如果要把日志记录到系统日志就改成yes
syslog-enabled no
#指定syslog里的日志标志
syslog-ident
#指定syslog设备，值可以是USER或LOCAL0-LOCAL7
syslog-facility
#设置可用数据库数，默认16，初始默认数据库为0号位
databases 16

2.SNAPSHOTTING快照

#指定在多长时间内，有多少次更新操作，就将数据同步到数据文件
save 秒钟 写操作次数
#Redis默认配置文件中提供了三个条件：
save 900 1
save 300 10
save 60 10000
#禁用rdb
save “”
#如果配置no表示不在乎数据一致
stop-writes-on-bgsave-error
#对存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbcompression
#在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
rdbchecksum
#指定本地数据库文件名
dbfilename
#指定本地数据库路径
dir /usr/local/redis/db/

3.sercurity安全问题

#获取redis当前路径
config get dir
#获取密码
config get requirepass
#修改密码
config set requirepass "123"
#使用密码登录
auth 123

4.limit限制问题

#设置redis同时可以与多少个客户端进行连接
maxclients 10000
#设置redis可以使用的内存量
maxmemory
#缓存的移除策略和过期策略,默认使用noeviction
#lru Least Recently Used最近最少使用算法,队列先进先出
#（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-policy
#设置样本数量,默认5,若小,速度快精度变差
maxmemory-samples

5.常用配置参数总结

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

5. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
   loglevel verbose

6. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
   logfile stdout

7. 设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id
   databases 16

8. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
   save
   Redis默认配置文件中提供了三个条件：
   save 900 1
   save 300 10
   save 60 10000
   分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。

9. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
   rdbcompression yes

10. 指定本地数据库文件名，默认值为dump.rdb
    dbfilename dump.rdb

11. 指定本地数据库存放目录
    dir ./

12. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
    slaveof

13. 当master服务设置了密码保护时，slav服务连接master的密码
    masterauth

14. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH 命令提供密码，默认关闭
    requirepass foobared

15. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
    maxclients 128

16. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
    maxmemory

17. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
    appendonly no

18. 指定更新日志文件名，默认为appendonly.aof
    appendfilename appendonly.aof

19. 指定更新日志条件，共有3个可选值：
    no：表示等操作系统进行数据缓存同步到磁盘（快）
    always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
    everysec：表示每秒同步一次（折衷，默认值）
    appendfsync everysec

20. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
    vm-enabled no

21. 虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
    vm-swap-file /tmp/redis.swap

22. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
    vm-max-memory 0

23. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
    vm-page-size 32

24. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
    vm-pages 134217728

25. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
    vm-max-threads 4

26. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
    glueoutputbuf yes

27. 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
    hash-max-zipmap-entries 64
    hash-max-zipmap-value 512

28. 指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
    activerehashing yes

29. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
    include /path/to/local.conf

二、持久化

rdb,aof

redis database

append only file

1.RDB

在指定时间间隔内将内存的数据集快照写入磁盘，也就是行话的Snapshot快照，它恢复时将快照文件直接读到内存里

1.rdb简介

redis会单独fork一个子进程来进行持久化，要先将数据写入到一个临时文件中，待持久化过程结束后，再用这个文件替换好上次持久化的文件。整个过程中，主进程不进行任何IO操作，确保了极高的性能。

如果进行大规模数据恢复，且对数据恢复的完整性不是很敏感，RDB的方式就比AOF方式更加高效。RDB的缺点就是最后一次持久化的数据可能会丢失。

2.Fork

fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

Rdb保存的是dump.rdb文件

3.配置文件

使用snapshotting快照

save 秒数 更变次数

4.触发快照

save 秒数 更变次数

默认1分钟改变1万次

5分钟改变10次

15分钟改变一次

禁用就是save ""或者不设置

如果flushall自动会备份

如果使用save或者bgsave指令就迅速备份

5.保存备份文件

使用冷拷贝进行保存

6.优势

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高

7.劣势

• 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就
  会丢失最后一次快照后的所有修改
• fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

8.动态停止rdb保存

redis-cli config set save “”

2.AOF

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

apppendonly yes 开启aof持久化

1.appendonly.aof和dump.rdb并存

以appendonly.aof为主

2.check工具

使用对应的check文件进行修复

redis-check-aof --fix appendonly.aof

docker不知道咋修复

3.相关配置

#always：同步持久化 每次发生数据变更会被立即记录到磁盘  性能较差但数据完整性比较好
#everysec：出厂默认推荐，异步操作，每秒记录   如果一秒内宕机，有数据丢失
#no:不配置
appendfsync
#重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。
no-appendfsync-on-rewrite
#设置重写的基准值
auto-aof-rewrite-min-size
#设置重写的基准值
auto-aof-rewrite-percentage

4.重写机制

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,
当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，
只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

**重写原理:**AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，
遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，
而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

**触发机制:**Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

5.优势与劣势

优势:可以在异步操作修改操作更新频率

劣势:相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb;aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

3.rbd与aof的选择

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些
  命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
  Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
• 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

推荐同时开启两种持久化方式

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。

三、事务

redis的事务就是可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞

也就是将一次事务的所有指令加入到一个队列中，一次性、顺序性、排他性的执行一系列命令

1.事务的使用

1.常用命令

#开启事务
multi
#结束事务去执行
exec
#放弃一个事务的执行
dicard
#监视一个key或多个key,如果这些Key在执行前发生改变则事务被打断
watch key(key...)
#取消对所有key的监视
unwatch

2.正常执行

127.0.0.1:6379> MULTI				#开启事务
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> EXEC				#关闭事务
1) OK
2) OK
3) "v2"
4) OK

3.放弃事务

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 111
QUEUED
127.0.0.1:6379> set k2 222
QUEUED
127.0.0.1:6379> DISCARD			#放弃事务后事务回滚
OK
127.0.0.1:6379> get k2
"v2"

4.全体连坐

如果其中出现一个错误,则直接执行失败,前后所有命令直接执行失败

这里是可以看成是java编译时异常

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 111
QUEUED
127.0.0.1:6379> set k2 222
QUEUED
127.0.0.1:6379> setget k3 333
(error) ERR unknown command `setget`, with args beginning with: `k3`, `333`, 
127.0.0.1:6379> set k4 444
QUEUED
127.0.0.1:6379> set k5 555
QUEUED
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

5.冤有头债有主

如果其中出现一个错误,则对应操作失败

这里是可以看成是java执行时异常

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 111
QUEUED
127.0.0.1:6379> INCR k2
QUEUED
127.0.0.1:6379> set k3 333
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK

只有执行的时候才知道有没有错误,所以找到错误的语句不执行

6.watch监控

1.悲观锁

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁

2.乐观锁

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，

乐观锁策略:提交版本必须大于记录当前版本才能执行更新

3.CAS

check and set

4.操作

127.0.0.1:6379> set balance 100
OK
127.0.0.1:6379> set debt 0
OK
127.0.0.1:6379> DECRBY balance 20
(integer) 80
127.0.0.1:6379> INCRBY debt 20
(integer) 20
127.0.0.1:6379> WATCH balance 100			#监视的时候,在另一个窗口修改balance
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set balance 50
QUEUED
127.0.0.1:6379> set debt 50
QUEUED
127.0.0.1:6379> EXEC									#在监视的时候发生修改,无法执行事务
(nil)						
127.0.0.1:6379> unwatch

5.总结

Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行

通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败

2.事务的总结

1.事务阶段

1.开启：以MULTI开始一个事务

2.入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面

3.执行：由EXEC命令触发事务

2.事务特性

1.单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

2.没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，
也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题

3.不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚.部分支持事务(全体连坐)