Redis总结

定义

Redis是C语言开发的一个开源的（遵从BSD协议）高性能键值对（key-value）的内存数据库，可以用作数据库、缓存、消息中间件等。它是一种NoSQL的内存数据库。

特性

• 性能优秀，数据在内存中，读写速度非常快，单机支持并发10W QPS
• 单进程单线程，是线程安全的，采用IO多路复用机制
• 丰富的数据类型，支持字符串（strings）、散列（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等
• 支持数据持久化。可以将内存中数据保存在磁盘中，重启时加载
• 主从复制，哨兵，高可用
• 可以用作分布式锁
• 可以作为消息中间件使用，支持发布订阅

数据类型

• 概括：使用一个redisObject对象来表示所有的key和value。redisObject有type（数据类型）encoding（存储方式）、数据指针、虚拟内存等
• String：基本的类型，string类型是二进制安全的，string类型可以包含任何数据，值最大能存储512M
• Hash是一个键值（key-value）的集合。redis的hash是一个string的key和value的映射表，Hash特别适合存储对象。常用命令：hget,hset,hgetall等。应用场景：存储、读取、修改用户属性
• list列表是简单的字符串列表，按照插入顺序排序。常用命令：lpush、rpush、lpop、rpop、lrange。应用场景：关注列表，粉丝列表，最新消息排行；消息队列
• set是string类型的无序集合。无序无重复。常用命令：sdd、spop、smembers、sunion。应用场景：共同好友，统计访问网站的所有Ip
• zset和set一样是string类型元素的集合，有序且不允许重复的元素。常用命令：zadd、zrange、zrem、zcard。内部使用HashMap和跳跃表(skipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score，使用跳跃表的结构可以获得比较高的查找效率。场景：排行榜；带权重的消息队列

数据结构

• int
• embstr
• raw
• LinkedList
• QuickList
• ZipList
• Intset
• Dict
• SkipList

使用方式

• RedisTemplate

缓存问题

• 缓存和数据库数据一致性问题
  1. 无法保证两者间的强一致性
  2. 只能采取合适的策略来降低缓存和数据库间数据不一致的概率
  3. 更新数据库后及时更新缓存、缓存失败时增加重试机制
• 缓存雪崩
  1. 描述：多个缓存key同时失效，请求全部落在数据库上，导致数据库被打挂。 解决：把每个Key的失效时间都加个随机值，保证key数据不会在同一时间大面积失效。
• 缓存穿透
  1. 描述：用户发起一个缓存和数据库都不存在的id进行请求，透过缓存不对不断攻击数据库，导致数据库压力很大，严重会击垮数据库。
  2. 解决：
     • 进行用户鉴权，不合法的用户请求直接return
     • 利用布隆过滤器，就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在，不存在你return就好了，存在你就去查DB刷新KV再return
• 缓存击穿
  1. 描述：指一个非常热点的key不断的承受着大量的请求，当这个Key在失效的瞬间，持续的大并发直接落到了数据库上，造成了缓存击穿。
  2. Redis为何这么快解决：设置热点数据永不过期，或者加上互斥锁就搞定了

Redis为何这么快

• 官方提供的数据可以达到100000+的QPS（每秒内的查询次数），这个数据不比Memcached差！
• Redis确实是单进程单线程的模型，因为Redis完全是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章的采用单线程的方案了（毕竟采用多线程会有很多麻烦）
• 第一：Redis完全基于内存，绝大部分请求是纯粹的内存操作，非常迅速，数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度是O(1)。
• 第二：数据结构简单，对数据操作也简单。
• 第三：采用单线程，避免了不必要的上下文切换和竞争条件，不存在多线程导致的CPU切换，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有死锁问题导致的性能消耗。
• 第四：使用多路复用IO模型，非阻塞IO。

Redis和Memcached的区别

• 存储方式上：memcache会把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。redis有部分数据存在硬盘上，这样能保证数据的持久性。
• 数据支持类型上：memcache对数据类型的支持简单，只支持简单的key-value，，而redis支持五种数据类型。
• 使用底层模型不同：它们之间底层实现方式以及与客户端之间通信的应用协议不一样。redis直接自己构建了VM机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
• value的大小：redis可以达到1GB，而memcache只有1MB。

key过期策略

• 定时删除
• 惰性删除

淘汰策略

• volatile-lru：从已设置过期时间的KV集中优先对最近最少使用(less recently used)的数据淘汰
• volitile-ttl：从已设置过期时间的KV集中优先对剩余时间短(time to live)的数据淘汰
• volitile-random：从已设置过期时间的KV集中随机选择数据淘汰
• allkeys-lru：从所有KV集中优先对最近最少使用(less recently used)的数据淘汰
• allKeys-random：从所有KV集中随机选择数据淘汰
• noeviction：不淘汰策略，若超过最大内存，返回错误信息

持久化

• RDB（默认）：快照形式是直接把内存中的数据保存到一个dump的文件中，定时保存，保存策略。
  1. save
  2. bgsave
  3. fork()
• AOF：把所有的对Redis的服务器进行修改的命令都存到一个文件里，命令的集合。
  1. fsync
  2. always
  3. no
  4. everysec
  5. Rewrite
• 当Redis重启的时候，它会优先使用AOF文件来还原数据集，因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。

事务

• 开启事务--命令入队--执行/放弃
• multi
• queued
• exec/discard
• watch
• unwatch

分布式锁

• 利用setnx命令的原子性来保证分布式系统中只有一个节点中的一个线程可以获得锁。
• 设置过期时间
• 续期
• 防止释放别人的锁
• 常用redisson框架实现

主从复制

• 主从配置结合哨兵模式能解决单点故障问题，提高redis可用性。从节点仅提供读操作，主节点提供写操作。对于读多写少的状况，可给主节点配置多个从节点，从而提高响应效率。
• 主从复制过程
  1. 从节点执行slaveof，保存主节点信息
  2. 从节点中的定时任务发现主节点信息，建立和主节点的socket连接
  3. 从节点发送Ping信号，主节点返回Pong，两边能互相通信
  4. 连接建立后，主节点将所有数据发送给从节点（数据同步）
  5. 主节点把当前的数据同步给从节点后，便完成了复制的建立过程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。
• 数据同步的过程
  1. edis2.8之前使用sync [runId] [ offset]同步命令，redis2.8之后使用psync [runId] [offset]命令。
     • sync命令仅支持全量复制过程，psync支持全量和部分复制。
     • runId：每个redis节点启动都会生成唯一的uuid，每次redis重启后，runId都会发生变化。
     • offset：主节点和从节点都各自维护自己的主从复制偏移量
  2. （1）主节点发送数据给从节点过程中，主节点还会进行一些写操作，这时候的数据存储在复制缓冲区中。从节点同步主节点数据完成后，主节点将缓冲区的数据继续发送给从节点，用于部分复制。
  3. （2）主节点响应写命令时，不但会把命名发送给从节点，还会写入复制积压缓冲区，用于复制命令丢失的数据补救。
  4. 从节点发送psync [runId] [offset]命令，主节点有三种响应：
     1. FULLRESYNC：第一次连接，进行全量复制
     2. CONTINUE：进行部分复制
     3. ERR：不支持psync命令，进行全量复制
• 全量复制的流程
  1. 从节点发送psync ? -1命令（因为第一次发送，不知道主节点的runId，所以为?，因为是第一次复制，所以offset=-1）。
  2. 主节点发现从节点是第一次复制，返回FULLRESYNC {runId} {offset}，runId是主节点的runId，offset是主节点目前的offset。
  3. 从节点接收主节点信息后，保存到info中。
  4. 4、主节点在发送FULLRESYNC后，启动bgsave命令，生成RDB文件（数据持久化）。
  5. 5、主节点发送RDB文件给从节点。到从节点加载数据完成这段期间主节点的写命令放入缓冲区。
  6. 6、从节点清理自己的数据库数据。
  7. 7、从节点加载RDB文件，将数据保存到自己的数据库中。
  8. 8、如果从节点开启了AOF，从节点会异步重写AOF文件。
• 部分复制的流程
  1. 部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施，使用psync[runId][offset]命令实现。当从节点正在复制主节点时，如果出现网络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，主节点的复制积压缓冲区将这部分数据直接发送给从节点，这样就可以保持主从节点复制的一致性。补发的这部分数据一般远远小于全量数据。
  2. 主从连接中断期间主节点依然响应命令，但因复制连接中断命令无法发送给从节点，不过主节点内的复制积压缓冲区依然可以保存最近一段时间的写命令数据。
  3. 当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们当做psync参数发送给主节点，要求进行部分复制。
  4. 主节点接收到psync命令后首先核对参数runId是否与自身一致，如果一致，说明之前复制的是当前主节点；之后根据参数offset在复制积压缓冲区中查找，如果offset之后的数据存在，则对从节点发送+COUTINUE命令，表示可以进行部分复制。因为缓冲区大小固定，若发生缓冲溢出，则进行全量复制。
  5. 主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。

哨兵

• 主从复制会存在哪些问题
  1. 一旦主节点宕机，从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
  2. 主节点的写能力受到单机的限制。
  3. 主节点的存储能力受到单机的限制。
  4. 原生复制的弊端在早期的版本中也会比较突出，比如：redis复制中断后，从节点会发起psync。此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的卡顿。
• 哨兵功能 主要功能包括主节点存活检测、主从运行情况检测、自动故障转移、主从切换。
  1. 监控：不断检查主服务器和从服务器是否正常运行。
  2. 通知：当被监控的某个redis服务器出现问题，Sentinel通过API脚本向管理员或者其他应用程序发出通知。
  3. 自动故障转移：当主节点不能正常工作时，Sentinel会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点，这样人工干预就可以免了。
  4. 配置提供者：在Redis Sentinel模式下，客户端应用在初始化时连接的是Sentinel节点集合，从中获取主节点的信息。
• 工作原理
  1. 每个Sentinel节点都需要定期执行以下任务：每个Sentinel以每秒一次的频率，向它所知的主服务器、从服务器以及其他的Sentinel实例发送一个PING命令。
  2. 如果一个实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds所指定的值，那么这个实例会被Sentinel标记为主观下线。
  3. 如果一个主服务器被标记为主观下线，那么正在监视这个服务器的所有Sentinel节点，要以每秒一次的频率确认主服务器的确进入了主观下线状态。
  4. 如果一个主服务器被标记为主观下线，并且有足够数量的Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个主服务器被标记为客观下线。
  5. 一般情况下，每个Sentinel会以每10秒一次的频率向它已知的所有主服务器和从服务器发送INFO命令，当一个主服务器被标记为客观下线时，Sentinel向下线主服务器的所有从服务器发送INFO命令的频率，会从10秒一次改为每秒一次。
  6. Sentinel和其他Sentinel协商客观下线的主节点的状态，如果处于SDOWN状态，则投票自动选出新的主节点，将剩余从节点指向新的主节点进行数据复制。
  7. 当没有足够数量的Sentinel同意主服务器下线时，主服务器的客观下线状态就会被移除。当主服务器重新向Sentinel的PING命令返回有效回复时，主服务器的主观下线状态就会被移除。