Redis总结

1. Redis是用C语言开发的一个开源的高性能键值对（key-value)内存数据库, 属于一种NoSQL数据库。

2. Redis提供五种数据类型来存储数据：String, Hash, List, Set, SortedSet 。

String: 使用INCR命令做ID自增，计数器

内部数据结构

在Redis内部，String类型通过 int、SDS(simple dynamic string)作为结构存储，int用来存放整型数据，sds存放字

节/字符串和浮点型数据。在C的标准字符串结构下进行了封装，用来提升基本操作的性能，同时也充分利用已有的

C的标准库，简化实现逻辑。我们可以在redis的源码中【sds.h】中看到sds的结构如下；

typedef char *sds;

redis3.2分支引入了五种sdshdr类型，目的是为了满足不同长度字符串可以使用不同大小的Header，从而节省内

存，每次在创建一个sds时根据sds的实际长度判断应该选择什么类型的sdshdr，不同类型的sdshdr占用的内存空

间不同。这样细分一下可以省去很多不必要的内存开销

　　hash: 存储对象数据

数据结构

map提供两种结构来存储，一种是hashtable、另一种是前面讲的ziplist，数据量小的时候用ziplist.

　　List: 评论列表

列表类型内部使用双向链表实现，所以向列表两端添加元素的时间复杂度为O(1), 获取越接近两端的元素速度就越

快。这意味着即使是一个有几千万个元素的列表，获取头部或尾部的10条记录也是很快的

内部数据结构

redis3.2之前，List类型的value对象内部以linkedlist或者ziplist来实现, 当list的元素个数和单个元素的长度比较小

的时候，Redis会采用ziplist（压缩列表）来实现来减少内存占用。否则就会采用linkedlist（双向链表）结构。

redis3.2之后，采用的一种叫quicklist的数据结构来存储list，列表的底层都由quicklist实现。

这两种存储方式都有优缺点，双向链表在链表两端进行push和pop操作，在插入节点上复杂度比较低，但是内存开

销比较大； ziplist存储在一段连续的内存上，所以存储效率很高，但是插入和删除都需要频繁申请和释放内存；

quicklist仍然是一个双向链表，只是列表的每个节点都是一个ziplist，其实就是linkedlist和ziplist的结合，quicklist

中每个节点ziplist都能够存储多个数据元素

　　Set:

集合类型的常用操作是向集合中加入或删除元素、判断某个元素是否存在。由于集合类型在redis内部是使用的值

为空的散列表(hash table)，所以这些操作的时间复杂度都是O(1).

数据结构

Set在的底层数据结构以intset或者hashtable来存储。当set中只包含整数型的元素时，采用intset来存储，否则，

采用hashtable存储，但是对于set来说，该hashtable的value值永远为NULL。通过key来存储元素

SortedSet: 销售排行榜

在集合类型的基础上，有序集合类型为集合中的每个元素都关联了一个分数，这使得我们不仅可以完成插入、删除

和判断元素是否存在等集合类型支持的操作，还能获得分数最高(或最低)的前N个元素、获得指定分数范围内的元

素等与分数有关的操作。虽然集合中每个元素都是不同的，但是他们的分数却可以相同

数据结构

zset类型的数据结构就比较复杂一点，内部是以ziplist或者skiplist+hashtable来实现，

3. NoSQL就是非关系型的数据库，每条数据和其他数据没有关联。NoSQL数据库是为了解决高并发、高可用、高扩展性、大数据存储问题而产生的数据库解决方案。它是关系型数据库的良好补充，但不能替代关系型数据库。

4. 关系型数据库就是一种有行有列的数据库，多条数据间有关联。

5. Redis的应用场景：缓存数据， 解决session共享问题， 任务队列，发布订阅的消息模式、网站访问统计、排行榜。

6. redis启动命令：./redis-server redis.conf  ./redis-cli -h 127.0.0.1 -p 6379

7. redis正常关闭：

./redis-cli shutdown

考虑到redis有可能正在将内存的数据同步到硬盘中，强行终止redis进程可能会导致数据丢失，正确停止redis的方

式应该是向Redis发送SHUTDOW命令

