1.Redis 的特点
优点: 速度快, 类型丰富, 丰富的特性, 持久化存储, 单线程.
2. Redis 的应用场景
(1) 令牌生成 (临时有效期)
(2) 短信验证码 (临时有效期)
(3) 热点数据 (使用 Redis 减轻数据库的压力)
(4) 使用 Redis 实现消息中间件, 发布订阅功能 (不推荐)
(这里多说一下消息中间件的作用: 应用解耦, 异步处理, 错峰与流控)
(5) 分布式锁 (使用 zk 或者 Redis 实现分布式锁)
(6) 网站计数器 (因为 Redis 是单线程的, 在高并发情况下, 保证记录的唯一性)
(7) 此外还有 Redis 解决雪崩效应, Redis 多种集群方案, reids 持久化机制, reids 哨兵机制
3. Redis 类型
(1)String 类型 字符串
(2)List 列表 简单的字符串列表, 采用的双向链表结构
(3)Hash 字典 在值比较少时使用数组, 值比较多的时候转换成 hashmap 数据结构
(4)Set 集合 String 类型的无序集合, 值是唯一的
(5)Sorted Set 有序集合 值是唯一的, 并且每个成员都会关联一个分数, 并通过该分数排序.
4. Redis 过期策略及清理算法问题
(1) 为什么不用定时删除策略
因为这样需要用一个定时任务来监测所有点 key, 虽然内存能及时释放, 但是十分消耗资源. 在大并发下 CPU 要将时间用来处理请求.
(2) 定期删除 + 惰性删除
每隔 100ms, 随机抽查一些 key 是不是过期, 然后剩下的在获取某个 key 的时候去校验是否过期.
(3) 配置内存淘汰机制
在 Redis.conf 中有一行配置
一般配置 allkeys-lru 随机删除最近使用最少的 key
默认 volatile-lru -> 使用 LRU 算法, 仅对设置了过期时间的键采取 LRU 淘汰
5.Redis 持久化机制
(1) 概述
Redis 持久化机制分为 RDB 和 AOF 两种, 默认是快照 RDB 方式
(2)RDB 持久化方式
Redis.conf 默认配置:
save 900 1 900 秒内, 超过一个 key 被修改, 则保存
save 300 10 300 秒内超过 10 个 key 被修改, 则保存
保存后默认生成一个 dump.rdb 的文件.
(3)AOF 方式
Redis.conf 默认配置
appendonly no 默认为 30 秒一次
可修改为:
appendfsync always 每次修改都会保存
appendfsync everysec 每秒一次
appendfsync no 每 30 秒一次
默认保存文件为 appendonly.aof
注: aof 模式有个问题就是 aof 文件会变的很大. 往往通过 aof 分析里面有太多冗余数据时, 会进行重写, 这个操作满足一定条件是, Redis 会自动触发. 一般生产环境一般要求 在达到几个 g 或者几十个 g 才会重写, 因为重写会影响 Redis 性能.
重写参数:
auto-aof-rewrite-percentage 100 重写增长比例, 如上次重写是 100, 则在 200 时触发.
auto-aof-rewrite-min-size 64mb 最小触发重写的文件大小
6.Redis 主从复制
(1) 什么是主从复制
将服务器分为主服务器和从服务器, 主服务器可以允许读写操作, 从服务器只能有读操作. 主服务器只能有一个.
(2) 主从复制的应用场景
集群, 读写分离, 日志备份, 高可用
(3) 什么是读写分离
读和写分库连接, 读一个库, 写一个库, 互不影响, 增加整体吞吐量, 读写分离需要解决两个库之间的数据同步问题, Redis 已解决
(4) 主从复制原理图
(5) 主从复制存在的问题
当数据同步延迟吃造成的主库和从库的不一致的问题.
1如果 qq 消息, 论坛等允许短时间内不一致的业务, 就可以不作处理.
2强制读主, 从库只用来主库挂掉过后的一个备份.
3不同的业务, 在进行表操作时用缓存记录下来, 比如库: 表: 主键 并设置一个过期时间, 过期时间为主从延时时间, 如果读到了 key 说明还在同步, 需要去读主库, 如果没有 读到 key 则去读从库. 具体读哪一个由路由来完成.
7. 主从复制的配置
在 "从服务器" 的 Redis.conf 的 salveof 后面添加主服务器的 ip 地址 + 端口, 如果主服务器配置了密码 需要加上 masterauth
8.Redis 安装
将 Redis-4.0.8.tar.gz 包放在 / usr/local 下
1解压 tar -zxvf Redis-4.0.8.tar.gz
2 cd Redis-4.0.8
3运行 make
报错:
zmalloc.h:50:31: 致命错误: jemalloc/jemalloc.h: 没有那个文件或目录
解决: 使用这个 make MALLOC=libc 替换 make
4make install PREFIX=/usr/local/Redis
5移动配置文件到安装目录下
- cd ../
- mkdir /usr/local/Redis/etc
- mv Redis.conf /usr/local/Redis/etc
6配置 Redis 为后台启动
- vi /usr/local/Redis/etc/Redis.conf // 将 daemonize no 改成 daemonize yes
- vi /usr/local/Redis/etc/Redis.conf // requirepass 123
7开启 Redis
/usr/local/Redis/bin/Redis-server /usr/local/Redis/etc/Redis.conf
8连接 Redis 客户端
./Redis-cli -h 127.0.0.1 -p 6379 -a "123456"
PING 结果表示成功
9关闭防火墙
- // 临时关闭
- systemctl stop firewalld
- // 禁止开机启动
- systemctl disable firewalld
- Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
- Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
10停止 Redis 服务
./Redis-cli -h 127.0.0.1 -p 6379 -a "123456" shutdown
修改 Redis.conf
注释掉
#bind 127.0.0.1 开启外网访问
9. 哨兵机制的配置
(1) 作用: 心跳检查, 故障转移 (选举策略), 监控.
注: 哨兵注意事项: 哨兵一般不和其他 Redis 服务器在一起, 启动的时候先启动哨兵的情况下, 最好先启动主的 Redis, 不然哨兵会以为主挂掉了, 进行选举.
(2) 配置
1配置拷贝到 etc 目录
cp sentinel.conf /usr/local/Redis/etc
2修改 sentinel.conf 配置文件
sentinel monitor mymast 192.168.110.133 6379 1 #主节点 名称 IP 端口号 选举次数
一个 Sentinel 节选举成为 Leader 的最低票数为 quorum(就是 6379 后面那个 1) 和 Sentinel 节点 数 / 2+1 的最大值.
sentinel auth-pass mymaster 123456
3 修改心跳检测 30 毫秒
- sentinel down-after-milliseconds mymaster 30
- 4sentinel parallel-syncs mymaster 2
- sentinel parallel-syncs <master-name> <numslaves>
注: 这个配置项指定了在发生 failover 主备切换时最多可以有多少个 slave 同时对新的 master 进行 同步, 这个数字越小, 完成 failover 所需的时间就越长, 但是如果这个数字越大, 就意味着越 多的 slave 因为 replication 而不可用. 可以通过将这个值设为 1 来保证每次只有一个 slave 处于不能处理命令请求的状态.
5启动哨兵模式
./Redis-server /usr/local/Redis/etc/sentinel.conf --sentinel &
6停止哨兵模式
ps -ef | grep Redis
7若需要 springboot 集成哨兵模式则需要
把哨兵配置文件中的 protected-mode no 的注释放开
搭建哨兵的时候要注意, 所有服务器都需要配置密码
masterauth 123456
主服务器不用配置 slaveof
10.Redis 事务在 spring 中的使用
muti() 开启
exec() 提交
dicard() 回滚
11. 使用 springboot + ehcache + Redis 实现二级缓存
一级 (ehcache)+ 二级 (Redis) 目的是尽量使用本地缓存: 作用1如果本地没有再走网络. 效率会更高. 2减轻 Redis 访问压力, 提高访问速度.3如果 Redis 挂了, 直接穿透到 数据库容易造成雪崩效应.
注意事项: 1. 一级缓存的过期时间, 一定要比二级缓存的过期时间要少能有效控制一二级缓存不同步的问题.
2. 使用 job 定时任务去比较一二级缓存里面的值, 或者使用二级缓存更新后发送到 mq 里面, 然后在拿去更新一级缓存, 这么做比较耗资源.
(代码如果需要的话, 可以在下方评论)
流程图如下
来源: https://www.cnblogs.com/chenfei-java/p/12459002.html