阐明: 应用缓存能够无效的升高用户拜访物理设施的频次. 疾速从内存中获取数据, 之后返回给用户, 同时须要保障内存中的数据就是数据库数据.
思考:
1. 缓存的运行环境应该在内存中.(快)
2. 应用 C 语言开发缓存
3. 缓存应该应用什么样的数据结构呢 ——–K- V 构造 个别采纳 String 类型居多 key 必须惟一 . v:JSON 格局
4. 内存环境断电即擦除, 所以应该将内存数据长久化(执行写盘操作)
5. 如果没有保护内存的大小, 则容易导致 内存数据溢出. 采纳 LRU 算法优化!!!
redis 介绍
redis 是一个 key-value 存储系统。和 Memcached 相似，它反对存储的 value 类型绝对更多，包含 string(字符串)、list(链表)、set(汇合)、zset(sorted set – 有序汇合)和 hash（哈希类型）。这些数据类型都反对 push/pop、add/remove 及取交加并集和差集及更丰盛的操作，而且这些操作都是 原子性 的。在此基础上，redis 反对各种不同形式的排序。与 memcached 一样，为了保障效率，数据都是缓存在内存中。区别的是 redis 会周期性的把更新的数据写入磁盘或者把批改操作写入追加的记录文件，并且在此基础上实现了 master-slave(主从)同步。
原子性阐明: Redis 的操作是单过程单线程操作, 所以没有线程并发性的平安问题. 采纳队列的形式一个一个操作.
用法
缓存
数据库
消息中间件(因为反对链表构造, 所以能够
装置 redis
只须要在 redis 根目录下顺次执行 make 和 make install 命令即可
配置
正文 ip 绑定 #bind 127.0.0.1
敞开保护模式 protected-mode no
开启后盾启动 daemonize yes
命令
1. 启动命令: redis-server redis.conf
2. 检索命令: ps -ef | grep redis
3. 进入客户端: redis-cli -p 6379
4. 敞开 redis: kill -9 PID 号 | redis-cli -p 6379 shutdown
根本办法
jedis.setex(“key”,time,”val”): 向 redis 插入规定超时工夫的数据
jedis.setnx(“key”,”val”):jedis 里存在 key 则不变, 不存在则批改
jedis.set(“key”,”val”,new setParam().ex(time).nx
jedis.multi(): 开启事务
jedis.exec(): 提交事务
jedis.discard(): 回滚事务
分布式锁机制
同步锁只能解决 tomcat 外部问题, 不能解决多态 tomcat 并发问题.
思维:
1. 锁应该应用第三方操作 , 锁应该专用.
2. 准则: 如果锁被人正在应用时, 其余的用户不能操作.
3. 策略: 用户向 redis 中保留一个 key, 如果 redis 中有 key 示意有人正在应用这把锁 其余用户不容许操作. 如果 redis 中没有 key , 则示意我能够应用这把锁.
4. 危险: 如何解决死锁问题. 设定超时工夫.
aop
可通过 aop 来管制哪些办法应用缓存
Redis 长久化策略
RDB
特点:
1.RDB 模式是 redis 的默认的长久化策略.
2.RDB 模式记录的是 Redis 内存数据的快照 . 最新的快照会笼罩之前的内容 所有 RDB 长久化文件占用空间更小 长久化的效率更高.
3.RDB 模式因为是定期长久化 所以 可能导致数据的失落.
命令:
- save 要求立刻马上长久化 同步的操作 其余的 redis 操作会陷入阻塞的状态.
- bgsave 开启后盾运行 异步的操作 因为是异步操作, 所以无奈保障 rdb 文件肯定是最新的须要期待.
AOF
特点:
1.AOF 模式默认条件下是敞开的, 须要用户手动的开启
- AOF 模式是异步的操作 记录的是用户的操作的过程 能够 避免用户的数据失落
- 因为 AOF 模式记录的是程序的运行状态 所以长久化文件绝对较大, 复原数据的工夫长. 须要人为的优化长久化文件
Redis 内存优化策略
1.LRU 最近起码应用. 最罕用最好的算法
2.LFU 最不常常应用.
3.Random 随机算法
4.TTL 把设定了超时工夫的数据将要移除的提前删除的算法.
Redis 分片机制
当海量数据存在 redis 中时, 会重大影响咱们的查问效率, 所以引入了 redis 分片机制, 实现扩容.
springboot 实现 reids 分片
一致性 hash 算法
平衡性 平衡性是指 hash 的后果应该平均分配到各个节点，这样从算法上解决了负载平衡问题. 因为会呈现节点地位不均的状况, 所以引入了虚构节点的概念, 来尽可能的达到均分.
枯燥性 集群在删除或新增节点时, 不会影响零碎的运行.
分散性 数据应该扩散的放在集群中的各个节点.
Redis 哨兵机制
Redis 分片实现了内容扩容, 但只有有一台宕机就会导致整个服务出问题, 所以引入了 Redis 哨兵机制, 相当于 Redis 的代理, 实现高可用性.
哨兵机制先得实现 Redis 之间得主从挂载.
命令:slaveof ip 端口
查看主从状态:info replication
原理阐明:
1. 配置 redis 主从的构造.
2. 哨兵服务启动时, 会监控以后的主机. 同时获取主机的详情信息(主从的构造)
3. 当哨兵利用心跳检测机制(PING-PONG) 间断 3 次都没有收到主机的反馈信息则判定主机宕机.
4. 当哨兵发现主机宕机之后, 则开启选举机制, 在以后的从机中筛选一台 Redis 当做主机.
5. 将其余的 redis 节点设置为新主机的从.
springboot 实现哨兵机制
Redis 集群
因为 redis 分片机制只实现扩容, 不反对高可用, 而 redis 哨兵只能实现高可用. 所以引出了 redis 集群机制
选举机制 脑裂景象
当集群选举时, 间断三次呈现平票后果则可能呈现脑裂景象.
预防: 只能通过多设主节点来预防脑裂.
springboot 整合 redis 集群