lfeishumomol的博客

Redisson分布式锁和乐观锁的使用场景

lfeishumomol — Tue, 02 Dec 2025 02:42:41 +0800

本文分析了礼品卡管理系统中激活操作的并发控制方案。传统使用Redisson分布式锁在大批量激活时存在性能问题，包括Redis连接开销大、内存占用高和网络延迟累积。Redisson锁更适合锁定整个业务流程（如订单创建、会员充值等复合操作），而礼品卡激活更适合采用版本号乐观锁机制。乐观锁通过添加version字段实现无锁并发控制，具有开销低、扩展性好和精确冲突检测等优势，能有效处理大批量礼品卡激活场景，同时保证数据一致性。应根据业务场景特点选择合适的并发控制方案。

为什么仅靠“版本号”不够？为什么需要以“消费房间”为粒度的分布式锁？

lfeishumomol — Tue, 02 Dec 2025 02:16:02 +0800

本文分析了在创建订单过程中使用乐观锁和分布式锁的差异。乐观锁（版本号）仅能保证单次更新的原子性，无法保护多步骤业务流程的完整性，存在数据不一致风险。而分布式锁（如Redisson）能保护整个业务流程，通过以"消费房间"为粒度加锁，既确保订单创建期间禁止修改，又不影响其他房间操作。文章指出，这种方案符合DDD聚合一致性边界原则，是保障高并发场景数据一致性的最佳实践。最后强调技术选型应基于业务本质，分布式锁在该场景下比乐观锁更精准高效。

Redis相关面试题

lfeishumomol — Mon, 24 Nov 2025 22:48:22 +0800

Redis性能优异主要基于三点：1）纯内存操作，读写速度远快于磁盘；2）核心命令单线程执行，避免多线程开销；3）I/O多路复用技术（如epoll）高效处理海量连接。6.0+版本虽引入多线程网络I/O，但命令执行仍保持单线程以确保原子性。持久化等后台任务由子进程处理，不影响主线程性能。

Spring、Spring MVC 和 Spring Boot ，mybatis 相关面试题

lfeishumomol — Mon, 24 Nov 2025 19:54:16 +0800

MyBatis中#{}和${}的核心区别在于安全性：#{}采用预编译机制防止SQL注入，将参数视为纯数据；${}是直接字符串替换，存在SQL注入风险。最佳实践是优先使用#{}，仅在动态表名/列名等特殊场景谨慎使用${}，但必须配合严格的白名单校验。例如雪花ID分表时，应由服务端解析安全后缀而非直接使用用户输入，确保${}使用的安全性。

redis 和数据库如何保持一致性问题

lfeishumomol — Mon, 24 Nov 2025 03:41:36 +0800

摘要：在数据库与缓存双写场景中，常规"先更新数据库再删缓存"策略在并发操作下可能出现数据不一致问题。通过延迟双删策略（先删缓存→更新数据库→延迟100ms→再删缓存）可有效解决这一问题，确保更新期间回填的脏数据被清除。典型场景分析显示，当多个写请求与读请求并发时，延迟双删能保证最终数据一致性，避免缓存中留存旧值的情况。

如何用 Redis 实现千万级实时积分排行榜？

lfeishumomol — Sun, 23 Nov 2025 23:50:55 +0800

摘要：针对千万级实时排行榜系统，本文提出分桶方案解决传统ZSet大Key问题。方案采用三个核心结构：1)Hash存储用户积分映射；2)按分数区间分桶的ZSet；3)Hash记录各桶人数。通过Lua脚本实现原子操作，查询时先定位用户所在桶，再累加更高分桶人数与桶内更高分人数得出精确排名。该方案支持同分并列，单次操作延迟低于2ms，内存占用优化显著（千万用户约1GB），有效解决了大ZSet导致的性能瓶颈和运维问题。

为什么有了乐观锁，我们仍选择 Redisson 悲观锁？

lfeishumomol — Sun, 23 Nov 2025 00:14:24 +0800

本文探讨了在并发控制中混合使用悲观锁与乐观锁的实践方案。通过分析读写分离延迟、业务流程完整性、用户体验等维度，指出在低并发场景下，Redisson分布式悲观锁能有效解决乐观锁的局限性：避免主从延迟导致的误判、确保业务流程原子性、将失败转化为等待提升用户体验。同时保留MySQL乐观锁作为兜底防线，形成纵深防御体系。这种设计虽增加轻微性能开销，但显著提升了系统可靠性和业务一致性，实现了"慢成功优于快失败"的工程权衡。

