项目中有高并发的挑战吗？并发量多少？用什么方案怎么做的？

相信不少朋友在面试的时候都被问到过：“项目中有高并发的挑战吗？并发量多少？”等等和高并发相关的问题，如果你不知道应该怎么回答，请继续往下看。

我就拿我们做过的分布式微服务抽奖项目给大家举例子：

这个项目是我们训练营内部的实战项目，近期会上线，如果想获取更多相关资料可以在文末加我好友。

举例：

像这种问题，咱们得分情况讨论，因为大家有的是实习生、有的是3年内经验，有的是把这个项目定位为：技术负责人，所以回答的思路和侧重点是不一样的：

1 思路和定位最重要

首先搞清楚你的项目定位是什么样的？保证你讲的数据自己能hold住，并不是数据越大越好，而是你自己能自信的讲清楚，面试官听着合理最重要！

1. 如果你是在校生、实习生，可以参考下面的初期阶段（小规模运营或测试）
2. 如果你对自己的判断是3年内的初级中级开发工程师，把这个项目作为你公司的项目去写，可以参考中期阶段（有一定用户量和活动规模）
3. 如果你是高级开发工程师，或者在一个公司已经工作了2年以上，要把抽奖项目作为你的重点项目去包装，那么你可以参考 大型成熟阶段（高流量、大规模运营）

2 项目中的高并发挑战分析

在抽奖类项目中，尤其是在市场上主流抽奖项目的背景下，高并发是一个常见且关键的挑战。对于我们的必中抽奖小程序也不例外。

• 从抽奖时间集中性角度来讲：我们的抽奖系统，方便三方快速接入，比如电商平台的限时抽奖、直播抽奖等，通常在特定时间点（如整点抽奖、直播中的某个时段抽奖）会吸引大量用户同时参与，导致瞬间高并发。我们项目的抽奖需要考虑上面的情况，也就是大量用户会在活动开始瞬间涌入，请求抽奖服务。
• 为了提高项目竞争力，我们也会和一些品牌开展合作，投放一些奖品吸引力高的商品，引发的高参与度：当奖品具有较高价值或独特性时，会吸引更多用户参与。就像一些热门的电子产品抽奖，可能会有成千上万甚至更多用户参与，也会带来高并发请求。

3 并发量

• 初期阶段（小规模运营或测试）：并发量可能在几百到上千，比如公司年会抽奖，参与人数可能在几百人，同时抽奖的情况较多。
• 中期阶段（有一定用户量和活动规模）：并发量可能在数千到数万，在一些大型促销活动中的抽奖环节，商城用户基数大，参与抽奖的人数众多。
• 大型成熟阶段（高流量、大规模运营）：并发量可达数万甚至更高，比如与网络平台合作的大型抽奖活动，会通过微博、抖音等进行导流宣发。

我建议大家按照并发量可能在数千到数万去说。

QPS和TPS

1. QPS（每秒查询率）和TPS（每秒事务处理量）概念解释

   • QPS主要衡量系统每秒能够处理的查询请求数量，这些请求可以是简单的读取操作，比如查询抽奖活动信息、用户积分等。TPS则侧重于衡量系统每秒能够处理的事务数量，事务通常涉及到写操作或者是包含多个操作的复杂业务逻辑，比如用户抽奖、签到打卡、积分更新等。

2. 数千到数万并发量对应的QPS和TPS范围估算

   • 初期估算（考虑到系统可能有一定的余量和波动）

     • 假设并发量在数千级别，以5000并发为例，如果用户的操作有70%是查询操作（QPS相关），30%是事务操作（TPS相关），并且这些操作在10秒内相对均匀分布。那么QPS大约在(5000 x 0.7/10 = 350)左右，TPS大约在 (5000x 0.3/10 = 150 )左右。

   • 中期正常情况（假设系统性能稳定，业务分布合理）

     • 当并发量达到10000时，若业务操作中查询操作占60%，事务操作占40%，并且这些操作在相对稳定的时间段内均匀分布，比如在20秒内。则QPS大约为 (10000 x 0.6/20 = 300 )，TPS大约为 (10000 x 0.4/20 = 200 )。

   • 高峰情况（如大型促销活动抽奖高峰）

     • 当并发量达到30000，考虑到抽奖活动中查询操作（查看抽奖信息、中奖名单等）可能占50%，事务操作（抽奖、打卡、积分更新等）占50%，并且集中在5秒内。此时QPS可能达到 (30000x 0.5/5 = 3000 )，TPS可能达到 (30000x 0.5/5 = 3000 )。
   • 综合考虑可能的范围
   • 一般情况下，QPS范围可能在几百到几千，大概在 (300 - 3000 )之间；TPS范围可能在一百多到几千，大概在 (150 - 3000 )之间。

4 应对高并发的方案

1. 架构层面

