说明:Redis运行环境在内存中,若是redis服务器关闭,则内存数据将会丢失.
需求: 如何保存内存数据呢?
解决方案: 能够按期将内存数据持久化到磁盘中.
持久化策略规则:
当redis正常运行时,按期的将数据保存到磁盘中,当redis服务器重启时,则根据配置文件中指定的持久化的方式,实现数据的恢复.(读取数据,以后恢复数据.)面试
1).RDB模式是Redis默认的策略.
2).RDB模式可以按期(时间间隔)持久化. 弊端:可能致使数据的丢失.
3).RDB模式记录的是内存数据的快照.持久化效率较高. 快照只保留最新的记录.redis
1.save命令: 将内存数据持久化到磁盘中 主动的操做 会形成线程阻塞
2.bgsave命令: 将内存数据采用后台运行的方式,持久化到文件中. 不会形成阻塞.
3.默认的持久化的机制
save 900 1 若是在900秒内,执行了1次更新操做,则持久化一次
save 300 10 若是在300秒内,执行了10次更新操做,则持久化一次
save 60 10000 若是在60秒内,执行了10000次更新操做,则持久化一次算法
1).指定持久化文件
2).指定持久化文件目录数据库
1).AOF模式默认条件下是关闭的.须要手动开启
2).AOF模式记录的是用户的操做过程,因此能够实现实时持久化操做.
3).AOF模式因为记录的是实时的操做过程,因此持久化文件较大.须要按期维护.数组
说明:若是一旦开启AOF模式,则以AOF模式为准.缓存
1.当内存数据容许少许丢失时,采用RDB模式 (快)
2.当内存数据不容许丢失时,采用AOF模式(按期维护持久化文件)
3.通常在工做中采用 RDB+AOF模式共同做用,保证数据的有效性.服务器
问题: 若是小李(漂亮妹子)在公司服务器中执行了flushAll命令,问怎么办?
答: 须要找到aof文件以后,删除flushAll命令 以后重启redis,执行save命令便可.并发
说明: 因为redis在内存中保存数据.若是一直存储,则内存数据必然溢出.因此须要按期维护内存数据的大小.
维护策略: 删除旧的不用的数据,保留新的经常使用的数据负载均衡
LRU是Least Recently Used的缩写,即最近最少使用,是一种经常使用的页面置换算法,选择最近最久未使用的页面予以淘汰。该算法赋予每一个页面一个访问字段,用来记录一个页面自上次被访问以来所经历的时间 t,当须淘汰一个页面时,选择现有页面中其 t 值最大的,即最近最少使用的页面予以淘汰。
计算维度: 时间T
注意事项: LRU算法是迄今为止内存中最好用的数据置换算法.dom
LFU(least frequently used (LFU) page-replacement algorithm)。即最不常用页置换算法,要求在页置换时置换引用计数最小的页,由于常用的页应该有一个较大的引用次数。可是有些页在开始时使用次数不少,但之后就再也不使用,这类页将会长时间留在内存中,所以能够将引用计数寄存器定时右移一位,造成指数衰减的平均使用次数。
维度: 使用次数
随机算法.
根据剩余的存活时间,将立刻要超时的数据提早删除.
3.volatile-lfu 在设定了超时时间的数据中,采用lfu算法
4.allkeys-lfu 全部数据采用lfu算法
5.volatile-random 设置超时时间数据的随机算法
6.allkeys-random 全部数据的随机
7.volatile-ttl 将设定了超时时间的数据,提早删除.
8.noeviction 默认规则 若是设定noeviction 则不删除数据,直接报错返回.
手动修改redis内存优化策略:
问题出发点:
因为缓存失效,致使大量的用户的请求,直接访问数据库服务器.致使负载太高,从而引起总体宕机的风险!!!
说明: 用户频繁访问数据库中不存在的数据,可能出现缓存穿透的现象.若是该操做是高并发操做,则可能直接威胁数据库服务器.
解决方案:
1.采用IP限流的方式 下降用户访问服务器次数. IP动态代理(1分钟变一次)
2.微服务的处理方式: 利用断路器返回执行的业务数据便可不执行数据库操做 从而保护了数据库.
3.微服务处理方式: API网关设计. 不容许作非法操做
说明: 因为redis中某个热点数据因为超时/删除等操做形成数据失效.同时用户高并发访问该数据,则可能致使数据库宕机.该操做称之为 缓存击穿.
解决方案: 能够采用多级缓存的设计. 同时数据的超时时间采用随机数的方式.
说明: 因为redis内存数据大量失效.致使用户的访问命中率过低.大量的用户直接访问数据库,可能致使数据库服务器宕机. 这种现象称之为缓存雪崩.
解决:
1.采用多级缓存.
2.设定不一样的超时时间
3.禁止执行 flushAll等敏感操做.
说明: 若是须要Redis存储海量的内存数据,使用单台redis不能知足用户的需求,因此能够采用Redis分片机制实现数据存储.
注意事项:
若是有多台redis,则其中的数据都是不同的…
搭建端口:6379/6380/6381
6379.conf 6380.conf 6381.conf
只修改80/81的端口便可
一致性哈希算法在1997年由麻省理工学院提出,是一种特殊的哈希算法,目的是解决分布式缓存的问题。
[1] 在移除或者添加一个服务器时,可以尽量小地改变已存在的服务请求与处理请求服务器之间的映射关系。一致性哈希解决了简单哈希算法在分布式哈希表( Distributed Hash Table,DHT) 中存在的动态伸缩等问题 [2] 。
知识复习:
①平衡性是指hash的结果应该平均分配到各个节点,这样从算法上解决了负载均衡问题.
实现平衡性的方案: 引入虚拟节点
②单调性是指在新增或者删减节点时,不影响系统正常运行 [4] 。
特色:在进行数据迁移时,要求尽量小的改变数据.
③分散性是指数据应该分散地存放在分布式集群中的各个节点(节点本身能够有备份),没必要每一个节点都存储全部的数据 [4] 。
俗语: 鸡蛋不要到放到一个篮子里
说明:将AOP中的注入对象切换为分片对象
说明: redis分片主要的做用是实现内存数据的扩容.可是若是redis分片中有一个节点宕机,则直接影响全部节点的运行. 可否优化?
实现策略: 采用Redis哨兵机制实现Redis节点高可用.
1).关闭redis分片的节点,以后复制配置文件准备哨兵的配置.
2).复制分片的目录 更名为sentinel
3).删除多余的持久化文件,保存redis配置文件
4).启动3台Redis服务器
命令: info replication
检查redis节点的状态信息
节点划分: 6379 当主机 6380/81 当从机
命令2: 实现主从挂载 slaveof host port
3).检查6379主机的状态
结论: redis全部节点均可以相同通讯.而且路径当前的主从的状态.
数据主从同步的状态
1).当哨兵启动时,会连接redis主节点,同时获取全部节点的状态信息
2).当哨兵连续3次经过心跳检测机制(PING-PONG),若是发现主机宕机,则开始选举.
3).哨兵内部经过随机算法筛选一台从机当选新的主机.其余的节点应该当新主机的从.
1.启动哨兵 redis-sentinel sentinel.conf
2).检查哨兵配置
3)将主机宕机,以后检查从机是否当选主机
4).启动以前的主机,检查是否当选新主机的从
5).若是搭建异常 则删除重作
关闭全部redis服务器.