redis2

事务：

 

 

 

 

 

 放弃事务：

 

2种异常：

 

 

 

 

 

 

 

 悲观锁（每次请求都会先对数据进行加锁， 然后进行数据操作，最后再解锁，数据库一般都采用此方法）和乐观锁（修改数据前记录一下versionid，修改完数据提交时，比较一下当前versionid有没有变动，没有变动的话话就认为这个期间没别人改动过，则提交成功，如果不一致，则认为别人改过，提交失败）：

 

 

 redis用watch实现乐观锁，它能在事务提交时自动比较当前变量值有没有变化，有变化就提交失败：

 

 

 

 

 jedis：

 

 

 

 

测试：

 

 

 

 

 

Jedis操作事务：

Springboot采用springdata来操作jps、monggodb、redis

 

使用 RedisTemplate 能操作 redis

 操作对象：

 

 或者用jdk序列化，外面就不用再转为 json 了：

 

 可以把redisTemplate封装到工具类里面，然后直接调用工具类就好了

redis配置文件：

对大小写不敏感；

bind ip：指定服务器 ip 

daemonize yes：是否以守护进程运行，即是否后台运行，默认是no，需要手动设置为yes

 

 

 

 

 

 

 

 

 

redis持久化：

例如，只要key set了，关机后还能get到

 

 

 RDB：

 

 

 

此时60s内set5个key就会触发rdb

 

 

 

 

 

 aof：

是将所有的写命令记录下来，当恢复的时候，将该文件全部执行一遍

 

 

 

 

 

 

 

 

 

 

 

 

 

 命令：

 

 测试：

 

 

 

 主从复制：

一个集群包含多节点，一般是1主3从，所有节点都是服务器，主负责处理写请求，从负责读，一个节点对应一个conf文件

 

 

 

 

 

 

环境配置：

 

  用命令配置从机：

 

 用命令配置主机：

 

主机能写（set key），从机只能读get

 

 从机第一次连到主机，主机会把所有数据文件复制过去（全量复制），后面主机在怎么变动，只把变动的部分复制过去（增量复制）

 

 

 哨兵模式：建立一个哨兵集群，哨兵会互相监控，也会监控服务器的状态，如果主节点崩塌了，则选举一个从节点做主节点，其他节点是它的奴隶，即便之前死去的主复活了，也是新的主的奴隶（自动的，无需手动）

 

 

 

 

 

 如上图：

 

 

监控的主节点的名字myredis、IP 和端口，最后一个count的意思是有几台 Sentinel 发现有问题，就认为主节点挂了

 

 

 下图显示，master从6379变成了6381

 

 如果原老大回来了，只能做slave

优缺点：

 

 全部配置：

 

 

 

 

 缓存穿透：多个请求都没有命中缓存，只能全部去查数据库

 

 解决：布隆过滤器（查缓存之前先过滤部分请求）、缓存空对象

 

 

 

 缓存击穿（某个点请求过多）：

 分布式锁是每次只有1个线程查后台，其他线程等待

 

 

 缓存雪崩：缓存的东西集体失效，如停电