redis体系

文件重写原理

AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似 

重写

（1）每修改同步always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好（2）每秒同步everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失（3）不同no：从不同步

触发机制

（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。（2）AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。（4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据 

优

（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大（2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的（3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。

劣

AOF

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止

执行完成时候如果存在老的RDB文件，就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万，这种方式显然不可取。

save

执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求

具体流程如下

具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令

bgsave

自动触发是由我们的配置文件来完成的。在redis.conf配置文件中

save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。默认如下配置：#表示900 秒内如果至少有 1 个 key 的值变化，则保存save 900 1#表示300 秒内如果至少有 10 个 key 的值变化，则保存save 300 10#表示60 秒内如果至少有 10000 个 key 的值变化，则保存save 60 10000不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能

自动触发

（1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。（2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据 

RDB

通常的指示是，如果您希望获得与PostgreSQL可以提供的功能相当的数据安全性，则应同时使用两种持久性方法。如果您非常关心数据，但是在灾难情况下仍然可以承受几分钟的数据丢失，则可以仅使用RDB。有很多用户单独使用AOF，但我们不建议这样做，因为不时拥有RDB快照对于进行数据库备份，加快重启速度以及AOF引擎中存在错误是一个好主意。注意：由于所有这些原因，我们将来可能会最终将AOF和RDB统一为一个持久性模型（长期计划）。                                                                                                                                                                                   ------引自官网

应该如何选择和平衡两种方式

redis官网-持久化

建议查看redis官网，持久化页面:https://redis.io/topics/persistence

Redis> = 2.4可以确保避免在RDB快照操作正在进行时触发AOF重写，或者在AOF重写正在进行时允许BGSAVE。这样可以防止两个Redis后台进程同时执行繁重的磁盘I / O。当进行快照时，用户使用BGREWRITEAOF显式请求日志重写操作时，服务器将以OK状态码答复，告知用户已计划该操作，并且快照完成后将开始重写。如果同时启用了AOF和RDB持久性，并且Redis重新启动，则AOF文件将用于重建原始数据集，因为它可以保证是最完整的。

AOF和RDB持久性之间的相互作用

在服务器中创建一个cron作业，在一个目录中创建RDB文件的每小时快照，在另一个目录中创建每日快照。每次运行cron脚本时，请确保调用find命令以确保删除太旧的快照：例如，您可以在最近的48小时内每小时拍摄一次快照，而在一个或两个月内每天拍摄一次。确保使用数据和时间信息命名快照。每天至少有一次确保将RDB快照传输到数据中心外部或至少传输到运行Redis实例的物理计算机外部。

备份Redis数据

持久化机制

哨兵

集群

和Mysql主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构

一主多从

从Redis 2.6开始，从服务器支持只读模式，并且是默认模式。这个行为是由Redis.conf文件中的slave-read-only 参数控制的，可以在运行中通过CONFIG SET来启用或者禁用。只读的从服务器会拒绝所有写命令，所以对从服务器不会有误写操作。但这不表示可以把从服务器实例暴露在危险的网络环境下，因为像DEBUG或者CONFIG这样的管理命令还是可以运行的。不过你可以通过使用rename-command命令来为这些命令改名来增加安全性。你可能想知道为什么只读限制还可以被还原，使得从服务器还可以进行写操作。虽然当主从服务器进行重新同步或者从服务器重启后，这些写操作都会失效，还是有一些使用场景会想从服务器中写入临时数据的，但将来这个特性可能会被去掉。

从服务器只读

读写分离

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下： - 从服务器连接主服务器，发送SYNC命令； - 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； - 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； - 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； - 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； - 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

全量同步

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

增量同步

主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步

Redis主从同步策略

