一、数据类型

Redis反对五种数据类型：

二、主从复制机制

Redis反对主从复制，Redis的主从构造能够采纳一主多从或者级联构造

Redis主从复制能够依据是否是全量分为全量同步和增量同步。

1. 全量同步

Redis全量复制个别产生在Slave初始化阶段，这时Slave须要将Master上的所有数据都复制一份。具体步骤如下：

  • 1）从服务器连贯主服务器，发送SYNC命令；
  • 2）主服务器接管到SYNC命名后，开始执行BGSAVE命令生成RDB文件并应用缓冲区记录尔后执行的所有写命令；
  • 3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间持续记录被执行的写命令；
  • 4）从服务器收到快照文件后抛弃所有旧数据，载入收到的快照；
  • 5）主服务器快照发送结束后开始向从服务器发送缓冲区中的写命令；
  • 6）从服务器实现对快照的载入，开始接管命令申请，并执行来自主服务器缓冲区的写命令；

实现下面几个步骤后就实现了从服务器数据初始化的所有操作，从服务器此时能够接管来自用户的读申请。

2. 增量同步

Redis增量复制是指Slave初始化后开始失常工作时主服务器产生的写操作同步到从服务器的过程。
增量复制的过程次要是主服务器每执行一个写命令就会向从服务器发送雷同的写命令，从服务器接管并执行收到的写命令。

3. 主从同步策略

主从刚刚连贯的时候，进行全量同步；全同步完结后，进行增量同步。当然，如果有须要，slave 在任何时候都能够发动全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不胜利，要求从机进行全量同步。

Redis 2.8 当前提供了PSYNC优化了断线重连的效率

三、集群计划

四种支流的redis架构计划

  • 客户端分片
  • Redis Cluster
  • Twemproxy
  • Proxy + Redis Cluster

四、长久化形式

redis提供了两种长久化的形式，别离是RDB（Redis DataBase）和AOF（Apend Only File）。

1. RDB

概念：是一种快照式的长久化办法，将某一时刻的数据长久化到磁盘中。过程如下

  • redis在进行数据长久化的过程中，会先将数据写入到一个临时文件中，待长久化过程都完结了，才会用这个临时文件替换上次长久化好的文件。正是这种个性，让咱们能够随时来进行备份，因为快照文件总是残缺可用的。
  • 对于RDB形式，redis会独自创立（fork）一个子过程来进行长久化，而主过程是不会进行任何IO操作的，这样就确保了redis极高的性能。
  • 如果须要进行大规模数据的复原，且对于数据恢复的完整性不是十分敏感，那RDB形式要比AOF形式更加的高效。

优缺点：

  • 长处：最大化redis的性能，复原大的数据集时速度更快；

  • 毛病：意外宕机时，会失落数据（取决于配置的save工夫点）

    2. AOF

    AOF形式是将执行过的写指令记录下来，在数据恢复时依照丛前到后的程序再将指令执行一遍。

  • AOF命令以redis协定追加保留每次写的操作到文件开端.Redis还能对AOF文件进行后盾重写,使得AOF文件的体积不至于过大.默认的AOF长久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种状况下，redis依然能够放弃很好的解决性能，即便redis故障，也只会失落最近1秒钟的数据。
  • 如果在追加日志时，恰好遇到磁盘空间满、inode满或断电等状况导致日志写入不残缺，也没有关系，redis提供了redis-check-aof工具，能够用来进行日志修复。
  • 因为采纳了追加形式，如果不做任何解决的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留能够复原数据的最小指令集。举个例子或者更形象，如果咱们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这显著是很低效的，齐全能够把这100条指令合并成一条SET指令，这就是重写机制的原理。
  • 在进行AOF重写时，依然是采纳先写临时文件，全副实现后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性。

优缺点

  • 长处：
  • 毛病：体积较大，数据长久慢

五、内存回收机制

1. 过期删除策略

  • 定时删除：对每一个设置了过期工夫的key都会创立一个定时器，一旦达到过期工夫就立刻删除。

    • 长处：可立刻革除过期的数据，对内存敌对
    • 毛病：占用了大量CPU资源去解决过期数据，会影响Redis的吞吐量和响应工夫。

  • 惰性删除：当拜访一个key时，才判断是否过期，过期则删除。

    • 长处：最大限度地节俭CPU资源。
    • 毛病：对内存非常不敌对，极其状况会呈现大量过期key没有被再次拜访，因而不会被革除，导致占用了大量的内存。

  • 定期删除：每隔一段时间，扫描redis中过期key字段，并革除局部过期的key。

    • 该策略是前两者的一个折中计划，还能够通过调整定时扫描的工夫距离和每次扫描的限定耗时，在不同状况下使得CPU和内存资源达到最优的均衡成果

    2. 内存淘汰策略

  • no-enviction（默认）：禁止驱赶数据。不会删除任何数据，回绝所有写入操作并返回客户端错误信息，此时Redis只响应读操作。
  • allkeys-lru：当内存不足以包容新写入数据时，在键空间（server.db[i].dict）中，移除最近起码应用的 key。
  • allkeys-random：在键空间（server.db[i].dict）中，随机移除某个 key。
  • volatile-lru：在设置了过期工夫的键空间（server.db[i].expires）中，移除最近起码应用的 key。
  • volatile-random：在设置了过期工夫的键空间（server.db[i].expires）中，随机移除某个 key。

  • volatile-ttl：在设置了过期工夫的键空间（server.db[i].expires）中，有更早过期工夫的 key 优先移除。

    注：

    lru：Least Recently Used，最近起码应用lfu：Least Frequently Used，最不常常应用

六、分布式锁

  1. 数据库乐观锁；
  2. 基于Redis的分布式锁；
  3. 基于ZooKeeper的分布式锁。

七、缓存穿透、雪崩、击穿

1. 缓存穿透

缓存穿透是指查问一个肯定不存在的数据，因为缓存不命中时须要从数据库查问，查不到数据则不写入缓存，这将导致这个不存在的数据每次申请都要到数据库去查问，造成缓存穿透。
解决办法：

  • 对所有可能查问的参数以hash模式存储，在管制层先进行校验，不合乎则抛弃。还有最常见的则是采纳布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个肯定不存在的数据会被这个bitmap拦挡掉，从而防止了对底层存储系统的查问压力。

  • 也能够采纳一个更为简略粗犷的办法，如果一个查问返回的数据为空（不论是数 据不存在，还是系统故障），咱们依然把这个空后果进行缓存，但它的过期工夫会很短，最长不超过五分钟。

2. 缓存雪崩

如果缓存集中在一段时间内生效，产生大量的缓存穿透，所有的查问都落在数据库上，造成了缓存雪崩。

解决办法：数据预热、缓存不过期、做二级缓存，或者双缓存策略

3. 缓存击穿

缓存在某个工夫点过期的时候，恰好在这个工夫点对这个Key有大量的并发申请过去，这些申请发现缓存过期个别都会从后端DB加载数据并回设到缓存，这个时候大并发的申请可能会霎时把后端DB压垮。

解决办法：应用互斥锁等