Redis注意事项

1、Redis3.0没有虚拟内存概念，已从2.4就移除；

2、redis挂掉并重启时，如果有主从备份的，主机挂掉重启时先关掉主从备份，不然从机的数据会被冲洗掉

数据恢复时如果有 AOF（原理是将Reids的操作日志以追加的方式写入文件）和 RDB（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化）的，则从 AOF 恢复，若只有 RDB 的，只从 RDB 恢复。

RDB存在哪些优势呢

1)、一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

2)、对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3)、性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

4)、相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB又存在哪些劣势呢

1)、如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2)、由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF的优势有哪些呢？

1)、该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了三种同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。

2)、由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

3)、如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4)、AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的劣势有哪些呢？

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

3、保存快照需要注意频率，好像没有指明什么方式save，是save还是bgsave；

4、redis指明使用多少内存比较好？

5、删除策略：

（1）过期策略

• 定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
• 惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
• 定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
  (expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)

　　Redis中同时使用了惰性过期和定期过期两种过期策略。

（2）内存淘汰机制

在redis.conf中有一行配置，用于配内存淘汰策略的

maxmemory-policy volatile-lru

1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。应该没人用吧。
2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。推荐使用，目前项目在用这种。
3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。应该也没人用吧，你不删最少使用Key，去随机删。
4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。这种情况一般是把redis既当缓存，又做持久化存储的时候才用。不推荐
5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。依然不推荐
6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。不推荐
ps：如果没有设置 expire 的 key，不满足先决条件(prerequisites)；那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为，和 noeviction(不删除) 基本上一致。

6、事务，没有回滚：只有当被调用的Redis命令有语法错误时，这条命令才会执行失败（在将这个命令放入事务队列期间，Redis能够发现此类问题），或者对某个键执行不符合其数据类型的操作：实际上，这就意味着只有程序错误才会导致Redis命令执行失败，这种错误很有可能在程序开发期间发现，一般很少在生产环境发现。Redis已经在系统内部进行功能简化，这样可以确保更快的运行速度，因为Redis不需要事务回滚的能力。

>>>multi，exec，watch（监控某个key，在watch监控mykey的过程中，mykey被修改了，所以随后的事务便会被取消），discard，unwatch

批量操作在发送 EXEC 命令前被放入队列缓存，收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。

watch无法阻止key被其他客户端修改，只能使本地的事务失败。

7、惊群效应：在并发量比较大的情况下，当一个缓存数据失效之后会导致同时有多个并发线程去向后端数据库发起请求去获取同一业务数据，这样如果在一段时间内同时生成了大量的缓存，然后在另外一段时间内又有大量的缓存失效，这样就会导致后端数据库的压力陡增，这种现象就可以称为“缓存过期产生的惊群现象”。

处理逻辑：

　　缓存内真实失效时间time1

　　缓存value中存放人为失效时间戳 ：time2 （ time2 永远小于time1）

　　缓存value对应的lock锁（就是一个与value 对应的 另一个key），主要用于判断是第几个线程来读取redis的value

　　当把数据库的数据写入缓存后，这时有客户端第一次来读取缓存，取当前系统时间:system_time 如果system_time >= time2  则认为默认缓存已过期（如果system_time< time1 则还没真实失效 ），这时再获取value的lock锁，调用redis的incr函数（单线程自增函数）判断是第几个获取锁的线程，当且仅当是第一个线程时返回1，以后都逐渐递增。第一个访问的线程到数据库中获取最新值重新放入缓存并删除lock锁的key，并重新设置时间戳；在删除lock之前所有访问value客户端线程获取lock的value都大于1，这些线程仍然读取redis中的旧值，而不会集中访问数据库。

8、redis 集群：

Redis仅支持单实例，内存一般最多10~20GB。对于内存动辄100~200GB的系统，就需要通过集群来支持了。

Redis集群有三种方式：客户端分片、代理分片、RedisCluster

9、缓存与数据库不一致：

1、写数据前后都del key，且设置缓存时间短些

2、监控mysql的binlog，异步删除key

3、缓存操作失败时需要重试，放入消息队列，实在不行报警

10、5种数据类型