redis设计与实现

一.哨兵（sentinel）

1.sentinel可以监控其他sentinel【和sentinel监视同样master的哨兵】，主服务器（master）,从服务器 （slave0,slave1...）

2.检测是否下线，sentinel会用每秒一次的频率向它所监控的其他sentinel，主服务器（master）,从服务器 （slave0,slave1...）发送ping命令

有效回复：实例返回+PONG、-LOADING、-MASTERDOWN  

无效回复：除+PONG、-LOADING、-MASTERDOWN外都是无效回复

如果一个实例在指定时间down-after-millisconds时间内向sentinel都返回的是无效回复，那么就认为实例主观下线了；sentinel会再去询问同样观测主从服务器的其他sentinel，如果超过一定个数的其他sentinel也认为这个实例下线了，那么这个实例就是客观下线，sentinel就会进行针对主服务器进行故障转移操作。

3.对于监视同一个主服务器和从服务器的多个sentinel来说，它们会以每两秒一次的频率，通过向被监视服务器的_sentinel_:hello频道发送消息来告诉其他sentinel自己的存在

 

二.redis集群：

集群的整个数据库被分为16384个槽（slot）

 

三.事务隔离性

事务隔离性指的是，及时数据库中有多个事务并发地执行，各个事务之间也不会互相影响。

因为redis使用单线程的方式执行事务（以及事务队列中的命令），并且服务器保证执行事务期间不会对事物进行中断。因此，redis

redis的事务总是以串行的方式运行的，并且事务也总是具有隔离性

 

四.

a.对key对应的value排序

sort

 

五.过期键的删除策略：

a.定时删除：订一定时间，到了一定时间后删除

优点：对内存友好，可以节省内存

缺点：但是如果需删除的键过多的话，会影响正常业务对cpu的影响

b.惰性删除：只有在查询时会看key是否过期，过期的话再删掉，没有查询时这个key还是存在的

优点：对cpu友好

缺点：占用内存，导致内存浪费

c.定期删除:定期是定时和惰性的一种综合，但如果过期时间和删除key的个数设置不合适的话会影响cpu和内存使用

 

六.

1.redis端口6379是merz【愚蠢】的键盘对应数字的组合

2.redis的五种基本数据类型：

a.String（字符串）：一个字符串自大长度是512M

b.list（列表）：

redis的list相当于java中的LinkedList,是链表不是数组，插入，删除很快，查询很慢。

右边进左边出：队列（先进先出）

> rpush books python java golang

(integer) 3

> llen books

(integer) 3

> lpop books

"python"

> lpop books

"java"

> lpop books

"golang"

> lpop books

(nil)

右边进右边出：栈（先进后出）

> rpush books python java golang

(integer) 3 > rpop books "golang"

> rpop books

"java"

> rpop books

"python"

> rpop books

c.set（集合）：

相当于java中的hashSet,无序，无重复

d.hash（字典）：

内部实现结构和java中的hashMap一致，数组+链表的二维结构

注：Hincrby 命令用于为哈希表中的字段值加上指定增量值。

e.zset（有序集合）

1.ZRANGE key start stop [WITHSCORES] ： 获取出来的是从小到大排序的

2.ZREVRANGEBYSCORE key max min [WITHSCORES] [LIMIT offset count]：获取的是从大到小排序的

 

七.分布式锁

实现分布式锁的两种方法：

1.> set lock:codehole true ex 5 nx

OK ... do something critical ...

> del lock:codehole

上面这个指令就是 setnx 和 expire 组合在一起的原子指令

2.使用lua脚本

注：Redis 的分布式锁不能解决超时问题，如果在加锁和释放锁之间的逻辑执行的太长，以至 于超出了锁的超时限制，就会出现问题。因为这时候锁过期了，第二个线程重新持有了这把锁， 但是紧接着第一个线程执行完了业务逻辑，就把锁给释放了，第三个线程就会在第二个线程逻 辑执行完之间拿到了锁。 为了避免这个问题，Redis 分布式锁不要用于较长时间的任务。如果真的偶尔出现了，数 据出现的小波错乱可能需要人工介入解决

八.延时队列

1.blpop/brpop

缺点：如果线程一直阻塞在哪里，Redis 的客户端连接就成了闲置连接，闲置过久，服务器一般 会主动断开连接，减少闲置资源占用。这个时候 blpop/brpop 会抛出异常来。 所以编写客户端消费者的时候要小心，注意捕获异常，还要重试。

2.使用zset ,zrangebyscore 和 zrem,lua【保证任务的原子性操作】实现redis延时队列

九.HyperLogLog提供不精确的去重计数方案

HyperLogLog 提供了两个指令 pfadd 和 pfcount，根据字面意义很好理解，一个是增加 计数，一个是获取计数

注:标准误差是 0.81%，这样的精确度已经可以满足 UV 统计需求了,因为一般这点误差的数量，对于统计网站用户访问量，一般老板对这点误差的用户访问统计是可以忽略的，如果要统计几乎无误差的，HyperLogLog就不推荐使用；HyperLogLog中是没有判断是否包含这个key的方法的

UV:https://www.zhihu.com/question/20448467

缺点：HyperLogLog 这个数据结构不是免费的，不是说使用这个数据结构要花钱，它需要占据 一定 12k 的存储空间，所以它不适合统计单个用户相关的数据。如果你的用户上亿，可以算 算，这个空间成本是非常惊人的。但是相比 set 存储方案，HyperLogLog 所使用的空间那真 是可以使用千斤对比四两来形容了

九.布隆过滤器

布隆过滤器有二个基本指令，bf.add 添加元素，bf.exists 查询元素是否存在

注：存在一定误判率

布隆过滤器的 initial_size 估计的过大，会浪费存储空间，估计的过小，就会影响准确 率，用户在使用之前一定要尽可能地精确估计好元素数量，还需要加上一定的冗余空间以避 免实际元素可能会意外高出估计值很多。 布隆过滤器的 error_rate 越小，需要的存储空间就越大，对于不需要过于精确的场合， error_rate 设置稍大一点也无伤大雅。比如在新闻去重上而言，误判率高一点只会让小部分文 章不能让合适的人看到，文章的整体阅读量不会因为这点误判率就带来巨大的改变

十.

1.redis是个单线程程序

2.Redis 单线程为什么还能这么快？

所有数据都是存储在内存中的，所有运算都是内存级别的运算

3.Redis 单线程如何处理那么多的并发客户端连接？

 

十一.Redis 的持久化机制

Redis 的持久化机制有两种:

第一种是快照，第二种是 AOF 日志

注：Redis 的主节点是不会进行持久化操作，持久化操作主要在从节点进行。从节 点是备份节点，没有来自客户端请求的压力，它的操作系统资源往往比较充沛。

 

十二.管道

十三.主从同步

注：主从同步，同步的是指令不是数据，从服务器执行同步过来的指令就达到数据同步的效果