liuerchong的博客

商品详情页的数据，都是从各个服务来的商品服务、价格服务、库存服务、促销服务、广告服务、推荐服务等，商品服务，管理商品的数据 分类管理：增删改查 品牌管理：增删改查 商品基本信息管理：增删改查 商品规格管理：增删改查 商品属性管理：增删改查 商品介绍管理：编辑 价格服务SKU一个商品根据属性的不同会有不同的价格，如：土豪金、白色、深空灰，土豪金的价格就比其他颜色的手机要贵一点还有多件套餐出售，价格也是多种多样库存服务.

消息队列很多时候并不是简单的使用一个 MQ 就可以的，为了应对复杂的场景，需要设计一套复杂的队列几种队列解释有以下几种队列： 任务等待队列 任务排重队列（异构 Worker 对一个时间段内的变更消息做排重） 失败任务队列（失败重试机制） 优先级队列，刷数据队列（依赖服务洗数据）、高优先级队列（活动商品优先级高） 这些队列服务于某一种业务场景而存在的，如下图，已经很复杂了 依赖服务 数据变更信息投递到 消息等待队列 中 ...

项目缓存介绍 nginx 本地缓存：抗热点数据，小内存缓存访问最频繁的数据 各个机房的 redis 集群： 抗大量离散数据，采用一致性 hash 策略构建分布式 redis 缓存集群 tomcat 中的动态服务本地 jvm 堆缓存 支持在一个请求中多次读取一个数据，或者与该数据相关的数据 作为 redis 崩溃的备用防线 固定缓存一些访问频繁更改较少的数据，比如分类、品牌等数据 对缓存过期时间为 redis 过期时间的一

商品详情分为三部分，整体架构如下图： 依赖服务（源） -> MQ -> 动态渲染服务 -> 多级缓存 负载均衡 -> 分发层nginx -> 应用层nginx -> 多级缓存 多级缓存 -> 数据直连服务 负载均衡 + 多机房模板渲染 + 1、2 级缓存 当自己缓存失效时，请求数据直连服务 数据直连服务 + 三级缓存 找自己本地缓存，不存在时从主集群获取信息， 如果主集群也没有，则直接从源服务获取信..

商品详情页介绍商品详情页的多模板化多套模板：比如聚划算商品详情、天猫超市商品、淘抢购、电器城不同模板的元数据大部分是一样的，只是展示方式不一样， 不同的业务，商品学详情页的个性化需求很多，数据来源也很多商品详情页结构拿一个淘宝详情页来举例时效性比较低的数据一个详情页包含了各种各样的数据 商品维度：标题、图片、属性 等等 主商品维度：商品介绍、规格参数 等等 规格 ： 颜色与尺码的笛卡尔积组成了不同的 sku， 一般来看商品介绍、规则参数等都是公用的，而...

什么是缓存穿透？如上图所表述， 简单来说：一个 key 在所有缓存中都不存在，并且在 mysql 中也不存在，叫做缓存穿透根源就在于不存在的 key，考虑一个场景，如果大量不存在的 key 穿透到 mysql，恐怖的事情就来了，很有可能 mysql 被压死缓存穿透解决方案我们的缓存穿透解决方案，其实非常简单：每次从源服务（商品服务）查询到的数据为空，就说明这个数据根本就不存在，需要往 redis 和 ehcache 等缓存中写入一条空数据。另外再配合缓存变更监听推送事件，能让缓存中...

什么是缓存雪崩？简单说：由于缓存不可用，导致大量请求访问后端服务，可能 mysql 扛不住高并发而打死， 像滚雪球一样，影响越来越大，最后导致整个网站崩溃不可用至于为什么会像滚雪球一样？整个与整个系统的架构有关； redis 集群彻底崩溃：不可用 缓存服务在请求 redis 时，会有大量的线程阻塞，占用资源 超时请求失败之后，会去 mysql 查询原始数据，mysql 抗不住，被打死 源头服务由于 mysql 被打死，对源服务的请求也被阻塞，占用资源 缓

怎么保证高可用性：在各种系统的各个地方有乱七八糟的异常和故障的情况下，整套缓存系统还能继续健康的 run 着有一些将高可用的知识：HA、HAProxy 组件，主备服务间的切换，这就做到了高可用性， 主备实例，多冗余实例只是高可用最最基础的东西接下来会讲解在什么样的情况下，可能会导致系统的崩溃？以及系统不可用，针对各种各样的一些情况， 然后我们用什么技术，去保护整个系统处于高可用的一个情况下高可用有很多方式，在这里使用 hystrixhystrix 提供了高可用相关的各种各样的功能，确保在 h