在技师上钟系统中实现WebSocket集群架构，以及如何结合RocketMQ来处理定时任务，从而构建一个高可用、可扩展的实时通知系统

lfeishumomol — Wed, 19 Nov 2025 03:18:10 +0800

摘要本文介绍了技师上钟系统中WebSocket集群和RocketMQ定时任务的技术实现方案。系统采用基于Redis和RocketMQ的WebSocket集群架构，通过多节点维护会话连接，结合消息广播实现实时通知。关键技术点包括：1) WebSocket配置注册多个处理器；2) 集群实现通过本地会话检查和Redis全局存储；3) 心跳检测机制保持连接活跃；4) RocketMQ处理定时任务。该方案实现了高可用、可扩展的实时通信系统，满足技师上钟业务场景的需求。

开发中常见的数据加密方式：不可逆加密和可逆加密以及对称加密与非对称加密的关系和区别

lfeishumomol — Tue, 18 Nov 2025 20:54:46 +0800

加密技术可分为三类：不可逆加密（哈希算法）用于密码存储和数据校验，推荐bcrypt等安全算法加盐处理；对称加密（如AES）适合高频加密，但需严格管理密钥；非对称加密（RSA/ECC）用于安全通信和数字签名。实际应用中，HTTPS采用混合加密机制，业务系统则通过签名验证实现身份认证。三类技术各司其职，需根据场景组合使用，兼顾安全与效率。密钥管理和算法选择是保障系统安全的关键。

收银台系统如何实现跨库分布式事务？——基于本地消息表与 MQ 的最终一致性实践

lfeishumomol — Sun, 16 Nov 2025 22:33:44 +0800

本文介绍了金融级系统中解决跨库一致性的轻量级方案。针对收银台用户权益支付场景，采用"本地消息表+XXL-JOB+RocketMQ"的组合方案替代分布式事务框架Seata，通过事务内同步写入业务数据和消息记录，由定时任务异步补偿消息投递，最终实现可靠消息驱动型的最终一致性。该方案具有强一致性、服务解耦、高可用和轻量可控等优势，已在生产环境支撑数亿级交易，验证了其稳健性。

腾讯二面：如何保证MQ消息不丢失？重复消费如何保证幂等，本地消息表配合MQ实现最终一致性？

lfeishumomol — Sun, 16 Nov 2025 21:34:54 +0800

腾讯二面记录：针对MQ消息可靠性问题，主要考察两方面：1）防止消息丢失，需通过生产者确认、Broker持久化、消费者确认机制实现端到端保障；2）处理重复消费，可通过业务唯一标识、数据库乐观锁或Redis原子操作实现幂等控制。面试重点在于系统架构设计中对消息可靠性与一致性的解决方案。

一锁、二判、三更新：Redisson 锁、MySQL 乐观锁、状态机别再混淆了！一文讲清它们到底解决什么问题

lfeishumomol — Sat, 15 Nov 2025 07:27:00 +0800

本文剖析了Redisson分布式锁、MySQL乐观锁和状态机的核心区别与应用场景：Redisson锁通过悲观策略控制同步请求的并发访问；MySQL乐观锁通过version字段实现无锁并发控制，适合批量任务和重试场景；状态机则通过WHERE条件防止非法状态跳转，尤其适用于异步流程。三者各司其职，最佳实践是"一锁、二判、三更新"的组合策略：同步请求优先使用Redisson锁，异步场景依赖数据库WHERE条件双重校验。文中通过真实案例展示了在支付回调、数据迁移等场景下的正确应用方式，强调安全兜

跨年查不到订单？一个雪花 ID 分库路由引发的“时间穿越” Bug

lfeishumomol — Sat, 15 Nov 2025 04:41:54 +0800

《跨年订单消失之谜：时间错位引发数据库路由故障》摘要：某系统在跨年时发生诡异故障——用户查询正常但订单详情404。排查发现，系统采用按年分库策略，订单ID使用含时间戳的雪花算法。跨年前查询2023年的订单，跨年后系统却默认查询2024年库，导致路由错误。解决方案是重构路由逻辑：通过解析雪花ID中的生成时间决定查询库，而非依赖当前时间。这个小故障揭示了分布式系统中"时间上下文错位"的经典陷阱，同时反映出雪花ID虽然具备反推时间优势，但也存在存储和索引性能问题，需要权衡取舍。（149字）

Redis 读写分离架构下用 Redisson 上锁安全吗？并发读会出问题吗？

lfeishumomol — Sat, 15 Nov 2025 04:20:25 +0800

