设计支持10W QPS的会员系统，如何做到？

后端出路在何方
1,264 阅读20分钟

架构设计

1. 问题背景

需求背景 某会员系统需要支撑 10W QPS 的高并发请求，主要功能包括：用户注册登录、资料查询、会员等级管理、积分处理（获取/消费）、营销活动支持（如优惠券系统）、以及高可靠性、低延迟的服务保障。

场景特点

  • 高并发性：瞬时用户访问量极大，需要系统快速响应，避免宕机。
  • 高可用性：会员系统是核心业务模块，任何故障都可能导致财务损失或品牌损害。
  • 数据一致性：需要保证用户信息、会员等级、积分等数据精准且一致。
  • 可扩展性：未来需要支持更大规模的流量和功能扩展。

在讨论设计之前，先确认需求的核心内容。

"首先，需要确认一下需求的核心功能和场景。根据描述，这个会员系统需要支持高并发，同时满足用户注册、登录、会员等级管理、积分操作以及优惠券管理等功能。作为一个高并发系统，我们需要特别关注系统的高可用性、数据一致性、低延迟和扩展性。"

如果有进一步说明，可以针对特定场景补充，比如：

  • 是否有峰值流量，例如在某些节假日营销活动中？
  • 数据一致性要求是否为强一致性还是最终一致性？
  • 是否需要考虑国际化、对接第三方系统？

2. 思考策略

在设计这样一个系统时，需要考虑以下几点：

  1. 拆解需求：明确核心功能和非核心功能，逐步完成设计。
  2. 高并发处理：如何通过架构设计和技术方案来支撑 10W QPS。
  3. 数据存储与查询优化：在高流量场景下如何避免数据库成为性能瓶颈。
  4. 高可用性与容灾能力：如何保证系统 7×24 小时稳定运行。
  5. 扩展性与成本控制：既能满足当前需求，也兼顾未来业务增长。
  6. 容量规划：对硬件资源、流量峰值有准确预估，避免资源浪费或不足。

接下来需要简要概述设计思路，展示整体设计框架。

"对于 10W QPS 的系统设计，会从以下几个方面进行：

  1. 确定核心需求并对其拆解。
  2. 考虑高并发架构设计，解决流量瓶颈问题。
  3. 优化数据存储，利用缓存和分库分表应对大数据量。
  4. 设计高可用和可扩展的系统架构，满足未来增长需求。
  5. 制定针对性策略来解决高并发和存储瓶颈等难点。"

3. 需求拆解与技术选型

根据会员系统的功能，拆解核心需求并进行技术选型：

核心需求拆解

  1. 用户管理（注册、登录、信息查询/修改）：

    • 目标：高速读写、支持用户登录认证。
    • 技术选型：分布式缓存（如 Redis）+ 用户服务 + Token 认证机制。

  2. 会员等级管理：

    • 目标：实时更新等级、快速查询。
    • 技术选型：关系型数据库（如 MySQL）+ 缓存。

  3. 积分管理：

    • 目标：支持并发获取/扣减积分，保证数据一致性。
    • 技术选型：高性能数据库（如 MySQL 分库分表）+ 分布式锁（如 Redis）。

  4. 营销活动（如优惠券发放与核销）：

    • 目标：支持海量优惠券生成、发放和并发核销。
    • 技术选型：消息队列（如 Kafka）+ 分布式数据库。

  5. 对外 API：

    • 目标：高并发、高可用 API 接口。
    • 技术选型：API 网关 + Nginx + 限流与熔断降级。

强调核心功能，并结合技术选型，对场景的理解。例如：

"我们可以将会员系统拆解为以下 4 个核心模块：

  1. 用户管理模块：实现注册、登录、信息查询等功能。由于登录场景通常是高并发的，我们可以采用分布式缓存（如 Redis）来缓存用户信息，并使用 JWT 提供无状态认证。
  2. 会员等级管理模块：会员根据消费或积分进行等级调整，此类操作通常是读多写少，因此可以将规则配置与常见等级信息缓存到 Redis。
  3. 积分管理模块：积分增减、消费属于高频写操作，我们需要采用分布式锁（如 Redis Redlock）来保证一致性，同时使用消息队列来削峰填谷。
  4. 营销活动模块：优惠券的发放与核销需要高并发支持，建议通过消息队列（如 Kafka）实现异步化，同时在核销时使用唯一性校验避免重复消费。"*

4. 需求拆解细化

我们进一步细化每个核心模块的内容：

