redis知识点

1 redis特点

　　内存数据库，读写速度快，被应用于缓存。

　　数据类型丰富，支持事务、持久化、LUA脚本、LRU驱动事件、多种集群方案。

　　丰富的特性：缓存，消息，过期，自动删除

2 数据类型：

　　hash：k-v集合，适用于存储对象。由于组合式的压缩，内存利用率更高。

　　字符串：一个键最大能存512MB

　　列表：按照插入顺序排序。

　　　　异步队列：rpush为生产消息，lpop为消费消息。但是消费者下线时，生产消息会丢失。

　　set集合：string类型的无序集合，通过哈希表实现，增删查的复杂度是O(1)。

　　zset：有序集合，且不重复。

3 存储结构：

　　redis通讯协议RESP格式的命令文本存储。是redis客户端和服务端之前使用的一种通讯协议。特点：实现简单、快速解析、可读性好。

4 redis做缓存的原因

　　高性能：

　　a 假如用户第一次访问数据库中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。b 将该用户访问的数据存在缓存中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。c 如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

　　高并发：

　　直接操作缓存能够承受的请求是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。

　　分布式缓存：

　　使用 redis 或 memcached 之类的称为分布式缓存，在多实例的情况下，各实例共用一份缓存数据，缓存具有一致性。缺点是需要保持 redis 或 memcached服务的高可用，整个程序架构上较为复杂。

5 单线程redis快速的原因：

　　1.完全基于内存操作，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，查找和操作的时间复杂度都是O(1)

　　忽略磁盘操作。

　　2.数据结构简单，对数据操作也简单

　　3.采用单线程，避免频繁的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗

　　4.采用I/O多路复用机制，非阻塞。

　　5.使用底层模型不同，它们之间底层实现方式以及客户端之间的通信的应用协议不一样，redis直接自己构建了VM机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

6 持久化技术

　　持久化就是将内存的数据写到磁盘中，防止宕机时内存数据丢失。

　　持久化策略包括RDB（redis database）快照和AOF（append-only file）日志。

　　RDB是每隔一段时间对redis进行一次持久化，速度快，性能好，但是数据不完整。核心函数有rdbSave为rdb文件和rdbLoad。

　　AOF是重新执行命令，数据完整，安全但是速度慢，文件大。主要是调用flushappendonlyfile函数。将aof_buf中的缓存写入到AOF文件，或者是调用fsync、fdatasync函数，将AOF文件保存到磁盘中。

7 架构模式：单机版和分布式

　　单机版：内存容量有限，处理能力有限，无法高可用。

　　分布式：主从复制。保证数据相同。无法保证高可用。没有解决master写的压力。

　　哨兵：分布式系统中监控redis主从服务器，并在主服务器下线时自动进行故障转移。

　　　　特性：监控：不断地检查主从服务器是否运作正常。

　　　　提醒：当被监控的某个redis服务器出现问题时，哨兵可以通过API向管理员或者其他应用程序发送通知。

　　　　自动故障迁移：当一个主服务器不能正常工作时，哨兵会开始一次自动故障迁移操作。

　　　　特点：保证高可用、监控各个节点、自动故障迁移；主从模式，切换需要时间，可能丢数据，没有解决master写的压力

　　集群proxy：

　　　　特点：twemproxy，代理服务器，快速的，单线程。

　　　　优点：可以支持多种hash算法，失败节点会自动删除，后端sharding分片逻辑对业务透明，业务方的读写方式和操作单个redis一致。

　　　　缺点：增加新proxy时，需要维护高可用。不支持故障的自动转移。

　　　　需要自己实现failover，扩展性差。手动干预扩容和缩容。

　　集群codis：

　　　　和twemproxy效果一致，但是支持在节点数量改变的情况下，旧节点恢复到新hash节点。

　　集群直连型：无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他节点连接。

　　　　特点：没有中心节点，没有proxy层。

　　　　　　节点间数据共享，可以动态调整数据分布。

　　　　　　可扩展，到1000个节点，节点可动态增加或者删除。

　　　　　　高可用，部分节点不可用时，集群仍然可以使用。slave做备份数据。