068. 缓存冷启动问题：新系统上线 redis 彻底崩溃导致数据无法恢复什么是缓存冷启动？简单说就是缓存中没有数据，考虑下面两个场景 新系统第一次上线，此时在缓存里可能是没有数据的 系统在线上稳定运行着，但是突然间重要的 redis 缓存全盘崩溃了，而且不幸的是，数据全都无法找回来 系统第一次上线启动，系统在 redis 故障的情况下重新启动，在高并发的场景下就会出现所有的流量 都会打到 mysql（原始数据库） 上去。可能导致 mysql 崩溃以下是图示：「冷启.

接下来，这个商品详情页缓存架构，缓存预热问题和解决方案，缓存热点数据可能导致整个系统崩溃的问题，以及解决方案缓存相关的「热」：预热、热数据在解决方案和架构设计中，会引入大数据的实时计算的技术 storm。为什么要引入这个 storm，难道必须是 storm 吗？我们后面去讲解那个解决方案的时候再说缓存架构和 storm 的关系因为有些热点数据相关的一些实时处理的一些方案，比如快速预热，热点数据的实时感知和快速降级，全部要用到 storm因为我们可能需要实时的去计算出热点缓存数据，我们的业

什么是分布式缓存重建并发冲突问题？很简单，多个缓存服务实例提供服务，发现缓存失效，那么就会去重建，这个时候回出现以下几种情况： 多个缓存实例都去数据库获取一份数据，然后放入缓存中 新数据被旧数据覆盖 缓存 a 和 b 都拿了一份数据，a 拿到 12:00:01 的数据，b 拿到 12:00:05 的数据 缓存 b 先写入 redis，缓存 a 后写入。 以上问题有多重解决方案，如： 利用 hash 分发 相同商品分发到同一个服务中，服务中再用队列去重建 但是这就

缓存数据生产服务那一层已经搞定了，相当于三层缓存架构中的本地堆缓存 + redis 分布式缓存都搞定了就要来做三级缓存中的 nginx 那一层的缓存了缓存命中率低如果一般来说，你默认会部署多个 nginx，在里面都会放一些缓存，就默认情况下，此时缓存命中率是比较低的如上图，被均衡分发了，所以命中率很低。如何提升缓存命中率？方案：分发层+应用层，双层 nginx分发层 nginx，负责流量分发的逻辑和策略，这个里面它可以根据你自己定义的一些规则， 比如根据 product.

多级缓存的架构主要用来解决的问题是：时效高低数据的维度存储时效性不高的数据，比如一些商品的基本信息，如果发生了变更，假设在 5 分钟之后再更新到页面中， 供用户观察到，也是 ok 的，那么我们采取的是异步更新缓存的策略时效性要求很高的数据，如库存，采取的是数据库 + 缓存双写的技术方案，也解决了双写的一致性的问题上面这两条可能直接看觉得好像差不多的，这里忽略了一个解释，对于页面来说，需要静态的生成页面， 这个过程可能稍微耗时一些，而对于双写来说则快太多了，它不负责页面渲染等工作，只需要把缓存数据

一，多级缓存架构，从底往上做，先分析缓存数据的生产数据库底层这一块如上图 监听多个 kafka topic，每个 kafka topic 对应一个服务 简化一下，监听一个 kafka topic 如果一个服务发生了数据变更，那么就发送一个消息到 kafka topic 中 缓存数据生产服务监听到了消息以后，就发送请求到对应的服务中调用接口以及拉取数据，此时是从 mysql 中查询的 缓存数据生产服务拉取到了数据之后，会将数据在本地缓存中写入一份，就是 e.

整个缓存的技术方案，分成两块 实时性较高数据 比如说库存，销量之类的这种数据，我们采取的实时的缓存+数据库双写的技术方案，双写一致性保障的方案 实时性要求不高的数据 比如说商品的基本信息，等等，我们采取的是三级缓存架构的技术方案，就是说由一个专门的数据生产的服务，去获取整个商品详情页需要的各种数据，经过处理后，将数据放入各级缓存中，每一级缓存都有自己的作用 我们先来看看一下，所谓的这种实时性要求不高的数据，在商品详情页中，都有哪些电商网站中的商品详情页的数据结构分析商品的