1. 用户管理

  • 支持手机号/邮箱注册，密码加密存储（如 bcrypt）。
  • 登录支持短信验证码或密码校验。
  • 数据查询优化：常用信息放入 Redis 缓存（如用户昵称、头像、会员等级）。

2. 会员等级管理

  • 等级规则：根据消费记录或积分动态调整。
  • 数据模型：等级表（存放规则配置）、用户表（记录等级与经验值分布）。

3. 积分管理

  • 积分规则：支持积分获取、消费和扣减。
  • 数据一致性：采用分布式锁（如 Redis RedLock）确保积分扣减的原子性。

4. 营销活动

  • 优惠券生命周期：生成、分发、核销、过期。
  • 并发控制：消息队列用于异步发放，避免分发压力集中到数据库。

5. 系统选型及中间件

一个典型的 10W QPS 的会员系统设计需要以下技术组合：

  1. 数据库层：MySQL（分库分表）+ Redis（缓存）。
  2. 消息队列：Kafka / RabbitMQ，用于异步解耦高并发任务。
  3. 分布式锁：基于 Redis 的 RedLock 或 Zookeeper。
  4. 网关：Nginx + Kong（支持限流、熔断）。
  5. 监控与容灾：Prometheus（监控）、ELK（日志）、Sentinel（限流降级）。
  6. 负载均衡：Nginx + LVS。
  7. 分布式 ID 生成器：Snowflake 算法（唯一性和高效性）。

6. 系统整体架构

整体架构分为以下几层：

  1. 接入层：
    • 使用 Nginx 作为负载均衡，搭配 API 网关（Kong 或 Spring Cloud Gateway）。
    • 限流与熔断：由 Sentinel 或 Hystrix 实现。
  2. 服务层（微服务模块化）：
    • 用户服务：负责用户的注册登录、信息管理。
    • 会员服务：管理会员等级规则与变更。
    • 积分服务：处理积分的增减和相关校验。
    • 营销服务：优惠券发放与核销模块。
  3. 存储层：
    • 数据库：MySQL（分库分表）和 Redis（缓存层）。
    • 分布式存储：用于存储图片、文件等非结构化数据（如阿里云 OSS）。

在这个部分，你需要画一个简化的架构图并进行讲解。如果没有白板或工具，可以通过语言清晰描述。

"在整体架构上，我会将系统设计为一个分层架构，主要包括以下几层：

  1. 接入层：通过 Nginx 配合 API 网关（如 Kong）来分发流量并实现限流和熔断操作。
  2. 服务层：采用微服务架构，将系统拆分为用户管理服务、会员等级服务、积分服务、营销服务等。同时，利用服务发现机制（如 Nacos 或 Eureka）来管理服务实例。
  3. 存储层：采用分布式数据库 MySQL，并对表做分库分表，结合 Redis 缓存热数据，避免数据库成为性能瓶颈。
  4. 异步化处理：通过 Kafka 或 RabbitMQ 实现高并发场景下的异步任务处理，比如积分扣减或优惠券发放。
  5. 监控与容灾：通过 Prometheus 进行系统监控，利用 ELK 堆栈分析日志，确保系统高可用性。

123.png

7. 数据结构设计（ER 图）

核心表结构：

  1. 用户表（user）：

    • 主键：user_id。
    • 字段：手机号、邮箱、加密密码、头像、注册时间等。

  2. 会员等级表（membership_level）：

    • 主键：level_id。
    • 字段：等级名称、所需经验值、优惠比例等。

  3. 积分表（points）：

    • 主键：user_id。
    • 字段：总积分、更新时间等。

  4. 优惠券表（coupon）：

    • 主键：coupon_id。
    • 字段：优惠金额、有效期、状态等。

数据设计是一个重要环节，尤其是高并发场景下，如何设计合理的数据模型和优化存储。可以这样组织：

"对于会员系统，会设计以下几个核心数据表：

  1. 用户表：user_id 作为主键，存储用户基本信息（手机号、昵称、注册时间等）。
  2. 会员等级表：记录等级规则（等级名、经验值区间等）。
  3. 积分表：user_id 作为主键，记录用户的积分总额和变更时间。
  4. 优惠券表：记录优惠券的状态（已发放、已使用、已过期）。*

为了应对大数据量，我们可以采用以下策略：

  1. 分库分表：按 user_id 进行水平拆分，每个库或表只存一部分用户数据。
  2. 缓存优化：将高频查询的数据（如积分余额、用户等级）缓存到 Redis，设置合适的过期时间。
  3. 存储归档：将冷数据归档到 Hadoop 或 OSS，减轻主库压力。*

