避坑 | 高并发系统设计要点

▌ 技术引导
高并发系统设计的难点在于如何在有限资源下实现稳定、高效和可扩展。我见过太多公司在初期操之过急，把所有流量直接怼到数据库，结果数据库死锁、CPU飙高、内存溢出，扛不住。核心问题在于负载均衡、缓存机制和数据库优化这三块没做好。比如在做限流时，不能只靠简单的令牌桶，得用滑动时间窗口，避免突发流量击穿。另外，异步处理是必须的，但很多人把消息队列当避风港，其实得结合业务场景判断是否需要重试、补偿机制，以及消息堆积的应对方案。真实项目中，我用过Redis做分布式锁，但碰到脑裂问题，必须配合etcd或者zookeeper做兜底。还有，别忽略线程池参数配置，比如corePoolSize和maxPoolSize，设置不对会影响整个系统的吞吐量。这些细节是实打实踩过坑后的经验，不玩虚的。

▌ 技术参考

一 限流策略选择与实现
限流是高并发系统的第一道防线，直接决定系统能否稳住。常用算法有令牌桶和滑动时间窗口，其中滑动时间窗口更精确，适合波动较大的流量。具体实现可借助Guava的RateLimiter，但要避免直接用它做全局限流。比如，在Spring Boot中配置RateLimiter时，必须加上@RefreshScope注解，否则配置变更无法生效。实际项目中，我会用Redis+Lua实现分布式限流，确保集群环境下限流统一。关键参数是每秒允许的请求数和滑动窗口大小，比如设置每秒5000请求，窗口10秒，能更细腻地控制流量。另外，别忘了设置降级策略，比如在限流时返回自定义错误码，而不是直接拒绝。

二 数据库读写分离与连接池优化
高并发系统必须拆分数据库读写，否则单点压力过大。主从复制是基础，但实际落地时要配合分库分表。例如，使用MyCat中间件做分库分表，配置分片规则时要根据业务特征调整，比如订单号按年分片，用户id按模分片。连接池参数是关键，比如最大连接数、最小空闲连接、等待超时时间，这些直接影响数据库性能。我见过项目用HikariCP时，把maximumPoolSize设成1000，结果MySQL连接数满了，线程阻塞严重。后来调整成根据业务峰值动态扩容，同时开启连接池的preparedStatementCacheSize，减少SQL编译时间。另外，别忘了在SQL中添加explain，分析查询计划，避免全表扫描。

三 异步处理与消息队列选型
异步处理是高并发系统中不可或缺的模块，但很多人只关注消息队列本身，忽略消息堆积和消费失败的问题。常见选型有Kafka、RabbitMQ和RocketMQ，其中Kafka适合高吞吐、低延迟场景，而RabbitMQ更适用于需要精确控制消息顺序的业务。在使用Kafka时，要注意分区策略和副本配置，比如设置replication.factor=3，确保数据可靠性。消息消费端必须有补偿机制，比如在Spring Boot中用@KafkaListener，每次消费失败后自动重试三次，如果还失败，写入死信队列。别忘了设置ackMode=manual，避免消息未处理就提交偏移量，导致数据丢失。实际项目中，我还会用Sleuth+Zipkin做链路追踪，方便排查消息处理异常。

四 缓存设计与淘汰策略
缓存是减轻数据库压力的核心手段，但很多人只关注缓存命中率，忽略缓存穿透、击穿和雪崩问题。Redis的淘汰策略有noeviction、allkeys-lru、volatile-lru等，其中volatile-lru适用于数据有生命周期的场景。我见过项目因为缓存未设置过期时间，导致内存爆掉，后来用TTL+随机删除策略优化。比如在Redis中配置maxmemory-policy=random，这样即使数据没过期，也会随机淘汰一部分。另外，缓存穿透可以用布隆过滤器解决，但得注意布隆过滤器本身的误判率，比如设置falsePositiveProbability=0.01，确保误判低。缓存击穿可以通过热点数据永不过期，或者使用互斥锁机制，比如用Redis的SETNX命令加锁，避免多个线程同时查询相同数据。

