从0到1：揭秘千万级并发系统架构设计

无论是电商平台的 “双 11”“618” 大促，还是 12306 的春运抢票时刻，抑或是在线直播的高峰时段，都对系统的并发处理能力提出了极高的要求。当每秒数以千万计的请求如潮水般涌来时，系统架构的设计就显得尤为关键，它直接决定了系统能否稳定、高效地运行，为用户提供良好的体验。若架构设计不合理，系统可能会陷入卡顿、崩溃的困境，导致用户流失、业务受损。

关键指标知多少 （一）QPS、TPS、并发数与响应时间

在开始设计千万级并发系统架构之前，我们首先需要明确一些关键的性能指标，它们是衡量系统性能的重要依据，就如同航海中的灯塔，指引着我们的架构设计方向。

QPS（Queries Per Second）即每秒查询数 ，它反映了系统每秒能够处理的查询请求数量。以搜索引擎为例，QPS 就是衡量其每秒能够响应用户搜索查询的次数。对于电商系统来说，QPS 则体现了系统每秒处理商品查询、订单查询等请求的能力。TPS（Transactions Per Second）即每秒事务数，一个事务通常是指一个客户机向服务器发送请求，然后服务器做出反应的完整过程。比如在电商系统中，用户下单购买商品这个操作，从用户点击下单按钮，到系统完成库存扣减、订单记录等一系列操作，就可以视为一个事务，TPS 则表示系统每秒能够处理这样完整事务的数量。

并发数是指系统可以同时承载的正常使用系统功能的用户数量。在一个在线游戏中，并发数就是同时在线玩游戏的玩家数量；对于电商平台，并发数则是同一时刻正在浏览商品、下单、支付等操作的用户数。响应时间是指系统对请求作出响应的时间，从用户角度来看，就是用户发出请求后，等待系统返回结果所花费的时间。在移动应用中，用户点击一个按钮，到界面刷新显示出相应结果的时间间隔，就是响应时间。

这些指标相互关联又相互制约。一般来说，QPS 和 TPS 越高，说明系统的处理能力越强；并发数越大，对系统的资源消耗也就越大；而响应时间越短，用户体验就越好。但在实际系统中，很难同时做到高 QPS、高并发数和短响应时间，需要我们在架构设计中进行权衡和优化。

（二）用 2/8 法则预估流量

在设计千万级并发系统时，准确预估流量是至关重要的一步。这里我们可以采用经典的 2/8 法则（也称为帕累托法则）来进行流量预估。

假设我们要设计一个千万级用户的电商网站，根据 2/8 法则，我们可以大致认为每天有 20% 的用户会活跃访问网站。那么每日活跃用户数大约为 1000 万 ×20% = 200 万。通常每个用户在一次访问中会进行多次操作，假设平均每个用户每次访问有 30 次点击操作（包括浏览商品、查看详情、加入购物车等），那么每日的总点击量（PV，Page View）大约为 200 万 ×30 = 6000 万。

一天有 24 小时，根据 2/8 法则，大部分用户的活跃时间集中在 20% 的时间段内，即 24×20% = 4.8 小时，我们近似认为是 5 小时。而在这 5 小时内，又会有 80% 的点击量集中出现，即 6000 万 ×80% = 4800 万点击量。那么在这 5 小时的活跃访问期内，平均每秒的请求量大约为 4800 万 ÷（5×3600）≈2667 次。

但在实际情况中，这 5 小时内还会出现高峰时段，比如在促销活动开始的半小时内，用户请求量会急剧增加。根据线上经验，高峰访问量通常是平均访问量的 2 - 3 倍，我们假设按照 3 倍来计算，那么在高峰时段，每秒的请求量可能会达到 2667×3 ≈ 8000 次。通过这样的预估，我们对系统可能面临的流量有了一个较为清晰的认识，为后续的架构设计提供了重要的数据支持。

架构设计步骤 （一）从单体到高可用架构

在网站发展的初期，由于业务量较小，用户访问量相对较低，通常采用单体架构。单体架构就像一座功能齐全的独栋别墅，将所有的业务功能都集成在一个应用程序中，应用服务器和数据库紧密结合在一起。这种架构的优点显而易见，开发和部署都非常简单，就像建造独栋别墅，所有的设计和施工都相对容易把控。