• 微服务与分布式架构：与市场主流抽奖项目一样，我们采用微服务架构，独立开发和部署用户服务、抽奖服务、晒单服务、签到服务、上传服务等。这种架构可以根据不同服务的负载情况进行灵活的资源分配和扩展。各服务间通过高效的 RPC 通信，如 gRPC 等，确保数据传输的低延迟和高可靠性，这在高并发场景下能有效避免服务间通信瓶颈。
• 容器化与集群化：基于阿里云提供的支持，利用 docker 和 k8s 技术实现容器化部署和集群管理。通过 k8s 的自动伸缩功能，可以根据并发量动态调整服务实例数量。例如，在并发请求高峰时自动增加抽奖服务的容器实例，以应对高负载。

2. 数据库优化方面

• 表结构优化与索引调整：除了之前对抽奖表结构的优化（将赞助商抽离，高内聚低耦合设计），还持续监控数据库查询情况，参考市场成熟抽奖项目的数据库优化经验，根据查询频率和数据量，对关键表的索引进行动态调整。例如，对于抽奖结果查询频繁的字段，添加索引，提高查询效率。
• 数据库连接池优化：配置合适的数据库连接池大小，避免连接过多导致数据库资源耗尽。在高并发情况下，根据负载动态调整连接池参数，确保数据库连接的高效利用。
• 数据库的主从分离

3. 缓存策略

• 多层缓存架构：除了在获取抽奖列表时的缓存预加载与超短过期时间策略，增加多层缓存。例如，在用户信息层面，设置本地缓存和分布式缓存（Redis 集群）。当用户频繁查询自己的抽奖资格、积分等信息时，先从本地缓存获取，若不存在再从分布式缓存获取，减少对数据库的直接访问。
• 缓存更新策略：在抽奖结果更新、用户积分变动等场景下，采用异步更新缓存的方式，避免缓存更新对高并发抽奖请求的影响。同时，设置合理的缓存过期和更新策略，保证数据的一致性。

4. 接口优化

• 接口限流与降级：引入令牌桶算法等限流机制，限制每个用户在单位时间内的请求次数，防止恶意刷接口或过度请求导致系统崩溃。同时，设置接口降级策略，当并发量过高导致某些非核心接口（如晒单服务接口）响应缓慢时，暂时关闭或简化这些接口的功能，优先保障抽奖和签到等核心接口的性能。
• 数据压缩与异步加载：在接口数据传输方面，对返回给用户的数据进行压缩，减少网络传输量。对于一些非关键数据（如抽奖活动的详细规则说明等），采用异步加载的方式，先返回核心抽奖信息，提高接口的响应速度。

5. 分布式事务处理

• 分布式事务框架优化：在使用消息队列解决通知服务的分布式事务问题和改造抽奖服务的分布式事务问题基础上，考虑引入成熟的分布式事务框架，如 Seata 等。这些框架可以提供更完善的分布式事务解决方案，保证在高并发场景下，抽奖、通知、积分更新等多个相关操作的事务一致性。
• 事务补偿机制：建立事务补偿机制，当分布式事务出现异常时，能够自动或手动触发补偿操作，确保数据的准确性。例如，在抽奖成功但通知失败的情况下，通过定时任务重新尝试通知。

6. 业务逻辑优化

• 开奖与打卡逻辑优化：在开奖逻辑中，继续优化策略模式。除了按时间和人数开奖，可增加更多灵活的开奖策略，如按用户活跃度、积分排名等。对于开奖任务的异步处理，优化 asynq 任务队列的配置，根据并发量动态调整任务执行的线程数和队列长度。在签到打卡逻辑方面，进一步细化任务类型和条件判断，采用缓存存储用户的打卡状态，减少每次打卡判断对数据库的查询。
• 积分管理优化：在积分管理方面，采用分布式缓存存储用户积分信息，实时更新缓存中的积分数据。当并发查询和更新积分时，通过分布式锁等机制保证数据的一致性。同时，对积分计算和更新的业务逻辑进行优化，减少复杂计算对系统性能的影响。

7. 监控与告警

• 性能监控系统：基于阿里云建立全面的性能监控系统，参考主流抽奖项目的监控方案，对系统的各个关键指标进行实时监控，包括接口响应时间、数据库查询性能、服务器资源利用率（CPU、内存、网络带宽等）、缓存命中率等。通过监控数据及时发现高并发下的性能瓶颈。
• 告警与自动优化：设置合理的告警阈值，当关键指标超出正常范围时，及时向运维和开发团队发送告警信息。同时，结合自动化脚本和智能算法，在一定范围内实现自动优化，如自动调整服务器资源、优化数据库查询语句等。

欢迎关注 ❤

我们搞了一个免费的面试真题共享群，互通有无，一起刷题进步。

没准能让你能刷到自己意向公司的最新面试题呢。

感兴趣的朋友们可以加我微信：wangzhongyang1993，备注：sf面试群。