Spring集成了redis缓存，并以注解的形式使用（@Cacheable、@CachePut、@CacheEvict）

Redis超详细介绍

redis是一个用C语言编写的开源Key-Value数据库，支持网络交互，可以是基于内存的，也可以是持久化的。

【redis数据结构-简介】redis是一个高级的key:value存储系统，其中value支持五种数据类型：

1. 字符串 2. 字符串列表 3. 字符串集 4. 排序集 5. 哈希

关于按键，有几点提醒大家：

1、key不要太长，尽量不要超过1024字节，这样不仅消耗内存，而且会降低查找效率； 2、按键不宜太短，太短会降低按键的可读性； 3、在一个项目中，key最好使用统一的命名模式，如user:10000:passwd。

【谈谈redis持久化——两种方式】

Redis提供了两种持久化方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。

RDB，简而言之，就是将redis中存储的数据在不同时间点生成快照，并存储在磁盘等介质上；

AOF从另一个角度实现了持久化，即记录了redis执行的所有写指令。 当redis下次重启时，只需从前往后再次执行这些写入指令即可实现数据。 恢复正常。

其实RDB和AOF方法也可以同时使用。 这种情况下，如果重启redis，会优先使用AOF方式进行数据恢复。 这是因为AOF方法的数据恢复完整性更高。

如果没有数据持久化需求，可以完全关闭RDB和AOF方式。 这样的话，redis就会变成一个纯内存数据库，就像memcache一样。

【聊聊redis持久化——RDB】

RDB方式将Redis某一时刻的数据持久化到磁盘上。 它是一种快照持久化方法。

在数据持久化的过程中，redis首先会将数据写入到临时文件中。 持久化过程完成后，该临时文件将用于替换上次持久化的文件。 正是这个功能让我们可以随时进行备份，因为快照文件始终是完全可用的。

对于RDB模式，redis会创建（fork）一个单独的子进程进行持久化，主进程不会执行任何IO操作，从而保证了redis极高的性能。

如果需要大规模数据恢复，并且数据恢复的完整性不是很敏感，那么RDB方法比AOF方法效率更高。

尽管RDB有很多优点，但它的缺点也不容忽视。 如果你对数据完整性非常敏感，那么RDB方式就不适合你，因为即使你每5分钟持久化一次，当redis出现故障时，仍然会有近5分钟的数据丢失。 因此，redis还提供了另一种持久化方式spring memcache 整合，那就是AOF。

【聊聊redis持久化——AOF】

AOF，英文是Append Only File，意思是只允许追加不可重写的文件。

前面介绍过，AOF方法会记录执行过的写指令，然后在数据恢复时按照从前到后的顺序再次执行它们。 它是如此简单。

我们可以通过在redis.conf中配置appendonly yes来开启AOF功能。 如果有写操作（如SET等），redis会追加到AOF文件的末尾。

默认的AOF持久化策略是每秒fsync一次（fsync是指将缓存中的写入指令记录到磁盘中），因为在这种情况下，即使redis出现故障，redis仍然可以保持良好的处理性能。 只有最后1秒的数据会丢失。

如果追加日志时，磁盘空间满了，inode满了，或者停电了，导致日志写入不完整，也没有关系。 Redis提供了redis-check-aof工具，可以用来修复日志。

因为是append方式，如果不做处理的话，AOF文件会变得越来越大。 为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过设定的阈值时，redis就会开始对AOF文件进行内容压缩，只保留能够恢复的最小指令集数据。 例如，可能会更生动。 如果我们调用INCR指令100次，那么AOF文件中就会存储100条指令，但这显然是非常低效的。 这100条指令可以合并为一条SET指令。 这就是重写机制的原理。

在重写AOF时，我们仍然采用先写入临时文件，等全部完成后再替换的流程。 因此，断电、磁盘满等问题不会影响AOF文件的可用性。 这点你可以放心。

AOF 方法的另一个好处是通过“场景再现”来解释的。 有同学在操作redis时，不小心执行了FLUSHALL，导致redis内存中的数据全部被清空。 这是一件非常悲惨的事情。 但这并不是世界末日。 只要redis配置了AOF持久，并且AOF文件没有被重写，我们就可以暂停redis并尽快编辑AOF文件，删除FLUSHALL命令的最后一行。 ，然后重新启动redis，就可以将redis中的所有数据恢复到FLUSHALL之前的状态。 是不是很神奇呢？ 这是 AOF 持久化的好处之一。 但如果AOF文件已被覆盖，则无法通过此方法恢复数据。