1）Redis使用异步复制。但从Redis 2.8开始，从服务器会周期性的应答从复制流中处理的数据量。2）一个主服务器可以有多个从服务器。3）从服务器也可以接受其他从服务器的连接。除了多个从服务器连接到一个主服务器之外，多个从服务器也可以连接到一个从服务器上，形成一个 图状结构。4）Redis主从复制不阻塞主服务器端。也就是说当若干个从服务器在进行初始同步时，主服务器仍然可以处理请求。5）主从复制也不阻塞从服务器端。当从服务器进行初始同步时，它使用旧版本的数据来应对查询请求，假设你在redis.conf配置文件是这么配置的。 否则的话，你可以配置当复制流关闭时让从服务器给客户端返回一个错误。但是，当初始同步完成后，需要删除旧的数据集和加载新的数据集，在 这个短暂的时间内，从服务器会阻塞连接进来的请求。6）主从复制可以用来增强扩展性，使用多个从服务器来处理只读的请求（比如，繁重的排序操作可以放到从服务器去做），也可以简单的用来做数据冗余。7）使用主从复制可以为主服务器免除把数据写入磁盘的消耗：在主服务器的redis.conf文件中配置“避免保存”（注释掉所有“保存“命令），然后连接一个 置为“进行保存”的从服务器即可。但是这个配置要确保主服务器不会自动重启（要获得更多信息请阅读下一段）

注意事项

master服务器会开启一个后台进程用于将redis中的数据生成一个rdb文件，与此同时，服务器会缓存所有接收到的来自客户端的写命令（包含增、删、改），当后台保存进程处理完毕后，会将该rdb文件传递给slave服务器，而slave服务器会将rdb文件保存在磁盘并通过读取该文件将数据加载到内存，在此之后master服务器会将在此期间缓存的命令通过redis传输协议发送给slave服务器，然后slave服务器将这些命令依次作用于自己本地的数据集上最终达到数据的一致性。

全量同步：

从redis 2.8版本以前，并不支持部分同步，当主从服务器之间的连接断掉之后，master服务器和slave服务器之间都是进行全量数据同步，但是从redis 2.8开始，即使主从连接中途断掉，也不需要进行全量同步，因为从这个版本开始融入了部分同步的概念。部分同步的实现依赖于在master服务器内存中给每个slave服务器维护了一份同步日志和同步标识，每个slave服务器在跟master服务器进行同步时都会携带自己的同步标识和上次同步的最后位置。当主从连接断掉之后，slave服务器隔断时间（默认1s）主动尝试和master服务器进行连接，如果从服务器携带的偏移量标识还在master服务器上的同步备份日志中，那么就从slave发送的偏移量开始继续上次的同步操作，如果slave发送的偏移量已经不再master的同步备份日志中（可能由于主从之间断掉的时间比较长或者在断掉的短暂时间内master服务器接收到大量的写操作），则必须进行一次全量更新。在部分同步过程中，master会将本地记录的同步备份日志中记录的指令依次发送给slave服务器从而达到数据一致。

增量同步:

同步的大概实现

1）在上面的全量同步过程中，master会将数据保存在rdb文件中然后发送给slave服务器，但是如果master上的磁盘空间有效怎么办呢？那么此时全部同步对于master来说将是一份十分有压力的操作了。此时可以通过无盘复制来达到目的，由master直接开启一个socket将rdb文件发送给slave服务器。无盘复制一般应用在磁盘空间有限但是网络状态良好的情况下.2）主从复制结构，一般slave服务器不能进行写操作，但是这不是死的，之所以这样是为了更容易的保证主和各个从之间数据的一致性，如果slave服务器上数据进行了修改，那么要保证所有主从服务器都能一致，可能在结构上和处理逻辑上更为负责。不过你也可以通过配置文件让从服务器支持写操作。3）主从服务器之间会定期进行通话，但是如果master上设置了密码，那么如果不给slave设置密码就会导致slave不能跟master进行任何操作，所以如果你的master服务器上有密码，那么也给slave相应的设置一下密码吧（通过设置配置文件中的masterauth）;4）关于slave服务器上过期键的处理，由master服务器负责键的过期删除处理，然后将相关删除命令已数据同步的方式同步给slave服务器，slave服务器根据删除命令删除本地的key。