234.png

8. 核心逻辑实现

1. 注册/登录流程

  • 请求：校验手机号/邮箱是否合法。
  • 密码加密：使用 bcrypt 存储。
  • Token 生成：采用 JWT（JSON Web Token）实现无状态鉴权。

2. 积分扣减

  • 获取分布式锁：
    • 使用 Redis 的 SETNX 锁保证扣减操作的原子性。
  • 更新数据库：
    • 增量更新积分字段，确保一致性。

3. 优惠券发放

  • 异步处理：
    • 优惠券生成任务放入 Kafka 队列，逐步发放以缓解瞬时压力。

9. 高并发场景的挑战与应对策略

挑战

  1. 瞬时高流量导致请求堆积。
  2. 数据库成为性能瓶颈。
  3. 数据一致性难以保证。

解决方案

  1. 限流与降级：
    • 使用 Sentinel 动态调整接口的 QPS 限制。
  2. 读写分离：
    • 数据库主从分离，读操作走从库，写操作走主库。
  3. 缓存优化：
    • 热数据放入 Redis，减少数据库压力。
  4. 异步化：
    • 高并发操作通过消息队列（Kafka）异步处理。

这个部分，leader肯定希望考察你对高并发问题的理解和解决能力。

"高并发场景下，我们需要解决以下几个关键挑战：

  1. 流量控制与限流：利用 API 网关或 Sentinel 实现限流、熔断和降级，避免流量突增压垮服务。
  2. 数据库性能优化：通过读写分离和分库分表，将读请求分发到从库，减轻主库压力。
  3. 缓存层优化：将用户常用数据存入分布式缓存（如 Redis），例如用户的会员等级、积分余额等。
  4. 异步化解耦：利用消息队列（如 Kafka）处理积分扣减或优惠券发放等耗时操作，避免阻塞主流程。
  5. 缓存穿透： 通过设置布隆过滤器拦截非法请求。
  6. 缓存击穿： 设置分布式锁，控制高并发时对同一数据的访问。

10. 存储瓶颈及解决方案

存储瓶颈

  • 单表数据量过大（如用户积分记录表可能会膨胀到亿级别）。
  • 高并发读写带来的锁等待。

解决方案

  1. 数据分库分表：
    • 按 user_id 进行水平拆分（如 100 张表）。
  2. 分布式缓存：
    • 热数据（如用户当前积分）放入 Redis。
  3. 压缩冷数据：
    • 归档历史数据到离线存储（如 Hadoop 或 OSS）。

存储优化是系统设计中非常重要的一部分，尤其是在 10W QPS 这种高并发场景下。

"存储层的瓶颈主要可能体现在以下两个方面：

  1. 单表数据量过大：单表记录量如果超千万级别，查询性能会大幅下降。解决方案是按用户 ID 或其他维度进行分库分表，结合分布式中间件（如 ShardingSphere）。
  2. 高并发写入压力：对于积分扣减等高并发写操作，可以通过 Redis 分布式锁保证一致性，同时将请求写入 Kafka 实现异步处理。

11. 容量预估

假设：

  • 单个请求大小为 2KB。
  • 峰值 QPS 为 10W，每秒数据写入量为 200MB。

存储需求：

  • 日请求量：10W * 60 * 60 * 24 = 86.4 亿。
  • 数据量：86.4 亿 * 2KB = 172TB/天。

解决：

  • 使用分布式存储系统（如 HDFS）存储历史数据。
  • Redis 缓存 10% 热数据。

"综上所述，我设计的会员系统通过合理的架构分层（接入层、服务层、存储层）、缓存优化、数据库分库分表，以及异步化和限流降级策略，能够稳定支撑 10W QPS 的并发请求。整体系统具备高可用、高扩展性，同时保证关键数据的一致性。未来还可以通过动态扩容和功能模块的优化，进一步提升性能。"

高性能、高可用系统架构策略

1. 双中心主备架构（基于ES）

  • 架构设计：在两个数据中心分别部署主集群和备集群。

    • 主集群负责处理所有读写请求。
    • 备集群通过消息队列（MQ）实时同步主集群数据，作为容灾备份。

  • 故障快速转移：当主集群出现异常时，流量切换到备集群，保障系统的高可用。

