Tinder System Design

设计一个支持 5 亿总用户、5000 万日活跃用户（DAU）的约会匹配系统。该系统的核心挑战在于结合高并发地理位置检索（LBS）与极低延迟的实时双向滑动匹配。

---

1. 核心业务与高可用指标

• 基本功能：
  1. 用户 Profile 维护：包含用户的基本属性、兴趣、照片以及关键的经纬度（Latitude/Longitude）。
  2. 地理位置发现（Recommendation）：根据用户的地理筛选范围及偏好，在毫秒级内返回附近未看过的推荐 Profile。
  3. 滑动判定（Swipe）：记录用户的“左滑（Pass）”和“右滑（Like）”。
  4. 实时匹配通知（Match & Notification）：若两名用户互相同意（右滑），立即触发 Match 通知双方。
• 非功能性指标：
  • 低延迟：推荐列表加载时间需在 200 毫秒以内。
  • 高吞吐量：支持 5000 万 DAU 下的高频滑动数据持久化。
  • 高可用性：系统服务需达到 99.99% 以上的可用性。

---

2. 关键系统架构与优化

地理位置索引 (Geohash / Quadtree)

• 挑战：传统数据库在海量经纬度下进行二维空间范围查询（如“寻找附近 10 公里的用户”）极其缓慢。
• 解法：引入 Geohash 或 四叉树（Quadtree） 机制。
  • 将地球表面划分为网格，并将二维的经纬度数据压缩编码为一维的哈希字符串。
  • 这使得空间范围查询可以退化为数据库中对一维 Geohash 编码的前缀或范围检索（Range Query），极大地提升了附近人查询的响应速度。

推荐去重与防重推荐 (Redis Bloom Filter)

• 挑战：避免向用户重复推荐其已经左滑（Pass）或右滑（Like）过的 Profile。
• 解法：在推荐服务前置引入 Redis 布隆过滤器（Bloom Filter） 或维护一个以 user_id 为 Key 的已阅集合（Read Set）。
  • 当加载推荐列表时，将候选人列表在缓存中快速做差集过滤，筛掉所有已被该用户滑过的人，保证推荐池的新鲜度。

实时双向滑动匹配与异步解耦

• 匹配工作流 (Match Workflow)：
  1. 滑动事件写入：当用户 A 右滑用户 B 时，请求进入 Match Service。
  2. 双向判定：服务在 Key-Value 缓存（如 Redis）中快速查询是否存在“B 已经右滑 A”的反向记录。
  3. 消息队列削峰：如果发生双向右滑（Like Match），不直接进行同步 of DB 读写，而是将 Match 事件推入消息队列（如 Kafka）。
  4. 异步消费与推送：
     • Match Worker：消费队列事件，在 Match 数据库中插入一条匹配记录。
     • WebSocket / Server-Sent Events (SSE)：长连接通知网关消费事件，立即向在线的双方用户推送匹配成功的实时系统通知。

Source: 2026-06-28-xiaohongshu-xhslink-com-o-1yYuoBQrRFH（来源未公开）