ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花一、核心定位：原生逻辑分页（内存分页）RowBounds是MyBatis内置的轻量分页工具，核心本质是逻辑分页（内存分页），而非数据库层面的物理分页。它不会改写SQL语句、不会生成LIMIT/OFFSET等数据库分页关键字，而是先执行全量SQL查询获取完整结果集，再在Java内存中对结果集做截取筛选，最终返回指定范围的分页数据。这种分页方式无需修改Mapper XML、无需额外配置，仅通过传入RowBounds对象即可实现分页，具备零侵入、易使用的特点，但也存在明显的性能短板...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花PageHelper是MyBatis生态中最常用的无侵入式分页插件，核心价值是无需手动编写分页SQL，只需一行代码即可实现分页查询，彻底规避手写分页的语法差异、参数错乱等问题。其底层原理高度依赖MyBatis原生扩展机制，整体可概括为：ThreadLocal线程隔离存储分页参数 + MyBatis拦截器拦截查询流程 + 动态适配数据库改写分页SQL，全程无侵入业务代码和原生Mapper SQL。一、核心底层：三大基石原理1. ThreadLocal：分页参数的线程隔离容器分页...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花一、SQL注入核心定义SQL注入（SQL Injection）是Web应用领域最常见、危害极高的安全漏洞，属于代码注入类攻击手段。攻击者通过在应用可控输入点（登录框、搜索框、URL参数、Cookie、表单等）插入恶意SQL语句片段，利用程序未严格校验过滤输入的漏洞，让恶意代码被数据库当作合法SQL指令执行，最终实现非法窃取、篡改、删除数据，甚至控制数据库服务器和Web服务器的目的。该漏洞的本质是代码与数据未分离，开发者将用户可控输入直接拼接进SQL语句，导致输入内容突破“数据...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花WatchDog（看门狗）是Redisson分布式锁的核心兜底机制，专门解决分布式锁超时自动释放、业务未执行完毕导致并发安全失效的问题。它本质是一个异步守护线程，会在持有锁的业务线程未完成执行时，自动为分布式锁续期，避免锁提前过期引发数据错乱、重复执行等风险，是Redisson可重入锁可靠性的关键保障。一、WatchDog机制的诞生背景原生Redis分布式锁存在一个致命短板：如果设置的锁过期时间过短，长耗时业务未执行完锁就会释放；如果设置过长，服务宕机后锁无法及时释放，会造成...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花分布式锁是分布式系统中解决共享资源并发竞争、防止数据错乱、重复执行的核心组件，核心目标是保证同一时刻仅有一个客户端持有锁、操作共享资源。根据底层依赖的中间件和实现机制，主流分布式锁可分为五大类，每类适配不同的业务场景、性能要求和一致性诉求，具体方案拆解如下：一、基于数据库的分布式锁（入门简易版）依托关系型数据库（MySQL、PostgreSQL）的事务、索引、锁机制实现，无需额外引入中间件，适合简单低并发场景，分为三种经典实现：1. 悲观锁（SELECT ... FOR UP...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花Redis分布式锁是分布式系统中解决并发竞争、保证数据一致性的常用方案，但设计或使用不当极易出现线程误释放锁、死锁、锁失效等问题。其中A线程释放B线程锁是最典型的致命漏洞，不仅会破坏业务原子性，还会引发数据错乱、超卖等严重问题。本文先拆解该问题的根本原因，再梳理分布式锁全生命周期的核心注意事项。一、A线程释放B线程锁的根本原因该问题并非偶然bug，而是锁无归属标识+锁超时自动释放+解锁逻辑无校验三者叠加的必然结果，核心是锁的持有者与解锁者身份不绑定。以下是完整场景复现与根源拆...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花一、问题本质：为什么会出现Key并发竞争？Redis是单线程串行执行命令的，本身不存在线程安全问题，但客户端并发请求会导致命令执行时序错乱，进而引发Key竞争：核心场景：多个客户端同时对同一个Key执行读-改-写流程（如查询库存、扣减库存、回写库存），Redis单命令原子，但多命令组合非原子，会出现脏写、数据覆盖、超卖/超扣等问题典型表现：库存超卖、计数器数值不准、分布式ID重复、缓存数据不一致本质矛盾：客户端并发操作 vs Redis多命令非原子性解决方案优先级：原子操作（...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花一、核心概念：什么是Redis分布式锁联锁Redis分布式锁联锁（MultiLock），是针对多个独立Redis锁资源的组合加锁方案，核心逻辑是：客户端必须同时获取所有目标锁资源的持有权，全部加锁成功才算联锁生效；若任意一个锁获取失败，则立即释放已拿到的锁，全程保证“全成功或全失败”的原子性，避免部分加锁导致的业务数据不一致。很多人容易混淆联锁与红锁（RedLock），二者核心差异一目了然：联锁（MultiLock）：针对同一Redis集群/单机的多个不同锁键（资源），追求多...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花红锁(RedLock)是Redis官方提出的分布式锁算法，由Redis作者Salvatore Sanfilippo(antirez)于2014年设计，旨在解决传统单节点Redis锁在分布式环境中的可靠性问题，尤其针对主从复制场景下的锁丢失风险。一、核心背景与问题传统单节点Redis锁通过SET key value NX PX ttl命令实现，但存在致命缺陷：主节点宕机时，若从节点尚未同步锁数据，主从切换会导致锁丢失单点故障直接导致整个锁服务不可用红锁通过多节点冗余+多数派共识...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花一、核心前提：Redis乐观锁的底层逻辑乐观锁的核心是不加锁、无阻塞，仅在最终提交操作时校验数据是否被并发修改：若数据未变则执行更新，若已被篡改则放弃本次操作并重试，避免线程阻塞。Redis没有内置的乐观锁API，而是通过WATCH命令 + 事务（MULTI/EXEC）实现CAS（比较并交换）机制，这是Redis实现乐观锁的唯一标准方案。核心原理：WATCH监控目标键的变更状态，事务提交前若键被修改，事务直接放弃执行，以此实现并发冲突校验。二、核心命令详解实现乐观锁需要配合4...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花秒杀库存扣减（Redis原子预扣 + 本地消息表/事务消息 + MySQL最终一致）的核心风险及防控方案该方案是秒杀场景下库存扣减的最优实现路径，可有效平衡高并发处理性能与数据一致性需求。在实际生产落地过程中，受秒杀场景超高并发特性、网络波动、系统异常等多重因素影响，系统仍面临高并发场景下的技术层面风险及业务数据一致性风险。本文将严格按照「风险发生阶段+影响程度」的逻辑拆解各类风险，针对每类风险提供可落地、可校验的防控措施，兼顾技术可行性与业务实用性，确保方案能够有效抵御秒杀...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花MySQL 作为持久化关系型数据库，具备强一致性特性；Redis 作为内存型缓存，具备高性能优势。二者作为异构存储，强一致性难以实现（需承担极高的性能损耗），因此绝大多数业务场景均以「最终一致性」为核心目标。以下将对主流一致性保证方案的执行流程、优缺点及适用场景进行详细解析，排序遵循「应用广泛程度+一致性强度」原则。核心背景：一致性问题的根源读写顺序异常：例如先更新缓存再更新数据库，在并发场景下易产生缓存脏数据；网络及系统故障：例如数据库更新成功，但缓存删除操作失败（如网络中...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花一、核心判定标准（先厘清概念）Redis的同步/异步，核心看命令/任务由谁执行、是否阻塞主线程：同步操作：由Redis单线程主线程串行执行，客户端发起请求后会阻塞等待服务端返回结果，执行完毕才会处理下一条命令，保证指令执行的原子性和顺序性；即使是耗时遍历类命令，全程仍由主线程处理，属于同步范畴。异步操作：由Redis后台线程/子进程独立执行，不阻塞主线程处理客户端请求，任务提交后主线程立即返回，后台默默完成执行，属于“非阻塞、最终完成”模式；部分异步任务存在极短暂的主线程准备...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花Redis集群是为了解决单机Redis的内存瓶颈、性能上限、单点故障等问题诞生的解决方案，整体分为官方原生集群（Redis内置，无额外依赖）和第三方集群方案（开源/商业扩展，适配特殊场景）两大类，且官方集群存在逐步演进的关系，覆盖从基础备份到分布式分片的全场景需求。一、官方原生Redis集群（推荐优先选用）官方集群无需引入第三方组件，兼容性强、运维成本低，是生产环境的主流选择，按功能演进分为三个层级，层层递进解决不同痛点。1. 主从复制集群（基础集群）这是Redis最基础的集...