作为后端研发工作中往往经常遇到一个关键词就是“高并发”。什么是高并发什么范围内的traffic可以被称为高并发。如果说建立这样的概念对于系统设计中线程竞争应对措施数据库选择与资源分配的 trade-off 会有明显的帮助。阶段1低并发100 QPS阶段2中并发1k-10k QPS开始出现内部竞争阶段3高并发10k-100k QPS竞争成为主要瓶颈阶段4超高并发100k QPS需要系统级重构竞争的资源包括CPU核心、内存、数据库连接、锁、网络带宽GenAI DB-connection simulation阶段1低并发100 QPS这个阶段一般Server没有什么性能瓶颈主要需要实现应用的关键功能的业务逻辑。阶段2中并发1k-10k QPS开始出现内部竞争在中等并发程度下需要开始考虑锁的设计是否需要数据库连接池实现复用数据库和服务器是否能支持负载扩容之后有哪些一致性的问题。例如 MySQL 单机数据库可负载500 TPS 和 10000 QPS需要考虑事务设计锁的设计来保证数据的准确。User A: READ(5) ----- WRITE(5-14)User B: READ(5) -------------------- WRITE(5-14)Final value: 4 ❌Expected: 3 ✓阶段3高并发10k-100k QPS竞争成为主要瓶颈在高并发情况下数据库锁有可能会成为性能瓶颈。设计案例库存抢购10万并发用户页面显示剩余库存量。在这个案例中写并发程度也很高单行数据并发写入的时候会导致数据库连接池 saturated如果使用的是乐观锁会因为CAS空转导致时延增加。常见解决方案1. 使用库存批次做 Redis 分片对库存数据进行切片提前 load 到 Redis 节点当节点中库存不够时再从数据库读取这样可以显著减少数据库的负载。如何同步数据库每一次扣减库存之后存入流水表最后汇总计算剩余库存。或者 Redis 定期快照异步批量更新数据库。设置 Reconcilation 任务定期比对库存。2. Redis 分布式锁Redis 命令处理层仍是单线程因此可以自然的形成锁。Redis 单个节点可以支撑 100,000 to 200,000 的QPS。3. MySQL 分库分表订单的数据表格可以根据用户ID切片order1, order2; order3采用多主多从的结构横向扩展写并发的负载根据原先的 assumption, 大概需要10台独立的mysql主机支撑10万QPS的并发。阶段4超高并发100k QPS需要系统级重构异步化引入消息队列Kafka 等将写请求削峰秒杀请求先入队异步落库无状态水平扩展应用层完全无状态配合负载均衡横向扩容最终一致性放弃强一致用补偿机制保证数据最终正确Performance 观测在应对上升的traffic的同时有哪些方法来判断可能出现性能瓶颈四大黄金指标Google 在《SREGoogle运维解密》中提出的分布式系统监控核心原则 。这四个指标是衡量系统健康状况的最佳实践Latency延迟响应请求的时间Traffic流量接收到的总请求数 QPS/RPS/TPSErrors错误请求失败的数量 (5xx, 4xx error rates)Saturation饱和度服务“满”的程度 a system or resource is being utilized or overloadedSaturation异常的表现CPU使用率持续高于80%缓冲池命中率低、大量磁盘I/OI/O等待时间长、写入堆积网络吞吐量接近带宽上限、连接延迟高连接数达到上限、线程创建延迟或内存耗尽。