在进行主从复制设置时，强烈建议在主服务器上开启持久化，当不能这么做时，比如考虑到延迟的问题，应该将实例配置为避免自动重启。 为什么不持久化的主服务器自动重启非常危险呢？为了更好的理解这个问题，看下面这个失败的例子，其中主服务器和从服务器中数据库都被删除了。 设置节点A为主服务器，关闭持久化，节点B和C从节点A复制数据。这时出现了一个崩溃，但Redis具有自动重启系统，重启了进程，因为关闭了持久化，节点重启后只有一个空的数据集。节点B和C从节点A进行复制，现在节点A是空的，所以节点B和C上的复制数据也会被删除。当在高可用系统中使用Redis Sentinel，关闭了主服务器的持久化，并且允许自动重启，这种情况是很危险的。比如主服务器可能在很短的时间就完成了重启，以至于Sentinel都无法检测到这次失败，那么上面说的这种失败的情况就发生了。如果数据比较重要，并且在使用主从复制时关闭了主服务器持久化功能的场景中，都应该禁止实例自动重启。

当主服务器不进行持久化时复制的安全性

问题延伸

同步策略

主从复制

hash 哈希

string 字符串

set 集合

list 列表

zset 有序集合

HyperLogLog 基数统计

六种数据类型

线程锁：主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如synchronized是共享对象头，显示锁Lock是共享某个变量（state）。进程锁：为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。分布式锁：当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。

概念

线程间并发问题和进程间并发问题都是可以通过分布式锁解决的，但是强烈不建议这样做！因为采用分布式锁解决这些小问题是非常消耗资源的！分布式锁应该用来解决分布式情况下的多进程并发问题才是最合适的。有这样一个情境，线程A和线程B都共享某个变量X。如果是单机情况下（单JVM），线程之间共享内存，只要使用线程锁就可以解决并发问题。如果是分布式情况下（多JVM），线程A和线程B很可能不是在同一JVM中，这样线程锁就无法起到作用了，这时候就要用到分布式锁来解决。

使用场景

分布式锁实现的关键是在分布式的应用服务器外，搭建一个存储服务器，存储锁信息，这时候我们很容易就想到了Redis。首先我们要搭建一个Redis服务器，用Redis服务器来存储锁信息。

1、锁信息必须是会过期超时的，不能让一个线程长期占有一个锁而导致死锁；2、同一时刻只能有一个线程获取到锁。

关键点

redis命令

分布式锁的实现（Redis）

分布式锁

常用命令

一个存在的key，在缓存过期的一刻(使用缓存 + 过期时间的策略既可以加速数据读写，又保证数据的定期更新)，同时有大量的线程重建缓存(构建缓存慢 造成另一线程判断时缓存取值为null)，这些线程都会击穿到DB，造成瞬时DB请求量大、压力骤增。甚至可能会让应用崩溃

互斥锁

从缓存的角度来看，如果你设置了永远不过期，那么就不会有海量请求数据库的情形出现。此时我们一般通过新起一个线程的方式去定时将数据库中的数据更新到缓存中，更加成熟的方式是通过定时任务去同步缓存和数据库的数据。但这种方案会出现数据的延迟问题，也就是线程读取到的数据并不是最新的数据。但对于一般的互联网功能来说，些许的延迟还是能接受的。

永远不过期

解决方案

缓存击穿

大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩

产生雪崩的原因之一，比如马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。

做电商项目的时候，一般是采取不同分类商品，缓存不同周期。在同一分类中的商品，加上一个随机因子。这样能尽可能分散缓存过期时间，而且，热门类目的商品缓存时间长一些，冷门类目的商品缓存时间短一些，也能节省缓存服务的资源。

其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，那么那个时候数据库能顶住压力，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。

解释

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

业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，类似于自旋锁，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

加锁排队. 限流

可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀

数据预热

A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。

做二级缓存，或者双缓存策略

这里的“永远不过期”包含两层意思： (1) 从缓存上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。 (2) 从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期. 从实战看，这种方法对于性能非常友好，唯一不足的就是构建缓存时候，其余线程(非构建缓存的线程)可能访问的是老数据，但是对于一般的互联网功能来说这个还是可以忍受。

缓存永远不过期

 解决方案

缓存雪崩

缓存穿透，是指查询一个数据库一定不存在的数据。

