Redis相关知识

Redis相关知识

1.redis的持久化
redis的持久化总共有两种RDB，AOF
RDB是Redis默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，
则会将内存中的数据写入次盘中，即在指定目录生成一个dump.rdb文件。
Redis重启会通过加载dump.rdb文件恢复数据。
save 900 1
save 300 1
save 60 10000

优点：

1、只有一个文件 dump.rdb，方便持久化。
2、容灾性好，一个文件可以保存到安全的磁盘。
3、性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进程来进行持久化，
主进程不会进行任何 IO 操作，保证了 redis 的高性能
4.相对于数据集大时，比 AOF 的启动效率更高。

缺点：
1、数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。
所以这种方式更适合数据要求不严谨的时候)
2、AOF（Append-only file)持久化方式：是指所有的命令行记录以 redis 命令请 求协议的格式完全持久化存储)保存为 aof 文件。

AOF是将Redis执行的每次写命令记录到单独的日志文件中，
当重启Redis会重新将持久化的日志中文件恢复数据。当两种方式同时开启时，
数据恢复Redis会优先选择AOF恢复。

优点：数据安全性高
缺点：AOF文件比RDB文件大，且恢复速度慢，数据集大的时候，比RDB启动效率低

优缺点是什么？

AOF文件比RDB更新频率高，优先使用AOF还原数据。
AOF比RDB更安全也更大
RDB性能比AOF好
如果两个都配了优先加载AOF

怎么保证redis的数据缓存一致性？
先更新数据库，在删除缓存场景
一改一查场景：

当有两个线程A、B，线程A先去将数据库的值修改为allen，然后需要去删除redis中的缓存，当线程B去读取缓存时，线程A已经完成delete操作时，
缓存不命中，需要去查询数据库，然后在更新缓存，数据一致性；如果线程A没有完成delete操作，线程B直接命中，返回的数据与数据库中的数据不一致，可能会短暂出现数据不一致情况，但最终都会一致。推荐
存在的问题：当数据过期或者初始化时，会出现数据不一致情况，也就是线程B从数据库中，查询到数据为tony，然后线程A将tony修改为了allen，然后去删除redis中的数据，然后线程B将读到的tony，
更新到了数据库中，出现了数据不一致问题。
解决方案：对于不过期的数据我们要在上线的时候做好数据的预热，保证缓存命中。对于存在过期的数据，因为有过期时间，只会在特定的时间段内数据不一致，下次数据过期后，可以恢复，对于实时性要求不高时，可以接受。

提到redis的事务，相信很多初学的朋友会对它的理解和使用有些模糊不清，料想它和我们常见的关系型数据库（mysql 、mssql等）中的事务相同，也支持回滚，但这样理解就进入了一个误区，
首先：关系型数据中的事务都是原子性的，而redis 的事务是非原子性的。再多说一句，什么是程序原子性？简单的理解就是：整个程序中的所有操作，要么全部完成，要不全部不完成，不会停留在中间某个环节。
那么非原子性就是不满足原子性的条件就是非原子性了。我们用例子来解释一下：

原子性：数据库中的某个事务A中要更新t1表、t2表的某条记录，当事务提交，t1、t2两个表都被更新，若其中一个表操作失败，事务将回滚。

非原子性：数据库中的某个事务A中要更新t1表、t2表的某条记录，当事务提交，t1、t2两个表都被更新，若其中一个表操作失败，另一个表操作继续，事务不会回滚。（当然对于关系型数据库不会出现非原子性）

Redis事务相关命令：

MULTI ：开启事务，redis会将后续的命令逐个放入队列中，然后使用EXEC命令来原子化执行这个命令系列。
EXEC：执行事务中的所有操作命令。
DISCARD：取消事务，放弃执行事务块中的所有命令。
WATCH：监视一个或多个key,如果事务在执行前，这个key(或多个key)被其他命令修改，则事务被中断，不会执行事务中的任何命令。
UNWATCH：取消WATCH对所有key的监视。

redis的主存复制
主从复制的作用：数据备份、读写分离、分布式集群、实现高可用、宕机容错机制等
光靠redis主存复制和哨兵机制不足以实现redis高可用。为什么呢？
因为若某一节点宕机后，不会实现自动重启。最稳健实现高可用的做法：
redis主从复制+哨兵机制（监控、提醒、自动故障迁移）+keepalived（自动重启），若重启多次不成功，可以通过邮件短信等方式通知