再来回顾下之前的思路： 数据更新：根据唯一标识路由到一个队里中，「删除缓存 + 更新数据」 数据读取：如果不在缓存中，根据唯一标识路由到一个队里中，「读取数据 + 写入缓存」 投入队里之后，就等待结果完成，由于同一个标识路由到的是同一个队列中， 所以相当于加锁了。下面就来实现这个思路，分几步走： 系统初启动时，初始化线程池与内存队列 两种请求对象封装 请求异步执行 service 封装 两种请求 Controller 封装 读请求去重优化

前面讲解完了 redis 如何支撑海量数据、高并发读写、高可用服务的架构redis 架构，在我们的真正类似商品详情页读高并发的系统中，redis 就是底层的缓存存储的支持从现在开始，我们正式开始做业务系统的开发商品详情系统旁白亿级流量以上的电商网站的商品详情页的系统，真实的系统中包含大量的业务，十几个人做一两年才堆出来复杂的业务系统。如果只是纯粹的架构，那么就是一个骨架，所以必须有少量的业务，有血有肉，把整个项目串起来，在业务背景下去学习架构，效果才会理想讲解商品详情页系统，主要讲解

redis cluster 的核心原理分析：gossip 通信、jedis smart 定位、主备切换[[toc]]节点间的内部通信机制基础通信原理redis cluster 节点间采取 gossip 协议进行通信gossip：互相之间不断通信，保持整个集群所有节点的数据是完整的而集中式是将集群元数据（节点信息，故障，等等）集中存储在某个节点上；经典的集中式中间件 zookeeper他们基本上都用于维护集群的元数据集中式： 优点：数据更新及时，时..

上一篇 将 redis cluster 搭建起来了redis cluster 提供了多个 master，数据可以分布式存储在多个 master 上; 每个 master 都带着 slave，自动就做读写分离; 每个 master 如果故障，那么就会自动将 slave 切换成 master，高可用redis cluster 默认是不支持 slave 节点读或者写的，跟我们手动基于 replication 搭建的主从架构不一样的slave node 上 使用 readonly，get，这个时候.

redis 如何在保持读写分离+高可用的架构下，还能横向扩容支撑 1T + 海量数据后面会老提到 读写分离和 master。之前的课程讲解中说了读写分离后的水平扩容是通过扩容 slave 来达到的。但是在实际生产环境中，读写分离支持不是很好，特别的 java 这种客户端，可以做到但是稍微复杂这里的说明其实我也不太听明白，记住一条信息：通过 master 去扩容的单机 redis 在海量数据面前的瓶颈之前讲解的一主多从架构，master 的瓶颈这种架构的瓶颈只是解决了 ..

动手实操，练习如何操作部署哨兵集群，如何基于哨兵进行故障转移，还有一些企业级的配置方案在这之前我一直以为 redis sentinel 是另外的一个项目，其实不是，还是 同一个 redis ，不过是通过 redis-sentinel + sentinel 配置文件 启动的另一个程序采用一主（MASTER）二从（SLAVE）三哨兵(SENTINEL)的架构前面已经在windows上搭建过一主两从高可用redis 6380主，6381，6382从现在在每个redis文件夹下新建一个sentine

redis 哨兵主备切换的数据丢失问题：异步复制、集群脑裂两种数据丢失的情况异步复制导致的数据丢失因为 master -> slave 的复制是异步的，所以可能有部分数据还没复制到 slave，master 就宕机了，此时这些部分数据就丢失了脑裂导致的数据丢失何为脑裂？如上图由于一个集群中的 master 恰好网络故障，导致与 sentinal 联系不上了，sentinal 把另一个 slave 提升为了 master。此时就存在两个 master了。当我们..

redis支持十万级的高并发架构搭建完成，那么下面讲解保证架构高可用那么redis 主从架构下如何才能做到 99.99% 的高可用性？什么是 99.99% 高可用？ 不可用：系统挂掉，很难恢复起来，短时间内都不行，这就不可用 高可用：全年 99.99/99.9/99 % 的时间都能正常提供服务就是高可用 这里有一个比较学术点的解释：可用性的高低 是使用 不可用时间 占 总时间 的比例来衡量。不可用时间是从故障发生到故障恢复的时间。比如，可用性 4 个 9 的系统（99.9..

