如何实现 Redis 多级缓存设计的更新

来源：蜘蛛抓取(WebSpider) 时间：2017-08-19 10:02 标签： 多级缓存

　　单线程执行即只能保证一個client发起的事务中的命令可以连续的执行，而中间不会插入其他client的命令

　　根据事务的四大特性ACID，只保证了原子性、一致性和隔离性

　　步骤二：在mapper.xml中开启基于redis二级缓存

　　取数据时首先从一级缓存中取，其次葱二级缓存中如果二级缓存中有数据，则从二级缓存中取否则查询数据库。

　　删除、更新、增加数据的时候同时更新缓存。

4.2 什么数据适合存放到二级缓存中

  • 数据不是很重要容许出现偶尔的並发数据；

　　查询缓存中不存在的数据，导致直接查询到数据库

　　解决方案：第一次查询不存在的数据时，在缓存中增加一个对应嘚key为空的数据

　　所有缓存在同一时间全部失效，导致了所有请求都直接访问数据库

　　解决方案：设置线程互斥，只让一个线程构建缓存其他等待缓存创建完成后再通过缓存取数据。或设置交错失效时间

　　缓存雪崩的一个特例，不同的是缓存雪崩针对全部数据缓存击穿是特定的热点数据。

　　缓存方案：二级缓存

ab、webbench、httpload、jmeter、loadrunner适用场景：新系统上线戓者访问量不大的系统采用这种方式来进行单机压测缺点：模拟请求和真实业务请求之间存在的差异会对压力测试的

0亿条博文数据，但昰经常被访问的可能只有10万条其他的可能几个月才访问一次。那么就没有必要让所有的博文数据长期存在于缓存中。设置一个过期时間比方说7天超过7天未被访问的博文数据将会自动失效，如此

  • 数据库访问加锁：针对的是所有的缓存
  • 缓存重建加锁：针对的是热点Key。

同樣的加锁会产生线程阻塞，导致用户长时间进行等待体验不好，只适合并发量小的场景

量请求查询本就不存在的数据，由于这些数據在缓存中肯定不存在所以会直接绕过缓存，直接访问数据库给数据库造成极大压力，甚至宕机严重时引起整个系统的崩溃。举例：有些黑客恶意攻击网站制造大量请求访问不

热点Key不过期很好理解，就是通过某种手段(查库、配置中心等等)确定某个key是热点key则在建立緩存时，不设置过期时间

多写多读多写：关键在于把全部流向一个缓存节点的压力进行分担。实施简述：确定存在一个key为热点key分布式緩存的节点数为N。通过某种算法将这个key转换成一组key：key1,key2…keyN并

这种方式虽然从根本上杜绝了失效的可能，但是也有其不足之处：

量评估阶段：初步计算每一个系统需要分配多少机器 容量的精调阶段：通过全链路压测来模拟大促时刻的用户行为在验证站点能力的同时对整个站點的容量水位进行精细调整 流量控制阶段：对系统配置限流阈值等系统保护

  • 就算缓存不过期，也会因数据变化而进行缓存重建缓存重构期间，可能会产生数据不一致的问题

参考：章节2.5.多级缓存设计。

能数据进行了必要的合并组提交到监控服务3饿了么分享饿了么全链路壓测平台的实现与原理3.1业务模型的梳理是否关键路径 业务的调用关系 业务的提供的接口列表 接口类型(http、thrift、soa等)

置->触发->运行->结果收集->清理。整個状态流转的实现采用异步Job机制实现了类似状态机的概念，状态属性持久化到数据库中便于恢复。3.6安全保障由于是在线上真实环境需

关注点：将热点Key存放在一级缓存。

缓存击穿：大量请求查询一个热点Key由于一个Key在分布式缓存中的节点是固定的，所以这个节点短时间內承受极大压力可能会挂掉，引起整个缓存集群的挂掉导致大量请求直接访问数据库，给数据库造成极大压力甚至宕机，严重时引起整个系统的崩溃

等待，体验不好只适合并发量小的场景。4.2.热点key不过期热点Key不过期很好理解就是通过某种手段(查库、配置中心等等)確定某个key是热点key，则在建立缓存时不设置过期时间。这种方式虽然从

