redis05 -事务，持久化，哨兵，缓存

redis单条命令有原子性，但事务不保证原子性，也没有隔离级别。事务写的时候只是入队，只有在exec时会全部一次性按顺序执行。

• multi ；开启事务
• set k1 v1;
• set k2 v2;
• get k1;
• exec; 执行事务
• discard ;放弃事务。队列中的全都不会执行

编译型异常：写的其中某一条redis命令就错了，这种情况会导致整个事务的失败，所有命令均不会执行。

运行时异常：如incr k1 (但k1不是int类型的数)，这种情况编译时检查不出来，不会导致整个事务的失败，只有错的那条命令不会执行，其他命令照常执行。

• watch key ； 相当于加锁操作，放在multi事务执行开始之前、并且每次事务执行完毕就会释放这个锁。
• unwatch key； 释放锁
• watch key就相当于redis的乐观锁，每次事务提交之前会比较要操作的值的版本号有没有变化。若变化了则整个事务都会失败。不是单纯的比较值，而是内部有个版本号，所以不会出现ABA问题。
• exec,discard unwatch都会清除连接中的所有监视

设置密码

• config set requirepass 1234
• auth 1234; 登录

RDB，持久化内存中的数据到磁盘里，保存至/dump.rdb文件

• 正常执行save方法，会触发rdb
• 执行flushAll会触发，将空的信息持久化到磁盘
• 退出redis也会触发
  
• rdb优点：子进程处理持久化操作，效率高，适合大规模的数据恢复，对数据的完整性要求不高
• 缺点：若服务器意外宕机，最后一次修改的数据无法持久化到磁盘

AOF append only file 默认不开启

优点是一般会比rdb恢复的数据更加完整
缺点是1.对于大量数据的写入操作会比较慢。运行效率低。2.文件占用大于rdb。3.文件修复速度慢于rdb。

发布订阅

主从复制

• 复制是单向的，只能从主机到从机
• 默认情况下大家都是master，只有slave需要单独配置
• 使用命令窗口，slaveof 127.0.0.1 6379 ; 认谁当主机。缺点是一旦shutdown或者宕机后，再次启动服务，配置的主从信息都丢失了。即暂时性
• 使用配置文件配置，会永久性的保存。
• 配置从机生效时，会复制主机的所有数据

哨兵模式

• sentinel monitor myredis 127.0.0.1 6379 1
  myredis:被监控的名称。 1 代表有几个哨兵认为主机挂了，就执行投票更换

缓存

• 缓存穿透：大量请求是请求的数据库中没有的字段，所以会经过缓存直接访问数据库，导致查询不到还在一直查，使数据库瘫痪。解决方案：布隆过滤器，通过几个哈希函数将所有存在于数据库中的key散列到只有0，1组成的表中，查询时先经过过滤器，看这个字段有没有，若显示没有，则数据库中一定没有。若显示有，则数据库中也不一定有，99.1.%的概率有好像是。

• 缓存击穿：大量访问请求打在一个点上，若到了这个点的过期时间，则这些大量请求就会直接访问数据库，造成瘫痪。解决方法：1.设置过期时间久一点2.加互斥锁。对于相同的key,每次只能有一个访问能访问到数据库，这就保证了数据库不会瘫痪，但把压力转移到了分布式锁上面

• 雪崩：大量在缓存中的key同时过期，导致这些大量请求就会直接访问数据库，造成瘫痪。解决方法：1.合理设置key过期的时间，尽量均匀，因为redis服务器内存是有限的 。多设几台redis服务器。2.服务降级。停掉一些服务，保证主要的服务可用。3.数据预热，把可能访问到的热点数据先访问一遍，让他加在redis里。