redis作为这几年非常有名的非关系型数据库，前年的时候就被我听说了。公司也一直在用，可是忙碌于业务代码的我基本没有啥涉猎，也就一直搁置。最近公司tair切换redis，有技术大佬进行培训，让我了解了一些。以下正文部分。
首先先扔上来四个我到现在也回答的不太好的问题
1: 为什么要用redis？
2: 为什么redis这么快？
3: redis底层数据结构有哪些？
4: redis 怎么做到持久化？
好了。我们先从数据结构说起。
Redis底层数据结构有以下几种：简单动态字符串、链表、字典、跳跃表、整数集合、压缩列表、快速列表。
1、简单动态字符串。
2.链表
3.字典哈希表
持久化方式：RDB持久化，AOF持久化。
RDB
RDB文件：
redis数据库的快照文件，就是将某一瞬间数据中所有数据以二进制保存到磁盘里，当redis发生宕机重启时，能重新加载rdb文件中的数据。
生成RDB文件命令：
SAVE ： 服务器执行SAVE命令时，服务器会发生阻塞，停止对外提供服务
BGSAVE： 服务器执行BGSAVE命令时，会fork一个子进程来执行 save命令，调用save方法，此时服务器不会发生阻塞。处理客户端正常的命令。
自动生成rdb文件 (redis.conf配置)：
save 900 1 --- 900s内，数据库至少有1次修改
save 300 10 ----300s内，数据库至少有10次修改
save 60 10000 ----60s内，数据库至少有10000次修改
redis服务器会将上述配置保存在 redisServer 结构中的saveparam属性。
redisServer维护两个属性：
1:ditry计数器： 上一次rdb后，服务器对数据库状态修
2: lastsave： unix时间戳，上次rdb时间。
redis服务器serverCron()函数默认每100ms执行一次，函数
会检测是否满足上面配置的rbd保存条件，如果满足则执行 BGSAVE
AOF
将对数据库的写命令以文件追加的方式写入文件，redis启动载入AOF文件时，将命令重新执行一次，来实现数据库的持久化机制，
AOF开启配置（redis.conf）：
appendonly yes ----- 开启aof
appendfilename "appendonly.aof" ----aof文件名
appendfsync everysec(默认)/always/no ---- 将缓存区同步到磁盘文件的频率。
AOF三步走：
1）命令追加 将命令写入redisServer中的aof_buf缓存区。
2）文件写入 在事件循环后，会调用flushAppendOnliyFile函数考虑是否要将aof_buf缓存区的内容写入aof文件。
3）文件同步
AOF重写：
随着服务器运行时间进行，aof文件追加的方式，势必导致aof文件越来越大。为了解决
aof文件膨胀的问题，redis服务器创建一个新的aof文件来代替现有的aof文件。
AOF重写实现：
fock一个子进程，遍历数据库中所有的key-value，然后将数据简化成写入命令，然后再将命令写入一个新的aof文件，再将现有的aof文件，替换成新生成的aof文件。
AOF重写期间，如何保证数据一致性以及服务不间断：
继续提供服务，开启一个AOF重写缓存区，客户端命令同时写入AOF缓存区和AOF重写缓存区。
重新工作完后后，子进程向父进程发送一个信号，父进程会将AOF重写缓存区的所有内容写入新的AOF文件，然后再对新的AOF文件进行改名，原子的覆盖旧的AOF文件。
当然redis更重要的是以下几个部分。学习了再来补充。
1: 主从复制
2: 哨兵机制
3: 集群
网友评论