- 博客(751)
- 收藏
- 关注
RSS订阅原创 Redis单线程还是多线程？
定调核心：先明确“Redis核心命令执行是单线程的”，解释单线程的优势（无锁竞争、低开销）和性能支撑（内存操作+IO多路复用），可以提一下10万QPS的官方数据增强说服力；补充多线程场景：再讲“Redis有辅助多线程”，列举持久化、内存释放、集群同步等后台任务，以及Redis 6.0后的多IO线程优化，体现知识的广度；总结设计思想：最后点出Redis的设计逻辑——“核心操作单线程保高效，辅助操作多线程解阻塞”，展现对架构设计的理解。
2025-11-06 23:33:42
1002
1
原创 本地缓存与分布式缓存：深入解析与多级缓存架构实践
本地缓存是指将数据存储在应用程序进程的内存中，数据生命周期与应用程序保持一致。这种缓存方式直接利用应用服务器的内存资源，提供极快的读写速度。本地缓存适用于对速度要求极高、数据量不大、允许短暂不一致的场景分布式缓存适用于数据共享、强一致性要求、大容量存储的场景多级缓存结合两者优势，在保证一致性的前提下提供最佳性能通过合理的缓存设计、一致性保证机制和监控体系，可以显著提升系统性能和用户体验。在实际项目中，建议根据业务特点灵活选择和组合不同的缓存策略。
2025-11-05 23:52:09
481
原创 分布式锁的特点
分布式锁的核心价值是“在分布式环境下保证资源的互斥访问”，其实现方式没有绝对的优劣，只有“是否适配业务场景”。性能要求、可靠性要求、运维成本。高并发、高性能、能接受轻微锁丢失风险：Redis锁（Redisson）；高可靠、并发适中、能接受运维成本：ZooKeeper锁（Curator）；小型系统、快速落地、低并发：数据库锁。
2025-11-04 23:53:54
711
原创 Redisson看门狗机制
Redisson的看门狗机制，通过“后台线程+定期续期”的设计，完美解决了分布式锁的过期难题。让开发者无需关注锁的续期细节，就能实现高可靠的分布式锁。在实际开发中，建议优先使用Redisson的默认lock()方法（启用看门狗），除非业务执行时间固定且较短，才手动指定过期时间。同时，结合Redis集群提高可用性，避免因网络问题导致续期失败。
2025-11-03 23:18:41
1255
原创 Redis性能优化避坑指南
Redis性能优化的核心逻辑是“理解特性，适配场景”：内存不足要兼顾优化和扩容，大Key要聚焦拆分和预防，阻塞要狠抓命令替代和配置优化。设计优先：选对数据结构，避免大Key，提前规划集群；监控先行：搭建监控体系，提前发现内存、大Key、阻塞问题；分层解决：先低成本优化，再高成本扩容，平衡性能和成本。
2025-11-02 23:57:55
922
原创 Redis哨兵与集群模式
当你需要“小数据量+高可用+读并发扩展”时，选哨兵模式，简单高效；当你需要“大数据量+高并发+弹性扩展”时，选集群模式，支撑业务增长。
2025-10-31 23:55:23
1221
原创 Redis哈希槽
性能优化：Redis集群节点之间通过“Gossip协议”交换槽位信息，16384个槽位对应的“槽位分配表”很小（仅需2KB左右，用位图存储，每个槽位占1bit），节点之间传输和同步成本极低，不会给网络带来负担；集群规模适配：16384个槽位足够支撑中小型集群（一般Redis集群节点数量不会超过1000个），每个节点平均可分配16个以上的槽位，能保证数据分布均匀。如果槽位数量过多（如65536），会导致槽位分配表变大，同步效率降低；如果过少（如1024），则无法实现精细的负载均衡。
2025-10-30 23:50:59
793
原创 redis过期策略
Redis的过期策略是“平衡艺术”的典型体现——从理论上的定时删除，到优化后的定期删除，再到互补的惰性删除，最终形成“定期+惰性”的组合方案，完美解决了CPU资源和内存资源的矛盾。
2025-10-29 23:58:51
489
原创 同步、异步、阻塞、非阻塞的区别
要理解这两对概念，首先要明确描述对象同步/异步：描述的是被调用者的执行逻辑（“做事的方式”）；阻塞/非阻塞：描述的是调用者的等待状态（“等结果的方式”）。用“A调用B完成任务”的场景具象化：概念对描述主体核心问题同步/异步被调用者BB接到调用后，是否“主动通知”A结果？阻塞/非阻塞调用者AA发出调用后，是否“原地等待”结果？核心区别：被调用者完成任务后，是否会主动通知调用者。分主体记定义：同步/异步看“被调用者是否主动通知”，阻塞/非阻塞看“调用者是否原地等待”；无必然绑定关系。
2025-10-28 22:47:55
488
原创 一文读懂计算机启动流程
计算机启动流程是“硬件自检→引导衔接→内核启动→驱动适配→服务就绪”的层层递进过程：BIOS保障硬件可用，引导程序搭建桥梁，内核掌控核心资源，驱动适配硬件，服务实现完整功能。理解这一流程，不仅能帮你排查开机故障（如自检报错、引导失败），更能加深对硬件与软件协同工作的认知。
2025-10-27 23:22:43
700
原创 redlock的分布式锁方案
Redlock算法是Redis作者针对集群锁一致性问题提出的经典解决方案，其核心价值在于：通过“多独立主节点+大多数原则”，从架构上规避了主从异步复制的锁漏洞，保证了分布式锁的独占性。但我们也要清醒地认识到，Redlock的“理论完美”需要付出高昂的部署和性能成本，这使得它在实际场景中很少被采用。大多数业务场景下，“主从架构+业务幂等”的方案已经足够；若对一致性要求极高，则更推荐使用ZooKeeper、etcd等天生支持一致性的工具。
2025-10-26 20:49:39
1152
原创 Redis分布式锁演进全解析
版本实现方式解决的问题存在的缺陷0.1实现基本的独占性和防死锁setnx与expire非原子，可能死锁0.2SET NX EX命令解决加锁的原子性问题释放锁无归属校验，可能误删0.3唯一lockValue + Lua释放解决误删锁问题锁过期与业务耗时不匹配生产级Redisson框架动态续期、可重入、高可用等依赖第三方框架（非缺陷）
2025-10-25 23:17:26
436
原创 Redis的有序集合的底层实现
Redis ZSet的两种编码实现，是“因地制宜”优化思想的又一经典体现——ziplist以“紧凑存储”为核心，解决小数据场景的内存浪费问题；skiplist+dict以“协同高效”为核心，解决大数据场景的性能瓶颈问题。两者的动态切换，让ZSet在不同场景下都能实现内存与性能的最佳平衡。
2025-10-24 23:38:30
874
原创 Redis哈希表渐进式rehash深度解析：为何百万数据迁移不阻塞服务？
触发条件：能区分扩容和缩容的负载因子阈值，尤其是持久化对扩容阈值的影响；实现流程：掌握“双哈希表并行+rehashidx标识+分步迁移”的核心逻辑；请求处理：明确rehash期间不同类型请求的处理规则，以及异常场景的应对策略。Redis的渐进式rehash机制，通过“分而治之”的思想，将原本可能阻塞服务的大型数据迁移操作，拆解为无数个微操作融入日常业务流程，完美平衡了性能与可用性。
2025-10-23 23:33:44
838
原创 Redis的Hash数据结构底层实现
两种编码的识别：明确ziplist和hashtable的定义及核心结构；转换条件：熟记两个配置参数的默认值（512个字段、64字节值长度）及触发规则；优劣对比：能结合内存和性能分析两种编码的适用场景；设计思想：理解Redis“小数据省内存、大数据保性能”的设计理念。Redis Hash类型的两种编码实现，是“因地制宜”优化思想的典型体现——ziplist以“紧凑存储”为核心，解决小数据场景的内存浪费问题；hashtable以“高效操作”为核心，解决大数据场景的性能瓶颈问题。
2025-10-22 22:28:40
1015
原创 ziplist、quicklist、listpack之间的区别
ziplist、quicklist、listpack的演进，本质是Redis对“内存效率”与“操作性能”平衡的持续探索。三者并非互斥关系，而是针对不同数据类型、不同场景的精准适配。List类型：无需关注底层实现，Redis会通过quicklist自动适配小列表与大列表场景；若为高频头尾操作的消息队列，可适当调大压缩中间节点，节省内存。Hash/ZSet类型：尽量控制字段数量和元素大小，使其能以listpack存储（Redis 7.0+默认），避免过早转为哈希表或跳表导致内存浪费。版本选择。
2025-10-21 23:21:53
1158
1
原创 Redis的List数据结构底层实现
ziplist是一种连续内存的紧凑存储结构，并非传统意义上的链表。它通过特定的编码方式存储多个元素（字符串或整数），整个结构无需指针关联，极大地节省了内存空间。整体结构：包含头部信息（存储总长度、元素数量等）、多个entry（元素数据）和尾部标记。单个entry：存储元素的长度、编码类型及实际数据，根据元素的大小和类型采用不同的压缩编码。格式为：quicklist是Redis 3.2版本后List的默认底层实现，其本质是由多个ziplist节点组成的双向链表。
2025-10-20 23:22:11
1039
原创 Redis字符串编码
Redis字符串的多编码设计，充分体现了“因地制宜”的优化思想——针对整数、短字符串、长字符串的不同特性，设计了差异化的存储方案，在内存利用率和操作性能之间实现了精准平衡。例如在存储用户ID、商品库存等整数字段时，可直接以整数形式存储以触发int编码；在存储短key（如）时，利用embstr编码提升访问性能；在存储长文本或二进制数据时，接受raw编码的开销以换取修改灵活性。通过对编码机制的合理运用，能让Redis发挥出更优的性能。
2025-10-19 21:10:28
612
原创 Redis 的字符串底层实现
SDS的结构设计：掌握五种SDS结构体的区别、关键字段的作用，以及短字符串优化的实现方式。SDS与C原生字符串的对比：清晰阐述C原生字符串的缺陷，以及SDS对应的解决方案（如长度计算、缓冲区安全、二进制存储等）。SDS的核心机制：理解空间预分配、惰性释放的实现逻辑及其带来的性能优势。总之，Redis的SDS设计充分体现了“高效、安全、灵活”的设计理念，通过针对性地解决C原生字符串的痛点，为Redis字符串的高性能运行提供了底层支撑。
2025-10-18 23:05:50
344
原创 Kafka、ActiveMQ、RabbitMQ、RocketMQ 对比
没有“最好”的消息队列，只有“最合适”的选择。Kafka 是高吞吐的王者，ActiveMQ 是中小场景的易用之选，RabbitMQ 擅长复杂路由，RocketMQ 则在性能、事务、扩展性之间做到了均衡。实际选型时，建议结合业务吞吐量、延迟要求、路由复杂度、团队技术栈四个维度综合评估，必要时可搭建原型进行压测验证。
2025-10-17 23:23:27
1051
1
原创 RocketMQ 事务消息
RocketMQ 事务消息通过“预备消息打底、本地事务执行、结果确认、回查兜底”的全流程设计，完美解决了分布式系统中“本地操作与消息发送原子性”问题。其核心是通过两阶段提交思想，结合持久化存储和定时回查，确保最终数据一致性。
2025-10-16 23:39:07
1051
原创 RocketMQ的负载均衡策略
若内置策略无法满足需求，RocketMQ 允许通过实现接口，自定义 Queue 分配逻辑。实现步骤实现接口，重写allocate方法，在方法中定义自己的分配规则（如按实例 IP Hash、按业务模块指定 Queue 等）。消费者初始化时，通过方法指定自定义策略。代码示例（自定义策略骨架）// 1. 实现自定义策略接口@Override// 自定义分配逻辑：例如按当前实例ID的Hash值分配Queue// 省略具体分配代码...@Override// 策略名称。
2025-10-16 22:08:43
608
原创 RocketMQ如何保证消息不丢失
在Broker层面，通过持久化机制（刷盘）来保证单机可靠性，通过主从复制机制来保证集群的高可用。生产上可以根据业务在性能和可靠性之间做权衡，比如选择同步刷盘还是异步刷盘。在生产端，我们依赖发送状态确认和内部重试机制，确保消息一定能成功送达Broker。在消费端，最关键的是采用手动ACK确认机制，只有在业务逻辑真正执行成功后，才告知Broker消息已消费。如果处理失败，Broker会通过重试机制重新投递，直到消费成功。通过这套‘刷盘 + 主从 + 确认 + 重试’
2025-10-15 23:26:31
1065
3
原创 RocketMQ的消费模式
大部分业务场景选集群模式，核心是 “负载均衡 + 避免重复处理”；少数需要 “全员处理” 的场景选广播模式，核心是 “消息群发 + 独立处理”。
2025-10-14 23:38:19
809
原创 RabbitMQ 消息可靠投递
机制解决问题优点缺点推荐场景发布者确认确保消息成功发送到 Broker性能高，非阻塞（异步模式），是 RabbitMQ 官方推荐的标准做法。需要额外的代码来处理确认逻辑。绝大多数场景下的首选。事务确保消息发送的原子性语义清晰，易于理解。性能极差，严重影响吞吐量。对性能要求不高，但对一致性要求极高的罕见场景。消费者手动 Ack确保消息被成功处理可靠性高，是保证消费端不丢消息的唯一标准做法。需要开发者手动管理 Ack 的发送时机，逻辑上要确保不遗漏。所有需要确保消息被可靠处理的场景，应始终开启。
2025-10-14 23:19:51
922
1
原创 Rabbitmq如何避免消息丢失
为了构建一个真正可靠的 RabbitMQ 系统，建议你组合使用以下方案：环节核心机制最佳实践生产端发布者确认 (Publisher Confirms)这是保证消息成功送达 MQ 服务器的首选方案，性能好且可靠。MQ 服务器端持久化 (Durability)必须开启。将队列（）和消息（）都设置为持久化，防止 MQ 重启丢失数据。消费端手动 Ack (Manual Acknowledgements)必须开启。将autoAck设置为false，在业务逻辑成功执行后，手动调用basicAck。
2025-10-13 23:04:15
740
原创 RabbitMQ为什么使用AMQP协议
特性解释带来的好处可靠性消息确认、持久化、发布确认保证数据不丢失，系统更稳定灵活性交换机、路由键、多种路由策略满足复杂的业务场景，解耦能力强跨平台多语言API支持技术栈无关，易于系统集成“RabbitMQ的核心是实现了AMQP协议，这让它具备了高可靠性、强大的路由灵活性和优秀的跨平台能力，成为了构建分布式系统的利器。
2025-10-13 22:32:53
934
原创 RabbitMQ四种交换机详解
大家好！在消息队列的世界里，RabbitMQ无疑是一个明星产品。今天我们要深入探讨的是RabbitMQ的核心——交换机（Exchange）。想象一下，交换机就像是邮局里的分拣员，负责把不同类型的邮件（消息）投递到正确的邮箱（队列）。掌握了交换机，你就掌握了RabbitMQ的精髓！简单来说，交换机就是消息的"交通指挥中心"。生产者发送消息到交换机，交换机根据类型和规则，决定把消息路由到哪些队列。RabbitMQ提供了四种不同类型的交换机，每种都有其独特的路由策略。交换机类型路由方式性能使用频率。
2025-10-12 23:31:37
1152
原创 RabbitMQ 核心概念解析
RabbitMQ 作为主流的开源消息队列，凭借高可靠性、灵活的路由策略，成为分布式系统解耦、削峰的常用工具。但很多新手刚接触时，会被“交换机”“信道”“虚拟主机”等概念绕晕，不清楚消息从生产者到消费者到底怎么流转。这篇文章用“概念拆解+消息流转图+实战案例”的方式，把 RabbitMQ 核心概念讲透，帮你快速入门。最后用一句口诀帮你记住核心逻辑：“生产者发消息给交换机，交换机按键绑队列，消费者从队列取消息，确认之后消息删”
2025-10-12 22:45:58
1474
原创 消息积压的问题如何解决
大家好，今天我们来聊聊一个让无数后端工程师“头秃”的问题——消息队列（MQ）积压。这是一个在高并发系统中非常常见且棘手的问题。如果处理不当，小则导致业务延迟，大则可能引发雪崩效应，让整个系统瘫痪。我将从**“紧急止血”和“长效根治”**两个角度，为你详细拆解如何应对这个问题。短期应急：通过增加消费者实例或使用临时程序转移消息，快速恢复系统的消费能力，防止问题扩大化。长期优化向内看：深入分析并优化消费者的处理逻辑，这是提升性能的关键。向外看：审视生产者，通过限流、降级。
2025-10-12 22:05:43
1059
原创 消息队列延迟与过期问题的实战解决
问题类型核心原因解决方案消息延迟消费慢、MQ瓶颈增加消费者、优化代码、调整分区、调参消息过期TTL不合理、消费堆积调整TTL、引入死信队列在实际项目中，这两类问题往往是交织的。解决它们不仅需要运维层面的调优，还需要开发人员对业务逻辑和MQ原理有深入理解。
2025-10-11 23:19:40
560
原创 死信队列vs延迟队列
大家好，今天我们来聊聊消息队列中两个很实用但经常被忽视的特性——死信队列和延迟队列。无论是在实际开发中，还是在技术面试中，理解这两个概念都能让你脱颖而出。简单来说，死信队列就是用来存放那些“处理不了”的消息的特殊队列。延迟队列就像是消息的“等候室”——消息发进去后，不会立即被消费，而是等设定的时间到了才会被投递出去。死信队列是你的安全网，确保问题消息不会影响正常业务流程延迟队列是你的定时器，让消息在正确的时间做正确的事。
2025-10-10 23:31:50
485
原创 MQ重复消费问题
简单说：同一条消息，消费1次和消费100次，结果一样。比如“扣库存”消息，重复消费后，库存也不会多扣。记住“1个核心+4个原因+1个方案”核心：MQ重复消费无法完全避免，因为重发是为了确保消息不丢失；原因：消费方没ack、位点提交失败、发送方逻辑错、网络不稳；解决办法：消费方做好幂等处理，常用“唯一ID防重”或“业务状态防重”。重复消费不是MQ的“bug”，而是为了“消息不丢失”付出的合理代价。只要消费方做好幂等，重复消费就不会影响业务——这是MQ开发的必备技能。
2025-10-09 23:49:47
812
原创 如何避免消息重复投递或重复消费
大家好，在消息队列的使用过程中，重复消费是一个比消息丢失更常见的问题。想象一下这样的场景：用户支付了100元，由于消息重复消费，账户被扣了200元；商品库存原本有100件，重复消费后变成了98件... 这种问题如果处理不好，会给业务带来严重的影响。今天我们就来深入探讨消息重复消费的原因，以及如何通过幂等性设计来彻底解决这个问题。
2025-10-08 23:26:50
500
原创 如何避免消息丢失
大家好，在消息队列的使用过程中，消息丢失是一个让很多开发者头疼的问题。特别是在金融、电商等对数据一致性要求极高的场景中，消息丢失可能意味着资金损失、订单异常等严重问题。今天我们就来深入剖析消息丢失的各个环节，并提供从生产到消费的完整防护方案。生产端：使用确认机制 + 重试 + 异步回调服务端：配置持久化 + 副本同步 + 定期备份消费端：手动提交 + 异常处理 + 死信队列监控：实时监控 + 告警通知 + 日志追踪防止消息丢失是一个系统工程，需要在消息的整个生命周期中都做好防护。
2025-10-07 23:52:36
771
原创 消息顺序消费问题
大家好，在消息队列的使用过程中，顺序消费问题是一个经常被提及的难点。特别是在面试中，这个问题出现的频率相当高。今天我们就来深入探讨一下消息顺序消费的问题，分析其原因并提供实用的解决方案。先来看一个简单的业务场景：假设我们有一个订单状态更新的需求，需要先执行"新增订单"操作，再执行"删除订单"操作。如果这两条消息的处理顺序颠倒，先执行了删除再执行新增，就会导致业务逻辑错误，这就是典型的消息顺序消费问题。
2025-10-06 23:24:12
1070
原创 mq的常见问题
消息不丢：发送方要确认、MQ要持久化、消费方要手动ack；消息不重：业务要做幂等，用唯一ID或状态机防重；顺序不乱：单线程消费或按关键字段分区；不积压：监控报警+临时扩容+优化消费速度。其实MQ的问题都有固定解法，关键是要在上线前做好预案，别等线上出问题了再慌慌张张处理。希望这篇文章能帮你避开MQ的坑，让线上系统更稳定！
2025-10-05 23:39:24
1495
原创 引入消息队列的缺点
很多开发同学刚开始使用消息队列（MQ）时，往往只看到它能解耦系统、削峰填谷的优点，觉得简直太爽了。但等到真正上线后才发现：消息丢了、重复消费导致数据错乱、系统复杂度直线上升...实际上，MQ 在解决问题的同时，也会引入新的麻烦。本文将深入剖析 MQ 的 6 个真实痛点，每个痛点都配有业务实例和避坑方案，帮助你在使用 MQ 前做好充分准备。不是必须用，就不用：如果系统没有遇到解耦、削峰等实际问题，不要为了"炫技"而使用 MQ，简单的同步调用比复杂的异步交互更稳定不做好避坑方案，不用。
2025-10-05 23:29:32
692
原创 为什么要使用MQ
核心价值：MQ主要解决分布式系统的“解耦”和“削峰”问题，同时支持异步处理和可靠投递；场景举例解耦：下单后通知、送券、加积分，用MQ让服务互不依赖；削峰：秒杀场景用MQ存请求，避免冲击数据库；避坑意识：不是所有场景都能用，比如实时性要求极高的场景，得选其他方案。MQ不是“高大上的炫技工具”，而是解决实际问题的“刚需”。什么时候该用？就看你有没有遇到“服务耦合死”“峰值扛不住”这些痛点——有痛点，MQ就是救星；没痛点，强行上MQ就是给自己找麻烦。
2025-10-04 23:29:07
928
原创 MQ 的使用场景
核心价值：MQ解决了分布式系统的“异步、解耦、削峰”问题，提升系统响应速度、扩展性和稳定性；重点场景：结合1-2个你项目里的实际场景，比如“我们项目在秒杀场景用MQ削峰，把10万QPS的峰值拉平到1000QPS，避免数据库崩溃”；避坑意识：提一句“不是所有场景都用MQ，比如实时性要求极高的场景，我们会用其他方案”，显得你考虑周全。MQ不是“银弹”，它的价值在于“解决特定场景的问题”。实际工作中，先想清楚“不用MQ会有什么问题”，再决定要不要上——这才是正确的使用姿势，而不是为了“用MQ而用MQ”。
2025-10-04 23:16:33
1010
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人