8. Redis默认一共是16个数据库，每个数据库之间是相互隔离（但是可以使用flushall一次清空所有的库）。数据库的数量是在redis.conf中配置的(databases 16). 切换数据库：select 数据库编号（0-15）

9. 

Redis的事务是通过MULTI，EXEC，DISCARD和WATCH这四个命令来完成的。

Redis的单个命令都是原子性的，所以这里确保事务性的对象是命令集合。

Redis将命令集合序列化并确保处于同一事务的命令集合连续且不被打断的执行

Redis不支持回滚操作：大多数事务失败是因为语法错误或者类型错误，这两种错误，在开发阶段都是可以预见的

redis为了性能方面就忽略了事务回滚

  • MULTI

用于标记事务块的开始。

Redis会将后续的命令逐个放入队列中，然后使用EXEC命令原子化地执行这个命令序列。

语法：multi

  • EXEC

在一个事务中执行所有先前放入队列的命令，然后恢复正常的连接状态

语法：exec

  • DISCARD

清除所有先前在一个事务中放入队列的命令，然后恢复正常的连接状态。

语法：discard

  • WATCH

当某个事务需要按条件执行时，就要使用这个命令将给定的键设置为受监控的状态。

语法：watch key [key…]

注意事项：使用该命令可以实现redis的乐观锁。

  • UNWATCH

清除所有先前为一个事务监控的键。

语法：unwatch

 10. 分布式锁的实现方式

  • 基于数据库的乐观锁实现分布式锁
  • 基于zookeeper临时节点的分布式锁
  • 基于redis的分布式锁

分布式锁的注意事项

  • 互斥性：在任意时刻，只有一个客户端能持有锁
  • 同一性：加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。
  • 可重入性：即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。

11. 

Redis是一个内存数据库，为了保证数据的持久性，它提供了两种持久化方案:

  • RDB方式（默认）
  • AOF方式

RDB是Redis默认采用的持久化方式。

RDB方式是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。

在redis.conf中设置自定义快照规则

  1. RDB持久化条件

格式：save <seconds> <changes>

 

示例：

save 900 1  ： 表示15分钟（900秒钟）内至少1个键被更改则进行快照。

save 300 10 ： 表示5分钟（300秒）内至少10个键被更改则进行快照。

save 60 10000 ：表示1分钟内至少10000个键被更改则进行快照。

可以配置多个条件（每行配置一个条件），每个条件之间是“或”的关系。

Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。

快照的实现原理

  1. redis使用fork函数复制一份当前进程的副本(子进程)
  2. 父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件。
  3. 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。  

 

  • 注意事项
  1. redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。 
  2. 这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份， RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。
  1. RDB优缺点
  • 缺点：使用RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化
  • 优点： RDB可以最大化Redis的性能：父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无需执行任何磁盘I/O操作。同时这个也是一个缺点，如果数据集比较大的时候，fork可以能比较耗时，造成服务器在一段时间内停止处理客户端的请求；

默认情况下Redis没有开启AOF（append only file）方式的持久化

开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件，这一过程显然会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高AOF的性能。

AOF重写原理（优化AOF文件）

  • Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写
  • 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 
  • 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
  • AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松
  • 参数说明

# auto-aof-rewrite-percentage 100  表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准

# auto-aof-rewrite-min-size 64mb   限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化

 

同步磁盘数据

Redis每次更改数据的时候， aof机制都会将命令记录到aof文件，但是实际上由于操作系统的缓存机制，数据并没有实时写入到硬盘，而是进入硬盘缓存。再通过硬盘缓存机制去刷新到保存到文件

 

  • 参数说明：

* appendfsync always  每次执行写入都会进行同步  ， 这个是最安全但是是效率比较低的方式

* appendfsync everysec   每一秒执行

* appendfsync no  不主动进行同步操作，由操作系统去执行，这个是最快但是最不安全的方式

 

AOF文件损坏以后如何修复

服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。

当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：

  1. 为现有的 AOF 文件创建一个备份。
  2. 使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。

redis-check-aof --fix readonly.aof

  1. 重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

