用LIST存评论盖楼因其天然支持按时间追加与顺序读取，而HASH无序、ZSET引入score管理复杂度；LRANGE不支持offset分页易致跳条，应改用游标式分页；大元素影响性能，需精简字段、外链资源、拆分存储并定期LTRIM。
为什么用 LIST 存评论盖楼而不是 HASH 或 ZSET
因为盖楼本质是「按时间先后追加、按插入顺序读取」，LIST 的 LPUSH/RPUSH + LRANGE 天然匹配这个模式；而 HASH 无序，ZSET 虽可排序但引入了 score 管理成本（比如时间戳精度、并发写入时钟漂移），反而让简单场景变重。
常见错误现象：ZSET 里用毫秒时间戳当 score，结果两个回复同一毫秒插入，顺序不确定；或者用 HASH 存 reply_id → data，再额外维护一个 LIST 存 id 列表——多一次写、多一次查，还容易不一致。
实操建议：
- 每个帖子的评论盖楼，用独立
LIST，key 命名为comment:post_id（如comment:12345） - 新回复一律
RPUSH comment:12345 "{'id': 'r678', 'uid': 101, 'text': '好有道理', 'ts': 1715823400}"，保证插入即有序 - 读最新 20 条：用
LRANGE comment:12345 -20 -1；读全部：用LRANGE comment:12345 0 -1
LRANGE 分页拉取时为啥不能直接用 offset/limit
Redis LIST 没有数据库那种 offset-based 分页能力，LRANGE 的起始索引是绝对位置（从 0 开始），不是偏移量。如果靠前的回复被删，索引会整体前移，导致“翻页跳条”或重复。
使用场景：用户下拉加载更多，需要稳定分页锚点。
实操建议：
- 放弃
LRANGE comment:12345 20 39这类“第 2 页”写法，改用游标式分页 - 每次返回数据时，附带最后一条回复的
id和它在LIST中的索引（用LPOS查，Redis 7.0+ 支持；旧版可用LRANGE+ 客户端扫描） - 下一页请求传入该
id，用LPOS comment:12345 "r678"找到位置，再LRANGE ... [pos+1] [pos+20] - 更稳妥的做法：不删历史回复，只加
"deleted": true字段标记，避免索引变动
单条回复太大，LIST 会不会撑爆内存或变慢
会。Redis LIST 底层对大元素（>4KB）会退化为双向链表存储，随机访问（如 LINDEX）变 O(N)，且每个元素都存完整 JSON 字符串，冗余高、序列化开销大。
性能影响：10 万条评论，平均 1KB/条 → 占用约 100MB 内存；若每条含 base64 图片字段，可能飙到 GB 级，触发淘汰或 OOM。
实操建议：
- 回复内容只存必要字段：
id、uid、text、ts，图片/附件用外链，别塞进LIST元素里 - 超过 2KB 的单条数据，拆成两部分：主
LIST存轻量元数据（{"id":"r678","uid":101,"ts":1715823400}），详情用HASH单独存：HSET reply:r678 text "..." image_url "..." - 定期用
LTRIM comment:12345 0 9999控制长度（比如只留最近 1 万条），避免无限增长
并发写入时，RPUSH 会不会丢数据或乱序
不会丢，也不会乱序。RPUSH 是原子操作，Redis 单线程模型保证同一 key 的多个 RPUSH 严格按网络到达顺序执行。
容易踩的坑：客户端没处理好连接复用或 pipeline 错误，比如 A 请求发了 RPUSH 但没等响应就断连，B 请求又发了一条——表面看像“后发先到”，其实是 A 根本没成功，不是 Redis 问题。
实操建议：
- 确认客户端是否开启 pipeline；开启状态下，必须确保所有命令发完再统一读响应，否则顺序不可控
- 关键业务加一层幂等：用
reply_id做唯一标识，写入前先SISMEMBER reply_ids:12345 r678，存在则跳过，再RPUSH+SADD reply_ids:12345 r678 - 不要依赖
LPUSH和RPUSH混用模拟栈/队列逻辑——盖楼只用RPUSH，读用LRANGE，保持语义清晰
最常被忽略的是：没控制 LIST 长度，也没做数据归档。线上跑半年，comment:12345 里存了 50 万条，LRANGE comment:12345 0 -1 一次拉全，不仅慢，还可能把 Redis 内存打满。得提前想好什么时候切分、怎么冷备。
