引言

在互联网应用中，站内未读消息系统是维系用户活跃度与粘性的核心功能之一。当面对如“享读系统”这样需要支撑50万Qps（每秒查询量）的高并发场景时，传统的数据库直接读写方案会迅速成为性能瓶颈。本文将系统性地探讨如何设计一个高可用、低延迟、可扩展的站内未读消息系统，以应对海量实时请求的挑战。

一、 核心挑战与设计目标

在50万Qps的压力下，系统设计面临多重挑战：

1. 极致性能与低延迟：用户对未读数的感知要求几乎是实时的，读取延迟必须控制在毫秒级。
2. 高并发写入：用户每阅读一条消息、系统每推送一条新消息，都可能触发未读数的更新，写入并发量巨大。
3. 数据一致性：在分布式环境下，保证用户看到的未读计数准确无误，避免出现多读或少读。
4. 可扩展性与高可用：系统需能随着用户量增长平滑扩容，且任何单点故障不应影响核心服务。

因此，我们的设计目标聚焦于：读扩散、异步化、内存优先、最终一致性。

二、 架构设计总览

整体架构采用分层、分模块的设计思想，核心分为三层：

1. 接入层：采用高性能网关（如Nginx、API Gateway）进行负载均衡与请求路由，并实现限流、熔断等保护措施。
2. 逻辑服务层：

• 消息投递服务：负责处理新消息的创建与分发逻辑，将“有新消息”这个事件异步通知给计数服务。

• 未读计数服务：系统的核心，负责未读计数的增、删、改、查。它不直接处理业务逻辑，而是作为计数缓存的管理者。

• 会话/列表服务：负责管理用户的消息会话列表和消息内容本身，与计数服务解耦。

1. 数据存储层：采用多级混合存储策略。

三、 核心设计策略

1. 读写分离与读扩散

放弃为每条消息单独标记已读/未读的“写扩散”模式（存储开销和写入压力巨大）。采用 “读扩散” 模式：

• 未读集存储：系统只为每个用户维护一个未读消息ID的集合（或一个总计数）。
• 判定逻辑：当用户查询某个会话的未读数时，由服务端实时计算：该会话的最新消息ID与用户已读的最后一条消息ID之间的差值（或检查消息ID是否在用户的未读集合中）。这将对数据库的频繁写入转移为对缓存的高效读取。

2. 缓存优先与存储选型

• 一级缓存（热点数据）：使用 Redis 集群作为核心计数存储。
• 存储结构：为每个用户维护一个 Hash，键为 uid，字段为会话ID（sid），值为该会话的未读数。可以设置一个总未读数的字段。

• 优势：内存读写，性能极高；丰富的数据结构（Hash, Sorted Set）能很好支撑聚合查询和范围查询。

• 容量规划：以2亿用户，每个用户平均10个活跃会话估算，存储量可控，可通过集群分片（如Codis, Redis Cluster）轻松扩展。

• 二级备份与持久化：使用 Apache Cassandra 或 TiDB 等分布式数据库。
• 作用：持久化存储全量的用户-会话未读关系，作为Redis数据的备份和恢复源。

• 选型理由：它们具有高写入吞吐、线性扩展能力，适合海量数据的最终一致性存储。

• 消息同步：采用 异步双写 或 Write-Through 策略。所有计数更新先写入Redis，确保前端响应速度；随后通过消息队列（如Apache Kafka, RocketMQ）异步同步到分布式数据库，实现最终一致性。

3. 计数更新策略——增量与合并

直接为每条新消息实时更新全局计数会给Redis带来巨大压力。优化方案：

• 本地累加：在消息投递服务中，为每个用户维护一个小的内存累加器（如Guava Cache），在短时间内（如1秒）将多次增量合并为一次更新操作，再批量写入Redis。这能极大减少对Redis的网络请求和写入命令。
• 延迟更新：对于非强实时性的全局总未读数，可以接受秒级的延迟更新，通过后台任务定期从各会话计数聚合计算。

4. 容灾与数据一致性保障

• Redis数据持久化与备份：开启AOF和RDB，结合哨兵或集群模式实现高可用。
• 兜底查询：当Redis集群发生故障或缓存未命中时，服务应能自动降级，从分布式数据库中查询并回种缓存。为防止缓存击穿，需使用分布式锁或布隆过滤器。
• 最终一致性核对：设立定时对账任务，比对Redis与分布式数据库中的计数差异，并进行修复，确保数据长期准确。

四、 关键流程示例

1. 用户查询未读数（读流程）：

• 请求到达网关，路由至未读计数服务。

• 服务直接查询Redis集群中对应用户的Hash结构，获取各会话未读数及总数。

• 毫秒级返回结果。

1. 新消息到达（写流程）：

• 消息投递服务将新消息持久化到消息库。

• 向Kafka发送一个事件：{"uid": 123, "sid": 456, "increment": 1}。

• 未读计数服务消费该事件，先在本地累加器合并增量。

• 累加器定时（如每秒）将合并后的增量（例如，{123: {456: 5}} 表示用户123在会话456的未读数需增加5），通过 HINCRBY 命令批量更新至Redis。

• 另一个消费者将同样的更新异步写入Cassandra进行持久化。

五、 性能估算与优化

• Redis集群估算：假设50万Qps全部为读请求，单Redis实例（分片）处理约8-10万Qps，则需要约5-7个分片组成的集群。实际中读写混合，需根据比例增加资源。通过Pipeline和批量命令可进一步提升吞吐。
• 网络与序列化：使用高性能序列化协议（如Protobuf），优化网关与服务间的网络通信。
• 监控与调优：建立完善的监控体系（如Prometheus + Grafana），实时跟踪Qps、延迟、缓存命中率、数据库负载等核心指标，以便动态调整和扩容。

结论

设计一个支持50万Qps的站内未读消息系统，关键在于将核心的计数功能从传统数据库中剥离，构建一个以内存缓存（Redis）为核心、异步持久化为保障的独立服务体系。通过采用“读扩散”、增量合并、多级缓存、最终一致性等设计模式，能够有效化解高并发压力，实现低延迟、高可用的目标。享读系统的实践表明，清晰的分层架构和针对性的技术选型，是应对此类规模挑战的坚实基础。系统上线后，仍需持续监控和迭代，以应对未来可能增长的业务量。