第 12 章的核心是：UV 统计的本质是海量去重计数。如果用 Set 保存所有用户，结果精确但内存高；HyperLogLog 不保存完整用户集合，而是用概率算法估算基数，用极低内存换取可接受的小误差。

第 10 章的核心是：Redis GEO 负责地理位置索引，MySQL 负责完整店铺信息。按 typeId 分组建立 GEO key，查询时用用户坐标做半径搜索，再回表补详情和距离。

可以这样回答：可重入锁是指同一个线程已经持有某把锁时，可以再次获取这把锁而不会被自己阻塞。它通常通过重入计数实现，线程每获取一次锁计数加一，每释放一次锁计数减一，直到计数为零才真正释放锁。5.3 这一节看起来突然讲了一段 Lua，但它不是黑马点评项目自己写的业务 Lua，而是 Redisson 内部实现RLock可重入能力的核心逻辑。用 Redis Hash 表示锁。大 key 表示锁名。小 ke

List：能模拟队列，能阻塞读取，比 JVM 队列更进一步，但缺少完善 ACK 和失败恢复。PubSub：能发布订阅，支持广播给多个消费者，但不持久化，消费者离线会丢消息。所以第 7 章最后要继续走向 Stream。记住这一句：秒杀订单消息不是普通通知，它必须尽量可靠地被消费、确认、失败恢复；这就是 List 和 PubSub 不够、Stream 要登场的原因。Stream 和消费者组到底强在哪里

消息队列就是存放消息的队列。1. 生产者：发送消息的人。2. 消息队列：保存和管理消息的地方。3. 消费者：从队列中取消息并处理的人。生产者：秒杀请求线程，或者 Lua 脚本消息队列：Redis Stream消费者：后台下单线程消息：订单任务，包含 userId、voucherId、orderId第 6 章 BlockingQueue 能讲通异步思想↓但它是 JVM 本地内存队列↓存在内存限制、宕

第 7 章最终落点是：也就是说，订单任务不再这样交接：而是变成：这篇文章主要讲清楚：先给结论：Stream 版秒杀下单可以拆成两段。第一段是请求线程 + Lua：第二段是后台消费者：完整流程图#mermaid-svg-KzsOyAk3JwTslqsG{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#3

存的是图片路径。真正的图片文件在 nginx 静态目录或 OSS 中。第 8 章的主线可以压缩成一句话：达人探店模块中，图片文件本身存 nginx/OSS，数据库保存笔记内容和图片路径；nginx/OSS：保存图片文件本身DTO/临时字段：组装前端需要的展示数据D` 保住。第 8 章的主线可以压缩成一句话：达人探店模块中，图片文件本身存 nginx/OSS，数据库保存笔记内容和图片路径；nginx

第 9 章后半部分的核心是：用写扩散换读性能。发布时把 blogId 推送到粉丝的 Redis ZSet 收件箱，读取时直接从自己的收件箱按时间滚动分页查询。

第 9 章后半部分的核心是：用写扩散换读性能。发布时把 blogId 推送到粉丝的 Redis ZSet 收件箱，读取时直接从自己的收件箱按时间滚动分页查询。

第 10 章的核心是：Redis GEO 负责地理位置索引，MySQL 负责完整店铺信息。按 typeId 分组建立 GEO key，查询时用用户坐标做半径搜索，再回表补详情和距离。