虽然有很多优点，但是 AOF 方法也有缺点。 例如，相同数据大小下，AOF文件比RDB文件大。 而且AOF方法的恢复速度也比RDB方法慢。

如果直接执行 BGREWRITEAOF 命令，redis 将生成一个全新的 AOF 文件，其中包含可以恢复现有数据的最小命令集。

如果你运气不好，AOF 文件损坏了，也不必太担心。 Redis不会贸然加载有问题的AOF文件，而是会报错退出。 此时，您可以通过以下步骤修复有问题的文件：

1. 备份损坏的 AOF 文件 2. 运行 redis-check-aof –fix 进行修复 3. 使用 diff -u 查看两个文件的差异，确认问题 4. 重新启动 redis 并加载修复后的 AOF 文件

【浅谈redis持久化——AOF重写】

我们需要了解AOF重写的内部工作原理。

当重写即将开始时，redis会创建（fork）一个“重写子进程”。 该子进程将首先读取现有的 AOF 文件，分析并压缩其中包含的指令，并将它们写入文件中的临时文件中。

同时，主工作进程会将新接收到的写入指令累积到内存缓冲区中，同时继续写入到原来的 AOF 文件中。 这保证了原始 AOF 文件的可用性并避免重复尝试。 写的时候发生了一件意想不到的事情。

当“重写子进程”完成重写工作时，它会向父进程发送信号。 父进程收到信号后，会将内存中缓存的写指令追加到新的AOF文件中。

当追加完成后，redis 会用新的 AOF 文件替换旧的 AOF 文件。 之后，任何新的写入指令都将附加到新的 AOF 文件中。

【聊聊redis持久化——RDB和AOF如何选择】

至于我们应该选择RDB还是AOF，官方建议是同时使用两者。 这提供了更可靠的持久性解决方案。

【说说master和slave——用法】

和MySQL一样，redis支持主从同步，也支持一主多从、多级从结构。

主从结构一是为了纯冗余备份，二是为了提高读性能。 例如，消耗性能的SORT可以由从服务器来承担。

redis的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低redis的处理性能。

在主从架构中，可以考虑关闭主服务器的数据持久化功能，只允许从服务器持久化。 这样可以提高主服务器的处理性能。

在主从架构中，从服务器通常设置为只读模式，以防止从服务器的数据被意外修改。 但从服务器仍然可以接受CONFIG等命令，因此从服务器不应该直接暴露在不安全的网络环境中。 如果有必要，请考虑重命名重要指令，以防止它们被外人错误执行。

【说说主从-同步原理】

从服务器将向主服务器发出SYNC命令。 当主服务器收到这个命令时spring memcache 整合，会调用BGSAVE命令创建一个专门用于数据持久化的子进程，即将主服务器的数据写入RDB文件中。 数据持久化时，主服务器执行的写指令会缓存在内存中。

执行BGSAVE指令后，主服务器会将持久化的RDB文件发送给从服务器。 从服务器收到文件后，将其存储在磁盘上，然后将其读入内存。 该动作完成后，主服务器会将这段时间缓存的写指令以redis协议的格式发送给从服务器。

另外，需要注意的一点是，即使多个从服务器同时发送SYNC命令，主服务器也只会执行一次BGSAVE，然后将持久化的RDB文件发送到多个下游。 redis 2.8版本之前，如果从服务器和主服务器由于某种原因断开连接，主从之间会进行全量数据同步； 2.8版本之后，redis支持更高效的增量。 同步策略，大大降低了断开连接的恢复成本。

主服务器在内存中维护一个缓冲区，用于存储要发送到从服务器的内容。 当从服务器与主服务器发生网络中断后，从服务器会再次尝试连接主服务器。 连接成功后，从服务器会将“要同步的主服务器ID”和“要请求的数据的偏移位置（复制偏移）”发送出去，主服务器收到后一个同步请求，它会首先验证主服务器ID是否与自己的ID匹配，其次检查自己的缓冲区中是否存在“请求的偏移位置”，如果两者都满足，主服务器就会向主服务器发送增量内容从服务器。

增量同步功能要求服务器支持新的PSYNC命令。 该命令仅在redis-2.8之后可用。

【说说redis事务处理】

众所周知，事务是指“一个完整的动作，要么全部执行，要么什么都不做”。

