详情页缓存架构

jinzk123

已于 2022-06-28 08:51:00 修改

阅读量246

点赞数

分类专栏：分布式 redis 文章标签：缓存架构 java redis

于 2021-05-22 18:38:08 首次发布

本文链接：https://blog.csdn.net/jinzk123/article/details/110307008

版权

分布式同时被 2 个专栏收录

10 篇文章 0 订阅

订阅专栏

redis

1 篇文章 0 订阅

订阅专栏

本文详细探讨了Redis集群的持久化、读写分离和高可用性，以及大数据场景下的Storm处理和缓存预热策略。同时，介绍了限流降级的Histrix机制，以及如何应对缓存雪崩。实战部分讲解了商品详情页的缓存架构和动态渲染服务的四级缓存策略。

摘要由CSDN通过智能技术生成

3.redis-cluster通过gossip协议通信（ping,pong,meet,fail）

2.storm（nimbus机器+n个supervisor机器）

5. 热点缓存问题nginx+lua+storm自动降级

（7.jenkins可以从github拉取代码，使用maven构建打包，创建镜像并部署

（8.商品详情整体架构

一.redis集群架构

redis持久化的意义在于故障恢复，持久化到磁盘+备份到云服务器可以应对灾难性故障

1.redis持久化

RDB和AOF（写指令的日志）AOF更完整

2.RDB优点：

性能更好，每隔一段时间redis主进程fork子进程执行磁盘IO进行持久化。做冷备RDB相比AOF可以由redis控制固定时长生成快照文件，AOF还需要写脚本。而且RDB是数据快照恢复起来相比指令重放更快。

缺点是容易丢失数据，不适合做第一优先恢复方案，定时写RDB时间间隔一般会比较长。RDB间隔太长生成文件太大对redisfork子进程写RDB可能会有影响。

3. AOF优点

以append-only方式写入，所以没有任何磁盘殉职的开销，写入性能高，文件不易破损。

AOF文件过大，出现后台重写，rewritelog会对其中的指导进行压缩，创建一份需要回复数据的最小日志出来，在创建新日志文件的时候，老的日志文件还是照常写入，新日志ready之后在交换。

在rewrite发生之前可以删除AOF中误操作的指令，重新恢复数据。

缺点是AOF文件相对来说比较大，写qps相比RDB更低。

综合使用RDB和AOF,用AOF来保证数据不丢失，作为数据恢复的第一选择，用RDB来做不同程度的冷备，AOF文件都损坏的时候可以用RDB做快速恢复。

恢复数据之后开启aof要用热修改redis config set,带备份完毕的数据生成了aof之后，开关闭redis改配置文件打开aof

2. 读写分离

一主多从，读写分离主写从读，主同步从。水平扩展slave增加读qps。master主机需开启持久化RDB,AOF.

1.主从复制原理

（第一次启动或重连）master启动子进程（同时继续在内存中缓存最新的数据）生成RDB发送到slave节点，slave将RDB保存到磁盘，然后加载到内存，master再将最新的缓存数据发给slave保证数据一致。slave重连master只会生成断掉这部分时间数据的rdb。
断点续传：master node 会在内存中创建一个backlog，master和slave都会保存一个replica offset还有一个masterId,如果master和slave断掉链接，slave会让master从上次的replica offset开始继续复制，如果没有找到对应的offset,就会执行全量复制。
无磁盘化复制:master在内存中直接创建rdb然后发送给slave,不会在自己本地落地磁盘。repl-diskless-sync
过期key处理：slave不会过期key，只会等待master过期key，master过期了key，会模拟一条命令发送slave

2.复制的完整流程

slave node启动仅保存master node的信息复制未开始（master host和ip在conf里slaveof配置）
slave node有定时任务每秒检查是否有新的master node要连接和复制，有则跟master node建立socket链接
slave node发送ping命令给master node
口令认证，若master设置了requirepass,slave则必须发送masterauth的口令过去认证。
master启动全量复制将所有数据发送给slave
master后续异步将新数据发送给slave node

3.同步相关的核心机制(全量复制)

master和slave都会维护一个offset,slave每秒上报自己的offset给master，master也会保存所有slave的offset
master node复制数据时会将数据在backlog中同步写一份（处理中断后的增量复制）
master run id:master node重启或数据变更，slave node要根据不同的run id区分，run id不同则全量复制不更改run ID重启（debug reload）

