Redis
最近学习了一下Redis写一篇文章来总结一下学习成果，学习的方式主要是看书，看的是Redis 5设计与源码分析；想系统学习的同学，可以好好看看很推荐这本书，那么，为什么标题选择Redis为什么会那么快？因为，我在学习的过程中，感受到Redis的精髓就是快，为了快这个属性，它有了很多自己特殊设计及实现；
简要概括原因
Redis快，我主要是基于三大部分的理解
- Redis是基于内存的，我们大家都知道内存的寻址和带宽都是远远快于磁盘的；
- Redis网络模型是采用I/O多路复用器，对key的处理是单线程 避免了多线程之间的竞争，省去了线程切换带来的时间和空间上的性能开销，而且也不会导致死锁的问题。
- 在Redis中，不管是底层数据结构的设计，以及事务的设计和key过期策略，乃至key的查找，还有持久化，都为了快速这个特性而有了自己的特殊实现；
下面分别对这2,3部分进行展开：
2. Redis网络模型及工作线程为单线程相关
首先，先要知道Redis工作线程是单线程的，但是，整个Redis来说，是多线程的；
Redis事件处理:
Redis 服务器是典型的事件驱动程序，而事件又分为文件事件(socket 的可读可写事件)与时间事件(定时任务)两大类。已经注册的文件事件存储在event[]数组中， 时间事件形成链表；Redis 底层可以使用4中I/O多路复用模型（kqueue、epoll、select等）根据操作系统的不同选择不同， 关于，多路复用模型相关内容可以查看我的另一篇文章 操作系统IO进化史 所以，epoll本身就效率很高了；但是，随着我们网卡的不断升级，在Redis 6.0之后的版本中，对IO的处理变成了多线程；
为什么对IO的处理变成了多线程能提高速度？
下面是Redis6.0之前的情况：
如果到了Redis6.0之后：
所以，这也是Redis快的一个主要原因；
3. Redis底层设计以及各部分的实现
由于，Redis中设计的话，主要分为底层设计结构以及一些相应的功能，所以，特定将其分为2部分来进行讲解；
3.1 Redis底层数据结构
Redis底层数据结构有简单动态字符串，跳跃表，压缩列表，字典，整数集合；针对，简单动态字符串，压缩列表，主要是考虑到节约内存；像跳跃表，字典，主要是考虑到查询速度，整数集合即考虑到了空间又考虑到了时间；其实像字典中的渐进式rehash，以及间断key查找，都是考虑到了节约时间；具体的内容可以查看我的另一篇文章，Redis底层数据结构
3.2 Redis中key的过期原理和Redis快的联系
具体细节可查看官网
- 被动访问时判断 （当访问这个key，发现它已经到过期时间了，那么，就算它过期，并进行删除）这种方式是比较占用内存的；
- 周期轮询判断 具体就是 Redis每秒10次做如下事情：1.测试随机的20个keys 进行相关过期检测 2.删除所有已经过期的key 3.如果有25%的key过期，那么，就重复步骤1；
优点：最多有25%的过期key存在内存中，这种方法会比轮询更加省时间；就是稍微牺牲内存，来保证redis的性能，就是快； 还是以空间换时间的思想；
注意：个人觉得这里和缓存雪崩还能建立其联系，如果，一个大型的redis实例中所有的key在同一时间过期了，那么，redis会持续扫描keys 因为，一直大于25%；虽然，这是有扫描时间的上限的25ms;这个时候，刚好客户端请求过来了，如果，客户端将超时时间设置的比较短，比如说10ms，那么就会出现大量链接因为超时而关闭，业务端也会出现很多异常。（客户端超时时间，如果说设置得太小，那么容易导致访问redis失败，如果，设置太大，那么，在redis异常的时候，不容易及时作出切换；一般是通过网络延迟和redis慢日志来进行查看的）
3.3 Redis中事务和Redis快的联系
redis的特点是快，它虽然有事务，但是，它是没有回滚的，事务的功能是不够完善的； 回滚：代表失败时，回滚到事务开始的时刻；
help @transactions
multi : 开启事务
exec : 执行事务
当你开启了事务以后，把你想一起发送的指令发给redis 然后，发送exec时，redis会把你的命令一股脑的执行起来。不会回滚，如果，是语法错误的话，那就统统不执行；
discard : 代表取消事务
watch: 乐观锁 cas watch k1 代表对k1 进行监控，如果，k1被更改了，那么之后的指令 是不会执行的；redis 只会告诉你这种情况，至于是怎么处理，是你客户端自己决定的。
例： 开启事务1
multi
get k1
开启事务2
multi
del k1
如果，先提交事务1 是可以取到k1的值的，如果，先提交事务2 事务1中的get是取不到消息的；
watch k1 // 演示watch
multi // 开启事务
get k1
keys *
// 再开启一个事务
multi
keys *
set k1 bbb
exec
// 在执行第一个事务提交 exec 会发现为nil 说明第一个事务是不会执行的;
redis 是单线程的 如果，有多个客户端，一个客户端的事务 并不会阻塞到其他客户端； 客户端1 发送 开启事务的标记 客户端2 也开启事务 。随着时间发展；2又连续发了一些命令 1 也发了一些命令； 这时候，会先看谁的执行指令先到； 假设 2 先到达，这个时候，先执行2 的相关数据，在执行1相关的命令； 如果 1 先到达，这个时候，先执行1 的相关命令，再执行2；
事务失败处理
- redis语法错误 就是编译器都过不去，举个例子：将set 写成了sets 这种指令都写错了，那么，整个事务就会失败；是报错，会拒绝执行并自动放弃这个事务；
- reids类型错误 （可以理解为语法是redis中有的语法，但是，用错了地方）举个例子：
这个时候，会发现报错那条语句不执行，剩下的语句都会进行执行；也没有发生了回滚；
证明 ：redis是不支持事务回滚的。在运行期错误，即使事务中有某条/某些命令执行失败了，事务队列中的其他命令仍然会继续执行 -- Redis 不会停止执行事务中的命令；
为什么Redis 不支持事务回滚？
- 大多数事务失败是应该语法错误和类型错误所导致的，这两种错误，是通过测试可以找到的，在生产环境中，一般是不会出现的。
- Redis 为了性能而忽略了事务回滚；
总结：Redis为了快，而不支持事务回滚；
3.4 Redis 持久化机制和Redis快的联系
在redis中，有两个东西 第一个为RDB ，第二个为AOF RDB为快照/副本相关内容， AOF为日志相关的内容；
RDB的特点：1.需要时点性 （比如说：我有1G的内存，需要持久化到硬盘，比如说：一个小时持久化一次。那么，假设在8点，就需要进行持久化）
如何实现RDB持久化呢？
方法一：阻塞Redis ，Redis不再对外提供服务了，但是，这种方式是需要阻塞的，很显然，如果，这个持久化需要花费1s，那么，这个时候，Redis 不能被客户端进行使用；
方法二：非阻塞 Redis继续对外提供服务；
但是，这个时候会出现一个问题；比如说：8点开始RDB持久化，8点零1秒才持久化完，问题就来了：持久化的数据是8点的还是8点零1秒的呢？很显然，是8点的；那么，在8点到8点零1秒这个过程中，数据是会发生改变的，那么，怎么解决这个数据不一致的问题呢？比如说：8点的时候，b = 10 到 8点零1秒的时候，b =20;
为了解决这个读写并存使用CopyOnWrite 的思想来进行实现；
就是，在操作系统中，先使用fork() 创建子线程来复制一份副本（注意：这里拷贝的是指针，所以，速度会很快）然后，这个副本，就保持在8点不变了。然后，复制的时候，就复制这份副本就行了，对数据增删改查就在父进程中更改。
但是，因为父子进程都指向的是同一个内存，所以，不能在这个内存中改，比如说：不能在原来key 8 中进行更改，比如说要改key = 10 那么，就得在内存中，再创建一块区域，然后，让父进程中指针指向新的key ,这样两个进程就不会相互影响了。
这里也验证了Redis是多线程的；
具体实现：
save ：这个是触发阻塞方式来实现 一般是明确知道要关机维护时用save来保存RDB；
bqsave :触发fork() 创建子线程来进行实现 可以在配置文件中给出bqsave的规则，用的是save来表示，实际是用bqsave去做的
// 什么时候启动RDB呢？ 这个可以在配置文件中进行设置
save 60 10000 当过了60s 或者变化超过10000次时实现RDB持久化
RDB的缺点
不支持拉链 只有一个dump.rdb文件，需要运维进行备份；
丢失数据的话，丢失的会多一点，因为它是每小时进行备份的；
RDB的优点：恢复数据的速度相对较快；
Redis内存大小选择 进程一般使用10G以内，因为从内存到磁盘持久化这个过程，如果说，10G需要写的时间比较久，那么，如何解决呢？1. 减少内存 2. 硬盘选择固态硬盘；
针对RDB容易丢失数据的问题，提出了AOF持久化机制
AOF : append on File 向文件中，进行追加；redis发生写操作时，会记录到文件中；
优点：1.丢失的数据比较少
背景：RDB和AOF可以同时开启，如果，开启了AOF只会用AOF来进行恢复，即便RDB也开启了，也不会使用它；因为，AOF的修复比较准确；但是，AOF是比较慢的，所以，在4.0以后，AOF就包含了RDB全量，和增加的新的写操作。这样来提高速度；
缺点：由于，AOF是增加的方式，所以，如果一直增加的话，就会有1.体量无限变大 2.恢复慢的缺点；为了解决这个问题，需要设计出一个方案让日志AOF足够小；这个，就有了重写的方案；4.0之前，重写方案是将AOF进行瘦身，比如说：把创建key和删除key的命令进行抵消删除；4.0之后，就采用混合持久化 比如说：我这个AOF已经到了100M文件了，这个时候，我先将老的数据变成RDB文件（二进制文件）然后，再存储到AOF中，再将增量以指令的方式Append 到AOF。所以，是一个混合体；这里的AOF日志不再是全量的日志，而是持久化开始到持久化结束这段时间的增量AOF日志通常很小；那么，它这么改变的优点是：在Redis重启时，可以先加载RDB的内容，在加载增量AOF日志，完全替代AOF全量日志重放，重启的效率将大幅度提升； 每次一重写完，就会变成RDB；
脏数据刷入时机：AOF日志是以文件形式存在的，当程序对AOF日志进行写操作时，实际上是先将数据写到一个内存缓存中，然后，让内存再把脏数据写回到磁盘中 那么，什么时候写呢？如果，还没来的及写就宕机了，那么可能会出现日志丢失；这时候有三个级别可以调；
no : 不调用fsync 等到它满了再进行调用（fsync 可以将指定文件的内容，强制从内核缓存刷到磁盘） 一般生产环境不用
always :每写了一个数据，就调用一次fsync 一般生产环境不用
everysec: redis每一秒调用一次flush
一般Redis 的主节点不会进行持久化操作，持久化操作主要是在从节点中进行。因为，没有来自客户端请求的压力；
上面是Redis持久化的两种方式 由于，持久化过程需要花费的时间是比较多的，所以，一般由从节点来进行持久化操作； 主服务器发现需要执行完整重同步时，会fork子进程执行RDB持久化，并将持久化数据发送给从服务器。这时候，有两种选择 1. 直接通过Socket发送给从服务器(从服务器支持eof)，2. 持久化数据到本地文件，待持久化完毕后再将该文件发送给从服务器。 默认第二种，具体情况是根据同步信息确定；但是，第一种效率会更高，速度会更快；
总结：为了Redis快的特性，Redis在持久化的时候，使用fork()函数，新开线程来执行；同时，如果主从服务器的话，还提供了psync2来进行部分重同步；eof功能；
全文总结
redis的特点就是快，在系统设计的方方面面都体现了这个快的特性；这是我自己在学习Redis相关知识时，了解到的内容，做个记录。如果，有偏差欢迎读者进行指正!