如何选择RDB和AOF

  • 一般来说,如果对数据的安全性要求非常高的话，应该同时使用两种持久化功能。
  • 如果可以承受数分钟以内的数据丢失，那么可以只使用 RDB 持久化。
  • 有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快 。
  • 两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话， 那么Redis重启时，会优先使用AOF文件来还原数据

Redis的主从复制

持久化保证了即使redis服务重启也不会丢失数据，因为redis服务重启后会将硬盘上持久化的数据恢复到内存中，但是当redis服务器的硬盘损坏了可能会导致数据丢失，不过通过redis的主从复制机制就可以避免这种单点故障

slave在整个体系中起到了数据冗余备份和读写分离的作用

说明：

  • 主redis中的数据有两个副本（replication）即从redis1和从redis2，即使一台redis服务器宕机其它两台redis服务也可以继续提供服务。
  • 主redis中的数据和从redis上的数据保持实时同步，当主redis写入数据时通过主从复制机制会复制到两个从redis服务上。
  • 只有一个主redis，可以有多个从redis。
  • 主从复制不会阻塞master，在同步数据时，master 可以继续处理client 请求
  • 一个redis可以即是主又是从（从也可以有从）
  1. 实现原理

* Redis的主从同步，分为全量同步和增量同步。

* 只有从机第一次连接上主机是全量同步

* 断线重连有可能触发全量同步也有可能是增量同步（master判断runid是否一致）

* 除此之外的情况都是增量同步

 

全量同步

Redis的全量同步过程主要分三个阶段：

  • 同步快照阶段：Master创建并发送快照给Slave,Slave载入并解析快照。Master同时将此阶段所产生的新的写命令存储到缓冲区。
  • 同步写缓冲阶段：Master向Slave同步存储在缓冲区的写操作命令。
  • 同步增量阶段：Master向Slave同步写操作命令。

master/slave 复制策略是采用乐观复制，也就是说可以容忍在一定时间内master/slave数据的内容是不同的，但是

两者的数据会最终同步。具体来说，redis的主从同步过程本身是异步的，意味着master执行完客户端请求的命令

后会立即返回结果给客户端，然后异步的方式把命令同步给slave。

这一特征保证启用master/slave后 master的性能不会受到影响。

但是另一方面，如果在这个数据不一致的窗口期间，master/slave因为网络问题断开连接，而这个时候，master

是无法得知某个命令最终同步给了多少个slave数据库。不过redis提供了一个配置项来限制只有数据至少同步给多

少个slave的时候，master才是可写的：

min-slaves-to-write 3 表示只有当3个或以上的slave连接到master，master才是可写的

min-slaves-max-lag 10 表示允许slave最长失去连接的时间，如果10秒还没收到slave的响应，则master认为该

slave以断开

增量同步

* Redis增量同步主要指Slave完成初始化后开始正常工作时，Master发生的写操作同步到Slave的过程。

* 通常情况下，Master每执行一个写命令就会向Slave发送相同的写命令，然后Slave接收并执行。

 

从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的

地方，继续复制下去，而不是从头开始复制一份

master node会在内存中创建一个backlog，master和slave都会保存一个replica offset还有一个master id，offset

就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续

复制

但是如果没有找到对应的offset，那么就会执行一次全量同步

无硬盘复制

前面我们说过，Redis复制的工作原理基于RDB方式的持久化实现的，也就是master在后台保存RDB快照，slave接

收到rdb文件并载入，但是这种方式会存在一些问题

ü1. 当master禁用RDB时，如果执行了复制初始化操作，Redis依然会生成RDB快照，当master下次启动时执行该

RDB文件的恢复，但是因为复制发生的时间点不确定，所以恢复的数据可能是任何时间点的。就会造成数据出现问

题

ü2. 当硬盘性能比较慢的情况下（网络硬盘），那初始化复制过程会对性能产生影响

因此2.8.18以后的版本，Redis引入了无硬盘复制选项，可以不需要通过RDB文件去同步，直接发送数据，通过以

下配置来开启该功能

repl-diskless-sync yes

master**在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了

Redis Sentinel哨兵机制

Redis主从复制的缺点：没有办法对master进行动态选举，需要使用Sentinel机制完成动态选举

 

* Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态

* 在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用（HA）

