redis进阶

redis持久化

Redis虽然是定义为一个内存数据库，但是其也支持数据的持久化，在Redis中提供了两种持久化机制：RDB持久化和AOF持久化。

RDB

• 概念
  RDB全称Redis Database，若设置持久化方式为rdb，redis默认会生成dump.rdb文件，保存当前数据副本dump.rdb
• 触发方式
  RDB有两种触发方式，手动触发和自动触发；
  1）手动触发：
  使用save和bgsave命令手动触发RDB，save是工作线程执行持久化操作，会阻塞其他客户端请求；bgsave是主线程会foce一个子线程来做持久化操作，主线程继续执行客户端请求。
  lastsave查看执行成功时间；
  
  2）自动触发：
  flushall、shutdown命令执行时，都会触发rdb；
  配置文件配置触发：

save 900 1  # 900秒内至少有一个key被添加或者更新，触发rdb
save 300 10 # 300秒内.....
save 60 10000 # 60秒内.....

• 优缺点
  优点：
  1）文件小；
  2）恢复数据快；
  3）子线程做持久化；
  缺点：
  1）不实时，丢数据；
  2）需要父进程fork子进程，短暂父进程不可用；

AOF

• 概念
  AOF全程，append only file文件追加，采用日志记录的方式将所有操作记录都存到文件appendonly.aof中。redis重启时按照aof文件执行命令来恢复数据。
• 触发方式
  aof默认是关闭的，可以修改配置触发：

appendonly no  #是否开启AOF机制，默认是no表示关闭，修改为yes则表示开启
appendfilename "appendonly.aof"  #AOF文件名

• 何时写入磁盘
  AOF机制下数据是否实时写入磁盘，这个和MySQL的redo log机制很类似，也是需要通过参数来进行控制。
  AOF数据何时写入磁盘由参数appendfsync来进行控制：

appendfsync	描述	备注
always	写入缓存的同时通知操作系统刷新（fsync）到磁盘（但是也可能会有部分操作系统只是尽快刷盘，而不是实时刷盘）	Slow, Safest
everysec	先写入缓存，然后每秒中刷一次盘（默认值），这种模式极端情况可能会丢失1s的数据	Compromise
no	只写入缓存，什么时候刷盘由操作系统自己决定	Faster

• 优缺点
  优点：
  1）默认策略最多损失一秒数据；
  2）文件记录格式易于理解，能看懂；
  缺点：
  1）相同数据aof文件比rdb文件大；
  2）恢复慢；
  3）因为AOF文件是追加形式，可能会遇到BRPOP、LPUSH等阻塞命令的错误，从而导致生成的AOF在重新加载时不能复制完全相同的数据集，而RDB文件每次都是重新从头创建快照，这在一定程度上来说RDB文件更加健壮；

redis淘汰策略

假如Redis当中所有的键都没有过期，而且此时内存满了，那么客户端继续执行set等命令时Redis会怎么处理呢？Redis当中提供了不同的淘汰策略来处理这种场景。

首先Redis提供了一个参数maxmemory来配置Redis最大使用内存：

maxmemory
或者也可以通过命令config set maxmemory 1GB来动态修改。

如果没有设置该参数，那么在32位的操作系统中Redis最多使用3GB内存，而在64位的操作系统中则不作限制。

Redis中提供了8种淘汰策略，可以通过参数maxmemory-policy进行配置：

• 8种淘汰策略

淘汰策略	说明
volatile-lru	根据lru算法，删除设置了过期时间的key，直到腾出可用空间。如果没有可删除key，且内存不够用时，直接报错
allkeys-lru	根据lru算法，删除所有的key，直到腾出可用空间。如果没有可删除key，且内存不够用时，直接报错
volatile-lfu	根据lfu算法，删除设置了过期时间的key，直到腾出可用空间。如果没有可删除key，且内存不够用时，直接报错
allkeys-lfu	根据lfu算法，删除所有的key，直到腾出可用空间。如果没有可删除key，且内存不够用时，直接报错
volatile-random	随机删除设置了过期时间的key，直到腾出可用空间。如果没有可删除key，且内存不够用时，直接报错
allkeys-random	随机删除所有的key，直到腾出可用空间。如果没有可删除key，且内存不够用时，直接报错
volatile-ttl	根据键值对象，删除即将过期时间的key，直到腾出可用空间。如果没有可删除key，且内存不够用时，直接报错
noevication	默认策略， 直接报错

