Redis进阶

redis的性能调优基本都在redis.conf.txt 。

一、MEMORY MANAGEMENT

1.redis 设置密码  

requirepass mypass
config set requirepass "123456"

2.缓存过期策略.

内存打满时 --清除无用和过期数据

# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached. You can select among five behaviors:
#
# volatile-lru -> Evict using approximated LRU among the keys with an expire set.
# allkeys-lru -> Evict any key using approximated LRU.
# volatile-lfu -> Evict using approximated LFU among the keys with an expire set.
# allkeys-lfu -> Evict any key using approximated LFU.
# volatile-random -> Remove a random key among the ones with an expire set.
# allkeys-random -> Remove a random key, any key.
# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
# noeviction -> Don't evict anything, just return an error on write operations.

# The default is:
#
 maxmemory-policy allkeys-lru

容如下

a. volatile-lru：使用LRU算法移除key，只对设置了过期时间的键
b. allkeys-lru：使用LRU算法移除key
c. volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键
d. allkeys-random：移除随机的key
e. volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key
f. noeviction：不进行移除。针对写操作，只是返回错误信息

 

二、持久化 -- RDB（Redis DataBase）

1. 什么是RDB

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

2. RDB实现过程

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

2.1 什么是Fork

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

3. 如何触发RDB快照

RDB 保存的是dump.rdb文件
3.1
save 900 1
save 300 10
save 60 10000

# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed

RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，
默认

或15分钟内改了1次；

或5分钟内改了10次；

或1分钟内改了1万次；
 

3.2 save bgsave
Save：save时只管保存，其它不管，全部阻塞
BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间

3.3 flushall
执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

4. 如何恢复？

将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可

5. RDB优点

适合大规模的数据恢复
对数据完整性和一致性要求不高
在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改

6. RDB缺点

Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

7. 如何停止

动态所有停止RDB保存规则的方法：redis-cli config set save ""

8. RDB 总结 

1.RDB是一个非常紧凑的文件
2.RDB在保存RDB文件时，父进程唯一需要做的就是fork一个子进程，接下来的全部工作由子进程来做。
父进程不需要再做其他IO操作，所以RDB的持久化方式可以最大化redis性能
3.与AOF相比，在恢复大的数据集时，RBD方式会快一些
4.数据丢失风险大
5.RDB需要经常fork子进程来保存数据到磁盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致redis在一些毫秒级不能响应客户端请求

 

三、持久化 -- AOF（Append Only File）

默认关闭的 appendonly no  [公司项目中也没有开启]

默认保存文件  appendonly.aof

1. 什么是AOF

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

2. 持久化策略

每修改同步：appendfsync always   同步持久化 每次发生数据变更会被立即记录到磁盘  性能较差但数据完整性比较好
每秒同步：appendfsync everysec    异步操作，每秒记录   如果一秒内宕机，有数据丢失
不同步：appendfsync no   从不同步

# appendfsync always
appendfsync everysec
# appendfsync no

3. 什么是重写rewrite

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

3.1 重写rewrite实现原理

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

3.2 触发机制

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

4. 缺点

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

5. aof 总结

1.aof文件是一个只进行追加的日志文件
2.redis可以在aof文件体积变得过大时，自动地在后台对aof进行重写
3.aof文件有序地保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存
4.对于体积相同的数据集来说，aof文件的体积通常要大于rdb文件的体积
5.根据使用的fsync策略，aof的速度可能会慢于rdb

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。
缺点：
1  比起RDB占用更多的磁盘空间
2 恢复备份速度要慢
3 每次读写都同步的话，有一定的性能压力
4 存在个别Bug，造成恢复不能

四、持久化 总结

1. RDB  vs AOF

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

2. 同时开启两种持久化方式

a. 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

b. RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

3. 性能建议

a. 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟[900秒]备份一次就够了，只保留规则save 900 1。
 
b. 如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。
代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
 
c. 如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。

 

 

五、Replication 主从复制

1.概览

1.1 什么是Replication？ 【和Hbase的replication雷同】

主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

1.2 目的

