Lxn2zh的博客

向字典中添加元素，将会为字典中的ht[0]分配空间，默认情况下table数组为4(DICT_HT_INITIAL_SIZE)，新添加元素的键值会经过哈希算法确定哈希表数组的位置，进行添加，如果两个不同的键经过哈希算法产生相同的哈希值，就会发生哈希冲突，采用链表的方式，新元素会放到链表头节点(与java7类似，因为新增加的节点，大概率会被再次访问)ziplist 一开始存储使用的ziplist，但是当满足一定条件时会转换为hash table。set有两种编码格式。

ziplist又叫做压缩列表，使用一段连续的内存来存储数据的数据结构，redis为了节约内存而开发的，可以节省内存空间，其并不是以某种压缩算法来进行压缩存储数据，而是表示一组连续的内存空间使用。ziplist会比hash、list、zset中使用的底层结构节省内存，存储越小的数据，使用ziplist来进行数据压缩可以得到更好的压缩率，但是会造成额外的内存碎片率。prevlen 上一个节点的长度，可以和当前的地址进行指针运算，找到上一个节点的起始地址。使用ziplist的数据类型。

有一次看redis的配置文件发现一个notify-keyspace-events配置，注释里边长篇大论的，那我得看看这是干啥的，看完注释内容，发现不得了了，redis竟然还有过期提醒的功能。g 一般性的，非特定类型的命令，比如del，expire，rename等。e 驱逐事件，当某个键因 maxmemore 策略而被删除时，产生该事件。首先呢，这个功能是基于发布订阅的，通过key的事件来触发发布订阅。x 过期事件，当某个键过期并删除时会产生该事件。s Set命令。

当然很多时候是不需要看这么多信息的，如果只需要看某一个模块的信息如何呢？在cli下使用info来查看统计信息。,如想看Server相关的。

为了解决该问题，redis提供了evalsha命令允许开发者通过脚本内容的SHA1摘要来执行脚本，该命令的用法的eval一样，不过是将脚本内容替换为脚本内容的SHA1摘要。redis在执行eval命令时会计算脚本的SHA1摘要并记录在脚本缓存中，执行evalsha命令时redis会根据提供的摘要从脚本缓存中查找对应的脚本内容，如果找到了则执行脚本，否则返回错误。SCRIPT FLUSH命令，redis将脚本的SHA1摘要加入到脚本缓存后会永久保留，不会删除，可以使用该命令清空脚本缓存。

多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将产生事件的 socket 放入队列中排队，事件分派器每次从队列中取出一个 socket，根据 socket 的事件类型交给对应的事件处理器进行处理。它采用 IO 多路复用机制同时监听多个 socket，将产生事件的 socket 压入内存队列中，事件分派器根据 socket 上的事件类型来选择对应的事件处理器进行处理。事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

双缓存，缓存1中设置过期时间，缓存2中在启动时加载，进行缓存预热，先访问缓存1，如果有值则返回；缓存1没有值，则访问缓存2，返回数据，并启动异步更新线程来同时更新缓存1和缓存2的数据，如果value特别大的话会占用很多内存，内存利用率低。只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存中获取数据，保证了每个时刻只有一个线程在执行请求，但是会导致很多线程在等待一个线程，降低了系统的qps。利用互斥锁，缓存中没有，先获取锁，再去请求数据库，写入缓存，这样后面的数据就可以从缓存中拿到数据了。

虚拟槽是根据某个散列函数得到槽位，找到对应的节点，N 个真实节点,把每个真实节点映射成 M 个虚拟节点，再把 M*N 个虚拟节点，散列在圆环上，各真实节点对应的虚拟节点相互交错分布，这样，某真实节点 down 后，则把其影响平均分担到其他所有节点上。当集群中的某个节点，收到半数以上认为某节点已下线的信息，就会真的标记该节点为已下线，并在集群中传播该信息。但是存在的问题是很难保证客户端的请求平均分配在各个节点，不能很好地负载均衡，在服务器很少的时候，容易出现服务器节点分布不均。