五 分布式锁实现与注意事项
分布式锁是协调多个节点操作的关键，常见实现有Redis、Zookeeper、etcd。我见过太多项目用Redis的SET命令做锁，结果因网络波动导致锁失效，引发数据不一致。后来改用Redlock算法，用多个Redis节点做锁，虽然实现复杂，但更可靠。配置时要注意锁的过期时间，比如设置ex=5s，线下业务处理时间必须小于这个值，否则会锁住其他节点。在Java中，可以用Redisson库做分布式锁，比如RLock lock = redisson.getLock("myLock"); lock.lock();，但要避免死锁，必须设置锁的超时时间。此外，别忽略锁的粒度控制，比如按业务ID加锁，而不是整个系统加锁，这样能提升并发性能。

六 负载均衡配置与健康检查
负载均衡是高并发系统的流量分发层，直接影响服务可用性。Nginx是常见选择，但必须配置健康检查，比如upstream模块中设置health_check，根据响应时间和成功率判断节点是否健康。实际项目中，我用过keepalive参数优化连接复用，比如keepalive=300，这样能减少TCP握手次数。另外，注意使用sticky session，确保同一用户请求始终落到同一节点，避免状态不一致。在配置时，要结合服务发现，比如用Consul或Eureka做动态注册，这样负载均衡器能自动感知节点状态。别忘了在Nginx中开启gzip压缩，减少传输带宽，提升吞吐量。

七 线程池参数调优与坑点规避
线程池是系统并发能力的基石，参数配置错误会直接导致性能瓶颈。比如在Java中使用ThreadPoolExecutor，必须根据CPU核心数和任务类型调整corePoolSize和maxPoolSize。我见过项目把corePoolSize设成1000，结果线程频繁创建销毁，CPU飙升。后来改为corePoolSize=50，maxPoolSize=200，配合keepAliveTime=60s，减少资源浪费。任务队列大小也很关键，比如queueCapacity=10000，避免直接抛出OOM。另外，拒绝策略不能随便选，比如使用CallerRunsPolicy，让线程池调用者线程处理任务，避免任务堆积。在Kubernetes中，可以配置horizontal pod autoscaler，根据CPU使用率自动扩容，但得注意最小副本数，防止频繁缩容。

八 数据库主从同步与一致性保障
数据库主从复制是高并发系统的常见做法，但同步延迟和一致性问题必须重视。比如在MySQL中配置binlog_format=row，确保主从数据一致。实际项目中，我见过主库写入后从库延迟达到10秒，导致查询结果不一致，后来优化了从库的配置，比如增大innodb_buffer_pool_size=8G，提升查询速度。另外，要结合canal或Debezium做数据同步，确保主从数据实时更新。对于强一致性要求的场景，比如金融交易，必须用分布式事务，比如Seata的AT模式，配置事务分组和TM服务器地址。但要注意事务性能损耗，比如事务提交时间比普通事务多300ms，需要权衡一致性与效率。

九 资源隔离与优先级调度
资源隔离是高并发系统中避免资源争抢的重要手段，比如CPU、内存、磁盘I/O。在Kubernetes中，可以配置ResourceQuota限制Pod的CPU和内存使用，比如resources.limits.memory=2Gi。我见过项目因为未做资源隔离，导致某些Pod占用了90%的CPU，其他服务直接崩溃。另外，使用Cgroups来限制容器资源，比如在Docker中设置--cpus=1.5，确保单个容器不会影响整体性能。在Linux系统中，可使用nice和ionice命令调整进程优先级，比如nice -n 10 java -jar app.jar，让Java应用处于较低优先级。不过，别滥用nice，否则会影响系统整体响应速度。