从节点使用psync从master node进行复制，psync runid offset,master node根据自身的情况返回响应信息，可能触发全量或增量复制。

3.全量复制

master执行bgsave,本地生成一份rdb文件
master node 将rdb文件发送给slave node,如果rdb文件的复制时间超过60s(repl-timeout),那么slavenode就会认为复制失败
master node生成rdb文件时，会将所有的新的写命令缓存在内存里，在slave node保存了rdb之后再将写命令赋值给slave node
client-output-buffer-limit slave 256mb 64mb 60,如果复制期间内存缓冲区持续消耗超过64mb，或者一次性超过256mb那么停止复制，复制失败
slave node收到rdb,清空旧数据，重新加载rdb到自己的内存，同时基于旧数据版本对外提供服务
slave node开启aof则会执行bgrewrite重写aof

4.增量复制

全量复制过程中，master-slave链接断掉，slave node重连master触发增量复制
master直接从自己的backlog中获取部分丢失的数据发送给slave node,默认backlog1mb
master就是根据slave发送的psync中的offset来送backlog中获取数据

3.redis高可用性

通过哨兵实现高可用监控master节点，并进行主备切换。

1.哨兵（集群通过选举的方式判断master是否宕了，至少三个实例）

集群监控，监控master和slave进程是否正常工作
消息通知，某个redis实例发生故障，哨兵负责发送消息作为报警给管理员
故障转移，如果master node挂掉了会自动转移到slave node上
配置中心，故障转移发生了，通知client客户端新的master地址。
三哨兵集群，quorum=2,majority=2,如果M1机器宕了，三个哨兵剩下两个，s2,s3一致认为master宕机，然后选举一个来执行故障转移

2.数据丢失的情况

异步复制导致，异步复制未发生主备切换发生
集群脑裂：网络问题导致redis master和哨兵集群切断联系,哨兵判断master故障进行主备切换选举新的master，此时原本的master网络恢复。可能client一直与原本的master可以连接写数据，原本的master恢复后变成slave节点，这一部分数据就会丢失。
解决：min-slave-to-write 1 min-slave-max-lag 10 要求至少有一个slave,数据复制和同步延迟不超过10s,一旦所有的slave都超过10s，master就不会再接受请求。
脑裂问题也可以通过两个参数处理，脑裂之后，旧master判断没有slave向master同步数据超过10s则由客户端降级处理。

从节点向主节点发送 REPLCONF ACK {offset} ,频率每秒1次.作用:

试试检测主从网络状态,该命令被主节点用于复制超时的判断.
检测命令丢失,主节点会比较从节点发送的 offset 与自身的是否一致,不一致则从 buffer 中查找对应数据进行补发,如果 buffer 中没有对应数据,则会进行全量复制.
辅助保证从节点的数量和延迟,master 通过 min-salves-to-write 和 min-slaves-max-lag 参数,来保证主节点在不安全情况下不会执行写命令.是指从节点数量太少,或延迟过高。例如 min-slaves-to-write 和min-slaves-max-lag 分别是3和10,含义是如果从节点数量小于3个,或所有从节点的延迟值都大于10s,则主节点拒绝执行写命令。

3.redis-cluster通过gossip协议通信（ping,pong,meet,fail）

4.redis常见问题与调优

5.多级缓存架构

时效性高：双写缓存加数据库时效性不高：异步消息+多级缓存大缓存进行维度拆分提高效率

三级缓存：nginx本地缓存+redis分布式缓存+tomcat jvm堆缓存
读写请求串行化，更新数据库请求和刷新缓存请求放置队列保证顺序性，读请求读不到就hang一会等缓存刷新处理高并发情况；读请求更新缓存，写请求删缓存。
提高缓存命中率nginx分为分发层和应用层，分发层采取根据idhash取模等方式达到一台机器。
openResty打包了lua+nginx，配置nginx导入lua文件执行。
分发层nginxlua脚本分发请求到nginx应用层服务器，应用层lua逻辑调用数据生产服务（http）层层获取数据渲染模版。

二.初级大数据

1.简介