redis的配置主要集中在redis.conf文件中，接下来就来看一下redis.conf中包含了哪些内容。默认情况下使用redis不需要进行安全认证，因为在配置文件中requirepass是注释掉的。该模块下可以使用include来包含其他的redis配置文件，将其他配置文件引入进来。ACTIVE DEFRAGMENTATION模块。EVENT NOTIFICATION模块。可以使用redis命令来查看当前的密码。快照模块主要是用来配置RDB持久化的。REDIS CLUSTER模块。

watch指令类似于乐观锁，在事务开始之前使用，如果在watch之后有任何所监视的key发生变化，exec指令所执行的事务将会被放弃，当 EXEC 被调用后，所有的之前被监视的键值会被取消监视，不管事务是否被取消或者执行。Redis的事务没有隔离级别的概念，因为事务提交前任何指令都不会被实际执行，也就不存在事务内的查询要看到事务里的更新，在事务外查询不能看到这种问题了。Redis的事务不保证原子性，也就是不保证所有指令同时成功或同时失败，只有决定是否开始执行全部指令的能力，没有执行到一半进行回滚的能力。

由于有时候redis中的数据比较多，不能瞬间完成扩容操作，会将rehash操作进行分步进行，其字段rehashidx就用于标识rehash过程，如果是-1表示当前没有进行rehash操作，当进行rehash操作时会将该值改为0，在进行更新、删除、查询操作时会在ht[0]和ht[1]中都进行，先更新ht[0]，在更新ht[1]，而进行新增操作就直接新增到ht[1]中，保证ht[0]只减不增，直到rehash完成。位图不是一个真实的数据类型，是定义在字符串类型之上的面向位操作的集合，每个单元只能存储0和1。

如果验证未通过，则进行全同步。自动故障迁移： 当一个主服务器不能正常工作时，sentinel会开始一次自动故障迁移操作，会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器，当客户端试图链接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。由于一主两从的主库挂掉之后，需要人工的去干预从库反客为主，再进行更改主从配置，而哨兵模式通过监听主库是否挂掉，从库根据投票来决定自动将从库切换为主库。

redis的键可以设置过期时间，但是并不是每个键一到过期时间就会立即删除，redis不可能给每个设置过期时间的key上添加一个定时器来监视是否过期，CPU根本承受不了如此多的定时线程。首先客户端在尝试访问某个key的时候，redis会检查是否过期，如果过期则删除，但是有些key是不会被访问到的，redis的定期删除则会进行扫描并删除过期的key。惰性删除 键值对过期暂时不进行删除，当获取键时先查看是否已经过期，过期则进行删除，这种策略可能会由于一些过期key一直没有被访问，浪费一定的内存。

由于AOF采用的是日志追加，可能会导致日志文件越来越大，为了避免此情况，增加了重写机制，当AOF文件超过所设定的阈值之后，redis会启动AOF文件的压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof来执行。通过bgrwriteaof完成，不同的是当开启混合持久化后，子进程会把内存中的数据以RDB的方式写入aof中，把重写缓冲区中的增量命令以AOF方式写入到文件，将含有RDB格式和AOF格式的AOF数据覆盖旧的AOF文件。子进程写入所有数据后会用临时文件替换旧RDB文件。

scan就是专门用来解决keys导致redis停顿的问题的，scan是一种迭代命令，其对keys进行了分解，即原本使用一个keys请求一次匹配获取所有符合的key的操作，分解了多次scan操作，每次scan操作返回匹配的key的一个子集，并记录游标，根据游标来进行偏移，这样每个scan请求的操作时间很短，多次scan请求之间可以执行其他命令，故减少对其他命令执行的阻塞，直到最后一个scan请求发现没有数据可返回了，则操作完成，汇总该次所有scan请求的数据，从而达到与keys命令一次获取的数据相同。