学习笔记---redis 的使用简单记录

  1. Redis 缓存,可用于多种数据类型存储:String,List,Set,Zset,Map

  2. (删除算法)Redis 对处理过期时间的Key处理方式:1.惰性处理:客户端访问时判断是否过期 2.积极处理:Redis 周期性在设置了设定时间的 Key 选择一部分来删除(随机),如果key超时,则删除,如果一轮中删除的 key 的数量>25%,循环该过程,如果<=的话,检查下一个超时时间,而redis内部会记录进入到了那个超时时间的,以此来作为下一次的执行的判断;

  3. 发布订阅:pub/sub,消费者提供者机制,订阅一个通道,不支持多协议,哨兵模式下的集群使用了这个方式;使用场景少,特定场景还是使用 MQ 较为合适;

  4. Redis 的持久化原理与解析:基于缓存,宕机会丢失数据,当然采用集群化来提高稳定性为其中的手段;另外持久化也是解决方法,采取两种方式:RDB 恢复以及AOF;持久化路径可配,生产环境最好配置公共路径,重启则自动加载;
    RDB: 基于快照的方式实现的,Redis 内部会 fork 出子进程(因此不影响原主进程)来,当达到一定的条件(配置条件),则会将内存数据写进临时文件,持久化后替换掉原来的dumb.rdb 里面,重启时则恢复;配置条件:在redis.config 文件里面 save seconds changes 有多条,或关系,当在某秒内有某条数据跟新则触发持久化,或者客户端执行 save 命令操作,主进程执行,这样性能较差,因为客户端执行线程阻塞(阻塞所有的客户端请求),或者才采用 bgsave ,不会阻塞客户端请求,后台异步快照任务的;或者执行 flushAll , 类似删库恢复备份的操作,只要配置了快照规则,则执行恢复操作;缺陷是在两次持久化之间的数据丢失(即来不及持久化的数据);正常关机触发持久化,在没有配置aof的情况下;

    AOF:(解决了内存丢失的问题,但是恢复数据比较慢)基于日志的方式实现,数据变更时则将变更操作日志写到另外的内存缓冲村,当缓冲区满了,由系统调用主进程持久化到 aof 文件,aof 文件记录的是变更日志,这样文件就会越来越大,因此优化:配置 aof 文件的大小,初次重写有初始化的大小,后面的就得按照配置的百分比进行叠加,如果达到这个大小的话,根据内存数据则创建新的 aof 文件(不如比记录set key value ,delte key value 这些没有用的操作日志)来存储数据,Y即重写,这个是主进程 fork 出子进程出来操作的,而且这个重写保存的数据是以RDB的文件内容,只不过形式是以AOF的文件格式保存的而已,因为RDB的保存内容占的字节少;

以上的 fork 出子进程非常耗资源的,尽量减低触发,所以配置的数据尽量大点;
重启后的备份数据还原方式顺序:AOF,只要有AOF,RDB不执行了;

  1. (逐出算法)Redis 内存回收策略:LRU机制,大概有六种:
    客户端申请内存不够时则异常;
    随机选出某些key删除;
    从设定过期时间的已经过期的删除;
    从设定过期的最少使用的删除;
    从设定过期的即将过期的删除;

  2. Redis 单线程(仅仅指IO线程)性能高的原因:1.影响的在于网络带宽以及内存大小,不在于线程;2.纯内存操作;3.基于多路复用的(同步非阻塞 IO 模型)机制,跟nio一个道路,nio是线程循环判断多路复用器的Selector上的channel所关心的事件,如果有则执行,没有则返回,因此达到非阻塞,说白了就是事件监听监听; 鉴于这种单线程机制,可以考虑到在同一服务器上(多核),开启多个Redis;

  3. Redis 的原子性操作:举个例子,分布式锁,Spring提供的RedisTemplate 可以在这是key 的同时设置过期时间,但是没有处理在超高并发处理的情况,业务执行逻辑时间长短的不一样导致锁过期时间到而失效以及因此可能造成的后面的线程所申请创建的分布式锁被前面的线程删除的可能性,这样就会导致分布式锁没有起到效果,解决方法:该分布式锁挂上标志。并且定时执行对过期时间的更新(加长),这些操作必须得原子性的,
    在这里插入图片描述
    采用Redisson 即可以处理,底层原理就是采用这种机制来的,保持原子性是通过lua脚本来实现的,通过这些脚本可以实现原子性操作;

  4. redis 的集群:全量复制+增量复制,无磁盘复制(直接创建rdb,然后发送给slave,不会在自己本地落地磁盘了): redis 的集群后必定涉及到主从复制的,
    全量复制+增量复制:
    采用集群的话,那么rdb备份方式是禁止不了的,
    过程消耗:从节点网络请求时间;主节点发送偏移量时间;主节点生成rdb时间;主节点发 送rdb文件以及buffer网络时间;从节点加载文件 的到内存时间 ; 增量复制与全量复制的区别在于缓存区是不是满了,可配置话;
    缺点:由于所有的数据写以及发送都是在主节点上操作的,当主节点繁忙的话那么数据的延迟就会增大;另外如果主节点宕机的话,那么需要手动切换主节点设置才可以;
    在这里插入图片描述
    为了解决主节点不能主动切换的问题,延伸出redis的哨兵集群:主要是sentinel 来监听redis集群,为了保证sentinel 的高可用,sentinel 本本身也要集群的:
    三个定时任务:每一秒哨兵去心跳 redis, 30ms 如何没有回应则代表下线;每2秒通过发布订阅的方式确定哨兵节点的节点情况;每10秒通过向主从节点发送info命令获取最新的主从结果;

选举方式:偏移量优先,redis节点i小优先的规则(类似于zab协议选择)过半机制;
缺点:在主节点宕机,重新选举的时候,会有一个空档期,这个时候如果出现并发访问的话,那么极有可能造成缓存崩溃,以此延伸出 redis-cluster 集群方式:

redis-cluster 集群方式:多个主从节点集群,分片处理(redis的hash一致性),大大降低整个redis架构崩溃的可能性(缓存崩溃),也解决存储大批量数据(数据的分片处理);

10.缓存穿透(db没有,缓存没有):1.缓存空对象 2.布隆过滤器(多个hash值,取模字节数组长度,降低hash冲突,即误判)
缓存击穿(db有,缓存没有):分布式锁,需要主要分布式锁的粒度,锁的线程误删以及锁的过期失效;
缓存崩溃:终极手段是集群

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值