产品中心
高并发系统的设计算是一个很热门的话题。面试也问，工作中也时不时会遇到。可是到底要如何设计，从哪里抓起，思路是什么？这篇文章做一个简单的梳理。
问题的关键是找到关键的问题，哈哈
高并发要解决的问题场景是什么？
高并发解决的是瞬时的大量请求场景，例如秒杀、热点直播等等。现在的互联网场景基本都要考虑一点这个场景，除非说你的产品请求量比较小。
高并发是从业务视角对系统处理能力的描述，其核心目标是在单位时间内支撑大量同时发生的请求。实现高并发可借助多种技术手段，包括分布式架构、缓存机制，也涵盖多线程、协程等并发编程方式。本质上，高并发的关键在于对有限资源的高效利用，以有限的系统资源应对海量请求的挑战。
我的思路是从外到内，随着请求的流向进行思考和优化。
请求首先进入的就是我们的应用层，也是我们平常代码改动最频繁的地方，个人操作空间也是比较大。
异步处理与协程
在go语言中，异步与协程是相辅相成的。一般来讲，不重要的操作能异步处理的尽量异步处理，例如日志上报、埋点上报、发消息等等，一定程度上可以提升吞吐量。
预热
通过预热，让系统先热起来，为高并发流量做好准备。
一般预热有DB预热、缓存预热等等。还有一种方式是通过定时任务将一些数据定时拉到本地缓存起来，这样就不用刻意去管理缓存，系统复杂度会下降不少，响应速度上也能得到提高。
客户端层面其实也能进行预加载，例如抖音一次都是拉取10-20个视频地址，我们在看当前视频的时候，他已经悄咪咪的预加载后面几个视频流了，所以我们滑动起来感到特别顺畅，就是这个原因。
系统架构层面上设计是很关键的，设计的不合理，就很难抗住高并发的流量。
服务端架构层
服务端架构设计是应对高并发场景的核心，我们需要从多个维度构建可扩展、高可用的技术体系。
是时候表演真正的技术了。
架构分层与业务分割
横向分层：将系统划分为应用层、服务层、数据层等，每层职责单一，通过层次间协作构建完整系统。应用层处理页面与用户交互，服务层封装核心业务，数据层负责存储与查询。
纵向分割：按业务域拆分为独立模块，如用户、订单、商品等，实现高内聚低耦合，支持分布式部署与独立扩展。
应用与数据集群
应用集群：通过 Nginx、SLB 等负载均衡技术，将流量分发至多台应用服务器，避免单点故障，提升系统吞吐能力。
数据集群：数据库采用主从架构，实现读写分离与数据冗余，既分担请求压力，又保障数据安全与可用性。
数据层扩展策略
读写分离：主库处理写请求，多个从库承担读查询，适用于读多写少的典型互联网场景。
分库分表：当单库性能或容量达到瓶颈时，对数据做水平或垂直拆分，提升系统整体TPS与存储能力。
冷热分离：将活跃热数据与归档冷数据分开存储，优化资源使用与访问性能。
缓存抗量与多级设计
引入 Redis、Memcached 等分布式缓存，减轻数据库直接压力，并需关注数据一致性问题, 这里会增加一点复杂度，缓存管理的不好容易出问题。
构建“本地缓存 + 分布式缓存”多级体系，本地缓存应对极端热点数据，进一步提升响应速度与系统韧性。
异步化与削峰机制
使用 Kafka 等消息队列，将同步请求转为异步消费，平滑流量峰值，增强系统对突发流量的处理能力。秒杀系统经常这么干。
业务隔离与容灾
通过 SET 化部署实现业务单元隔离，按业务重要性或用户维度划分独立集群，防止局部故障扩散，保障核心业务链路的稳定性。
基础设施一般是指服务器部署方式。
可以采取的方式一般有：
多地部署。这样一方面发生极端情况时还有其他机器可用（想想有一年阿里云新加坡一个机房着火了，我们服务全部都在这个可用区内，整整几天都没有办法提供服务...），另一方面，可以利用就近接入提升响应速度。
本文总结了一些设计高并发系统的思路，其实秒杀系统的一些设计范式也可以拿过来直接复用，道理都是一样的。
以下是AI写的总结，ai写的就是好
面对高并发挑战，服务端架构设计需要在扩展性、性能与可用性之间取得平衡。核心思路可归结为“分、抗、兜、隔”四大策略：
“分”是基础：通过横向分层（如应用、服务、数据层）与纵向业务分割，将系统拆分为职责单一、可独立扩展的模块，为分布式部署奠定基础。
“抗”是关键：在数据库前引入多级缓存（本地+分布式）以抵御读流量洪峰；通过消息队列异步化处理，削峰填谷，平滑突发写请求。
“兜”是保障：任何单点都是潜在风险。应用与数据均需集群化部署，配合负载均衡与主从复制，实现高可用与故障自动转移。
“隔”是韧性：采用SET化等资源隔离方案，按业务或用户维度划分独立部署单元，避免局部故障引发系统雪崩，保障核心链路稳定。