正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。想象一下这个情况，如果传入的参数为-1，会是怎么样？这个-1，就是一定不存在的对象。就会每次都去查询数据库，而每次查询都是空，每次又都不会进行缓存。假如有恶意攻击，就可以利用这个漏洞，对数据库造成压力，甚至压垮数据库。即便是采用UUID，也是很容易找到一个不存在的KEY，进行攻击。

对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。还有最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。在击穿缓存时，先查一下布隆过滤器，如果不存在，则不查db，一定程度保护了db层

可以用来实现数据字典，进行数据的判重，或者集合求交集

基本原理及要点：对于原理来说很简单，位数组+k个独立hash函数。将hash函数对应的值的位数组置1，查找时如果发现所有hash函数对应位都是1说明存在，很明显这个过程并不保证查找的结果是100%正确的。同时也不支持删除一个已经插入的关键字，因为该关键字对应的位会牵动到其他的关键字。所以一个简单的改进就是counting Bloom filter，用一个counter数组代替位数组，就可以支持删除了。添加时增加计数器，删除时减少计数器。

适用范围

布隆过滤

第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间(最长不超过五分钟)，让其自动剔除。 第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

缓存空对象. 将 value设为null

缓存穿透

网站访问数据的特点大多数呈现在\"二八定律\":80%的业务访问集中在20%的数据上。这时为了减轻数据的压力和提高网站的数据访问速度，则可以使用缓存机制来优化网站。

二八定律

比如网站的用户总数就是一个小而热的数据，但是比如每个用户的个人轨迹信息就是一个量大但是还冷热不均的数据，防止数据无限膨胀，所以用户缓存放到内存中都要设立过期时间。比如，论坛的最新发表列表，最新报名列表，包括比如最新激活的用户可以存在redis做最新列表的使用方式。redis 一定要用在小而热的情况，防止数据的无限膨胀。

基于redis做冷热分离从技术上是可行的，从业务实用角度看却不一定。因为首先redis不能很好区分冷热数据，然后很难避免读取落地冷数据时的性能问题，因此肯定不如纯内存的redis性能好，而用户对KV数据库性能的期望是没有最好，只有更好。随着内存越来越大、越来越便宜，更多的数据可以直接放到redis内存，会进一步导致冷热分离成为一个无人使用的鸡肋功能。

建议

热数据和冷数据

缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统，刷新过期时间。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！ 缓存预热解决方案：（1）直接写个缓存刷新页面，上线时手工操作下；（2）数据量不大，可以在项目启动的时候自动进行加载；（3）定时刷新缓存；

缓存预热

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：（1）定时去清理过期的缓存；（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

缓存更新

核心就是弃车保帅，保证核心服务可用，降级可以丢弃的服务，可以让程序实施自动降级，也可以人工紧急降级。

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

缓存降级

Redis缓存淘汰策略与Redis键的过期删除策略并不完全相同，前者是在Redis内存使用超过一定值的时候（一般这个值可以配置）使用的淘汰策略；而后者是通过定期删除+惰性删除两者结合的方式进行内存淘汰的。这里参照官方文档的解释重新叙述一遍过期删除策略：当某个key被设置了过期时间之后，客户端每次对该key的访问（读写）都会事先检测该key是否过期，如果过期就直接删除； 但有一些键只访问一次，无法在访问该key时，去判断是否过期进行删除，因此需要主动删除，默认情况下redis每秒检测10次，检测的对象是所有设置了过期时间的键集合，每次从这个集合中随机检测20个键查看他们是否过期，如果过期就直接删除，如果删除后还有超过25%的集合中的键已经过期，那么继续检测过期集合中的20个随机键进行删除。这样可以保证过期键最大只占所有设置了过期时间键的25%。

