亿级流量场景下，大型缓存架构设计实现，你知道吗？(14) _缓存架构

4、与哨兵比较
整个流程跟哨兵相比，非常类似，所以说，redis cluster功能强大，直接集成了replication和sentinal的功能
----------------------------------------------------------------------------------------------------
两套不同的redis缓存架构适用的不同场景
----我们主要使用的是redis cluster模式的缓存框架

文章插图
************实战环节**********
亿级流量商品详情页的缓存架构：
我们之前的三十讲，主要是在讲解redis如何支撑海量数据、高并发读写、高可用服务的架构，redis架构。redis架构，在我们的真正类似商品详情页读高并发的系统中，redis就是底层的缓存存储的支持。
从这一讲开始，我们正式开始做业务系统的开发亿级流量以上的电商网站的商品详情页的系统，商品详情页系统，大量的业务，十几个人做一两年，堆出来复杂的业务系统
几十个小时的课程，讲解复杂的业务，把整体的架构给大家讲解清楚，然后浓缩和精炼里面的业务，提取部分业务，做一些简化，把整个详情页系统的流程跑出来。
架构，骨架，有少量的业务，血和肉，把整个项目串起来，在业务背景下，去学习架构。
讲解商品详情页系统，缓存架构，90%大量的业务代码（没有什么技术含量），10%的最优技术含量的就是架构，上亿流量，每秒QPS几万，上十万的，读并发，缓存架构

文章插图
架构理解：
采用三级缓存：nginx本地缓存+redis分布式缓存+tomcat堆缓存的多级缓存架构
时效性要求非常高的数据：库存
一般来说，显示的库存，都是时效性要求会相对高一些，因为随着商品的不断的交易，库存会不断的变化。
当然，我们就希望当库存变化的时候，尽可能更快将库存显示到页面上去，而不是说等了很长时间，库存才反应到页面上去。
时效性要求不高的数据：时效性要求不高的数据：商品的基本信息（名称、颜色、版本、规格参数，等等）。
时效性高：商品价格/库存等时效性要求高的数据，而且种类较少，采取相关的服务系统每次发生了变更的时候，直接采取数据库和redis缓存双写的方案，这样缓存的时效性最高。
时效性不高：商品基本信息等时效性不高的数据，而且种类繁多，来自多种不同的系统，采取MQ异步通知的方式，写一个数据生产服务，监听MQ消息，然后异步拉取服务的数据，更新tomcat jvm缓存+redis缓存
-------------------------------------------------------------------------------
nginx+lua脚本做页面动态生成的工作，每次请求过来，优先从nginx本地缓存中提取各种数据，结合页面模板，生成需要的页面如果nginx本地缓存过期了，那么就从nginx到redis中去拉取数据，更新到nginx本地
如果redis中也被LRU算法清理掉了，那么就从nginx走http接口到后端的服务中拉取数据，数据生产服务中，现在本地tomcat里的jvm堆缓存中找，ehcache，如果也被LRU清理掉了，那么就重新发送请求到源头的服务中去拉取数据，然后再次更新tomcat堆内存缓存+redis缓存，并返回数据给nginx，nginx缓存到本地