从单机到集群，多台服务器如何协同支撑网站海量访问与登录？
网站支撑海量访问需从单机演进到集群架构，通过负载均衡器将海量请求分发至多台服务器协同处理，实现分流与高可用，针对多服务器登录问题，网站通常采用分布式Session管理，例如将用户会话数据统一存储在Redis等公共缓存中实现Session共享，或使用JWT令牌机制在客户端携带身份信息，此举可确保用户在任意节点登录后，跨服务器访问时身份状态均能被一致识别，保障无缝登录体验。
当一个网站刚刚建立时,通常只有一台服务器，这台服务器“包揽”了所有工作：存放网页文件、运行后端代码、存储数据库，甚至处理用户的文件上传，这就好比一家小卖部，老板一个人既负责进货、又负责收银、还要理货。
随着网站名气越来越大,访问量激增，单台服务器的CPU、内存或网络带宽很快就会达到极限，网站开始变得卡顿甚至崩溃，这时，就需要引入多台服务器来“分担压力”，一个网站究竟是怎么用多台服务器的呢？
网站从单机走向多台服务器,会经历以下几个关键的架构演进：
流量入口：DNS负载均衡
当用户在浏览器输入网址时,第一步是DNS解析，对于多台服务器的网站，最简单的利用方式就是在DNS服务器上为同一个域名配置多个IP地址。 当用户访问时，DNS服务器会根据轮询策略，把不同的用户分配到不同的服务器IP上，这就好比拨打客服电话，总机自动把你转接到空闲的分机，这种方式实现简单，但缺点是如果某台服务器宕机，DNS无法及时察觉，部分用户仍会被分配到死机节点。
交通指挥官：反向代理与负载均衡
为了更精准地控制流量,网站通常会在最前端部署一台“负载均衡服务器”（Load Balancer，如Nginx、HAProxy或云厂商的SLB）。 这台服务器拥有一个公网IP，是用户访问网站的唯一入口，它背后连接着多台真正处理业务的“Web应用服务器”，当请求到达时，负载均衡器会根据策略（如轮询、最少连接数、IP哈希等），将请求智能地分发给后端的某台Web服务器。 这样做的好处是：如果某台Web服务器宕机，负载均衡器会自动将其剔除；当流量更大时，只需在后面增加新的Web服务器即可，实现了“横向扩展”。
应用层解耦：无状态Web服务器
在使用多台Web服务器时,必须解决一个核心问题：用户状态，如果用户在服务器A上登录了，下一个请求被分配到了服务器B，B不认识这个用户怎么办？ 答案是让Web服务器变成“无状态”的，网站通常会把Session（会话数据）不再保存在本地服务器内存中，而是统一存放到一个公共的地方，比如Redis缓存数据库中，这样，无论用户的请求落到哪台Web服务器上，都能从Redis中读取到登录状态，实现多台服务器的无缝协作。
数据层分离：主从数据库与读写分离
Web服务器可以随便加,但数据库往往只有一个，数据库是网站最容易出现瓶颈的地方，为了利用多台服务器提升数据库能力，网站会采用“主从架构”与“读写分离”。
- 主库： 负责处理写操作（INSERT、UPDATE、DELETE）。
- 从库： 负责处理读操作（SELECT），主库在写入数据后，会实时将数据同步给从库。 因为绝大多数网站都是“读多写少”，通过增加多台从库服务器，就可以把大量的查询请求分散出去，极大减轻数据库压力。
静态资源剥离：CDN与独立文件服务器
如果网页中包含大量图片、视频、CSS或JS文件，每次请求都去Web服务器拉取，会极大消耗带宽和服务器资源。 网站会把这些静态资源剥离出来，存放到独立的文件服务器或对象存储（如阿里云OSS、AWS S3）中，更进一步，网站会使用CDN（内容分发网络），将这些静态资源缓存到全国各地的多台边缘节点服务器上，用户访问时，系统会自动从离用户最近的CDN服务器获取图片和视频，既快又节省了主服务器的带宽。
微服务架构：按业务拆分服务器
当网站业务极其复杂（如电商、社交平台）时，多台服务器的使用就不再仅仅是“复制”相同的代码，而是“分工”。 网站会被拆分成用户服务、订单服务、商品服务、支付服务等，每个服务都拥有自己独立的一组服务器集群，双十一”期间，支付服务压力巨大，网站只需要临时给支付服务增加几十台服务器，而不会影响到其他业务的正常运行，这就好比大医院里，内科、外科、骨科分在不同的楼层，每个楼层都有自己独立的医生团队和设备。
一个网站使用多台服务器,并不是简单地把代码复制几份，而是通过负载均衡分发流量、无状态应用实现横向扩展、数据库读写分离突破瓶颈、CDN卸载静态资源、微服务按业务拆分等一系列技术手段，将原本一台机器扛不下来的压力，科学、合理地分散到一个由多台服务器组成的“集群”中，这不仅解决了性能瓶颈，还保证了即使某台机器坏掉，网站依然能正常运转，这就是现代互联网高可用架构的核心奥秘。