noeviction：当内存使用超过配置的时候会返回错误，不会驱逐任何键allkeys-lru：加入键的时候，如果过限，首先通过LRU算法驱逐最久没有使用的键volatile-lru：加入键的时候如果过限，首先从设置了过期时间的键集合中驱逐最久没有使用的键allkeys-random：加入键的时候如果过限，从所有key随机删除volatile-random：加入键的时候如果过限，从过期键的集合中随机驱逐volatile-ttl：从配置了过期时间的键中驱逐马上就要过期的键volatile-lfu：从所有配置了过期时间的键中驱逐使用频率最少的键allkeys-lfu：从所有键中驱逐使用频率最少的键

ZERO、Redis内存不足的缓存淘汰策略

在Java中LRU的实现方式是使用HashMap结合双向链表，HashMap的值是双向链表的节点，双向链表的节点也保存一份key value。新增key value的时候首先在链表结尾添加Node节点，如果超过LRU设置的阈值就淘汰队头的节点并删除掉HashMap中对应的节点。修改key对应的值的时候先修改对应的Node中的值，然后把Node节点移动队尾。访问key对应的值的时候把访问的Node节点移动到队尾即可。

Java中的LRU实现方式

Redis维护了一个24位时钟，可以简单理解为当前系统的时间戳，每隔一定时间会更新这个时钟。每个key对象内部同样维护了一个24位的时钟，当新增key对象的时候会把系统的时钟赋值到这个内部对象时钟。比如我现在要进行LRU，那么首先拿到当前的全局时钟，然后再找到内部时钟与全局时钟距离时间最久的（差最大）进行淘汰，这里值得注意的是全局时钟只有24位，按秒为单位来表示才能存储194天，所以可能会出现key的时钟大于全局时钟的情况，如果这种情况出现那么就两个相加而不是相减来求最久的key。

Redis中LRU的实现

Redis中的LRU与常规的LRU实现并不相同，常规LRU会准确的淘汰掉队头的元素，但是Redis的LRU并不维护队列，只是根据配置的策略要么从所有的key中随机选择N个（N可以配置）要么从所有的设置了过期时间的key中选出N个键，然后再从这N个键中选出最久没有使用的一个key进行淘汰。

redis算法差别

LRU

LFU是在Redis4.0后出现的，LRU的最近最少使用实际上并不精确，考虑下面的情况，如果在|处删除，那么A距离的时间最久，但实际上A的使用频率要比B频繁，所以合理的淘汰策略应该是淘汰B。LFU就是为应对这种情况而生的。

A~~A~~A~~A~~A~~A~~A~~A~~A~~A~~~|B~~~~~B~~~~~B~~~~~B~~~~~~~~~~~B |

LFU把原来的key对象的内部时钟的24位分成两部分，前16位还代表时钟，后8位代表一个计数器。16位的情况下如果还按照秒为单位就会导致不够用，所以一般这里以时钟为单位。而后8位表示当前key对象的访问频率，8位只能代表255，但是redis并没有采用线性上升的方式，而是通过一个复杂的公式，通过配置两个参数来调整数据的递增速度。

下图从左到右表示key的命中次数，从上到下表示影响因子，在影响因子(越大计数器改变越慢)为100的条件下，经过10M次命中才能把后8位值加满到255.

lfu-log-factor 10lfu-decay-time 1

# +--------+------------+------------+------------+------------+------------+# | factor | 100 hits | 1000 hits | 100K hits | 1M hits | 10M hits |# +--------+------------+------------+------------+------------+------------+# | 0 | 104 | 255 | 255 | 255 | 255 |# +--------+------------+------------+------------+------------+------------+# | 1 | 18 | 49 | 255 | 255 | 255 |# +--------+------------+------------+------------+------------+------------+# | 10 | 10 | 18 | 142 | 255 | 255 |# +--------+------------+------------+------------+------------+------------+# | 100 | 8 | 11 | 49 | 143 | 255 |# +--------+------------+------------+------------+------------+------------+

上面说的情况是key一直被命中的情况，如果一个key经过几分钟没有被命中，那么后8位的值是需要递减的，具体递减多少根据衰减因子lfu-decay-time来控制

上面递增和衰减都有对应参数配置，那么对于新分配的key呢？如果新分配的key计数器开始为0，那么很有可能在内存不足的时候直接就给淘汰掉了，所以默认情况下新分配的key的后8位计数器的值为5（可配置），防止因为访问频率过低而直接被删除。

