【Redis】前言--介绍redis的全局系统观

原创 已于 2023-11-24 14:15:30 修改 · 301 阅读 · 0 ·
CC 4.0 BY-SA版权
本文为博主原创文章，未经博主允许不得转载。
文章标签：

#redis #数据库 #缓存

于 2023-11-24 14:14:55 首次发布
本文引导读者通过学习Redis的系统架构图，包括思维导图、平铺图和画像图，以形成整体理解，避免碎片化知识，同时提到了参考《极客时间》中Redis核心技术与实战的重要性。

一.前言

      学习是要形成自己的网状知识以及知识架构图，要不最终都还是碎片化的知识，不能达到提升的目的，只有掌握了全貌的知识才是全解，要不只是一知半解。这章会介绍redis的系统架构图，帮助认识redis的设计是什么样的，方便后续的学习。

二.系统架构图

     2.1  思维导图

         

2.2  平铺图

2.3  画像图

三.注意

1.借鉴 极客时间 redis 核心技术与实战

博客系统案例练习2-用户注册-redis
ck的博客
04-20 1116
在对于性能要求⽐较⾼的模块中,Redis作为⼀个缓存层,经常存储⼀些热点数据,减少数据库的读取压⼒,提⾼数据访问速度Redis 是⼀种基于键值对（key-value）的NoSQL数据库，与很多键值对数据库不同的是，Redis中的值可以是由string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）、Bitmaps（位图）、HyperLogLog、GEO（地理信息定位）等多种数据结构和算法组成，因此Redis。
go-zero&go web集成redis实战
small_to_large的博客
09-06 1264
go-zero&go web集成redis、go-redis实战
17 redis-server 的启动
970655147的专栏
08-28 6675
前言 相关介绍主要围绕着 redis 服务的启动相关 redis-server 的启动, 是执行 server.c 的 int main(int argc, char **argv), 我们这里看的是 standalone 的情况下的服务的启动流程 本文的相关代码 拷贝自 redis-6.2.0 代码来自于https://redis.io/ 初始化服务配置 初始化 随机种子, 初始化 hashseed, 初始化服务器的配置[server.xxx 系列], 记录命令行参数...
Linux系统搭建redis-cluster集群案例
weixin_44823875的博客
12-15 1617
本文是在一台服务器上搭建多个redis的伪集群方式来进行讲解，后续要换成多台步骤类似。Redis5.0前采用redis-trib进行集群的创建和管理，需要ruby支持Redis5.0可以直接使用Redis-cli进行集群的创建和管理。本文用的是redis版本5.0.5。
Redis实战-单机项目下实现优惠劵秒杀【万字长文】
a6543665的博客
05-27 1072
今天看了Redis实战篇有关优惠券秒杀的视频，学习了很多很多的东西，想要讲一讲。
SpringBoot集成Redis-6.x版本流程
nandao158的博客
06-28 334
到此，SpringBoot集成Redis分享完成，下篇我们分享器源码相关，敬请期待。4）多个key获取数据。1）保存并获取字符串。5）使用注解获取缓存。
Redis-内存管理
hyWang94
11-28 596
内存消耗 进程自身消耗 自身内存 对象内存 缓冲内存 客户端缓冲 查看指令 redis-cli config get client-output-buffer-limit 返回：“normal x x x slave x x x pubsub x x x”，其中第一个normal代表普通客户端，slave代表从客户端，pubsub代表订阅客户端。 x代表参数，0代表不限制，第一个x表示最大值，第二个是多少秒内最大值（秒在第三个参数配置），如果超过这个最大值就会关闭连接，第三个表示多少秒。单位都是字节 可以通
Redis源码---如何实现一个性能优异的Hash表
汤键的博客
02-28 691
Redis源码---如何实现一个性能优异的Hash表
Redis实战-基于redis和lua脚本实现分布式锁以及Redission源码解析【万字长文】
a6543665的博客
05-31 2264
分布式锁是一种在分布式系统中用于协调多个节点或进程对共享资源进行互斥访问的机制。它的核心目标是确保在分布式环境下，同一时间只有一个节点能够执行关键操作（如修改共享数据、访问数据库等），避免并发导致的数据不一致问题。分布式锁是在分布式系统中协调多个节点对共享资源访问的一种同步机制。同俗一点解释就是，只能管住自己JVM里的线程，而Redis分布式锁相当于一个"全局管理员"，能管住所有JVM的线程，让它们在集群里排队用资源。就好比单机游戏（只能在本机内存档）和网游游戏的区别（所有电脑都可以读取存档）
Redis数据结构总结-哈希表
左灯右行的爱情
02-19 1116
Hash 表是一种非常关键的数据结构。比如在数据库系统中，Hash 表被用来辅助 SQL 查询。而对于 Redis 键值数据库来说，Hash 表既是键值对中的一种值类型，同时，Redis 也使用一个全局 Hash 表来保存所有的键值对，从而既满足应用存取 Hash 结构数据需求，又能提供快速查询功能。Hash 表应用如此广泛的一个重要原因，就是从理论上来说，它能以 O(1) 的复杂度快速查询数据。
写最好的最新稳定版Redis7（redis-7.0.5）在云服务器Centos7安装部署教程（参考官方文档）
u014282578的博客
11-27 7015
本教程参考官方文档，在云服务器Centos7上安装部署最新稳定版Redis-7.0.5，有些地方有坑，笔者也是一边踩坑一边填坑，教程内容里面会有说明。本文和其它博文不太一样，其它博文可能只“照猫（网络上的博文）画虎”，天下内容一片抄，本文即使是“画虎”，也是按照“猫（官方文档）”的哪些部位去详细地描绘。笔者意在写最好的最新稳定版Redis7安装教程。
redis 过期删除策略、惰性删除（lazy-free），深入剖析
持之以恒
10-11 6351
如果一个键过期了，什么时候会被删除呢？又如何找出这些过期 key 并删除？会不会影响服务正常运行？ redis 中有两种 key，一种带有 expire 过期时间，另一种则是不带过期时间，本文讨论的过期删除策略是针对带有 expire 过期时间的 key。 为了方便找出带过期时间并且已经过期的 key，redis 用了额外的字典专门存储带 expire 过期时间的 key，这样一来，只需遍历该字典即可找出过期的 key。
Redis7——进阶篇（一）
想飞的dragon
02-28 1194
本篇旨在介绍redis的经典面试，通过对面试题拆分、细化，来巩固redis相关知识，为以后面试打下夯实的基础。
Redis 02-实战篇Redis
qq_43409973的博客
04-03 643
在这个方案中，他确实可以使用对应路径的拦截，同时刷新登录token令牌的存活时间，但是现在这个拦截器他只是拦截需要被拦截的路径，假设当前用户访问了一些不需要拦截的路径，那么这个拦截器就不会生效，所以此时令牌刷新的动作实际上就不会执行，所以这个方案他是存在问题的前言什么是缓存?就像自行车,越野车的避震器举个例子:越野车,山地自行车,都拥有"避震器",防止车体加速后因惯性,在酷似"U"字母的地形上飞跃,硬着陆导致的损害,像个弹簧一样;
Redis实现全局唯一id
时间如瑾 代码如诗
05-30 1409
ID 生成器在微博我们一直叫发号器，微博就是用这样的号来存储，而我微博里讨论的时候也都是以发号器为标签。它的主要目的确如平常大家理解的“为一个分布式系统的数据object产生一个唯一的标识”，但其实在一个真实的系统里可能也可以承担更多的作用。唯一性时间相关粗略有序可反解可制造下面我会分别讲每个作用后面的考虑和权衡，也会对比介绍一下业界已知的几种 ID 设计。要唯一性，是否需要全局唯一？
Redis 安全加固终极指南
SmallBull的博客
12-17 1130
Redis安全加固指南摘要： 本文提供Redis数据库全面安全防护方案，涵盖7个关键维度：1）网络隔离：通过IP绑定和防火墙限制访问；2）身份认证：推荐使用Redis6+的ACL精细化权限控制；3）命令安全：禁用或重命名FLUSHALL等高危命令；4）通信加密：配置TLS/SSL传输加密；5）运行安全：以非root用户运行并设置内存保护；6）监控审计：开启日志记录和审计功能；7）应急响应：制定入侵处理预案。强调安全核心原则是最小权限+多层防御，必须完成绑定IP、强密码认证、禁用高危命令等基础防护，并建议定期
redis-Lettuce 框架因网络黑洞导致恢复时间变长
最新发布
line_on_database的博客
12-19 675
生产上出现了两次 Redis 宿主机或者本身故障的情况，Redis 很快出现了切换，业务的影响面却在 15 分钟以上，使用的SDK 为 Lettuce外贸通这里需要将 Lettuce 升级为 6.3.0 + 版本并配置 tcp_user_timeout , Lettuce 详细参数见文档对于部分网卡宕机、网络分区故障等情况，概率性不会产生 RST。大多数的宕机，操作系统会在退出前给客户端发送 RST，因此这个问题不是切换或者宕机就必现；引用文章：详细文章net.ipv4.tcp_retries2 是 Lin
RedisTemplate、StringRedisTemplate、RedisIndexedSessionRepository之间的区别？
2201_75642742的博客
12-19 790
组件用途是否需手动操作数据格式典型场景通用 Redis 操作✅ 是二进制（默认）缓存对象、复杂数据结构字符串 Redis 操作✅ 是可读字符串缓存 JSON、计数器、简单 KVHTTP Session 存储到 Redis❌ 否（自动）Spring Session 内部格式分布式 Web 应用 Session 共享@Bean// 使用 JSON 序列化这样也能存可读的 JSON，但通常不如直接用灵活。
ELK + Redis Docker 企业级部署落地方案
赵玉的专栏
12-15 995
本文介绍了一个基于Docker的企业级ELK+Redis日志收集与分析系统部署方案。方案采用Docker Compose编排，包含Elasticsearch集群(3节点)、Logstash集群(2节点)、Kibana(2节点)和Redis主从复制(2节点)架构，并集成Prometheus、Grafana等监控工具。部署内容包括：1) 详细的环境准备和目录结构；2) Docker Compose编排文件；3) 各组件配置文件模板；4) 初始化、启动、健康检查等运维脚本；5) 监控告警配置；6) 备份恢复策略。
前言 1.1. 背景和目标 VMS Cloud Event模块作为承载海量设备事件上报的核心组件，负责事件过滤、转发、存储等复杂处理逻辑。当前依赖的公共组件EventCenter仅支持基础订阅消费能力，存在以下瓶颈： 异常事件处理缺失：失败事件直接丢弃，无重试/隔离机制； 时效性不足：缺乏延迟触发能力（如定时删除事件）； 扩展性弱：无法适配新增的复杂业务场景（如设备批量操作或批处理）。 本模块在项目中处于事件处理链路的核心地位，直接影响设备事件的可靠性与时效性。本需求分析文档的撰写目标是明确死信队列与延迟队列的功能需求、非功能性需求及实现方案，为后续开发提供指导。 1.2. 定义 死信队列（Dead Letter Queue, DLQ）：存储无法被正常消费的异常消息（如重试耗尽、消费失败），用于错误隔离与问题排查。 延迟队列（Delayed Queue）：支持消息在指定延迟时间后被消费，用于异步定时任务（如定时删除事件）。 EventCenter：现有公共组件，提供事件发送、处理器注册等基础能力，支持Kafka、Local实现。 指数退避原则：设置初始等待时间，发生可重试错误时重试，再次发生错误时等待时间会以指数级别增长。 1.3. 参考资料 kafka官方文档（Apache Kafka Documentation）：用于死信队列自定义拦截器实现参考。 EventCenter现有设计文档（Event Center 使用说明文档 - CRD_EP_Software_Service - Confluence）及EventCenter学习报告（EventCenter组件学习报告 - CRD_EP_Software_Service - Confluence）：包含模块结构、核心接口及消息处理模式说明。 kafka消息范式调研报告（kafka消息范式扩展调研报告 - CRD_EP_Software_Service - Confluence）：包含kafka消息范式扩展概述，死信队列及延迟队列设计与实现。 2. 调研结果 2.1 死信队列（Dead Letter Queue, DLQ）设计与实现 2.1.1 死信队列核心价值 死信队列是存储“无法被正常消费的消息”的特殊队列，核心作用： 错误隔离：避免异常消息阻塞主消费流程，保障主队列吞吐量。 问题追踪：集中存储失败消息（含上下文、错误日志），便于定位根因。 数据补偿：支持人工/自动修复后重新投递，减少数据丢失风险。 2.1.2死信队列常见设计方案 方案1：基于Kafka消费者拦截器（Consumer Interceptor） 实现原理： 在Kafka消费者端实现ConsumerInterceptor接口，拦截poll()返回的消息。当消费逻辑（如EventHandler.handle()）抛出异常时，拦截器捕获失败消息，通过独立生产者将其发送至死信Topic（如vms_dlq_topic），并提交原消息的偏移量（避免重复消费）。 关键流程： 消费者从Kafka拉取消息（poll()）。 拦截器预处理消息（如记录元数据）。 业务逻辑消费消息（调用handleEvent()）。 若消费成功，正常提交偏移量；若失败，拦截器： 记录失败原因（异常堆栈、重试次数）。 通过独立生产者将消息发送至死信Topic。 提交原消息偏移量（避免重复消费）。 worddavc4f46eb0b4de0b1c28abbc3921c9884a.png 优点： 完全基于Kafka原生API，无需引入外部中间件。 灵活控制重试策略（如最大重试次数、间隔）。 与业务代码解耦（拦截器逻辑独立）。 缺点： 需开发拦截器逻辑，增加代码复杂度。 独立生产者需处理线程隔离（避免阻塞主消费线程）。 依赖消费者端配置（需为每个消费者组启用拦截器）。 方案2：基于Kafka生产者回调（Producer Callback） 实现原理： 在消息发送阶段，通过生产者的Callback接口捕获发送失败的消息（如网络异常、Broker不可用），将其直接发送至死信Topic。此方案主要处理“发送失败”的消息，而非“消费失败”的消息。 关键流程： 生产者调用send()发送消息，附加Callback。 若消息成功写入Kafka（RecordMetadata返回），流程结束。 若发送失败（Exception抛出），Callback捕获异常，将原消息+异常信息封装后发送至死信Topic。 优点： 直接捕获发送阶段的失败消息，避免未达Broker的消息丢失。 实现简单（仅需在生产者端添加回调逻辑）。 缺点： 仅覆盖“发送失败”场景，无法处理“消费失败”的消息。 死信Topic需与主Topic同步扩容，增加运维成本。 方案3：Confluent平台DLQ支持（Kafka生态扩展） 实现原理： Confluent平台（Kafka商业发行版）提供内置DLQ功能，通过在消费者配置中指定dead.letter.topic.name，当消息消费失败（如反序列化异常、处理超时）时，Confluent客户端自动将消息转发至死信Topic。 优点： 零代码开发（仅需配置），集成成本低。 自动处理反序列化失败、消费超时等异常场景。 缺点： 依赖Confluent商业组件（需评估License成本）。 仅支持Confluent客户端（与原生Kafka客户端不兼容）。 无法自定义重试策略（依赖默认逻辑）。 其他中间件对比 RabbitMQ DLX：通过绑定“死信交换器”实现，支持消息拒绝、超时、队列满等场景自动路由。优点是原生支持，缺点是与Kafka技术栈不兼容。 RocketMQ DLQ：为每个消费者组自动创建死信队列（%DLQ%+组名），重试耗尽后自动存储。优点是无需开发，缺点是死信无法自动消费（需人工干预）。 2.1.3 死信队列方案对比总结 消费者拦截器 消费失败消息隔离 自主可控、兼容原生Kafka 需开发拦截器，线程隔离复杂 生产者回调 发送失败消息隔离 实现简单、覆盖发送阶段 不处理消费失败场景 Confluent DLQ 快速集成、低代码场景 零开发、自动转发 依赖商业组件，License成本高 2.2 延迟队列（Delayed Queue）设计与实现 2.2.1 延迟队列核心价值 延迟队列支持消息在指定延迟时间后被消费，典型场景包括： 定时任务触发（如设备事件30分钟后删除）。 失败重试（如消费失败后5分钟重试）。 订单超时取消（如未支付订单30分钟后自动关闭）。 2.2.2 延迟队列常见设计方案 方案1：基于Redis有序集合（ZSet）的Kafka扩展 实现原理： 结合Kafka与Redis，将延迟消息暂存于Redis ZSet（以到期时间戳为score），通过定时任务扫描ZSet，将到期消息发送至Kafka目标Topic。 关键流程： 消息生产：生产者将延迟消息（含事件内容、延迟时间）存入Redis ZSet（Key：vms_delay_queue，score=当前时间+延迟时间）。 扫描触发：定时任务（如每1秒）执行ZRANGEBYSCORE vms_delay_queue 0 <当前时间戳>，获取到期消息。 消息投递：将到期消息通过Kafka生产者发送至目标Topic（如vms_delete_event_topic）。 异常处理：若投递失败，重新设置消息的score（当前时间+10秒）并重新插入ZSet，等待下次扫描。 worddav39d7de94833eb9c9b2016e420c5fb318.png 优点： 支持任意延迟时间（毫秒级精度）。 复用现有Redis资源（如VMS缓存集群），无需引入新中间件。 分布式友好（通过Redis主从复制保障高可用）。 缺点： 需开发定时扫描逻辑（需处理并发扫描、消息去重）。 依赖Redis持久化（如AOF）保障消息不丢失。 扫描间隔与精度权衡（间隔过小增加Redis压力，过大导致延迟误差）。 方案2：基于时间轮算法的Kafka内部扩展 实现原理： 时间轮（Time Wheel）是一种高效的延迟任务调度算法，通过“轮盘槽位”管理延迟任务。Kafka的KafkaDelayedMessage和Netty的HashedWheelTimer均基于此原理。在Kafka中，可扩展消费者端实现时间轮，将延迟消息按到期时间分配至不同槽位，轮盘转动时触发消息投递。 关键设计： 时间轮结构：轮盘分为多个槽位（如100个），每个槽位代表1秒。 消息入轮：计算消息到期时间与当前时间的差值，分配至对应槽位（如延迟5秒的消息放入槽位5）。 轮盘转动：每秒移动一个槽位，触发当前槽位的消息投递。 优点： 时间复杂度O(1)，高吞吐量下延迟低（百万级消息/秒）。 无需外部存储（依赖内存），响应速度快。 缺点： 需深度修改Kafka客户端源码（开发难度大）。 内存限制（槽位数量与消息容量需平衡，大延迟消息可能跨多轮）。 消息持久化困难（内存数据易丢失，需结合日志备份）。 方案3：基于Kafka分区与消费者暂停的分桶策略 实现原理： 利用Kafka的分区特性，为不同延迟时间创建独立分区（或Topic），消费者通过pause()和resume()控制分区消费时机。例如，为延迟5秒、30秒、5分钟的消息分别创建分区，消费者启动时暂停所有分区，根据当前时间计算各分区的恢复时间（如5秒后恢复延迟5秒的分区）。 关键流程： 消息生产：根据延迟时间将消息发送至对应分区（如topic-delay-5s、topic-delay-30s）。 消费者初始化：订阅所有延迟分区，调用pause()暂停消费。 定时恢复：定时任务检查当前时间，对到期的分区调用resume()，触发消息消费。 优点： 完全基于Kafka原生功能，无需外部组件。 分区隔离保障不同延迟消息的独立性。 缺点： 仅支持预设延迟等级（如5s、30s），无法动态调整。 分区数量随延迟等级增加而膨胀（如支持10种延迟需10个分区）。 消费者需维护复杂的分区恢复逻辑（易出错）。 其他中间件对比 RabbitMQ延迟交换器：通过x-delayed-message交换器实现，消息设置x-delay字段。优点是毫秒级精度，缺点是依赖插件且与Kafka不兼容。 RocketMQ延迟消息：支持18级预设延迟（1s~2h），Broker暂存后转发。优点是原生支持，缺点是延迟等级固定。 2.2.3 延迟队列方案对比总结 Redis ZSet 自定义延迟、资源复用场景 灵活、复用现有资源 需开发扫描逻辑，依赖Redis 时间轮算法 高吞吐量、低延迟场景 高效、低延迟 开发难度大，内存依赖 Kafka分区分桶 预设延迟、原生依赖场景 无需外部组件 延迟等级固定，分区膨胀 3. 功能需求 3.1. 总体描述 本模块为VMS系统事件相关组件EventCenter的扩展模块，聚焦死信队列（DLQ）与延迟队列的功能实现，解决现有EventCenter的异常事件处理不完善、时效性不足问题。模块通过低侵入式扩展（最小化修改EventCenter原生代码）提供配置化管理、灵活的重试策略及定时触发机制，支持开发人员通过EventCenter原生接口调用扩展功能（如发送延迟消息、启用死信队列），运维人员通过配置平台管理策略（如重试次数、延迟等级）。 扩展模块架构如下图所示： 3.1.1. 需求主体 开发人员 VMS业务系统开发者，调用EventCenter的接口开发消息队列相关功能（如设备事件上报），需通过扩展接口启用死信队列、发送延迟消息以及配置相关策略。 运维人员 VMS系统运维人员，负责监控死信堆积量。 3.1.2. 功能模块划分 配置管理模块 01 管理死信队列（开关、重试策略）的全局配置，支持开发人员通过EventCenter接口传递配置。 死信处理模块 02 基于EventCenter消费者拦截器扩展，捕获消费失败消息，执行重试逻辑，发送至DLQ并记录日志，与EventCenter原生消费流程解耦。 延迟消息管理模块 03 两种延迟方案：Redis ZSet/Kafka分区分桶（目前选用redis zset方案，可调整）； 支持发送延迟消息，用延迟队列时通过调用相关方法选择延迟时间 监控与告警模块 04 监控死信堆积量、延迟消息触发成功率。 3.1.3. 用例图 3.2. 功能模块1：配置管理模块（模块编号01） MQE-01-0001 支持死信队列开关配置（默认关闭） 开发人员通过EventCenter的相关接口启用，避免非必要资源消耗。 开发人员 高 MQE-01-0002 支持自定义重试次数（默认3次） 开发人员通过接口设置，某些业务需修改重试次数。 开发人员 高 MQE-01-0003 支持重试间隔策略配置（默认指数退避，可选固定间隔、自定义/预设） 开发人员通过setRetryPolicy(topic, policy)接口设置，默认指数退避（如1s→2s→4s）。 开发人员 高 MQE-01-0004 支持死信名称配置（默认业务名_dlq_topic), 开发人员开启死信队列时需要设置对应业务的死信名称，未自定义业务使用默认。 开发人员 中 配置管理流程图如下图所示： 3.3. 功能模块2：死信处理模块（模块编号02） 典型场景：事件消费时，因业务逻辑异常导致消费失败，重试3次（默认值）后仍失败，消息需进入死信队列，避免阻塞主流程。 MQE-02-0001 基于EventCenter消费者拦截器扩展，无侵入式集成 拦截器实现ConsummerInceptor接口，不修改原生消费逻辑。 开发人员 高 MQE-02-0002 捕获消费失败消息 拦截器监听EventHandler.handleEvent()的异常抛出。 系统 高 MQE-02-0003 执行重试逻辑（基于配置的重试次数和间隔），重试时间通过延迟队列实现 重试期间记录重试次数，避免无限重试。 系统 高 MQE-02-0004 重试耗尽后，将消息发送至DLQ（含原消息体、异常堆栈、重试次数） 死信消息通过独立Kafka生产者发送，不阻塞主消费线程。 系统 高 MQE-02-0005 提交原消息偏移量（仅在死信发送成功后） 避免重复消费（通过KafkaConsumer.commitSync(offset)实现）。 系统 高 MQE-02-0006 记录死信日志（含消息ID、Topic、业务标识、失败时间、错误原因） 运维人员订阅死信topic，通过其中日志追溯上下文 运维人员 中 3.4. 功能模块3：延迟消息管理模块（模块编号03） 典型场景：VMS设备删除时，需先删除事件上报，然后延迟一定时间后删除设备，避免设备删除后仍有事件上报导致数据不一致。方案还未确定，将写出两个方案的需求。 3.4.1 Redis ZSet方案需求 MQE-03-0001 支持开发人员通过sendDelayedEvent(topic, event, delayS)方法发送自定义延迟消息 延迟时间单位为秒（如30分钟=1800s），兼容任意延迟需求。（如需要扩展，添加时间转换或设置不同时间单位的参数） 开发人员 高 MQE-03-0002 消息存储至Redis ZSet（Key格式：vms_delay_） 按Topic隔离数据，避免不同业务消息混淆（如设备事件与订单事件）。 系统 高 MQE-03-0003 定时扫描ZSet（间隔可配置，默认1秒）获取到期消息 扫描线程独立于EventCenter主线程，避免资源竞争。 系统 高 MQE-03-0004 到期消息通过EventCenter的send()接口发送至目标Topic（默认原Topic） 开发人员可通过参数指定目标Topic（如sendDelayedEvent(topic, event, delayS, targetTopic)）。 开发人员 高 MQE-03-0005 发送失败时重新插入ZSet（新到期时间=当前时间+重试间隔，默认10秒） 重试间隔可通过setDelayRetryInterval(interval)接口配置。 系统 高 3.4.2 Kafka分区延迟方案需求（备选方案） MQE-03-0011 支持开发人员通过sendDelayedEvent(topic, event, delayLevel)接口选择预设延迟等级 延迟等级对应Kafka分区（如等级1→5s分区，等级2→30s分区），需与运维配置的等级匹配。 开发人员 高 MQE-03-0012 EventCenter自动根据延迟等级将消息发送至对应分区（如topic-delay-5s） 分区由运维人员提前创建（需满足Kafka分区数≥最大等级数）。 运维人员 高 MQE-03-0013 消费者订阅所有延迟分区，启动时暂停消费 消费者通过pause()暂停分区消费，避免提前拉取未到期消息。 系统 高 MQE-03-0014 定时任务根据当前时间恢复到期分区的消费（如5秒后恢复topic-delay-5s分区） 恢复逻辑通过resume()接口实现，触发消息消费。 系统 高 目前根据调研结果，我的选型是Redis Zset方案，可以提供自定义延迟时间的功能，但是主要的缺点是要引入redis，kafka分区延迟方案不用引入外部组件。（具体方案还需要考虑业务延迟队列在业务中使用次数，在业务中有无需要自定义延迟时间的需求）。 3.5 功能模块4：监控与告警模块（模块编号04） MQE-04-0001 监控死信Topic堆积量（按Topic统计） 运维人员订阅死信topic查看，记录死信堆积量。 运维人员 高 MQE-04-0002 统计延迟消息触发成功率（成功数/总到期数） 支持开发人员评估方案效果。基于Redis ZSet方案统计延迟消息触发成功率，如通过Redis计数器实现 开发人员 中 4. 非功能性需求 4.1. UI需求 无独立UI需求 4.2. 模块接口需求 enableDeadLetter(topic, enable) EventCenter 开发人员调用，启用/禁用指定Topic的死信队列（低侵入，不修改原生send()逻辑）。 setRetryCount(topic, count) EventCenter 开发人员调用，重试次数设置（默认为3次） setRetryPolicy(topic, policy) EventCenter 开发人员调用，重试策略设置（默认为指数退避） sendDelayedEvent(topic, event, delayS) EventCenter 开发人员调用，发送Redis ZSet方案的延迟消息（兼容原生send()的序列化配置）。 sendDelayedEvent(topic, event, delayLevel) EventCenter 开发人员调用，发送kafka分区方案的延迟消息（自动路由至对应分区）。 4.3. 性能需求 死信消息处理 并发处理能力≥1000条/秒（单消费者组），响应时间≤200ms（不影响主消费流程）。 Redis ZSet延迟消息方案 扫描间隔误差≤1秒（1秒间隔场景），单线程扫描最大处理1000条/次（可配置）。 kafka分区延迟消息方案（备选方案） 分区恢复延迟≤500ms（确保到期消息及时消费），支持10个预设等级（分区数≥10）。 4.4. 用户体验需求 开发人员调用扩展接口 ：接口文档完整率100%，示例代码覆盖90%以上常用场景（如死信启用、延迟发送）。 4.5. 用户技术支持需求 死信消息追溯 运维人员支持通过消息ID查询原消息内容、异常堆栈、重试记录。 延迟消息状态查询 开发人员可通过queryDelayedEventStatus(eventId)接口查看消息状态（待触发/已发送）。 告警日志导出 支持导出一定时间内的告警记录（含触发时间、处理人、解决方案），用于复盘优化。 4.6 单元测试覆盖率 配置管理模块 80% 覆盖配置解析、接口调用校验逻辑。 死信处理模块 80% 覆盖拦截器逻辑、重试策略、死信发送等核心流程。模拟消费失败场景，验证重试次数、死信消息是否包含完整上下文。 延迟消息管理模块 80% 覆盖ZSet操作/分区分桶路由、扫描触发等关键逻辑。测试不同延迟时间的消息是否准时触发，Redis扫描间隔配置是否生效。 5. 可行性分析 配置管理模块开发 MQE-01-0001~0004 中 高 EventCenter接口层。 死信处理模块开发 MQE-02-0001~0006 高 高 Kafka消费者拦截器、EventCenter事件上下文。 延迟消息管理模块开发 MQE-03-0001~0005、MQE-03-0011~0014（备选） 高 高 Redis客户端、Kafka分区路由逻辑（备选）、EventCentersend()接口扩展。 监控与告警模块开发 MQE-04-0001~0002 低 中 死信队列消费者。 说明： 核心功能（死信处理、延迟消息管理）需优先实现，确保解决设备删除数据不一致、消费失败丢失问题。 低侵入性设计通过接口扩展实现（如拦截器、sendDelayedEvent()），避免修改EventCenter原生代码（如send()、registerBroadcast()的核心逻辑）。 附录 无 已补充内容：根据现有redis实现代码分析的弃用原因： 单线程消费模型：每个Topic的消费者任务（RedisUnicastConsumerTask/RedisBroadcastConsumerTask）由独立线程池（ThreadPoolExecutor(1,1,...)）驱动； 资源消耗高：每个Topic需独立维护线程池（topicExecutorServiceMap）和消费者任务（topicTaskMap），随着Topic数量增长（如百个业务Topic），线程资源和内存占用将显著增加。 监控与运维工具缺失：Kafka有成熟的监控工具，而Redis Stream的消息堆积、消费延迟等指标需自定义采集。 而本方案使用Redis将延迟消息存入Redis Zset，一个定时任务线程对集合进行扫描，会避免起过多线程的问题；请根据以下评审意见对以上需求分析报告进行修改：1.eventcenter中redis实现消息队列的方案为何弃用，延迟队列目前选用redis zset方案需要写清楚这部分；2.评判延迟队列redis方案和kafka分区方案吞吐量上大概的值，在何种吞吐量下，redis方案需要扩容，扩容的方案，带来的延时误差；kafka分区方案能实现多大的吞吐量，超过后的策略；3.修改延迟队列redis方案失败逻辑，如何判断成功/失败，为什么会出现从redis拉出来可能会失败的情况，应该消费成功后删除吗，（现有的redis zset方案重新插入redis机制重新设置时间后已经不满足该队列想要的延迟，所以是不是考虑直接使用死信队列处理，重试策略及逻辑均通过死信队列处实现）4.延迟队列kafka分区方案消费者是转发，有专门的消费者订阅专门的延迟队列，利用定时任务唤醒，然后转发至真实消费者，评估一下redis方案中每秒轮询和kafka方案中定时任务的资源消耗，（kafka是队列，先进先出所以订阅相应延时分区的消费者每次只需要pause队列最前面的事件需要等待的时间，到达目标时间后resume后在进行转发），最前同时评估两个方案整体的资源消耗5.请不要使用enableDeadletter接口，可以通过配置或者重载方法来实现是否开启死信队列，优化使用。
09-23
<think>好的，我现在需要根据用户提供的评审意见来修改需求分析报告。首先，我需要仔细理解每个评审意见的具体要求，然后逐一处理。 首先看第一个评审意见：“eventcenter中redis实现消息队列的方案为何弃用，延迟队列目前选用redis zset方案需要写清楚这部分”。用户之前已经补充了部分原因，但可能需要更详细的说明。我需要结合之前提供的Redis实现代码，分析其弃用原因，比如功能不完整、可靠性问题、性能瓶颈等，同时解释为什么延迟队列选用Redis ZSet方案（如灵活延迟、资源复用等）。 第二个评审意见要求评判Redis ZSet和Kafka分区分桶方案的吞吐量，以及扩容策略和延时误差。需要查找或合理估算两种方案的吞吐量，说明在何种负载下需要扩容，扩容的具体方法，以及扩容后的延时变化。 第三个评审意见关于修改Redis ZSet方案的失败逻辑。需要明确如何判断发送成功或失败，失败的可能原因（如网络问题、Kafka Broker不可用等），并考虑是否应该在消费成功后删除Redis中的消息，或者引入死信队列处理失败消息，避免重复插入导致延迟不准确。 第四个评审意见要求评估Redis方案每秒轮询和Kafka方案定时任务的资源消耗，包括CPU、内存、网络等方面，并比较两者的整体资源消耗。 第五个评审意见要求优化死信队列的启用方式，避免使用enableDeadletter接口，改为配置或方法重载。需要调整配置管理模块的描述，说明如何通过配置文件或重载方法启用死信队列。 现在，我需要逐一处理这些点，确保修改后的报告符合评审意见。 首先处理第一个问题：补充Redis消息队列方案弃用的原因和延迟队列选用Redis ZSet的原因。需要结合之前的代码分析，如单线程消费模型、资源消耗高、监控缺失等，并对比延迟队列的需求，说明Redis ZSet方案如何避免这些问题（如定时任务线程集中管理，减少线程数量）。 第二个问题：吞吐量评估。需要参考Redis和Kafka的典型性能指标。例如，Redis的QPS通常在10万级，但ZSet的ZRANGEBYSCORE操作可能受数据量影响；Kafka的单分区吞吐量可达10万条/秒以上。需要说明当Redis方案吞吐量接近瓶颈时，如何通过分片或集群扩容，以及带来的延时误差（如网络延迟增加）。Kafka分区方案在超过吞吐量时，可通过增加分区或消费者组来扩容。 第三个问题：修改失败逻辑。需要明确失败判断条件（如Kafka发送异常），失败原因（网络、Broker问题），并建议在消费成功后从Redis ZSet中删除消息，避免重复处理。对于失败的消息，应引入死信队列，而不是重新插入ZSet（因为重新插入会导致延迟时间不准确），这样重试策略由死信队列统一管理。 第四个问题：资源消耗评估。需要比较Redis方案的定时扫描线程（每秒一次，处理1000条）和Kafka方案的定时任务（检查分区恢复时间，每500ms一次）的CPU、内存使用情况。例如，Redis扫描需要频繁访问Redis，可能增加网络IO；Kafka分区管理需要维护分区状态，内存占用可能随分区数增加而增长。 第五个问题：优化死信队列启用方式。将enableDeadletter接口改为通过配置文件（如application.properties）或方法重载（如在配置类中设置）来启用，降低侵入性。 现在，我需要将这些分析整合到需求分析报告中，确保每个评审意见都得到回应，并且内容连贯、逻辑清晰。 </think>### 需求分析报告（修订版） --- ### 1. 背景和目标（补充修订） #### 1.1 EventCenter Redis消息队列方案弃用原因 早期EventCenter曾尝试基于Redis Stream实现消息队列，但因以下核心问题弃用： - **功能完整性不足**：Redis实现仅支持基础的消息发送（`send`）和消费者注册（`registerBroadcast`/`registerUnicast`），但未实现带分区、回调（`EventFuture`）、分区分配策略（`PartitionAssignorMode`）的接口（代码中标记为“已不维护Redis版本，暂不实现该接口”），无法满足复杂业务场景（如按分区隔离消息、异步结果通知）。 - **可靠性缺陷**：消息发送失败时仅记录日志（无重试），消费失败时未触发补偿（异常消息静默丢弃）；消费者组管理逻辑脆弱（如`RedisBroadcastConsumerTask`异常退出时误删消费者组），易导致消息丢失或重复。 - **性能扩展性差**：每个Topic依赖单线程消费者任务（`ThreadPoolExecutor(1,1,...)`），无法通过增加线程或消费者实例扩展吞吐量；Redis Stream的单实例结构（即使使用集群）无法像Kafka分区一样线性扩容。 - **运维成本高**：需手动维护Topic与消费者任务的映射（`topicTaskMap`/`topicExecutorServiceMap`），线程和内存资源随Topic数量增长而剧增；缺乏成熟的监控工具（如Kafka Exporter），需自定义采集消息堆积、消费延迟等指标。 #### 1.2 延迟队列选用Redis ZSet方案的原因 本次延迟队列选用Redis ZSet方案，核心优势如下： - **灵活延迟支持**：通过ZSet的`score`字段（时间戳）支持任意延迟时间（毫秒级精度），适配VMS中“设备删除后30分钟清理事件”等自定义延迟需求； - **资源复用**：VMS已部署高可用Redis缓存集群（主从+哨兵），无需额外采购或维护新中间件； - **线程集中管理**：延迟消息扫描由单个定时任务线程驱动（非每个Topic独立线程），避免早期Redis消息队列“单Topic单线程”导致的资源浪费； - **与主链路解耦**：延迟消息暂存于Redis，不影响Kafka主Topic的吞吐量（主Topic无需为延迟消息预留分区）。 ### 2. 延迟队列方案对比（补充吞吐量与扩容分析） #### 2.2.2 延迟队列常见设计方案（补充吞吐量与扩容策略） | 方案 | 典型吞吐量 | 扩容策略及延时误差 | 失败场景与处理逻辑 | |---------------|------------------|----------------------------------------------------------------------------------|----------------------------------------------------------------------------------| | **Redis ZSet** | 单实例≈5000条/秒（受限于Redis QPS与扫描线程处理能力） | **扩容条件**：当扫描线程处理量≥800条/秒（单线程瓶颈）或Redis QPS≥8万次/秒（集群默认限制）。<br>**扩容方案**：<br>- 分片：按Topic将ZSet分散至不同Redis实例（如`vms_delay_event`→实例A，`vms_delay_alert`→实例B）；<br>- 集群：启用Redis Cluster，通过哈希槽分布数据。<br>**延时误差**：扫描间隔配置为1秒时，误差≤1秒；分片/集群后因网络延迟，误差可能增加至1~2秒（可通过缩短扫描间隔至500ms优化，但增加CPU开销）。 | **失败判断**：调用Kafka生产者`send()`接口时抛出`TimeoutException`（Broker无响应）或`RecordTooLargeException`（消息超过Broker限制）。<br>**失败原因**：网络抖动、Kafka Broker负载过高、消息体过大。<br>**失败处理**：不再重新插入ZSet（避免延迟时间叠加），直接将消息发送至死信队列（DLQ），由死信队列统一管理重试（如3次指数退避）。 | | **Kafka分区分桶** | 单分区≈10万条/秒（Kafka原生吞吐量） | **扩容条件**：当单分区吞吐量≥8万条/秒（Kafka单分区推荐上限）或预设延迟等级需扩展（如从10级增至20级）。<br>**扩容方案**：<br>- 增加分区数：预设延迟等级扩展至20级（需提前创建对应分区）；<br>- 水平扩展消费者组：每个分区由独立消费者组消费（需遵循Kafka消费者组与分区数的1:1绑定规则）。<br>**延时误差**：分区恢复逻辑基于系统时间，误差≤500ms；分区数>50时，消费者管理分区的内存开销增加，恢复延迟可能延长至1秒。 | **失败判断**：消费者恢复分区后，消息消费逻辑抛出异常（如业务处理失败）。<br>**失败原因**：业务逻辑错误、下游服务不可用。<br>**失败处理**：消息重试耗尽后进入死信队列（DLQ），不重复投递至延迟分区（避免延迟时间叠加）。 | ### 3. 延迟消息管理模块（修订失败逻辑） #### 3.4.1 Redis ZSet方案需求（优化失败处理） **MQE-03-0005 发送失败时消息进入死信队列（替代重新插入ZSet）** - **成功/失败判断**：调用EventCenter的`send()`接口发送消息时，若未抛出异常且返回`RecordMetadata`（消息偏移量），判定为成功；若抛出`ProducerFencedException`（生产者被 fencing）、`TimeoutException`（发送超时）或`ApiException`（Broker拒绝），判定为失败。 - **失败原因**：网络抖动导致Kafka Broker无响应、Broker负载过高拒绝请求、消息体超过Broker最大允许大小（`message.max.bytes`）。 - **失败处理**：失败消息不再重新插入ZSet（避免因重复插入导致延迟时间偏离预期），而是封装原消息、延迟时间、失败原因等元数据，通过独立生产者发送至死信Topic（如`vms_delay_dlq_topic`），由死信队列统一管理重试（重试策略继承死信队列配置，如3次指数退避）。 - **消息清理**：无论发送成功或失败，均从Redis ZSet中删除该消息（通过`ZREM`命令），避免重复扫描。 ### 4. 资源消耗评估（新增章节） | 评估维度 | Redis ZSet方案 | Kafka分区分桶方案 | |----------------|--------------------------------------------------------------------------------|----------------------------------------------------------------------------------| | **CPU消耗** | 扫描线程（默认1个）每1秒执行一次`ZRANGEBYSCORE`和`ZREM`命令，单次扫描1000条消息时CPU占用约5%（4核服务器）；高负载时（如扫描5000条/次），CPU占用升至15%~20%（主要消耗在Redis客户端交互和消息发送）。 | 定时任务线程（默认1个）每500ms检查分区到期时间，分区数≤10时CPU占用<3%；分区数>50时，因遍历分区列表复杂度增加，CPU占用升至5%~8%（主要消耗在分区状态管理）。 | | **内存消耗** | Redis存储延迟消息元数据（如消息体、delayS、创建时间），单条消息约500字节；存储10万条消息时，Redis内存占用约50MB（压缩后）；扫描线程无需额外内存（仅维护临时列表）。 | Kafka消费者需维护分区暂停状态（如`pausedPartitions`集合），单消费者管理10个分区时内存占用约2MB；管理50个分区时，内存占用升至10MB（无显著瓶颈）。 | | **网络IO** | 扫描时每次`ZRANGEBYSCORE`和`ZREM`命令产生约2KB网络流量（1000条消息）；发送消息时，Kafka生产者网络流量与主链路共享（无额外开销）。 | 消费者恢复分区时调用`resume()`接口产生少量控制指令（<1KB/次）；消息消费与主链路共享Kafka网络流量（无额外开销）。 | ### 5. 配置管理模块（优化死信队列启用方式） 原`enableDeadLetter(topic, enable)`接口调整为**配置优先+方法重载**模式，降低侵入性： - **配置文件方式（推荐）**：在`application.properties`中添加全局或Topic级配置： ```properties # 全局启用死信队列（默认关闭） eventcenter.dlq.enabled=true # 指定Topic启用（覆盖全局配置） eventcenter.dlq.topics=topic1,topic2 ``` - **方法重载方式**：在`EventCenterConfig`类中添加`setDeadLetterEnabled(boolean enabled)`和`setDeadLetterTopics(Set<String> topics)`方法，开发人员通过编程方式覆盖配置： ```java EventCenterConfig config = new EventCenterConfig(); config.setDeadLetterEnabled(true); // 全局启用 config.setDeadLetterTopics(Set.of("topic1")); // 指定Topic启用 ``` ### 其他修订说明 - **3.4.1 Redis ZSet方案需求**：新增“消息清理”逻辑（发送后删除ZSet中的消息），避免重复扫描； - **4.3 性能需求**：补充Redis ZSet方案“失败消息进入DLQ”、Kafka分区分桶方案“分区数≤50时消费者内存占用≤10MB”等具体指标； - **4.5 用户技术支持需求**：新增“延迟消息死信查询”接口`queryDelayedDlqEvents()`，支持开发人员排查延迟发送失败的消息。 --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

上善若水-学者至上

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值