Redis

pexels-matteo-badini-4343131.jpg

Redis为啥快：

• 纯内存操作: 数据存在内存中,类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
• 单线程操作: 避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

五种数据类型：

• 字符串：string是redis的最基本类型,一个key对应一个value；string 类型在 redis 中是二进制安全(binary safe)的,这意味着 string 值关心二进制的字符串，不关心具体格式，你可以用它存储 json 格式或 JPEG 图片格式的字符串。 一个键最大能存储512MB.

• Hash：是一个键值对集合,是一个String类型的key与value的映射表.

  
  Hash.png
  

  场景：
  Hash类型十分适合存储对象类数据,相对于string 中介绍的把对象转化为 json 字符串存储,hash 的结构可以任意添加或删除‘字段名’，更加高效灵活。

• List：是链表(redis 使用双端链表实现的 List),就是按照插入顺序排序的字符串链表,可以在头部和尾部插入新的元素.

  
  List.png
  

  场景：
  a)：使用 List 结构，我们可以轻松地实现最新消息排行等功能。
  b)：List 的另一个应用就是消息队列，可以利用 List 的 *PUSH 操作，将任务存在 List 中，然后工作线程再用 POP 操作将任务取出进行执行。

• Set：集合是通过哈希表实现的,Set就是一个集合,集合的概念就是一堆不重复值的组合.set 类型提供了多个 set 之间的聚合运算，如求交集、并集、补集，这些操作在 redis 内部完成，效率很高。
  

  Set.png
  场景：
  a)：利用 Redis 提供的 Set 数据结构，可以存储一些集合性的数据。比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。
  b)：因为 Redis 非常人性化的为集合提供了求交集、并集、差集等操作，那么就可以非常方便的实现如共同关注、共同喜好。

• Sorted Set：在 set 的基础上给集合中每个元素关联了一个分数，往有序集合中插入数据时会自动根据这个分数排序。
  场景：
  a)：比如一个存储全班同学成绩的 Sorted Sets，其集合 value 可以是同学的学号，而 score 就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序.
  b)：另外还可以用 Sorted Sets 来做带权重的队列，比如普通消息的 score 为1，重要消息的 score 为2，然后工作线程可以选择按 score 的倒序来获取工作任务。让重要的任务优先执行.
  c)：延迟队列(订单超过30分钟自动取消)。

持久化：

• RDB：
  a）：Redis是内存数据库，数据都是存储在内存中，为了避免进程退出导致数据的永久丢失，需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘；当下次Redis重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置.
  b）：Redis持久化分为RDB持久化和AOF持久化：前者将当前数据保存到硬盘，后者则是将每次执行的写命令保存到硬盘（类似于MySQL的binlog）；由于AOF持久化的实时性更好，即当进程意外退出时丢失的数据更少，因此AOF是目前主流的持久化方式，不过RDB持久化仍然有其用武之地。
  RDB执行流程：

  
  RDB执行流程.png
• AOF：
  a）：Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置.
  b）：由于需要记录Redis的每条写命令，因此AOF不需要触发.AOF的执行流程包括:
  命令追加(append)：将Redis的写命令追加到缓冲区aof_buf；
  文件写入(write)和文件同步(sync)：根据不同的同步策略将aof_buf中的内容同步到硬盘；
  文件重写(rewrite)：定期重写AOF文件，达到压缩的目的.
  c）：为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性.
  AOF缓存区的同步文件策略：
  a）always：命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命.
  b）no：命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证.
  c）everysec：命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置.
  RDB和AOF的优缺点：
  a）RDB持久化：
  优点:RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小.
  缺点:RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流.
  b）AOF持久化：
  与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大.

主从复制：

是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点.
a）数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
b）故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
c）负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
d）高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

哨兵：

哨兵的核心功能是主节点的自动故障转移。
a）监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常.
b）自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点.
c）配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址.
d）通知（Notification）：哨兵可以将故障转移的结果发送给客户端.
两部分组成：
a）哨兵节点: 哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据.
b）数据节点: 主节点和从节点都是数据节点.
哨兵架构图：

哨兵架构图.png

集群：

即Redis Cluster，是一种分布式存储方案。集群由多个节点(Node)组成，Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点：只有主节点负责读写请求和集群信息的维护；从节点只进行主节点数据和状态信息的复制.
作用：
a）数据分区：数据分区(或称数据分片)是集群最核心的功能: 集群将数据分散到多个节点，一方面突破了Redis单机内存大小的限制，存储容量大大增加；另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力.
b）高可用：集群支持主从复制和主节点的自动故障转移（与哨兵类似）；当任一节点发生故障时，集群仍然可以对外提供服务。
数据分区方案：
a）哈希取余分区: 计算key的hash值，然后对节点数量进行取余，从而决定数据映射到哪个节点上。该方案最大的问题是，当新增或删减节点时，节点数量发生变化，系统中所有的数据都需要重新计算映射关系，引发大规模数据迁移。
b）一致性哈希分区: 一致性哈希算法将整个哈希值空间组织成一个虚拟的圆环，如下图所示，范围为0-2^32-1；对于每个数据，根据key计算hash值，确定数据在环上的位置，然后从此位置沿环顺时针行走，找到的第一台服务器就是其应该映射到的服务器.一致性哈希分区的主要问题在于，当节点数量较少时，增加或删减节点，对单个节点的影响可能很大，造成数据的严重不平衡。还是以上图为例，如果去掉node2，node4中的数据由总数据的1/4左右变为1/2左右，与其他节点相比负载过高.
c）带虚拟节点的一致性哈希分区.

• 带虚拟节点的一致性哈希分区：
  该方案在一致性哈希分区的基础上，引入了虚拟节点的概念,Redis集群使用的便是该方案，其中的虚拟节点称为槽（slot）.槽是介于数据和实际节点之间的虚拟概念；每个实际节点包含一定数量的槽，每个槽包含哈希值在一定范围内的数据。引入槽以后，数据的映射关系由数据hash->实际节点，变成了数据hash->槽->实际节点.
  槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点之间的关系，增加或删除节点对系统的影响很小.
  a）：Redis对数据的特征值（一般是key）计算哈希值，使用的算法是CRC16.
  b）：根据哈希值，计算数据属于哪个槽.
  c）：根据槽与节点的映射关系，计算数据属于哪个节点。

  
  一致性哈希分区.png

带虚拟节点的一致性哈希分区.png 集群.png

总结：

Redis真的是强大，还有一些牛逼的扩展，牛逼的人物是真的多...