然而，随着业务的逐渐发展，用户量不断增加，单体架构的弊端也逐渐显现出来。它就像一个不堪重负的巨人，开始出现各种问题。应用服务器和数据库成为了单点故障，如果应用服务器出现故障，整个网站将无法访问；如果数据库出现故障，数据的存储和读取将受到影响，业务也会陷入停滞。就好比别墅的主要支撑结构出现问题，整个建筑就会面临倒塌的危险。

为了解决这些问题，我们引入了初步的高可用架构。首先，将应用服务器进行集群化部署，就像建造了多栋相同的别墅，形成一个别墅群。通过负载均衡器，将用户的请求均匀地分发到集群中的各个应用服务器上，这样不仅可以提高系统的处理能力，还能实现应用服务器的冗余备份。当某一台应用服务器出现故障时，负载均衡器会自动将请求转发到其他正常的服务器上，确保服务的连续性。

同时，对数据库采用主从架构，主数据库负责数据的写入操作，从数据库则实时同步主数据库的数据，并负责数据的读取操作。这样，即使主数据库出现故障，从数据库也可以继续提供数据读取服务，保证系统的部分功能正常运行。通过这些措施，系统的可用性得到了显著提高，就像别墅群和备用支撑结构的结合，大大增强了系统的稳定性和可靠性。

（二）业务垂直拆分

随着业务的持续增长，研发团队也在不断扩大。此时，单块系统就像一个庞大而复杂的迷宫，开发和维护的难度越来越大。不同业务模块之间的代码耦合度高，牵一发而动全身，一个小小的改动可能会引发一系列意想不到的问题。就像在迷宫中改变一条路径，可能会导致整个迷宫的通行规则发生变化，让人迷失方向。

为了提高开发效率，降低系统的复杂度，我们需要对业务进行垂直拆分。这就好比将一个大型商场按照不同的商品类别划分成多个独立的小店铺，每个小店铺专注于经营一类商品。将单块系统拆分为多个业务系统，每个业务系统专注于一个特定的业务领域，例如电商系统可以拆分为用户系统、商品系统、订单系统、支付系统等。每个小团队负责一个业务系统的开发、维护和升级，他们可以独立地进行技术选型、架构设计和功能迭代，就像每个小店铺可以自主决定商品的进货、陈列和销售策略一样。

这样的垂直拆分使得业务逻辑更加清晰，团队之间的职责分工更加明确，大大提高了开发效率和系统的可维护性。同时，不同业务系统之间通过接口进行通信，实现了业务的解耦，就像不同店铺之间通过商场的通道进行货物运输和信息交流一样，相互协作又互不干扰。

（三）分布式缓存抗读压

在高并发的场景下，数据库就像一个繁忙的交通枢纽，承受着巨大的压力。大量的读请求如潮水般涌来，数据库的处理能力很容易达到瓶颈，导致响应时间变长，系统性能下降。就像交通枢纽在高峰期时，车辆拥堵，通行速度变慢。

为了缓解数据库的压力，我们引入了分布式缓存，如 Redis 集群。分布式缓存就像一个高效的临时仓库，它遵循 2/8 法则，将经常被访问的数据（大约 80% 的读请求所涉及的数据）存储在内存中，当用户发起读请求时，首先从缓存中获取数据。如果缓存中存在所需数据，就可以直接返回给用户，大大减少了对数据库的访问次数。据统计，在一些高并发的电商系统中，引入分布式缓存后，数据库的读压力可以降低 80% 以上，系统的响应时间也可以缩短数倍。

Redis 集群通过将数据分片存储在多个节点上，实现了数据的分布式存储和高可用性。它支持多种数据结构，如字符串、哈希表、列表、集合等，可以满足不同业务场景的需求。例如，在电商系统中，可以将商品信息、用户信息、订单信息等常用数据存储在 Redis 缓存中，提高数据的读取速度。通过分布式缓存的引入，系统的读性能得到了极大的提升，就像在交通枢纽旁边建立了多个临时停车场，减轻了交通枢纽的压力，提高了交通的流畅性。

（四）数据库主从架构与读写分离