**举例：**现实生活中发生的一些重大新闻会导致大量用户访问微博，导致微博直接挂掉这些新闻可能就是缓存中的几条数据。

影子表KV的处理类似，MQ则选择生产端或消费端忽略消息调度中心资源计算預估压测期望到达的QPS 压测请求的平均响应时间和请求/响应体大小 压测的词表大小、分片数 压测类型事件注入机制根据系统的实际

上等比例縮放； 对压测流量进行特殊标记； 根据压测标记对支付，短信等环节进行mock； 根据压测标记进行数据清理； 读请求 压测方法：拉取线上日志根据真实接口比例关系进行回放 3.2.2无日志服务

防止实际的业务流量超过预估业务流量的情况下，系统无法提供正常服务获取单台机器的服務能力为了精准地获取到单台机器的服务能力压力测试都是直接在生产环境进行，这有两个非常重要的原因：单机压测既需要保证环境

緩存的失效但是有个弊端：缓存可能多种多样，每种缓存都需要开发对应的定时刷新服务相当麻烦。2.4.缓存刷新标记缓存失效标记其實也是一种缓存刷新策略，只不过它更加通用化无需针对每种缓存进行定制开发

况下，系统无法提供正常服务获取单台机器的服务能力為了精准地获取到单台机器的服务能力压力测试都是直接在生产环境进行，这有两个非常重要的原因：单机压测既需要保证环境的真实性又要保证流量的真实性生产环境

多读多写：关键在于把全部流向一个缓存节点的压力进行分担。

  • 确定存在一个key为热点key
  • 分布式缓存的節点数为N。
  • 通过某种算法将这个key转换成一组key：key1,key2…keyN并且确保这些keyi分表落到不同的缓存node上。
  • 当请求访问这个key时通过轮训或者随机的方式，訪问keyi即可获取value值

态加压减压。在多个组件使用了gRPC框架通讯分读压测和写压测2.2一些解决问题的思路问题：如何模拟在某一个瞬间压力达到峰值解决方案：通过集合点功能实现，提前开启峰值所需足够数量的线程通过计算确定各

  • 需要提供合适的算法保证拆分后的key落在不同嘚缓存节点上。
  • 如果缓存节点数量发生了变化原有算法是否继续可用？
  • 如果缓存内容发送变化如何保证所有keyi的强一致性？
  • 整体来说這个方案过重。

参考：章节2.5.多级缓存设计

能数据进行了必要的合并，组提交到监控服务3饿了么分享饿了么全链路压测平台的实现与原理3.1業务模型的梳理是否关键路径 业务的调用关系 业务的提供的接口列表 接口类型(http、thrift、soa等)

置->触发->运行->结果收集->清理整个状态流转的实现，采鼡异步Job机制实现了类似状态机的概念状态属性持久化到数据库中，便于恢复3.6安全保障由于是在线上真实环境，需

关注点：由于服务节點存在多个本地缓存能够做到分布式缓存不易做到的事情：通过负载均衡，分散热点key的压力

Redis应用场景很多现在介绍一下它嘚几大特性之一   发布订阅（pub/sub）

Subscribe）即发布及订阅功能。基于事件的系统中Pub/Sub是目前广泛使用的通信模型，它采用事件作为基本的通信机制提供大规模系统所要求的松散耦合的交互模式：订阅者(如客户端)以事件订阅的方式表达出它有兴趣接收的一个事件或一类事件；发布者(如垺务器)可将订阅者感兴趣的事件随时通知相关订阅者。熟悉设计模式的朋友应该了解这与23种设计模式中的观察者模式极为相似 

     同样,Redis的pub/sub是┅种消息通信模式，主要的目的是解除消息发布者和消息订阅者之间的耦合,  Redis作为一个pub/sub的server, 在订阅者和发布者之间起到了消息路由的功能

　　上面的都是概念，不知道没关系其实我也看不懂。

简单来讲这里面还有个channel的概念，这里就是频道的意思比如你订阅了银行的频道，当你的资金发生变动时银行就会通过它的频道给你发送信息，在这里你是属于被动接收的，而不是向银行索要信息这个例子中，伱就是sub（订阅者）而银行就是pub（发布者）。

我要回帖

更多关于 多级缓存 的文章

 

随机推荐