十 压力测试与性能监控
压力测试是验证高并发系统稳定性的关键步骤，必须结合实际业务场景模拟。比如用JMeter做压测时，配置Thread Group设置线程数为1000，循环次数为10000，同时添加CSV Data Set Config读取用户数据。我见过项目压测时CPU飙升到100%，但实际上线后没有问题，后来发现压测用的是单线程，而生产环境用的是多线程，导致结果偏差。监控工具必须用Prometheus+Grafana，配置MySQL的innodb_buffer_pool_read_requests和query_cache_misses指标，分析数据库性能瓶颈。另外，别忽略网络延迟监控，比如用tcpdump抓包，分析请求响应时间是否正常。

十一 分布式事务与最终一致性
分布式事务是高并发系统中复杂问题，必须根据业务场景选择方案。比如在微服务架构中，使用Seata的TC模式，配置transcationManager=seata，同时设置事务分组为default。实际项目中，我见过因为未配置事务回滚，导致库存超卖，后来改用补偿事务，比如在订单服务中存入临时状态，再通过定时任务去核对。不过，补偿事务会导致延迟，比如订单状态更新到MySQL，但库存扣减可能滞后10秒，需要在业务允许范围内权衡。此外，别忽略消息补偿，比如在Kafka消费失败时，用补偿队列重新消费，但要避免无限重试。

十二 服务降级与熔断机制
服务降级是高并发系统必备的容错手段，必须在代码层和配置层都做好。比如在Spring Cloud中使用Hystrix，配置hystrix.command.default.circuitBreaker.requestVolumeThreshold=10，这样当请求量超过阈值时，自动触发熔断。我见过项目因为未配置熔断，导致某个服务挂掉后，整个系统瘫痪。降级策略要分场景，比如支付服务失败时，直接返回缓存数据，而不是让系统等待。在配置文件中设置降级阈值和恢复时间，比如hystrix.command.default.fallbackEnabled=true，hystrix.command.default.circuitBreaker.sleepWindowInMs=30000。另外，别忘记用Spring Cloud Gateway做网关层降级，避免流量堆积。

十三 业务逻辑拆分与异步解耦
高并发系统必须拆分业务逻辑，避免单点阻塞。比如将订单创建和支付拆分为两个服务，用消息队列做异步解耦。在Kafka中，配置acks=all，确保消息被所有副本确认，避免消息丢失。我见过项目因为未拆分支付逻辑，导致创建订单时数据库锁等待超过10秒，严重影响用户体验。拆分后用Spring Cloud Stream做消息编排，配置binding.binders.kafka.configuration.bootstrapServers=xxx:9092，确保消息可靠投递。另外，注意消息顺序性，比如在RocketMQ中设置messageQueueSelector，确保同一订单的消息发到同一队列，避免数据错乱。

十四 容器化部署与资源管理
容器化部署是高并发系统的基础，但很多人忽略了资源分配和调度。比如在Kubernetes中，使用Horizontal Pod Autoscaler，根据CPU使用率自动扩展副本数，配置minReplicas=2，maxReplicas=10。我见过项目因为没有设置资源限制，导致某些Pod占用过多内存，其他服务直接OOM。可以用kubectl describe pod查看资源使用情况，调整requests和limits。另外，在Docker中设置--memory=2G，--cpus=2，确保容器不越界。别忘了用Liveness和Readiness探针检测服务健康状态，比如设置livenessProbe.httpGet.path=/health，intervalSeconds=10，确保Pod异常时能自动重启。

十五 日志审计与性能优化
日志系统是排查高并发问题的利器，但必须配置合理。比如在ELK中，使用Filebeat采集日志，配置output.elasticsearch.hosts=["xxx:9200"]，同时设置logstash的filter模块分析日志。我见过项目因为日志格式无序，导致无法快速定位问题，后来统一使用JSON格式，比如在Spring Boot中配置logging.pattern.level=%d{yyyy-MM-dd HH:mm:ss} [%thread] %level %logger{36} - %msg%n。性能优化方面，要关注JVM调优，比如设置Xms=4G，Xmx=4G，避免频繁GC。另外，使用JProfiler或Arthas分析线程阻塞，比如发现某个方法耗时超过500ms，就进行拆分或异步处理。别忽略JVM内存模型，比如老年代GC频繁，说明需要调整堆大小或对象生命周期。

