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. 四、主节点在发送FULLRESYNC后，启动bgsave命令，生成RDB文件（数据持久化）。
  5. 五、主节点发送RDB文件给从节点。到从节点加载数据完成这段期间主节点的写命令放入缓冲区。
  6. 六、从节点清理本身的数据库数据。
  7. 七、从节点加载RDB文件，将数据保存到本身的数据库中。
  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命令返回有效回复时，主服务器的主观下线状态就会被移除。