Redis 原理
一：Redis事务
Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。 总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
- 按进入队列的顺序执行
- 不会受到其他客户端的请求的影响
- 事务不能嵌套，多个multi命令效果一样
使用：
- multi：开启事务
- exec：执行事务
- discard：取消事务
- watch：监视key，如果被监视的key在exec之前被修改，事务会取消
- unwatch：取消watch对所有key的监视。
watch命令可以为 Redis 事务提供 check-and-set （CAS）乐观锁行为。
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC
如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。 这种形式的锁被称作乐观锁， 它是一种非常强大的锁机制。
为什么不回滚？
官方解释：
- Redis命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现（代码问题），而不应该出现在生产环境中。
- 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速（回滚不能解决代码的问题）。
Pipeline 有什么好处，为什么要用 pipeline？
可以将多次 IO 往返的时间缩减为一次，前提是 pipeline 执行的指令之间没有因果相关性。使用 redis-benchmark 进行压测的时候可以发
现影响 redis 的 QPS峰值的一个重要因素是 pipeline 批次指令的数目。
二：Lua脚本
为什么用Lua脚本？
- 1、批量执行命令
- 2、原子性
- 3、操作集合的复用
怎么在Lua脚本中执行Redis命令？
redis.call(command, key [param1,param2…])
- command是命令，包括set、get、del等
- key是被操作的键
- param1,param2…代表给key的参数
redis调用lua脚本： redis-cli --eval 脚本名称 参数个数 参数1 参数2……
lua使用案例：
- 对IP进行限流
- 缓存Lua脚本
- 分布式锁
lua脚本一定能保证原子性吗？
单机部署：不管 Lua脚本中操作的 key是不是同一个，都能保证原子性；
主从、哨兵集群：是用于将主节点的数据同步到从节点，以保持数据的一致性。而Redis的所有写操作都在主节点上，所以，不管 Lua脚本中操作的 key是不是同一个，都能保证原子性
Cluster集群：如果 Lua脚本操作的 key是同一个，能保证原子性；如果操作的 Key不相同，可能被 hash 到不同的 slot，也可能 hash 到相同的 slot，所以不一定能保证原子性；
因此，在 Cluster集群部署的环境下使用 Lua脚本时一定要注意：Lua脚本中操作的是同一个 Key；
三：Redis为什么这么快？
总结主要就四点:
- 1、单线程
- 2、纯内存 KV
- 3、高效的数据结构及合理的数据编码
- 4、同步非阻塞I/O——多路复用
3.1、单线程
这个单线程是处理客户端请求的是单线程，从6.0之后引入了多线程，多线程只是用来处理网络数据的读写和协议解析处理其他的事情。
单线程的好处：
- 没有线程创建销毁带来的消耗
- 避免线程上下文切换 导致的cpu消耗
- 避免线程竞争问题
官方的解释：单线程已经够用了，cpu不是redis 的瓶颈，瓶颈是机器的内存或者网络带宽。既然单线程容易实现，又不用处理线程并发的问题，就采用了单线程的方案。所以不要在生产环境运行长命令，比如：keys、flushdb
3.2、纯内存 KV
我们都知道内存读写是比磁盘读写快很多的。Redis是基于内存存储实现的数据库，相对于数据存在磁盘的数据库，就省去磁盘磁盘I/O的消耗。MySQL等磁盘数据库，需要建立索引来加快查询效率，而Redis数据存放在内存，直接操作内存，所以就很快。
虚拟内存机制
- 1、通过把同一块物理内存映射到不同的虚拟地址空间实现内存共享
- 2、对物理内存进行隔离，不同的进程操作互不影响
- 3、虚拟内存可以提供更大的地址空间，并且地址空间是连续的，使得程序编写、 链接更加简单。
虚拟内存机制就是暂时把不经常访问的数据(冷数据)从内存交换到磁盘中，从而腾出宝贵的内存空间用于其它需要访问的数据(热数据)。通过VM功能可以实现冷热数据分离，使热数据仍在内存中、冷数据保存到磁盘。这样就可以避免因为内存不足而造成访问速度下降的问题。
3.3、高效的数据结构及合理的数据编码
Redis支持多种数据基本类型，每种基本类型对应不同的数据结构，每种数据结构对应不一样的编码。为了提高性能，Redis设计者总结出，数据结构最适合的编码搭配。
- String：如果存储数字的话，是用int类型的编码;如果存储非数字，小于等于39字节的字符串，是embstr；大于39个字节，则是raw编码。
- List：目前统一使用quicklist来存储
- Hash：哈希类型元素个数小于512个，所有值小于64字节的话，使用ziplist编码,否则使用hashtable编码。
- Set：如果集合中的元素都是整数且元素个数小于512个，使用intset编码，否则使用hashtable编码。
- Zset：当有序集合的元素个数小于128个，每个元素的值小于64字节时，使用ziplist编码，否则使用skiplist（跳跃表）编码
3.4、I/O 多路复用
- I/O ：网络 I/O
- 多路 ：多个网络连接
- 复用：复用同一个线程
IO多路复用其实就是一种NIO模型，它实现了一个线程可以监视多个文件句柄；一旦某个文件句柄就绪，就能够通知应用程序进行相应的读写操作；而没有文件句柄就绪时,就会阻塞应用程序，并交出cpu。epoll 是LINUX系统内核提供支持的。
四：内存回收
4.1、内存过期策略 通常有以下三种：
- 1、定时过期（主动）：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即对key进行清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
- 2、惰性过期（被动）：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
- 3、定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
Redis采用的过期策略：惰性删除 + 定期删除。
如果所有的key都没有设置过期属性，redis内不足了怎么处理？这就是内存淘汰。
4.2、内存淘汰策略
内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。
- volatile针对设置了ttl的key
- allkeys是针对所有key
- LRU，Least Recently Used最近最少使用
- LFU，Least Frequently Used
提供了八种淘汰策略：
volatile-lru、allkeys-lru
volatile-lfu、allkeys-lfu
volatile-random、allkeys-random
volatile-ttl
noeviction
LRU的回收问题：
假设A在10s内访问了5次，而B在10s内访问了2次，B最后一次访问的时间比A要晚，在同等情况下，A反而会先被回收。所以需要基于访问频率的淘汰机制LFU。
LFU的实现
当24 bits用作LFU时，其被分为两部分：
- 高16位用来记录访问时间（单位为分钟，ldt，last decrement time）
- 低8位用来记录访问频率，简称counter（logc，logistic counter）
counter是用基于概率的对数计数器实现的，8位可以表示百万次的访问频率
并不是访问一次，计数就+1，增长的速率而是由增长因子 # lfu-log-factor 决定的，没有访问的时候计数器还要递减，减少的值由衰减因子 # lfu-decay-time 来控制，衰减因子越大衰减越慢。
五：持久化机制
因为Redis数据在内存，断电既丢，因此持久化到磁盘是必须得有的，Redis提供了RDB跟AOF两种模式。
- RDB ：Redis DataBase，记录快照
- AOF ：Append Only File，记录日志
5.1、RDB 持久化机制
是对 Redis 中的数据执行间隔一段时间周期性的持久化，更适合做冷备。
-
优势：压缩后的二进制文，适用于备份、全量复制。紧凑，适合备份和灾难恢复生成文件过程不影响主进程，大数据集时恢复速度较快
-
缺点：不能实时持久化，数据的完整性和一致性不高不高，可能丢失数据
RDB手动触发
1、SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，导致无法提供服务。
2、BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，在保存完成后（先将数据集写入临时文件，写入成功之后再替换之前的文件，用二进制压缩存储）向主进程发送信号告知完成。在BGSAVE 执行期间仍可以继续处理客户端的请求
5.2、AOF 持久化机制
默认关闭的，AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像 Mysql 中的binlog。AOF更适合做热备。
3种appendfsync同步策略
- no表示不执行fsync，由操作系统保证数据同步到磁盘（不同步）
- always表示每次写入都执行fsync，以保证数据同步到磁盘（每次写同步）
- everysec（默认）表示每秒执行一次fsync，可能会导致丢失这1s数据（每秒同步）
AOF整个流程分两步：
- 第一步是命令的实时写入，不同级别可能有1秒数据损失。命令先追加到aof_buf然后再同步到AO磁盘，如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能
- 第二步是对aof文件的重写，目的是为了减少AOF文件的大小，可以自动触发或者手动触发(BGREWRITEAOF)，是Fork出子进程操作，期间Redis服务仍可用。
AOF重写
- 优点：提供了3种同步策略，同步频率灵活，最多丢失一秒数据。 append-only 的模式写文件，即使服务器宕机也不会破坏已经存在的内容。rewrite重写模式定期对AOF文件重写以达到压缩的目的
- 缺点：AOF文件通常要大于RDB文件,消耗更多性能，RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
971
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