storm ：实时缓存热点数据统计->缓存预热->缓存热点数据自动降级（不存储数据实时数据计算，消息可靠性机制，元数据存储在zk，并行计算）
Hive:高并发访问下，海量日志数据的批量统计分析，日报周报月报，接口调用情况，业务使用情况。
spark：离线批量数据处理，比如从db中一次性倒入亿级数据，清洗处理之后导入redis中供后续使用，大型互联网公司的用户相关数据。
zookeeper：分布式协调，分布式锁，分布式选举-》高可用HA架构，轻量级原数据存储。
HBase：海量数据的在线存储和简单查询，替代mysql分库分表提供更好的伸缩性。
Es:搜索引擎。。。
hadoop：分布式存储，离线数据批处理

2.storm（nimbus机器+n个supervisor机器）

1.核心概念

Topology（拓扑）拓扑涵盖了数据源数据获取/生产+业务处理的代码逻辑（spout+balt）
Spout：数据源的代码组件，我们可以实现spout的一个接口，尝试从数据源中获取数据（kafka中消费数据）
balt：一个业务处理的代码组件，spout将数据传给balt，各种balt可以串联成一个计算链条，实现一个balt接口。
tuple:一条数据，每条数据都会被封装在tuple中，在spout和balt中传递。

2.并行度与task

对于一个拓扑来说并行度就是task，默认情况下一个executor就一个task，最小计算单元是task。每个spout/balt都会运行在一个task中。
流分组：流分组是task与task之间的数据流向关系。（shuffle grouping随机分组发射数据，Fields grouping根据某一个或多个字段）

3.打包部署

将本地storm项目maven打包，用storm jar ***.jar(jar名) topology包路径 topology名
storm有ui启动supervisor机器的ui，启动其他两台supervisor机器的logviewer可以看日志。
部署到nimbus机器上，三台supervisor会启动进程运行。

4.缓存预热

（1. 预热redis

避免高并发请求下redis第一次启动无数据所有请求直接打到mysql
对一系列访问频率高的数据灌入redis在进行启动。
需要根据当天的访问请求状况实时计算出访问频次最高的热数据。并行读取写入redis

(2. 步骤（分段存储按照taskId，技术时采取了FieldsGrouping,因此不同的task持有不同商品的计数，因此预热服务要）

nginx+lua将详情页访问流量日志上报到kafka
storm从kafka中实时消费数据，统计出每个商品的访问次数，访问次数保存基于LRU内存数据结构方案（LRUMap）,维护出一个前N个访问最多商品list。
每个storm task启动基于zk分布式锁，将自己的id写入zk同一个节点中。
每个storm task完成自己热数据的统计，每隔一段时间遍历map，维护前n个商品的list，更新list
写一个后台线程每隔一段时间，将统计过后的前n个商品list更新到zk中。存储到task对应的znode中。
缓存预热的服务有多个实例，每次启动就会去获取一个storm task的列表，根据taskId获取taskId对应的znode分布式锁，取出list从mysql中查询数据写入redis完成预热，多个实例分布式去做基于分布式锁。

（3. 操作

nginx+lua，lua脚本创建kafka producer生产数据到kafka。（可以下载resty包（包装了kafka+lua）继续放到lualib/目录下）
lua既可以进行nginx流量分发，也可以读取缓存数据渲染模板，流量分发机器不动，修改业务数据生产的机器lua，通过require方法获取导入lualib包下指定工具
写一个拓扑，spout从kafka（kafka启动会连zk，消费者通过链接zk消费）中消费数据发射出去--》LogParamBolt负责解析message获取productId--》CountBolt负责统计计数（LRUMap）。并且CountBolt可以起一个线程每隔一分钟遍历LRUMap，获取前n个list，上报到
上报zk流程

CountBolt将自己的taskId初始化时写入zk的node中形成一个task列表
每次都将自己的热门商品列表写入自己的taskId对应的zk节点中
这样并行预热程序会从第一步中获取到task列表
然后根据每个task获取一个锁，从znode中拿到列表，并行处理

（4. 缓存预热服务的操作

预热服务启动进行缓存预热
从zk中读取taskId列表
依次遍历每个taskId，尝试获取对应的分布式锁，获取失败快速报错，说明有其他实例在预热
尝试获取下一个taskId的分布式锁
获取到了分布式锁，检查一下预热状态，预热过则不再预热
进行预热操作，遍历productId列表，读取数据set到redis和echache里
预热完成，设置taskId的预热状态
通过创建zk节点来获取锁，一个节点只会被创建一次。get或setData往节点里获取数据，锁与数据节点均不相同，锁节点最后会删除。
双重zk锁，锁taskId读相应的数据，锁task-status读修改是否预热的状态