在高并发系统中，数据库的性能优化至关重要。除了引入分布式缓存，数据库主从架构与读写分离也是提升数据库性能的重要手段。

数据库主从架构就像一个主从协作的团队，主数据库负责处理写操作，如数据的插入、更新和删除。从数据库则通过复制主数据库的二进制日志，实时同步主数据库的数据，并负责处理读操作，如数据的查询。这样的分工可以将读写操作分离，避免读写冲突，提高数据库的并发处理能力。

以电商系统为例，当用户下单购买商品时，写操作（如订单信息的插入、库存的扣减等）会被发送到主数据库进行处理。主数据库完成写操作后，会将相应的二进制日志记录下来，从数据库通过 I/O 线程监听主数据库的二进制日志更新，一旦发现有新的日志记录，就会将其拷贝到自己的中继日志中，然后通过 SQL 线程从中继日志中读取事件，并在自己的数据库中重放这些事件，从而实现数据的同步。

当用户查询订单信息或商品信息时，读操作会被路由到从数据库。由于从数据库可以有多个，通过负载均衡器可以将读请求均匀地分发到各个从数据库上，这样不仅可以提高读操作的效率，还能减轻主数据库的压力。据测试，在一个具有一主三从架构的数据库系统中，读操作的性能相比单数据库可以提升 3 - 5 倍，大大提高了系统的整体性能。

（五）其他优化策略

除了上述的架构设计和优化措施，还有一些其他的优化策略可以进一步提升系统的性能。

在磁盘数据访问方面，页缓存是一种重要的优化技术。操作系统会将磁盘中的数据以页为单位缓存到内存中，当应用程序需要读取数据时，首先会在页缓存中查找，如果命中，则可以直接从内存中读取，避免了磁盘 I/O 操作，大大提高了数据读取的速度。例如，在一个文件存储系统中，通过页缓存技术，数据的读取速度可以提高数倍。

顺序读写也是一种优化策略，相比于随机读写，顺序读写可以减少磁盘寻道时间，提高 I/O 性能。在设计数据库表结构和存储方式时，应尽量保证数据的存储和读取是顺序的。此外，使用 SSD（固态硬盘）代替传统的机械硬盘也是提升磁盘性能的有效方法，SSD 具有更快的读写速度和更低的延迟，能够显著提高系统的 I/O 性能。

在内存优化方面，内存缓存是常用的手段。将热点数据存储在内存中，可以减少对磁盘和数据库的访问，提高系统的响应速度。池化技术也是一种重要的内存优化策略，如数据库连接池、线程池等。通过池化技术，可以预先创建一定数量的资源对象，并将其缓存起来，当应用程序需要使用这些资源时，可以直接从池中获取，而不需要重新创建，这样可以减少资源的创建和销毁开销，提高系统的性能和资源利用率。

案例分析

以淘宝为例，在其发展历程中，经历了多次架构演进以应对不断增长的并发需求。早期淘宝采用单体架构，随着用户量和业务量的迅速攀升，单体架构的局限性逐渐凸显。为了提升系统的可用性和性能，淘宝引入了负载均衡和应用服务器集群，实现了初步的高可用架构。

随着业务的进一步拓展，淘宝对业务进行了垂直拆分，将系统拆分为多个独立的业务模块，如商品、订单、用户等，每个模块都有独立的数据库和服务，提高了系统的可维护性和扩展性。为了应对高并发场景下的读压力，淘宝大规模使用分布式缓存，如 Redis 集群，将大量的热点数据存储在缓存中，极大地减轻了数据库的读压力。

在数据库方面，淘宝采用了主从架构和读写分离技术，通过多个从数据库来分担读请求，同时对写操作进行优化，保证了数据的一致性和系统的高性能。此外，淘宝还在磁盘数据访问、内存优化等方面进行了大量的技术创新和优化，如使用 SSD 硬盘提高 I/O 性能，采用内存缓存和池化技术减少资源开销。

通过这一系列的架构设计和优化，淘宝成功地应对了每年 “双 11” 等大促活动带来的千万级并发挑战。在 “双 11” 当天，系统能够稳定地处理海量的用户请求，实现高效的商品展示、下单、支付等操作，为用户提供了流畅的购物体验，也为电商行业的高并发系统架构设计提供了宝贵的经验和借鉴。