Redis-从入门到起飞

 Redis的多级缓存

- 只有大项目使用三级缓存, 因为三级缓存维护起来需要成本, 中小型项目直接用redis作缓存

        1 一级缓存 "咖啡因" 进程级别

        2 二级缓存 "redis" 内存级别

        3 三级缓存 系统缓存

Redis主从架构如何数据统一

首先一个master多个slave,

全量同步: 当slave站起来, 向master发送自己的slaveid和offset偏移量, master通过比对slaveid来判断是否已经建立通讯, 在第一次接触, 会令slave节点继承自己的slaveid建立连接, 并且使 slave执行ofslave命令, master节点备份数据, 通过bgsave生成RDB文件, 结合repl-log文件, 将数据同步给slave, 实施全量同步.

增量同步: slave向master发送请求, master节点根据偏移量offset比较偏移量的变化, 将更新的数据备份为RDB, 在备份期间会有新的写操作, 这时会将写操作记录到repl-log日志, 一起发送给slave节点, 实施增量同步.

RDB: 业务上, 使用RDB备份, 文件小, 可以实现高可用,

AOF: 如果需要数据强一致性, 就可以使用AOF备份, 开启AOF重写瘦身, 可以节省存储空间

Redis如何解决缓存穿透,缓存击穿, 缓存雪崩的问题

 缓存穿透

有大量的mysql和redis都不存储的数据请求, 会击穿redis到达mysql数据库, 给数据库带来压力, 是一种攻击行为, 我们的业务解决方法是设置一个布隆过滤器, 本质是一个大数组, 这个数组通过三种不同的哈希算法对请求做哈希运算, 如果算法验证都存在则放行请求去访问redis, 否则过滤请求.

布隆过滤器的效果非常好, 但是仍然存在误判的情况, 我们业务配置时, 设置误判率不超过4%, 这样是业务可以接收的一个区间, 能很好的保护数据库. 当然也有一种办法是将不存在的值仍然缓存在redis中访问到达就响应空值, 但是这样会浪费redis的宝贵空间, 所以没有采用这种做法

缓存击穿

这种现象呢是因为有key过期, 大量的请求击穿redis到达mysql数据库, 有可能会造成把数据库压死的情况, 这种问题我们业务中解决是考虑到业务要求, 需要达到高可用的一个目标, 从而采取了让数据逻辑过期的策略, 这种策略的原理是只有当请求访问的时候才检查数据是否过期, 过期也不删除该数据, 直接响应给请求, 并且拿到一把锁去数据库查,  等查回来的数据到了就更新数据并且设置过期时间, 在更新期间如果有别的数据到达, 仍然会响应过期数据, 但是会因为前面已经加了锁, 从而不会有过多的请求去执行更新, 这样减少了数据库的压力, 也在高可用的前提下保证了数据的一致性, 这种办法就是我们解决缓存击穿的方式

当然了, 也可以通过加分布式锁的办法, 来达到数据强一致性, 但是这样会影响性能, 不满足业务的预期, 因而没有采取这种办法.

缓存雪崩

一, 缓存雪崩是有大量的key过期, 在同一时间访问数据库, 从而有可能压死数据库, 我们的业务解决方式, 最主要是在设置key过期时间时, 加上一个随机值, 使其不要在同一时间过期, 这样就能避免缓存雪崩

第二呢, 是采用了兜底的策略, 网关处有降级限流策略, nginx处也有漏桶算法保证流量不会增加的太离谱

第三呢, 我们的redis也搭建的主从集群, 有哨兵集群监控, redis本身比较抗造, 即使有redis服务挂掉, 也可以通过自动故障恢复, 选举新的master来使业务正常流转.

这三种方式已经足以保护当前业务的安全性, 当然听说大公司会设置进程级缓存咖啡因, redis作为二级缓存, 还有三级系统层面的缓存, 但是这样需要维护成本, 我们的业务就没有考虑搭建三级缓存