读写分离 
容灾恢复

1.3 实现

info replication  # 主副本信息查看
从库配置：slaveof 主库IP 主库端口

2. 实现机制

1.主机有的从机全部有。主机中间某个时刻timeA开启了主从复制，那么主机timeA之前的数据也会同步到从机。因为是首次加入 此时是全量复制。之后的复制都是增量复制
2.读写分离。只有主机能写。主 set k1 v1，从 set k1 v2 会报错
3.主机挂了。主机挂了，从机中不会选举为主机。不会篡位。
4.从机挂了[es 脑裂 ]，需要手动重新加入。挂了从机自己选举为master，且挂了window时间内数据不同步。
            如果想要重新同步主的数据，需要作为从机重新加入主从集群 slaveof 主库IP 主库端口。这样主的数据会同步到从。

备注
主机挂了。有办法让从机成为主机。丛机配置 slaveof no one

3. 哨兵模式 sentinel 

3.1 什么是哨兵模式

主机挂了，能够从剩余的从机中投票重新选举出主机。能够后台监控主机是否故障，如果发生故障了，根据投票数自动将从库转换为主库。

3.2  实现 

目录下新建sentinel.conf文件，内容如下
sentinel monitor 被监控数据库名字 127.0.0.1 6379 1
#最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机
#之前的故障机器恢复后，会作为从机重新加入主从集群

4. 复制的缺点  -- 复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

 

六、事务

此处有时间了，务必亲自实践一下。

MULTI    标记一个事务块的开始。
EXEC    执行所有事务块内的命令。
DISCARD    取消事务，放弃执行事务块内的所有命令。

WATCH key [key ...]
        监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断
UNWATCH    取消 WATCH 命令对所有 key 的监视。

redis对事务的支持是部分支持

悲观锁 并发性差 一致性好 
乐观锁 在每条数据后加一个版本 version 
CAS 
 
悲观锁 Pessimistic Lock 每次A取数据的时候都认为B会修改，所以每次A在取数据的时候会加上锁。
        这样B想拿这个数据就会block，直到A释放锁。
        传统的关系型数据库里就用到了很多这种锁机制，比如行锁，表锁等；读锁，写锁等，都是在操作之前先上锁
乐观锁 Optimistic Lock 很乐观，每次A取数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断：在此期间别人有没有更新这个数据，
        可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。
        乐观锁策略：提交版本必须大于记录当前版本才能执行更新

 

七、工作中遇见的问题 -- 缓存穿透

 缓存穿透
1.缓存系统定义：
按照KEY去查询VALUE，当KEY对应的VALUE一定不存在的时候并对KEY并发请求量很大的时候，就会对后端造成很大的压力。（查询一个必然不存在的数据。比如文章表，查询一个不存在的id，每次都会访问DB，如果有人恶意破坏，很可能直接对DB造成影响。）
由于缓存不命中，每次都要查询持久层。从而失去缓存的意义。
2解决方法：
（1）缓存层缓 存空值。 
缓存太多空值，占用更多空间。（优化：给个空值过 期时间） 
存储层更新代码了，缓存层还是空值。（优化：后台设置时主动删除空值，并缓存把值进去）
（2）将数据库中所有的查询条件，放布隆过滤器中。当一个查询请求来临的时候，先经过布隆过滤器进行查，如果请求存在这个条件中，那么继续执行，如果不在，直接丢弃。
3 备注  ：
比如数据库中有10000个条件，那么布隆过滤器的容量size设置的要稍微比10000大一些，比如12000.
对于误判率的设置，根据实际项目，以及硬件设施来具体定。但一定不能设置为0，并且误判率设置的越小，哈希函数跟数组长度都会更多跟更长，那么对硬件，内存中间的要求就会相应  的高
 private st atic BloomFilter<Inte ger> bloomFi lt er = BloomFilter.create(Funnels.integerFue l(), size, 000 01)  ; 
有了siz跟误判率，那么布隆过滤器会产相应的哈希函数跟数组。  
综上：我们可以利用布隆过滤器，将redis缓存击穿制在一个可容的范围内