• LRU算法
  LRU全称为Least Recently Used。即：最近最长时间未被使用。这个主要针对的是使用时间。
• LFU算法
  LFU全称为Least Frequently Used。即：最近最少频率使用，这个主要针对的是使用频率。

redis事务

• 概念
  redis事务不是真正的事务，只保证串行化执行命令；
  redis当中每个命令都是原子的，但是当我们把一批命令组合操作时，要保证数据一致性时，就需要开启redis事务（或者使用lua脚本）；
  redis通过4个命令实现事务：
  1）multi：开启事务；
  2）exec：执行事务；
  3）discard：取消事务；
  4）watch：监视，可以为redis添加CAS乐观锁行为，可以在exec前监视key变化，如有变化则事务执行返回nil，如下图：
  

• redis事务ACID特性
  1）原子性：不保证原子性，有报错不回滚，跳过继续执行
  
  redis作者认为，发生事务回滚的原因都是程序错误导致，说白了就是redis不为程序员编程错误买单；
  redis追求简单高效，传统的事务实现复杂，和redis思想相违背；
  2）一致性：
  redis事务满足一致性，错误命令不会执行，保证从一个正确状态到另一个正确状态；
  3）隔离性：
  事务中所有命令按顺序执行，其他客户端请求不会被执行，满足隔离性；
  4）持久性：
  开启持久化可满足持久性；

LUA脚本

• 概念
  使用Lua脚本最大的好处是Redis会将脚本作为一个整体执行，不会被其它请求打断，可以保持原子性且减少了网络开销。
• LUA语法
  eval lua-script numkeys key [key …] arg [arg …]
  eval：执行Lua脚本的命令。
  lua-script：Lua脚本内容。
  numkeys：表示的是Lua脚本中需要用到多少个key，如果没用到则写0。
  key [key …]：将key作为参数按顺序传递到Lua脚本，numkeys是0时则可省略。
  arg：Lua脚本中用到的参数，如果没有可省略。
• 示例
  eval “return redis.call(‘set’,KEYS[1],ARGV[1])” 1 name luatest
  

redis集群

• 为什么要有redis集群？
  Redis作为一款优秀的Nosql数据库，使用非常广泛。但是在有些场景下，一台Redis服务器是不能满足要求的，我们可能需要多台Redis服务器来一起工作，而且如果仅仅使用一台Redis服务器，那么假如这一台服务器宕机了，也会给业务带来很大的影响，严重的可能会导致整个系统不可用，所以一个高可用的分布式Redis集群是非常必要的。

• 主从
  1）主从设置：主：replicaof(salveof) no one 从：replicaof(salveof) 127.0.0.1 6379
  2）主从同步原理：
  全量同步： 主 -> bgsave -> RDB文件，从：接收RDB文件；后续同步命令；
  命令传播：主服务器每执行一个能改变数据库状态的命令就会立刻实时同步给从服务器，配置repl-disable-tcp-nodelay no；
  部分同步：
  

• 主从缺点
  非高可用：
  1）首次同步或者部分重同步时需要执行全量同步时发送的RDB文件如果过大，则会非常耗时；
  2）master节点挂掉，不会有slave节点主动切换为master，需要手动切换；

• 哨兵（sentinel）
  单独的master-slave集群最大的缺点就是一旦master节点挂了，并不能自动实现将其中一个slave节点选举为master节点，所以sentinel机制就相当于是一个监控，用来实现主从的自动切换，从而让整个集群达到高可用性。

• 启用哨兵
  redis-server redis.conf
  redis-server sentinel.conf --sentinel

• 哨兵缺点
  1）主从切换过程会丢失数据，因为只有一个master，切换过程中服务不可用；
  2）本质还是master-slave集群，即一主n从，master只有一个，没有实现水平扩展；

• redis cluster分片集群
  高并发用，数据分片隔离；
  最少3主3从，因为需要过半选举；