　　　　　　实现故障自动failover，节点间通过gossip协议交换状态信息，投票机制完成slave到master的角色提升。

　　　　缺点：资源隔离性差，容易互相影响。

　　　　　　数据异步复制，不保证数据的一致性。

　　　　hash槽：根据CRC16(key) mod 16384，觉得key-value放入哪个桶（节点）。

8 redis和memcached区别　

1. redis支持更丰富的数据类型（支持更复杂的应用场景）：Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。memcache支持简单的数据类型，String。
2. Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用,而Memecache把数据全部存在内存之中。
3. 集群模式：memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 redis 目前是原生支持 cluster 模式的.
4. Memcached是多线程，非阻塞IO复用的网络模型；Redis使用单线程的多路 IO 复用模型。

5. Memcached类似于一致性哈希的分布式算法实现分布式存储。

   一致性哈希：DHT可以通过减少影响范围的方式，解决增减服务器导致的数据散列问题，解决分布式环境下负载均衡问题。如果存在热点数据，可以通过增添节点的方

　

9 redis设置过期时间

　　Redis中有个设置时间过期的功能，即对存储在 redis 数据库中的值可以设置一个过期时间。作为一个缓存数据库，这是非常实用的。如我们一般项目中的 token 或者一些登录信息，尤其是短信验证码都是有时间限制的，按照传统的数据库处理方式，一般都是自己判断过期，这样无疑会严重影响项目性能。

　　我们 set key 的时候，都可以给一个 expire time，就是过期时间，通过过期时间我们可以指定这个 key 可以存活的时间。如果假设你设置了一批 key 只能存活1个小时，那么接下来1小时后，redis是怎么对这批key进行删除的？

　　定期删除+惰性删除。

• 定期删除：redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。注意这里是随机抽取的。为什么要随机呢？你想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载！
• 惰性删除 ：定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。这就是所谓的惰性删除，也是够懒的哈！

　　但是仅仅通过设置过期时间还是有问题的。我们想一下：如果定期删除漏掉了很多过期 key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期key堆积在内存里，导致redis内存块耗尽了。怎么解决这个问题呢？ redis 内存淘汰机制。

10 redis内存淘汰机制

　redis 提供 6种数据淘汰策略：

1. volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
4. allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
6. no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。

　　4.0版本后增加以下两种：

7. volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
8. allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key

11 redis事务（不是原子性）

　　Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。

　　注意：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。　

12 缓存雪崩和缓存穿透

　　缓存雪崩：

　　　　当缓存服务器重启或者大量缓存集中在一个时间段失效，失效时会对后端系统带来很大压力，严重时数据库会宕机。

　　　　避免：

　　　　1.缓存失效后，通过加锁或者队列控制读数据库、写缓存的线程数量。比如某个key只允许一个线程查询数据和写缓存，其他线程等待

　　　　2.做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，访问A2，A1缓存失效时间短期，A2为长期

　　　　3.不同的key设置不同的过期时间，让缓存失效的时间点尽量均匀。

　　缓存穿透：

　　　　一般的缓存系统是按照key去缓存查询，不存在对应的value时，会去后端系统查询。而恶意的请求会故意查询不存在的key，请求量直接到数据库上，请求量很大时，会对后端系统造成很大压力，就叫缓存穿透。

　　　　正常处理流程：

　　　　解决：

　　　　　　1.查询结果为空的情况进行缓存过期时间，缓存时间短，最长不超过5分钟，或者key对应的数据插入后清理缓存。

　　　　　　2.使用布隆过滤器。对一定不存在的key进行过滤。把所有可能存在的key放在一个大的bitmap（哈希表）中，查询时通过bitmap过滤，这样避免了对底层存储系统的查询压力。

13 分布式锁

　　原因：

　　　　redis并发竞争key时，多个系统同时对一个 key 进行操作，但是最后执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同！

　　先使用setnx抢锁，设置超时时间以释放锁、超过一半的redis实例设置成功，就表示加锁完成。

　　注意：如果不存在 Redis 的并发竞争 Key 问题，不要使用分布式锁，这样会影响性能