Go语言技术文章
-
RedisCluster默认不支持传统Pub/Sub跨节点广播，因频道按slot分片且gossip协议不传播订阅状态，SUBSCRIBE仅在本地节点生效；根本原因在于集群设计只负责数据分片，不实现消息路由。459 收藏 -
必须配合日期动态生成key，因Bitmap无时间维度，共用key会丢失日期信息且导致单key膨胀、RDB/AOF暴增、主从延迟；用户ID须映射为非负整数offset，避免直接强转；BITCOUNT偏高多因key未清理或offset错位；5000万DAU下Bitmap体积约6.25MB，但需防ID稀疏浪费内存。458 收藏 -
Redis布隆过滤器不支持动态扩容，BF.RESERVE设定的capacity和error_rate不可修改；扩容需手动迁移数据并切换key，参数选错易致内存激增或OOM。457 收藏 -
Pub/Sub频道命名必须带租户前缀，采用三段式结构{租户标识}:{业务域}:{实体ID}，禁用裸频道和通配符泛订阅；ACL需按前缀精确控制，显式授权+subscribe/+publish；TLS与消息体加密必须同时启用；Pub/Sub不可替代可靠队列，应改用Stream或List。457 收藏 -
Redis碎片率超1.5时响应变慢甚至雪崩，根本原因是jemalloc在不连续空闲块中反复查找合适内存块，导致分配延迟升高、CPU波动、GC压力上升并可能引发级联雪崩。457 收藏 -
缓存击穿是热点key过期瞬间并发请求涌向DB，需用逻辑过期、随机过期时间、分级预热、互斥锁及行为验证来防控。455 收藏 -
本文用两个 MySQL 会话复现可重复读和幻读场景，解释快照读、当前读、范围查询和间隙锁的关系，帮助排查线上并发写入问题。455 收藏 -
不能。volatile-ttl仅在内存不足时随机采样少量带过期时间的key淘汰TTL最小者，并非定时批量清理；高QPS下写入快于淘汰易致OOM，需配合随机偏移、调优采样数、限流及兜底策略。454 收藏 -
RedisCommandTimeoutException本质是命令执行完成但客户端未及时收到响应，与连接池大小无关；应优先调整command-timeout、keepalive及tcpUserTimeout等网络层参数。454 收藏 -
根本原因是客户端频繁新建并立即关闭TCP连接，导致Linux内核在主动关闭方维持TIME_WAIT状态（2×MSL，通常60秒），端口无法复用；Redis服务端不产生该状态，问题源于客户端未复用连接池、错误调用close()、配置不当或框架内重复初始化。454 收藏 -
volatile-lru是仅对设置了TTL的key生效的近似LRU淘汰策略，不淘汰无过期时间的key；必须显式配置maxmemory-policy且配合EXPIRE或SETEX使用，否则无效。454 收藏 -
是，HLL适合统计日活UV，但需接受约0.81%误差且不支持成员查询与精确交集；按日期分key（如uv:20240520）、设过期、统一用户标识方可稳健使用。453 收藏 -
发布订阅模式适合实时性要求极高、可容忍消息丢失、一对多广播型通知场景，如服务状态广播、实时日志分发、WebSocket用户事件广播；Stream适合需持久化、至少一次投递、支持消费者组与重试的场景，如订单异步处理、用户行为埋点、审计日志归档。452 收藏 -
不能。Redis6–7.0的ACL不支持Key前缀通配符（如~tenant:a:），仅支持字面Key名或~；7.0起虽有实验性前缀匹配，但生产未验证且不支持嵌套通配。452 收藏 -
Redis集群不支持Pub/Sub跨节点广播，因设计上无全局频道路由机制，PUBLISH消息仅被本地订阅者接收；应改用单节点Redis+连接池，或升级至Kafka/Pulsar等专业消息中间件。451 收藏