假设与数据支撑：

  1. 假设：

    • 系统需求为10W QPS，其中80%的流量分布在“查询会员信息”和“查询积分”场景。
    • 两个机房：A机房（主机房）和 B机房（备份机房）。
    • 每个机房部署的ES集群需支持至少60W QPS的峰值流量（考虑冗余设计）。
    • 日均数据新增量：1TB（会员活动产生的数据），主备集群需实时同步。
    • 响应时间要求：查询数据需控制在50毫秒以内。

  2. 部署设计：

    • 主集群部署在A机房，备集群部署在B机房。
    • 数据通过消息队列（MQ）实时同步，从主机房写入到备机房集群。
    • A机房（主机房）：运行主集群，承担70%的流量。
    • B机房（备机房）：运行备集群，主要用于容灾，平时承担30%的流量。
    • 通过公网IP或内网路由实现两个机房的数据互通，延迟<10ms。

  3. 数据读取策略：主机房 vs 备机房

    • 正常情况：

      • 读取主机房节点（A机房主集群）：服务请求会优先路由到A机房，减少链路延迟。
      • 备机房（B机房备集群）：仅用于容灾或非关键场景（如后台数据分析）。

    • 故障情况：

      • 如果A机房部分节点或整个机房不可用，流量动态切换至B机房。

故障应对方案：

  • ES节点宕机：

    • 使用ES的分片（shard）副本机制，保证单节点宕机时，其数据副本可以从其他节点读取。
    • 例如：每个索引配置3个主分片（primary shard），再创建1个副本分片（replica shard），总共6个分片分布在3个节点。

  • 主集群宕机：

    • 流量切换到B机房的备集群，通过DNS切换或者流量网关（比如API网关）重新分配流量。
    • 备用集群通过MQ同步的方式，保证数据一致性。

image.png

2. 流量隔离三集群架构

  • 原因： 营销活动产生的高TPS请求（如大促销、促销短信）可能影响系统的核心功能。
  • 解决方案：将营销活动流量隔离到独立的ES集群，与主集群分离，确保核心会员服务（如积分查询、权益兑换）的稳定性。

双中心主备架构

image.png

假设与数据支撑：

  1. 数据假设：

    • 营销活动流量占用20%的总流量，但由于高TPS特性，可能在短时间内暴增至50%。
    • 核心会员功能（如积分查询）需要保持低延迟（<50毫秒）。
    • 营销系统流量波动范围：2W QPS ~ 50W QPS。

  2. 隔离设计：

    • 核心会员功能流量使用主集群。
    • 营销活动的流量使用独立的ES集群。
    • 用户请求通过API网关流量分类，根据请求类型分别路由到不同的集群。

image.png

流量隔离设计

1. 假设与数据支撑

  • 流量特征：

    • 核心会员功能（积分查询、身份认证）：70%流量，稳定，性能要求高。
    • 营销活动（促销、推送等）：30%流量，高TPS，短时流量峰值可能占用系统资源。

  • 设计目标：

    • 核心功能和营销流量分离，避免营销活动影响用户体验。
    • 使用独立ES集群处理营销流量。

image.png

三、Elasticsearch（ES）集群优化

为支持高并发的查询需求，对ES集群进行优化是关键。

  1. 负载分配优化

    • 合理规划节点和分片，确保流量均匀分布，避免单点性能瓶颈。

  2. 线程池调整

    • 根据实际并发量调整线程池大小，比如增加搜索线程池来提升查询能力。

  3. shard（分片）优化

    • 减少小分片的数量，避免内存浪费，同时也要避免单个分片过大。

  4. 字段类型设置

    • 精准定义字段类型，避免全文索引的额外开销。例如，“积分”字段可以设置为数值类型（integer），避免使用默认string类型。

  5. 查询优化

    • 设计合理的过滤条件和索引结构，减少复杂查询的耗时。例如，使用前缀过滤或keyword字段代替通配符查询。

假设与数据支撑：

  1. 性能目标：

    • 查询响应时间 <50毫秒
    • 支持10W QPS的查询并发能力

  2. 优化措施与数据支撑：

    • 分片设计：

      • 为每个ES索引设置6个分片，每个分片配置1个副本。假设每个节点的查询吞吐量为2W QPS，6个分片分布在4个节点上，可以满足10W QPS的需求。

    • 查询优化：

      • 精准字段类型设置，例如积分字段设为integer，避免使用text类型。
      • 使用过滤器（filter）替代查询（query），提高性能。
      • 主动缓存热查询，减少重复计算。