本文探讨Redis主从架构下Redisson分布式锁的安全性问题。对于主从复制延迟导致的锁丢失问题，指出Redis作为AP系统的局限，但强调可通过数据库状态机(如带条件的SQL更新)实现业务兜底。同时解释Redisson锁操作不受从节点影响，所有锁操作都通过Lua脚本在主节点执行，确保原子性。建议金融等关键业务可选用ZooKeeper，而常规业务通过数据库状态机+Redis锁的组合即可保障数据一致性。

中小公司别被微服务“绑架”了！不拆微服务，也能高可用：中小团队的轻量级分布式单体实践

lfeishumomol — Sat, 15 Nov 2025 01:07:29 +0800

本文分享了一种适合中小团队的“轻量级分布式单体”架构方案。该方案在保留单体应用优势的同时，通过中间件实现分布式能力：使用JWT+HttpClient处理服务调用，Redisson分布式锁保障并发安全，按年分库控制数据规模，OSS直传优化文件处理。相比传统微服务，该架构开发调试更简单、性能更稳定（核心接口P99<80ms），运维成本更低（无需注册中心/配置中心/网关）。文章强调架构选择应匹配团队规模（10人以下）和业务阶段（日均数十万订单），认为简单可靠的方案比盲目追求技术先进性更重要。

RocketMQ消费组详解：构建高可用消息消费系统

lfeishumomol — Thu, 13 Nov 2025 21:07:36 +0800

RocketMQ消费组是构建高可用消息系统的核心机制。本文通过电商订单系统Demo，详细解析消费组的关键特性：1) 同一消费组内消费者分摊消息处理，避免重复消费；2) 支持集群和广播两种模式；3) 提供故障自动转移能力；4) 实现业务隔离和水平扩展。文章展示了订单创建、日志记录等典型场景的代码实现，分析了负载均衡机制和容错原理，并提供了命名规范、分组策略等最佳实践。合理使用消费组能显著提升系统处理能力、容错性和可维护性。

RocketMQ微服务架构实践：从入门到精通完整指南

lfeishumomol — Thu, 13 Nov 2025 20:13:15 +0800

本文以电商场景为例，系统介绍RocketMQ在微服务架构中的应用实践。通过小明水果店的业务场景（订单处理、库存扣减等），展示如何使用RocketMQ实现服务解耦和异步处理。文章涵盖基础概念（生产者、消费者、Topic）、项目结构设计，并提供了核心代码示例，包括订单创建消息发送和库存扣减消费逻辑。通过具体案例讲解RocketMQ如何提升系统性能与可靠性，适合开发者从入门到进阶系统学习。完整代码可通过指定链接下载实践。

RocketMQ 中顺序消费的实现及面试回答

lfeishumomol — Thu, 13 Nov 2025 03:01:52 +0800

摘要：RocketMQ在常规场景（如日志、通知）支持并发消费以提高吞吐量，但在订单处理等关键业务中需保证顺序消费。实现方式：生产端通过订单ID取模将相关消息路由至同一队列；消费端使用MessageListenerOrderly同步处理，确保同一队列消息按序执行。这种"归堆+排队"机制既能保证特定业务顺序，又不影响其他消息的并行处理能力。

用 RocketMQ 写个“自动取消订单并释放库存” —— 从发消息到防翻车全攻略

lfeishumomol — Thu, 13 Nov 2025 00:17:31 +0800

文章摘要：本文详细介绍了如何利用RocketMQ实现电商订单30分钟未支付自动取消的高可靠方案。核心方案包括：通过延迟消息触发超时处理，消费者采用数据库条件更新实现幂等操作，死信队列兜底异常消息，并通过本地消息表（Outbox模式）保证订单创建与消息发送的最终一致性。文章对比了同步/异步发送的适用场景，强调幂等设计、重试机制和监控告警的重要性，最终构建了一个能应对高并发、网络抖动和服务器故障的稳健系统。

ThreadLocal 在项目中的应用

lfeishumomol — Mon, 03 Nov 2025 21:48:03 +0800

本文摘要：ThreadLocal是Java线程本地存储机制，通过为每个线程维护变量副本实现线程安全的数据共享。文章结合消息中心项目，展示了ThreadLocal在管理用户登录信息和第三方应用凭证等场景的应用实践，重点分析了其核心原理、典型实现模式（如SecurityContextHolder）及生命周期管理策略。特别强调了使用规范，包括必须及时remove()防止内存泄漏，以及异步场景下ThreadLocal的局限性（需使用InheritableThreadLocal）。通过拦截器机制确保线程上下文的安全创