低8位我们描述完了，那么高16位的时钟是用来干嘛的呢？目前我的理解是用来衰减低8位的计数器的，就是根据这个时钟与全局时钟进行比较，如果过了一定时间（做差）就会对计数器进行衰减

实现

LFU

在配置文件有一行：# maxmemory-policy volatile-lru

配置

具体实现在evict.c文件中，当redis需要通过释放缓存的key来释放空间时，将会通过ecict.c的freeMemoryIfNeeded()函数来通过设定的算法来清除key以腾出空间。

缓存淘汰策略LRU与LFU

缓存问题的名词解释

MemCache

MongoDB

与其他缓存系统的差异

可用性

一致性

容错性

CAP原则

与传统关系型数据库差异

标记一个事务块的开始

MULTI

执行所有事务块内的命令

EXEC

取消事务，放弃执行事务块内的所有命令。

DISCARD

取消 WATCH 命令对所有 key 的监视

UNWATCH

监视一个(或多个) key ，如果在事务执行（EXEC）之前这个(或这些) key 被其他命令所改动，那么事务将被打断

一旦执行了EXEC，之前加的监控锁都会失效

相当于java锁机制，乐观锁

\tWATCH key [key ...]

开始事务

命令入队

执行事务

事务经历阶段

编译(语法错误)时出错，那么全部失败（回滚）

执行时有错误，那么继续执行，失败的失效

好处:使得Redis内部更加简单，而且运行速度更快

只支持部分事务

金融

批量

应用场景

事务

无法取代其他专门做消息中间件的地位

订阅一个或多个符合给定模式的频道。

PSUBSCRIBE pattern [pattern ...]

查看订阅与发布系统状态。

PUBSUB subcommand [argument [argument ...]]

将信息发送到指定的频道。

PUBLISH channel message

退订所有给定模式的频道。

PUNSUBSCRIBE [pattern [pattern ...]]

订阅给定的一个或多个频道的信息。

SUBSCRIBE channel [channel ...]

指退订给定的频道。

UNSUBSCRIBE [channel [channel ...]]

发布订阅(了解即可)

jedis就是集成了redis的一些命令操作，封装了redis的java客户端。提供了连接池管理。一般不直接使用jedis，而是在其上再封装一层，作为业务的使用

定义

连接池自动管理，提供了一个高度封装的“RedisTemplate”类

提供了对key的“bound”(绑定)便捷化操作API，可以通过bound封装指定的key，然后进行一系列的操作而无须“显式”的再次指定Key，即BoundKeyOperations

将事务操作封装，有容器控制

针对数据的“序列化/反序列化”，提供了多种可选择策略(RedisSerializer)

关于spring-redis

RedisTemplate

Jedis

如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据

问题焦点

在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。具体步骤是： 1）先删除缓存 2）再写数据库 3）休眠500毫秒（根据具体的业务时间来定） 4）再次删除缓存。那么，这个500毫秒怎么确定的，具体该休眠多久呢？ 需要评估自己的项目的读数据业务逻辑的耗时。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。 当然，这种策略还要考虑 redis 和数据库主从同步的耗时。最后的写数据的休眠时间：则在读数据业务逻辑的耗时的基础上，加上几百ms即可。比如：休眠1秒。

延时双删策略

先操作 Redis，再操作数据库

1、不做任何操作，等着Redis里的缓存数据过期后，自动从数据库同步最新的数据，此时最严重的数据不一致性周期就是在缓存过期的一段时间（考虑一下这个过期时间的范围）；如果在这个时间段内，又有新的更新请求，也许这次就更新缓存成功了。2、如果数据一致性要求比较高，那么 Redis 操作失败后，我们把这个操作记录下来，异步处理，用 Redis 的数据去和数据库比对，如果不一致，再次更新缓存确保缓存数据与数据库数据一致。

先操作数据库，再操作 Redis

最终一致性的解决方案

所有的写操作以数据库为准，只要到达缓存过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存

设置缓存的过期时间

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。

因果一致性。

当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。