在讲redis事务处理之前，先给大家介绍一下redis的四个指令，分别是MULTI、EXEC、DISCARD、WATCH。 这四个指令构成了redis事务处理的基础。

1.MULTI用于组装一笔交易； 2.EXEC用于执行事务； 3.DISCARD用于取消一笔交易； 4.WATCH用于监控一些按键。 一旦在交易执行之前这些密钥被更改，交易就会被取消。 实施。

纸上谈兵很容易理解，我们看一个MULTI和EXEC的例子：

redis> MULTI //标记事务开始 OKredis> INCR user_id //多个命令按顺序排队 QUEUEDredis> INCR user_idQUEUEDredis> INCR user_idQUEUEDredis> PINGQUEUEDredis> EXEC //执行 1) (integer) 12) (integer) 23) (integer) 34 ) 乒乓球

在上面的例子中，我们看到了QUEUED这个词，这意味着当我们使用MULTI组装一个事务时，每个命令都会进入内存队列并被缓存。 如果出现QUEUED，说明我们的命令已经成功插入到缓存队列中了。 以后执行EXEC时，这些QUEUED命令会被组装成一个事务来执行。

对于事务的执行，如果redis开启了AOF持久化，那么一旦事务执行成功，事务中的命令就会通过write命令一次性写入磁盘。 如果恰好是在写入磁盘的过程中，遇到断电、硬件故障等问题，有可能只用AOF持久化了部分命令，导致AOF文件不完整。 这时候我们就可以使用redis-check-aof工具来修复这个问题。 问，这个工具会去除AOF文件中不完整的信息，保证AOF文件完整可用。

关于事务，我们经常会遇到两类错误：

1. 调用 EXEC 前出错 2. 调用 EXEC 后出错

“Error before Calling EXEC”可能是由于语法不正确或内存不足引起的。 每当一个命令未能成功写入缓冲队列时，redis就会记录下来。 当客户端调用EXEC时，redis将拒绝执行事务。 （这是2.6.5版本之后的策略，2.6.5之前的版本，redis会忽略入队失败的命令，只执行入队成功的命令）。 让我们看一个例子：

127.0.0.1:6379> multiOK127.0.0.1:6379> haha​​ ​​//一个明显错误的命令（错误）ERRknown command 'haha'127.0.0.1:6379> pingQUEUED127.0.0.1:6379> exec//redis无情的 EXECABORT 事务因为之前的错误而被丢弃。

对于“调用EXEC后出现错误”，redis采取了完全不同的策略，即redis会忽略这些错误，继续执行事务中的其他命令。 这是因为应用层面的错误并不是redis本身需要考虑和处理的问题，所以如果某个命令在事务中执行失败，也不会影响后续其他命令的执行。 我们还看一个例子：

127.0.0.1:6379> multiOK127.0.0.1:6379> set Age 23QUEUED//age不是一个集合，所以下面是一个明显错误的命令 127.0.0.1:6379> Sadd Age 15 QUEUED127.0.0.1:6379> setage 29QUEUED127.0.0.1:6379> exec //执行事务时，redis不会忽略第二条指令执行 error1) OK2) (error) WRONGTYPE 针对持有错误类型值的键进行操作3) OK127.0.0.1 : 6379> get Age"29" //可见第三条指令执行成功

好吧，我们来谈谈最后一条指令“WATCH”。 这是一个非常有用的指令。 它可以帮助我们实现类似于“乐观锁”的效果，即CAS（检查和设置）。

WATCH本身的功能就是“监控某个key是否被修改”，并且支持同时监控多个key。 只要交易没有真正被触发，WATCH就会勤奋地监控。 一旦发现某个键被修改，执行EXEC时就会对其进行监控。 会返回nil，表示交易无法触发。

127.0.0.1:6379> set Age 23OK127.0.0.1:6379> watch Age //开始监控ageOK127.0.0.1:6379> set Age 24 //在EXEC之前，修改了age的值 OK127.0.0.1 : 6379> multiOK127.0.0.1:6379> setage 25QUEUED127.0.0.1:6379> getageQUEUED127.0.0.1:6379> exec //触发 EXEC(nil) //事务无法执行

【手把手教你读懂redis配置-简介】redis配置文件分为几大区域，分别是：

1. General 2. Snapshotting 3. Replication 4. Security 5. Limits 6. Append only mode 7. LUA scripting 8. Slow Log（慢日志） 9. Event notification（事件通知）