redis (2) --redis核心原理

Redis的单线程与高性能

1）redis单线程为什么还能这么快
因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换性能损耗问题。正因为 Redis 是单线程，所以要小心使用 Redis 指令，对于那些耗时的指令(比如keys)，一定要谨慎使用，一不小心就可能会导致 Redis 卡顿。
2）Redis单线程如何处理客户端并发请求
Redis的IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。

持久化

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读取到内存中
redis 会单独创建fork一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对数据恢复的完整性不是非常敏感，那rdb方式比aof方式更加的高效
。rdb的缺点是最后一次持久化后的数据可能丢失
1） RDB快照
在默认情况下，Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中。
save 60 1000 60s内有至少有1000个键被改动 时 自动保存一次数据集
手动rdb

bgsave

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

2）AOF (append-only file)
默认是关闭的 开启配置

appendonly yes

aof rewriter操作 主要是将aof文件中无用的指令整合

auto-aof-rewrite-percentage 100
aof文件增长比例，指当前aof文件比上次重写的增长比例大小。aof重写即在aof文件在一定大小之后，重新将整个内存写到aof文件当中，以反映最新的状态(相当于bgsave)。这样就避免了，aof文件过大而实际内存数据小的问题(频繁修改数据问题).
auto-aof-rewrite-min-size 64mb
aof文件大于64M  
两个条件满足后可自动重写

appendfsync
always 同步持久化 每次发生数据变更会被立刻记录到磁盘 性能较差但数据完整性比较好
everysec 出场默认推荐，异步操作，每秒记录 如果一秒内宕机，有数据丢失
No 将数据交给操作系统处理，更快，也更不安全

aof 优势 数据完整度较高
劣势 相同数据集的数据而言aof文件要原发于rdb文件，恢复速度慢于rdb
aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

3）混合持久化
开启配置

aof-use-rdb-preamble yes

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。AOF在重写(aof文件里可能有太多没用指令，所以aof会定期根据内存的最新数据生成aof文件)时将重写这一刻之前的内存rdb快照文件的内容和增量的 AOF修改内存数据的命令日志文件存在一起，都写入新的aof文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换；
AOF根据配置规则在后台自动重写，也可以人为执行命令bgrewriteaof重写AOF。 于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

缓存淘汰策略

当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)。交换会让 Redis 的性能急剧下降，对于访问量比较频繁的 Redis 来说，这样龟速的存取效率基本上等于不可用。
在生产环境中我们是不允许 Redis 出现交换行为的，为了限制最大使用内存，Redis 提供了配置参数 maxmemory 来限制内存超出期望大小。
当实际内存超出 maxmemory 时，Redis 提供了几种可选策略 (maxmemory-policy) 来让用户自己决定该如何腾出新的空间以继续提供读写服务。

noeviction 不会继续服务写请求 (DEL 请求可以继续服务)，读请求可以继续进行。这样可以保证不会丢失数据，但是会让线上的业务不能持续进行。这是默认的淘汰策略。
volatile-lru 尝试淘汰设置了过期时间的 key，最少使用的 key 优先被淘汰。没有设置过期时间的 key 不会被淘汰，这样可以保证需要持久化的数据不会突然丢失。
volatile-ttl 跟上面一样，除了淘汰的策略不是 LRU，而是 key 的剩余寿命 ttl 的值，ttl 越小越优先被淘汰。
volatile-random 跟上面一样，不过淘汰的 key 是过期 key 集合中随机的 key。
allkeys-lru 区别于 volatile-lru，这个策略要淘汰的 key 对象是全体的 key 集合，而不只是过期的 key 集合。这意味着没有设置过期时间的 key 也会被淘汰。
allkeys-random 跟上面一样，不过淘汰的策略是随机的 key。

volatile-xxx 策略只会针对带过期时间的 key 进行淘汰，allkeys-xxx 策略会对所有的 key 进行淘汰。如果你只是拿 Redis 做缓存，那应该使用 allkeys-xxx，客户端写缓存时不必携带过期时间。如果你还想同时使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，这样可以保留没有设置过期时间的 key，它们是永久的 key 不会被 LRU 算法淘汰。

redis事务 mutil

基本操作

multi       开启事务
exec       提交事务块中所有的命令
discard    回滚事务块中的命令
watch   监视一个或多个key  如果在事务执行之前这个key被其他命令所改动，那么事务将被打断
unwatch   取消watch命令对所有key的监控

悲观锁
顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里面就用到了很多这种锁机制，比如行锁，表锁等

乐观锁
顾名思义，就很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量 乐观锁策略 提交版本必须大于记录当前版本才能执行更新

watch指令，类似于乐观锁，事务提交时，如果key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行 通过watch命令在事务执行之前监控了多个keys，倘若在watch之后有任何key的值发生了变化，exec命令执行的事务都将被放弃，同时返回null multi-bulk应带以同值调用者事务执行失败

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

redis发布订阅模式

redis 可以作为消息中间件 但目前生产使用的很少很少

redis的发布订阅
  进程间的一种消息通信模式 发送者pub发送消息，订阅者sub接受消息
  订阅/发布消息图
  subscribe  c1 c2 c3 一次性订阅一个或多个
  publish c2 hello  消息发布
  订阅多个 通配符*  psubscribe new*
  收取消息，publish new1 redis2015