读己之所写（read-your-writes）”一致性。

这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。

会话（Session）一致性。

如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。

单调（Monotonic）读一致性。

系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

单调写一致性。

最终一致性细分

强一致性、弱一致性、最终一致性

数据一致性

假设我们查找的是”a.png”，由于有4台服务器（排除从库），因此公式为hash(a.png) % 4 = 2 ，可知定位到了第2号服务器，这样的话就不会遍历所有的服务器，大大提升了性能！

示例

上述的方式虽然提升了性能，我们不再需要对整个Redis服务器进行遍历！但是，使用上述Hash算法进行缓存时，会出现一些缺陷，主要体现在服务器数量变动的时候，所有缓存的位置都要发生改变！试想一下，如果4台缓存服务器已经不能满足我们的缓存需求，那么我们应该怎么做呢？很简单，多增加几台缓存服务器不就行了！假设：我们增加了一台缓存服务器，那么缓存服务器的数量就由4台变成了5台。那么原本hash(a.png) % 4 = 2 的公式就变成了 hash(a.png) % 5 =？

一致性Hash算法也是使用取模的方法，只是，刚才描述的取模法是对服务器的数量进行取模，而一致性Hash算法是对2^ 32-1取模，什么意思呢简单来说，一致性Hash算法将整个Hash值控件组织成一个虚拟的圆环，如假设某哈希函数H的值空间为0-2^32-1取模（即哈希值是一个32位无符号整型）

整个空间按顺时针方向组织，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、5、6……直到2^ 32-1，也就是说0点左侧的第一个点代表2^ 32-1， 0和2^ 32-1在零点中方向重合，我们把这个由2^32个点组成的圆环称为Hash环。下一步将各个服务器使用Hash进行一个哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置

接下来使用如下算法定位数据访问到相应服务器：将数据key使用相同的函数Hash计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器！

过程

现假设Node C不幸宕机，可以看到此时对象A、B、D不会受到影响，只有C对象被重定位到Node D。一般的，在一致性Hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器，如下图中NodeC与NodeB之间的数据，图中受影响的是ObjectC）之间数据，其它不会受到影响

下面考虑另外一种情况，如果在系统中增加一台服务器Node X

此时对象Object A、B、D不受影响，只有对象C需要重定位到新的Node X ！一般的，在一致性Hash算法中，如果增加一台服务器，则受影响的数据仅仅是新服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它数据也不会受到影响。

综上所述，一致性Hash算法对于节点的增减都只需重定位环空间中的一小部分数据，具有较好的容错性和可扩展性。

一致性Hash算法的容错性和可扩展性

一致性Hash算法在服务节点太少时，容易因为节点分部不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）问题，例如系统中只有两台服务器

此时必然造成大量数据集中到Node A上，而只有极少量会定位到Node B上。为了解决这种数据倾斜问题，一致性Hash算法引入了虚拟节点机制，即对每一个服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。具体做法可以在服务器IP或主机名的后面增加编号来实现。

可以为每台服务器计算三个虚拟节点，于是可以分别计算 “Node A#1”、“Node A#2”、“Node A#3”、“Node B#1”、“Node B#2”、“Node B#3”的哈希值，于是形成六个虚拟节点

同时数据定位算法不变，只是多了一步虚拟节点到实际节点的映射，例如定位到“Node A#1”、“Node A#2”、“Node A#3”三个虚拟节点的数据均定位到Node A上。这样就解决了服务节点少时数据倾斜的问题。在实际应用中，通常将虚拟节点数设置为32甚至更大，因此即使很少的服务节点也能做到相对均匀的数据分布

Hash环的数据倾斜问题

一致性hash算法的神秘面纱

解决

为Redis集群使用Hash

Redis集群

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

优势

EVAL script numkeys key [key ...] arg [arg ...]

其中：<1> script： 你的lua脚本<2> numkeys: key的个数<3> key: redis中各种数据结构的替代符号<4> arg: 你的自定义参数

eval \

示例1

keys.lua脚本文件

执行语句和结果

示例2:执行Lua脚本文件的方式

eval的语法格式

LUA脚本

redis