四、缓存方案

Redis缓存层是高并发系统的标配，用于缓解数据库和ES的压力。

  1. 引入Redis缓存

    • 作用：为高频访问的数据（如会员等级、积分信息）提供快速读写能力，减少ES和数据库的直接查询压力。
    • 设计：对热点数据（如前1万名活跃用户）设置缓存。

  2. 解决缓存一致性问题

    • 问题：ES有近1秒的写入延时，可能导致缓存数据与ES数据不一致。
    • 解决方案：采用双写机制（同时更新缓存和ES），并设置TTL（过期时间）定期刷新缓存。

假设与数据支撑：

  • 访问模型：

    • 80% 的请求为读取（查询会员等级/积分）。
    • 缓存命中率目标：95%。

  • 方案设计：

    • 热点数据（高频访问的会员信息）写入Redis缓存。
    • 设置TTL（过期时间）为10秒，减少缓存与存储层数据不一致的时间窗口。
    • 使用双中心多集群架构，实现就近访问和容灾。

image.png

五、Redis高可用性方案

  1. 双中心多集群架构

    • 设计：在两个机房分别部署Redis主备集群，并通过双写同步数据。
    • 效果：用户的请求可就近访问Redis，提高响应速度。

  2. 故障切换

    • 方法：配置Redis哨兵（Sentinel）机制，当主节点宕机时自动切换到备节点，保障服务不中断。

六、数据库迁移

  1. 从SqlServer迁移到MySQL

    • 原因：MySQL提供更好的扩展性，支持分布式部署。
    • 设计：采用分区集群，将数据按用户ID或区域分片存储到不同的节点，提高性能和扩展性。

  2. 迁移过程

    • 全量同步：使用数据迁移工具（如DTS）将所有历史数据迁移到MySQL。
    • 增量同步：通过监听SqlServer的日志变化，实时同步新增或更新的数据。
    • 灰度切换：逐步将流量切换到MySQL集群，确保迁移过程平稳。

假设与数据支撑：

  1. 迁移目标：

    • 数据量：10TB级会员数据。
    • 完成时间：2周（全量+增量+灰度切换）。

  2. 迁移流程：

    • 全量同步：使用数据复制工具（如DTS）将历史数据迁移到MySQL。
    • 增量同步：通过监听SqlServer的变更日志，实时同步新数据。
    • 灰度切换：逐步将读写流量导入新的MySQL集群，避免风险。

image.png

七、MySQL和ES主备架构

  1. 应对DAL（数据访问层）组件故障

    • 方法：设计自动化的故障转移机制，确保当数据库连接池或路由层发生问题时，系统自动切换到备数据库。

  2. 应对数据库故障

    • 主备数据库之间通过异步复制保持一致性，备数据库承担灾备角色。

八、数据精准性和正确性保障

  1. 治理异常会员关系

    • 针对用户多账号绑定或异常账户行为，设计校验逻辑清理异常数据。

  2. 复杂逻辑处理

    • 通过日志分析和接口优化，解决错误绑定、重复积分等问题。

九、系统稳定性和性能保障

  1. 流控策略

    • 对外层流量进行分级限流，比如核心功能的优先级高于营销活动流量。

  2. 降级策略

    • 当系统负载过高时，优先保障核心功能（如积分查询），对于非核心功能（如活动推荐）进行临时关闭或限流。

深度优化（当ES被打爆时怎么办）

1. 假设：ES被打爆场景

  • 单个ES节点吞吐上限为2W QPS，假设读写流量突然超出10W QPS。
  • 查询响应时间提升至>200ms，部分服务不可用。

2. 优化措施

  1. 查询优化：

    • 使用过滤器（filter）代替查询（query）：将条件变为布尔值缓存，减少重复计算。
    • 字段类型优化：避免全文索引的开销，对精确匹配字段使用keyword类型。
    • 热点数据缓存：将高频查询（如VIP会员信息）写入Redis缓存，减少ES压力。

  2. 分片（shard）优化：

    • 增加分片数量，让更多节点参与查询。
    • 假设原本有6个分片，可以扩展至12个分片，分布在6个节点上。

  3. 索引生命周期管理：

    • 设置冷数据索引：将3个月前的历史数据存储在S3或Hadoop等冷存储。

  4. 扩容集群：

    • 水平扩展ES节点，例如从4节点扩展到6或8节点，提升整体吞吐量。

image.png

avatar
文章
阅读
粉丝