* 其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。

 

哨兵进程的作用

  1. 监控(Monitoring):哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
  2. 提醒(Notification)： 当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
  3. 自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作。

* 它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；

* 当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。

* Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

 

哨兵进程的工作方式

  1. 每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
  2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）。
  3. 如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。
  4. 当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）。
  5. 在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
  6. 当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
  7. 若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

 

Redis Cluster集群

redis3.0以后推出的redis cluster 集群方案，redis cluster集群保证了高可用、高性能、高可扩展性。

(1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.

(2)节点的fail是通过集群中超过半数的节点检测失效时才生效.

(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

(4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value

Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点

 

redis-cluster投票:容错

最小节点数：3台

(1)节点失效判断：集群中所有master参与投票,如果半数以上master节点与其中一个master节点通信超过(cluster-node-timeout),认为该master节点挂掉.

(2)集群失效判断:什么时候整个集群不可用(cluster_state:fail)? 

  • 如果集群任意master挂掉,且当前master没有slave，则集群进入fail状态。也可以理解成集群的[0-16383]slot映射不完全时进入fail状态。
  • 如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态。

Redis的数据分区

分布式数据库首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节

点负责整个数据的一个子集, Redis Cluster采用哈希分区规则,采用虚拟槽分区。

虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，

整数定义为槽（slot）。比如Redis Cluster槽的范围是0 ～ 16383。槽是集群内数据管理和迁移的基本单位。采用

大范围的槽的主要目的是为了方便数据的拆分和集群的扩展，每个节点负责一定数量的槽。

计算公式：slot = CRC16(key)%16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。

HashTags

通过分片手段，可以将数据合理的划分到不同的节点上，这本来是一件好事。但是有的时候，我们希望对相关联的

业务以原子方式进行操作。举个简单的例子

我们在单节点上执行MSET , 它是一个原子性的操作，所有给定的key会在同一时间内被设置，不可能出现某些指定

的key被更新另一些指定的key没有改变的情况。但是在集群环境下，我们仍然可以执行MSET命令，但它的操作不

在是原子操作，会存在某些指定的key被更新，而另外一些指定的key没有改变，原因是多个key可能会被分配到不

同的机器上。

所以，这里就会存在一个矛盾点，及要求key尽可能的分散在不同机器，又要求某些相关联的key分配到相同机器。

这个也是在面试的时候会容易被问到的内容。怎么解决呢？

从前面的分析中我们了解到，分片其实就是一个hash的过程，对key做hash取模然后划分到不同的机器上。所以为

了解决这个问题，我们需要考虑如何让相关联的key得到的hash值都相同呢？如果key全部相同是不现实的，所以

怎么解决呢？在redis中引入了HashTag的概念，可以使得数据分布算法可以根据key的某一个部分进行计算，然后

让相关的key落到同一个数据分片

举个简单的例子，加入对于用户的信息进行存储， user:user1:id、user:user1:name/ 那么通过hashtag的方式，

user:{user1}:id、user:{user1}.name; 表示

当一个key包含 {} 的时候，就不对整个key做hash，而仅对 {} 包括的字符串做hash。

重定向客户端

Redis Cluster并不会代理查询，那么如果客户端访问了一个key并不存在的节点，这个节点是怎么处理的呢？比如

我想获取key为msg的值，msg计算出来的槽编号为254，当前节点正好不负责编号为254的槽，那么就会返回客户

端下面信息：

-MOVED 254 127.0.0.1:6381

表示客户端想要的254槽由运行在IP为127.0.0.1，端口为6381的Master实例服务。如果根据key计算得出的槽恰好

由当前节点负责，则当期节点会立即返回结果

分片迁移

在一个稳定的Redis cluster下，每一个slot对应的节点是确定的，但是在某些情况下，节点和分片对应的关系会发

生变更

ü1. 新加入master节点

ü2. 某个节点宕机

也就是说当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，

在目前实现中，还处于半自动状态，需要人工介入。

新增一个主节点

新增一个节点D，redis cluster的这种做法是从各个节点的前面各拿取一部分slot到D上。大致就会变成这样：

节点A覆盖1365-5460

节点B覆盖6827-10922

节点C覆盖12288-16383

节点D覆盖0-1364,5461-6826,10923-12287

删除一个主节点

先将节点的数据移动到其他节点上，然后才能执行删除

槽迁移的过程

槽迁移的过程中有一个不稳定状态，这个不稳定状态会有一些规则，这些规则定义客户端的行为，从而使得Redis

Cluster不必宕机的情况下可以执行槽的迁移

简单的工作流程

ü1. 向MasterB发送状态变更命令，吧Master B对应的slot状态设置为IMPORTING

ü2. 向MasterA发送状态变更命令，将Master对应的slot状态设置为MIGRATING

当MasterA的状态设置为MIGRANTING后，表示对应的slot正在迁移，为了保证slot数据的一致性，MasterA此时

对于slot内部数据提供读写服务的行为和通常状态下是有区别的，

MIGRATING状态

ü1. 如果客户端访问的Key还没有迁移出去，则正常处理这个key

ü2. 如果key已经迁移或者根本就不存在这个key，则回复客户端ASK信息让它跳转到MasterB去执行

IMPORTING状态

当MasterB的状态设置为IMPORTING后，表示对应的slot正在向MasterB迁入，及时Master仍然能对外提供该slot

的读写服务，但和通常状态下也是有区别的

ü1. 当来自客户端的正常访问不是从ASK跳转过来的，说明客户端还不知道迁移正在进行，很有可能操作了一个目前

还没迁移完成的并且还存在于MasterA上的key，如果此时这个key在A上已经被修改了，那么B和A的修改则会发生

冲突。所以对于MasterB上的slot上的所有非ASK跳转过来的操作，MasterB都不会uu出去护理，而是通过MOVED

命令让客户端跳转到MasterA上去执行

这样的状态控制保证了同一个key在迁移之前总是在源节点上执行，迁移后总是在目标节点上执行，防止出现两边

同时写导致的冲突问题。而且迁移过程中新增的key一定会在目标节点上执行，源节点也不会新增key，是的整个迁

移过程既能对外正常提供服务，又能在一定的时间点完成slot的迁移。

 

 

什么是LUA？

  • Lua 是一种轻量小巧的脚本语言，用标准C语言编写并以源代码形式开放， 其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。

Redis中使用LUA的好处

1. 减少网络开销，在Lua脚本中可以把多个命令放在同一个脚本中运行

2. 原子操作，redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。换句话说，编写脚本的过程中无需担心会出现竞态条件

3. 复用性，客户端发送的脚本会永远存储在redis中，这意味着其他客户端可以复用这一脚本来完成同样的逻辑

 

队列模式

使用list类型的lpush和rpop实现消息队列

 

注意事项：

* 消息接收方如果不知道队列中是否有消息，会一直发送rpop命令，如果这样的话，会每一次都建立一次连接，这样显然不好。

* 可以使用brpop命令，它如果从队列中取不出来数据，会一直阻塞，在一定范围内没有取出则返回null、

 

关于缓存

缓存穿透

  • 什么叫缓存穿透？

一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。如果key对应的value是一定不存在的，并且对该key并发请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。

  • 如何解决？

1：对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存。

2：对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中，查询时通过该bitmap过滤。（布隆表达式）

 

缓存雪崩

  • 什么叫缓存雪崩？

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

  • 如何解决？

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

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

3：做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期（此点为补充）

 

缓存击穿

什么叫缓存击穿？

* 对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。

 

* 缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

  • 如何解决？

使用redis的setnx互斥锁先进行判断，这样其他线程就处于等待状态，保证不会有大并发操作去操作数据库。

 

if(redis.sexnx()==1){

//查询数据库

//加入线程

}

  1. Redis内置缓存淘汰策略
  • 最大缓存

* 在 redis 中，允许用户设置最大使用内存大小maxmemory，默认为0，没有指定最大缓存，如果有新的数据添加，超过最大内存，则会使redis崩溃，所以一定要设置。

* redis 内存数据集大小上升到一定大小的时候，就会实行数据淘汰策略。

  • 淘汰策略

redis淘汰策略配置：maxmemory-policy voltile-lru，支持热配置

  • redis 提供 6种数据淘汰策略：
  1. voltile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
  2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
  3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
  4. allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
  5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
  6. no-enviction（驱逐）：禁止驱逐数据
  1. LRU原理

LRU（Least recently used，最近最少使用）算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。

  1. LRU实现

最常见的实现是使用一个链表保存缓存数据，详细算法实现如下：

1. 新数据插入到链表头部；

2. 每当缓存命中（即缓存数据被访问），则将数据移到链表头部；

3. 当链表满的时候，将链表尾部的数据丢弃。

 

在Java中可以使用LinkHashMap去实现LRU。

 

过期删除的原理

Redis 中的主键失效是如何实现的，即失效的主键是如何删除的？实际上，Redis 删除失效主键的方法主要有两

种：

消极方法（passive way）

在主键被访问时如果发现它已经失效，那么就删除它

积极方法（active way）

周期性地从设置了失效时间的主键中选择一部分失效的主键删除

对于那些从未被查询的key，即便它们已经过期，被动方式也无法清除。因此Redis会周期性地随机测试一些key，

已过期的key将会被删掉。Redis每秒会进行10次操作，具体的流程：

ü1. 随机测试 20 个带有timeout信息的key；

ü2. 删除其中已经过期的key；

ü3. 如果超过25%的key被删除，则重复执行步骤1；

这是一个简单的概率算法（trivial probabilistic algorithm），基于假设我们随机抽取的key代表了全部的key空

间。

Redis是单进程单线程？性能为什么这么快

Redis采用了一种非常简单的做法，单线程来处理来自所有客户端的并发请求，Redis把任务封闭在一个线程中从而

避免了线程安全问题；redis为什么是单线程？

官方的解释是，CPU并不是Redis的瓶颈所在，Redis的瓶颈主要在机器的内存和网络的带宽。那么Redis能不能处

理高并发请求呢？当然是可以的，至于怎么实现的，我们来具体了解一下。 【注意并发不等于并行，并发性I/O

流，意味着能够让一个计算单元来处理来自多个客户端的流请求。并行性，意味着服务器能够同时执行几个事情，

具有多个计算单元】

多路复用

Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞

的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提

供服务，而 I/O 多路复用就是为了解决这个问题而出现的。

 

Redis缓存与数据一致性问题

那么基于上面的这个出发点，问题就来了，当用户的余额发生变化的时候，如何更新缓存中的数据，也就是说。

\1. 我是先更新缓存中的数据再更新数据库的数据；

\2. 还是修改数据库中的数据再更新缓存中的数据

这就是我们经常会在面试遇到的问题，数据库的数据和缓存中的数据如何达到一致性？首先，可以肯定的是，

redis中的数据和数据库中的数据不可能保证事务性达到统一的，这个是毫无疑问的，所以在实际应用中，我们都

是基于当前的场景进行权衡降低出现不一致问题的出现概率

更新缓存还是让缓存失效

更新缓存表示数据不但会写入到数据库，还会同步更新缓存； 而让缓存失效是表示只更新数据库中的数据，然后删

除缓存中对应的key。那么这两种方式怎么去选择？这块有一个衡量的指标。

\1. 如果更新缓存的代价很小，那么可以先更新缓存，这个代价很小的意思是我不需要很复杂的计算去获得最新的

余额数字。

\2. 如果是更新缓存的代价很大，意味着需要通过多个接口调用和数据查询才能获得最新的结果，那么可以先淘汰

缓存。淘汰缓存以后后续的请求如果在缓存中找不到，自然去数据库中检索。

先操作数据库还是先操作缓存？

当客户端发起事务类型请求时，假设我们以让缓存失效作为缓存的的处理方式，那么又会存在两个情况，

\1. 先更新数据库再让缓存失效

\2. 先让缓存失效，再更新数据库

前面我们讲过，更新数据库和更新缓存这两个操作，是无法保证原子性的，所以我们需要根据当前业务的场景的容

忍性来选择。也就是如果出现不一致的情况下，哪一种更新方式对业务的影响最小，就先执行影响最小的方案

 

posted @ 2019-10-18 21:47  Emyin  阅读(322)  评论(0)  编辑  收藏  举报