日志记录

📄🦌🙌🐟🏖️

日志记录

Where there is a where there is a way

随机文章

按住 Shift 横向滚动

服务端优化

Redis服务端优化包括：缓存实例尽量关闭持久化，使用AOF并合理配置rewrite；慢查询阈值建议设为1000微秒，日志队列长度1000；安全方面需设置密码、禁用keys等危险命令、限制网卡和端口；内存需监控使用率，合理配置复制、AOF和客户端缓冲区大小。

2026-03-26 Middleware 8

Administrator

本文介绍了Redis中Pipeline批处理的优化原理与应用。通过对比单条命令、N条依次执行和批量执行的流程，说明管道技术能显著减少网络往返时间，提升吞吐量。需注意Pipeline的多个命令不具备原子性。在集群环境下，批处理命令的多个key必须落在同一插槽，否则会执行失败。解决方案包括使用hash_tag（如`{a}name`）使key的哈希计算集中于标签部分，确保同一槽位；或采用并行slot方式，如`StringRedisTemplate.opsForValue().multiSet(map)`底层即采用该机制，相关查询可用`multiGet`实现。

2026-03-26 Middleware 9

Administrator

Redis键值设计与BigKey问题

根据文章内容，摘要如下： Redis使用需遵循最佳实践：Key结构采用`[业务名]:[数据名]:[id]`格式，value不超过44字节，避免特殊字符，以提升可读性、防冲突、便管理并节省内存。BigKey指单个value超10KB或集合元素超1000的数据，会引发网络阻塞、数据倾斜、Redis阻塞及CPU飙升。可通过`redis-cli --bigkeys`、`scan`扫描、第三方工具或网络监控发现，Redis 4.0后建议用`unlink`异步删除。此外，应根据业务场景合理选择数据类型，以优化性能与内存。

2026-03-26 Middleware 10

Administrator

Redis通过HyperLogLog实现UV统计

Redis的HyperLogLog是一种概率型数据结构，用于高效统计大规模数据的唯一元素数量（基数估算）。它固定占用12KB内存，可处理亿级数据，标准误差约0.81%。底层通过哈希分桶（16384个桶）和调和平均数修正估算基数，支持PFADD、PFCOUNT、PFMERGE命令。UV（独立访客数）统计需去重，面临海量数据、实时性和存储成本挑战。示例中向HyperLogLog添加100万用户数据后统计基数，内存占用极小，验证了其高效性。

2026-03-26 Middleware 11

Administrator

Redis通过BitMap实现用户签到

本文介绍了Redis BitMap在用户签到场景中的应用。传统数据库存储签到信息（如每天一条记录）会因海量数据（1亿条/年）导致压力巨大。BitMap利用bit位映射日期（每月一位图），0/1表示未签到/签到，通过Redis string实现（最大512M，约2^32 bit）。核心命令包括：`SetBit`（设置指定偏移位）、`GetBit`、`BitCount`（统计1的数量）、`BitField`（批量操作位字段）、`BitOp`（位运算）、`BitPos`（查找首个0/1）。签到功能：每月为每个用户生成key（如`sign:userId:2024/07`），当天通过`setBit key dayOfMonth-1 1`记录签到。连续签到统计：使用`BitField get u[dayOfMonth] 0`获取本月截至今日的十进制数，然后从后向前逐位与1做AND运算并右移，计数连续为1的位数，直至遇到0结束。该方法高效节省存储空间，适合大规模签到场景。

2026-03-26 Middleware 7

Administrator

Redis的GEO实现查看附件商户

本文介绍了Redis GEO数据结构及其在商户搜索中的应用。GEO（地理坐标）从Redis 3.2版本开始支持，核心命令包括：GEOADD（添加坐标）、GEODIST（计算距离）、GEOHASH（转换哈希）、GEOPOS（获取坐标）、GEORADIUS（已废弃）和GEOSEARCH（6.2新增，支持圆形/矩形范围搜索）。在附件商户搜索实践中，先将店铺按类型分组，用GEOADD批量导入经纬度数据；查询时，根据客户端坐标、类型和半径，使用GEOSEARCH按距离排序、分页返回附近商户的ID和距离，再从数据库查询完整信息。该方法有效实现了基于地理位置的附近商户搜索功能。

2026-03-26 Middleware 10

Administrator

Redis实现共同关注和关注推送

该文章介绍了关注系统的三部分功能： 1. **关注与取关**：基于`tb_follow`表实现两个接口——关注/取关（通过`isFollow`布尔值控制新增或删除记录）和判断是否关注（查询记录数）。 2. **共同关注**：改造关注/取关接口，将用户ID同步到Redis的Set中；求当前用户与目标用户关注列表的交集，实现共同关注查询。 3. **关注推送（Feed流）**：对比Timeline（时间排序）和智能排序模式，详解Timeline的三种实现方案（拉、推、推拉混合），并基于Redis的SortedSet实现推模式：博主发布笔记时推送到粉丝收件箱，使用`ZRevRangeByScore`实现滚动分页（根据时间戳和偏移量），保证消息不重复、不遗漏。

2026-03-26 Middleware 8

Administrator

Redis实现点赞排行表

本文介绍了点赞与排行榜功能的实现。点赞功能要求同一用户只能点赞一次，再次点击取消，前端通过isLike字段高亮。实现步骤：在Blog类添加isLike字段；利用Redis的set集合存储点赞用户ID，未点赞时数据库点赞数+1并将用户加入set，已点赞则减1并移除。同时修改查询业务，判断当前用户是否点赞并赋值isLike。排行榜功能将set改为sorted set，以时间戳为分数存储点赞用户，实现按时间排序。查询点赞列表时，使用ZSet的range方法获取top5用户ID，再根据ID查询用户信息，并通过ORDER BY FIELD保持原顺序。

2026-03-26 Middleware 10

Administrator

Redis实现优惠卷秒杀(消息队列，分布式锁，全局id生成器,lua脚本)

本文围绕分布式系统下的秒杀场景，介绍了全局唯一ID的生成策略（UUID、Redis自增、雪花算法等）及Redis实现的ID生成器；详细阐述了优惠券秒杀下单的完整流程，包括表结构设计、库存判断与订单创建。针对高并发下的超卖问题，采用乐观锁（stock>0条件）解决。为实现“一人一单”，引入分布式锁，对比了基于Redis的简单锁与Redisson可重入锁，并解决锁误删、原子性及主从一致性问题。最后通过Redis+Lua脚本+Stream消息队列实现异步秒杀，将库存扣减与订单创建分离，大幅提升性能，确保数据一致性与高可用。

2026-03-26 Middleware 9

Administrator

Redis商户查询缓存(缓存三大问题以及解决方法)

本文系统介绍了缓存的核心概念与常见问题。缓存是临时存储数据的高性能缓冲区，可降低后端负载、提升读写效率，但会带来数据一致性、代码维护和运维成本。添加Redis缓存时，通常先查缓存，若命中则直接返回；未命中则查数据库并写入缓存。缓存更新策略建议：先更新数据库，再删除缓存，并设置过期时间。针对缓存穿透（缓存和数据库均无数据），可通过缓存空对象、布隆过滤或加强参数校验来防御。缓存雪崩（大量key同时失效或Redis宕机）可通过TTL随机值、Redis集群、限流和多级缓存缓解。缓存击穿（热点key失效导致高并发请求击穿数据库）可用互斥锁保证只重建一次，或用逻辑过期方案（数据过期后异步更新）以提高性能。

2026-03-26 Middleware 10

Administrator