部署 redis 的读写分离架构（包含节点间认证口令）之前了解了各种 redis replication 的原理和知识，那么怎么搭建呢？只搭建一主一从，往主节点去写，在从节点去读，可以读到，主从架构就搭建成功了## 启用复制，部署 slave node在 centos6.5 上安装 redis，一个IP地址为192.168.25.128，一个为192.168.25.129，分别安装好之后，128开启 `slaveof <masterip> <masterport>`

redis replication 的完整流运行程和原理的再次深入剖析复制的完整流程 slave node 启动，仅仅保存 master node 的信息 但是复制流程没开始，master 信息包括 host 和 ip ， 那么是从哪儿来的？是在配置文件 redis.conf 里面的 slaveof 配置的 slave node 定时检查是否需要与 master 连接 内部有个定时任务，每秒检查是否有新的 master node 要连接和复制，如果发现，就跟 maste.

redis 如何通过读写分离来承载读请求 QPS 超过 10 万 +？首先我们来聊一下QPS关于高并发程序的几个重要概念吞吐量（TPS）、QPS、并发数、响应时间（RT）QPS原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间。公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器 。每天300w PV 的在单台机器上，这台机器需要多少QPS？.

redis 企业级数据备份方案到这里为止，其实还是停留在简单学习知识的程度，学会了 redis 的持久化的原理和操作，但是在企业中，持久化到底是怎么去用得呢？企业级的数据备份和各种灾难下的数据恢复，是怎么做得呢？企业级的持久化的配置策略在企业中，RDB 的生成策略，用默认的也差不多，如果有可能改动的地方，可能是如下两个配置： save 60 10000：如果你希望尽可能确保说，RDB 最多丢 1 分钟的数据，那么尽量就是每隔 1 分钟都生成一个快照，低峰期，数据量很少，也没必要.

图解分析 redis 的 RDB 和 AOF 两种持久化机制的工作原理我们已经知道对于一个企业级的 redis 架构来说，持久化是不可减少的牢记企业级 redis 集群架构是用来支撑海量数据、高并发、高可用持久化主要是做灾难恢复、数据恢复，也可以归类到高可用的一个环节里面去 :::比如你 redis 整个挂了，redis 就不可用了，你要做的事情是让 redis 变得可用，尽快变得可用你会怎么做？你会重启 redis，尽快让它对外提供服务，但是就像上一讲说，如果你没做数据备份，这..

商品详情页的架构实现缓存架构的第一块儿，要掌握的很好的，就是 redis 架构高并发、高可用、海量数据、备份、随时可以恢复，缓存架构如果要支撑这些要点，首先 redis 就得支撑redis 架构它自身就支持：每秒钟几十万的访问量 QPS、99.99% 的高可用性，TB 级的海量的数据、备份和恢复，有了它缓存架构就成功了一半了最最简单的模式，无非就是存取 redis，存数据，取数据，支撑你的缓存架构，最基础的就是 redis 架构解决各种各样高并发场景下的缓存面临的难题，缓存架构中不断的引

小型电商网站的商品详情页的页面静态化架构以及其缺陷背景是商品详情页的系统架构，以此基础讲解 -> 缓存架构 -> 高并发 -> 高可用电商网站里，大概可以说分成两种， 小型电商，简单的一种架构方案，页面静态化的方案； 大型电商，复杂的一套架构 为了讲解大型电商的详情页架构，这里先把小型的讲解下部分页面静态化或全量的页面静态化先来看看页面静态化带来的问题，假设有一个商品详情页的模板如下<html> <title>&lt

课程的一个简单的介绍亿级流量的电商网站商品详情页的整体架构其中 复杂的缓存架构：才是我们最真实要讲解的东西，支撑高并发、高可用缓存架构过程中，我们会讲解各种高并发场景下的各种难题，怎么去解决这些难题、缓存架构的过程、各种技术和解决方案、高可用性「亿级流量电商网站的商品详情页系统」的架构讲解会作为项目背景贯穿，且项目实战； 缓存架构，支撑高并发，高可用的系统架构；在缓存架构的过程中，高并发以及高可用相关的各种技术点和知识点、解决方案串在一起讲解了这套课程，下面的 问题学完以后，会学到很