十六 网络优化与负载均衡策略
网络是高并发系统中最易被忽视的部分，必须关注延迟和带宽。比如在Nginx中配置proxy_read_timeout=60s，避免连接超时。我见过项目因未设置keepalive，导致每次请求都要重新建立TCP连接，吞吐量下降一半。使用TCP keepalive优化，比如在Linux中配置net.ipv4.tcp_keepalive_time=600，确保连接空闲时自动维持。另外，负载均衡算法要根据业务选择，比如轮询适合无状态服务，而最少连接适合有状态服务。在Kubernetes中，配置Service的type=LoadBalancer，同时使用Envoy作为sidecar进行更精细化的流量控制。注意避免DNS污染，比如使用IP直连而非域名，减少解析时间。

十七 服务治理与调用链追踪
服务治理是高并发系统中提升可用性的关键，必须用注册中心和配置中心做统一管理。比如在Consul中配置健康检查，设置check.timeout=5s，check.interval=10s，确保服务健康状态及时更新。调用链追踪是必选项，比如使用Sleuth+Zipkin，配置spring.zipkin.base-url=http://zipkin:9411，确保请求链路可视化。我见过项目未做链路追踪，导致调用异常无法快速定位。在调用链中，必须记录关键节点耗时，比如RPC、数据库、缓存，这样能发现瓶颈。另外，服务发现要配合健康检查，使用Consul的service health命令查看节点状态，及时剔除故障节点。

十八 高可用架构与故障转移
高可用架构是高并发系统的底线，必须用主从、集群和自动故障转移。比如在Redis中配置哨兵模式，设置sentinel monitor mymaster 127.0.0.1 6379 2，这样在主节点故障时能自动切换。我见过项目未配置故障转移，导致主库宕机后，从库无法接管，请求全部失败。在MySQL中使用MySQL Router做读写分离，配置read_only=1，确保只读流量走从库。另外，应用层要做重试逻辑，比如在Feign Client中配置feign.client.config.default.connectTimeout=5000，feign.client.config.default.readTimeout=10000，同时添加重试策略，比如retryable=true。别忽略断路器机制，避免雪崩效应。

十九 系统监控与告警配置
监控是高并发系统中的“眼睛”，必须覆盖CPU、内存、磁盘、网络和业务指标。比如在Prometheus中采集Node Exporter的指标，配置CPU使用率的阈值为80%，触发告警。我见过项目因为未配置告警，导致CPU飙高到100%，系统直接崩溃。使用Alertmanager设置告警规则，比如当CPU使用率超过阈值时，发送邮件和Slack通知。另外，监控数据库性能，比如MySQL的innodb_buffer_pool_reads和queries_per_second，发现异常时及时扩容。别忘了在Kubernetes中配置kubectl top node，监控节点资源使用，避免某个节点过载。

二十 持续集成与性能测试
高并发系统必须有持续集成和自动化性能测试，确保每次变更不会引入新问题。比如在Jenkins中配置性能测试任务，使用JMeter生成压测报告，保存结果到Prometheus。我见过项目因为未做自动化测试，上线后因缓存未更新导致数据错误。在测试中，要模拟真实流量，比如使用JMeter的CSV数据文件，设置线程数为5000，循环次数为1000。另外，使用CI/CD流水线进行灰度发布，比如在Kubernetes中配置RollingUpdate策略，maxSurge=1，maxUnavailable=0，确保新版本上线不中断服务。别忘记在测试环境中模拟高并发场景，比如使用Locust工具，设置spawn_rate=1000，执行10分钟，验证系统稳定性。