关于redis:Redis学习总结

一、数据类型

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 压垮。

解决办法：应用互斥锁等