SELECT * 为什么项目里不建议用 ？
不建议使用 SELECT * 的主要原因包括：1. 查询冗余字段浪费网络传输资源；2. 可能阻碍覆盖索引优化，降低查询效率；3. 表结构变更易引发代码兼容性问题，尤其是敏感字段泄露风险；4. SQL可读性差。虽然调试场景下SELECT *仍可使用，但正式开发中应明确指定所需字段（如SELECT id, username FROM users），以提高性能、安全性和代码可维护性。这一规范尤其适用于高频接口、大数据量查询等核心业务场景。
辰风沐阳 阅读 134 2026-07-31
NULL 到底等不等于 NULL ？
MySQL 中 NULL 表示未知或不存在的值，不能直接用 = 判断。查询 NULL 值应使用 IS NULL 或 IS NOT NULL，而非 = 或 !=。NULL 与空字符串不同，前者表示无值，后者是有值的空字符串。开发中需明确字段为 NULL 的含义，避免查询错误和统计偏差。关键点：NULL 不等于 NULL，判断 NULL 必须用专用语法，且要与空字符串区分开。
辰风沐阳 阅读 127 2026-07-30
Redis 修炼之路【第23讲：Redis 为什么怕大 Key】
Redis 大 Key 问题指存储超限数据（String>10KB/集合>5000元素），会导致严重性能问题：阻塞单线程处理、占用带宽、内存不均、持久化延迟。通过 redis-cli --bigkeys 或 --memkeys 扫描识别。解决方案包括：数据拆分（如大Hash分片）、压缩存储、使用 UNLINK 异步删除替代 DEL、分批遍历（如HSCAN）。日常需警惕业务累积产生的大 Key，从节点扫描避免影响主服务。核心思路是控制单Key数据量，保持Redis高效特性。
辰风沐阳 阅读 226 2026-07-26
Redis 修炼之路【第22讲：布隆过滤器到底靠不靠谱】
本文介绍了布隆过滤器的原理与应用。布隆过滤器通过位数组和多个哈希函数判断元素是否存在，具有"不存在则100%准确，可能存在则可能误判"的特点。在 Redis 中可通过 RedisBloom 模块实现，常用命令包括创建过滤器、添加元素和查询存在性。其主要用途是防止缓存穿透，能拦截99%无效请求。但存在不可删除元素、需要预热和可能误判的局限性。布隆过滤器是解决缓存穿透问题的有效方案，尽管有少量误判但不影响系统正确性。
辰风沐阳 阅读 216 2026-07-25
Redis 修炼之路【第21讲：秒杀系统设计】
本文介绍了使用 Redis 实现高并发秒杀系统的核心方案。系统采用分层架构：Nginx 限流→应用服务→Redis 库存扣减→MQ 异步下单→MySQL。关键技术点包括：1. 使用 Redis 的 decr 原子操作避免超卖；2. 通过Set集合防止用户重复下单；3. 异步消息队列削峰填谷。方案还包含库存预热、异步处理和数据库兜底三重保障机制，在保证数据一致性的同时实现高并发处理。该方案充分利用Redis的原子特性和高性能，有效解决了秒杀场景下的库存控制难题。
辰风沐阳 阅读 232 2026-07-24
Redis 修炼之路【第20讲：滑动窗口限流器】
本文介绍了一种基于 Redis ZSet 实现的滑动窗口限流方案，用于防止接口被恶意高频调用。核心思路是将每次请求的时间戳作为 score 存入 ZSet，通过统计窗口期内元素数量判断是否超限。方案支持通过 pipeline 批量执行清理过期数据、添加记录、计数和设置过期时间等操作，并可按用户、接口或 IP 等不同维度进行限流控制。这种实现简单高效，能有效应对突发流量问题。
辰风沐阳 阅读 207 2026-07-23
Redis 修炼之路【第19讲：延迟队列实现】
本文介绍如何使用 Redis 的 ZSet 实现延迟队列功能。核心思路是将任务执行时间戳存入 ZSet 的 score，任务内容作为 member。通过 zrangebyscore 获取到期任务，配合 zrem 实现任务消费的原子性操作，防止重复执行。消费逻辑采用先删除再执行的策略，利用 zrem 返回值确保多 worker 安全。失败任务可通过重试机制处理，设置最大重试次数。该方法适用于简单场景，复杂需求建议使用专业消息队列如 RabbitMQ/RocketMQ。
辰风沐阳 阅读 196 2026-07-22
Redis 修炼之路【第18讲：Redis 分布式锁实战】
本文介绍了分布式系统中使用 Redis 实现锁机制的方法。核心问题在于多服务器并发操作库存导致的超卖情况。基础方案是使用 set NX EX 命令加锁，配合删除操作。但存在锁过期误删问题，需通过 UUID 标识锁归属，并用 Lua 脚本保证原子性释放。针对长任务需引入看门狗机制自动续期，推荐直接使用 Redisson 工具库实现。关键点包括：唯一标识防误删、原子操作脚本、自动续期设计，强调原理理解与实际工具使用并重。
辰风沐阳 阅读 183 2026-07-21
Redis 修炼之路【第17讲：缓存雪崩为什么这么危险】
缓存雪崩指大批 key 同时失效或 Redis 宕机，导致请求直接冲击数据库，比缓存穿透和击穿更严重。解决方案包括：为 key 设置随机过期时间避免同时失效、采用多级缓存（本地+Redis）、部署 Redis 高可用集群（哨兵/Cluster模式）、实施限流降级保护数据库。与穿透（查询不存在key）和击穿（热点key失效）相比，雪崩影响范围更广，需综合运用多种策略保障系统稳定性。
辰风沐阳 阅读 169 2026-07-20
Redis 修炼之路【第16讲：缓存击穿和热点 Key】
缓存击穿指热点 key 突然过期，导致大量请求直接冲击 MySQL。解决方案包括： 互斥锁：仅允许一个请求查询数据库，其他请求等待，可能影响用户体验； 逻辑过期：value 中存储逻辑过期时间，先返回旧数据并异步更新，平衡一致性与性能； 热点 Key 防护：提前缓存、延长过期时间或使用本地缓存（如Caffeine）。与缓存穿透（查询不存在的key）不同，缓存击穿针对热点 key 失效场景，需结合业务选择合适策略。
辰风沐阳 阅读 196 2026-07-19