黑马点评

在上面的一章中，你已经成功敏锐地察觉到了主从架构的致命弱点：单点故障风险。 在主从架构中，如果“带头大哥”（Master）突然因为机房断电或硬件损坏而彻底宕机，整个集群就会瞬间失去处理“写请求”的能力

在真实的网络环境中，机房的网络抖动简直是家常便饭。如果小弟（Slave）仅仅因为网络波动断开了 3 秒钟，再次连上时，大哥（Master）如果还要傻乎乎地去执行 bgsave，把几 GB 的全量数据重

📚 高级篇 08. 分布式缓存 - Redis 主从全量同步原理 一、 核心概念：大哥如何认出小弟？ 在讲解同步流程前，必须先掌握两个极其关键的底层身份证号。如果没有它们，主从节点之间根本无法交流。

📚 高级篇 07. 分布式缓存 - 搭建 Redis 主从集群 (Docker 实战版) 一、 架构规划与核心思想 在本地只有一台电脑的情况下，为了模拟真实生产环境中的多台服务器，我们采用了 Dock

📚 高级篇 05. Redis 持久化 - RDB 与 AOF 终极对比 一、 核心特性终极 PK (面试速记表) 在实际的架构选型中，没有绝对的好与坏，只有最适合业务场景的权衡（Trade-off）

上一节我们极其硬核地扒开了 RDB 的底层 fork 和 COW 机制，明白了它是如何巧妙地利用操作系统特性来做“无感”快照的。 但是，RDB 最大的软肋也已经暴露无遗：两次快照之间的数据，在宕机时会

我们在上一节已经初步了解了 bgsave 命令会通过开启子进程来实现异步的 RDB 快照保存。 在面试中，对于初中级开发，知道 bgsave 不阻塞主进程就够了。但对于高级开发工程师，面试官一定会深挖

在单机版 Redis 中，数据全部存放在内存里，一旦服务器停电或宕机，内存里的数据就会瞬间灰飞烟灭。为了保证数据的高可用和持久化，Redis 提供了两种主流方案，我们要学的第一个就“快照派”的代表：R

进入高级篇，意味着你的技术视野将从“单机业务应用”正式跃升为“大型企业级架构”。在接下来的秋招提前批，以及像国家电网、湖南烟草等对系统稳定性要求极高的大型国企核心研发岗位面试中，仅仅掌握“Redis

上一节的 BitMap 非常适合统计“某个用户在一段连续时间内的状态（如签到）”，但如果我们要统计“一篇文章、一个商铺或者整个网站，每天有多少不同的人来看过”，面对千万级甚至亿级的用户量，BitMap

如果说前一节的 SETBIT 只是简单的数据记录，那么这一节我们要做的，就是把底层的二进制流完整地取出来，并利用 Java 的位运算（与运算、右移运算）像剥洋葱一样，一层层算出连续签到的天数。 📚 实

太棒了！上一节我们彻底理解了 BitMap（位图）的底层原理和极致的空间压缩能力。现在，我们要把理论转化为真实的 Java 代码，为我们的“黑马点评” App 加上每日签到功能。 这个接口的实现其实非

太棒了！我们终于来到了实战篇的最后一块“黑科技”拼图——用户签到。 在绝大多数的互联网 App（如淘宝、网易云音乐、掘金等）中，都有每日签到领积分的功能。这个功能看似简单，但如果用户量级达到千万级别，

太棒了！数据已经全部导入到 Redis 的 GEO 结构中了。万事俱备，只欠东风。 现在我们要打通这最后一公里：接收前端传来的用户经纬度，从 Redis 中查出附近的商铺，并把具体的商铺信息返回给前端

太棒了！掌握了 GEO 的基础命令后，我们现在要真刀真枪地把 MySQL 里的商铺数据“搬”到 Redis 里了。 这部分不仅仅是一段简单的数据同步代码，其中隐藏的**“大 Key 拆分”和“批量操作

我们即将开启一个非常有意思且极其贴近日常生活的模块——附近商铺。 无论是美团的“附近的美食”、微信的“附近的人”，还是滴滴的“附近车辆”，底层都离不开对地理位置（经纬度）的存储与范围计算。在传统关系型

太棒了！上一节我们彻底理清了“滚动分页”极其烧脑的理论和 offset 偏移量的计算规则。现在，我们要把这些理论翻译成实打实的 Java 代码。 这是整个“达人探店”模块中逻辑最复杂、细节最多的一段代

太棒了！我们在上一节成功把探店笔记推送到了粉丝的 Redis ZSet 收件箱里。现在，我们要解决 Feed 流架构中最容易出 Bug，也是秋招面试中 Feed 流架构必问的经典压轴题：如何正确地读取

太棒了！在上一节中，我们经过深思熟虑，最终为黑马点评项目选择了**“推模式（Push）”**作为 Feed 流的底层架构。并且明确了要使用 Redis 的 SortedSet (ZSet) 作为每个粉

你在朋友圈、小红书首页、微博里不断往下刷，永远刷不到头的内容列表，就是 Feed 流。实现一个高性能的 Feed 流，是所有大型互联网社交产品后端架构重中之重的难题。 📚 实战篇 07. 好友关注 -