大型网站中通常把系统分为三层：1.应用层，2.服务层，3.数据层。
位于应用层的服务器在面对高并发访问请求，通常用负载均衡进行解决。例如：将一组服务器组成集群对外提供服务。负载均衡设备通过心跳检测手段发现某台服务器不可用时就将其剔除服务器列表，并将请求分发到急群众其他可用的服务器上。而处于服务层的服务器与应用层类似。
位于数据层的服务器则比较特殊，因为数据就存储在上面，为了保证服务器宕机时数据不丢失、访问不中断，所以会在数据写入操作的时候进行数据同步复制，写入到多台服务器上，实现数据冗余备份。当数据服务器宕机，应用程序将访问切换到其他备用数据服务器上，保持整体服务的可用性。
对于以上三层的讲述中都是用意外发生时的应对方式，但有时候整个系统宕机时必然的，例如：网站系统升级，需要关闭服务器并重新部署系统，整个过程相当于服务器宕机。这种主动的服务器宕机，在现在的应对方式是采用灰度发布的手段，以免出现大规模的问题或灾难。
通过负载均衡进行无状态服务的失效转移。
应用层具有无状态性，在用户的每次请求中不包括业务上下文，多个服务器实例完全对等。无论请求打到哪个服务器处理的结果都是一样的。不保存状态给系统高可用带来巨大便利，因为多个服务器实例对等，当一台服务器宕机后请求可以发给其他服务器进行处理，对于终端用户而言请求总是能成功的。实现服务器状态实时监测、失效转移的方式为负载均衡。
负载均衡只在业务量和数量较高时，单台服务器不足以承担所有压力，可以通过负载均衡将流量和数据分摊到一个集群组成的多台服务器上，提高整体负载处理能力。
服务器session管理
网站无状态性是一种高可用的理想状态，通常业务总是有状态的，这时就会使用服务器端保存session会话：即多次请求修改使用的上下文对象。单机处理session时可以将session部署到web容器中进行管理。但是在分布式集群中，负载均衡服务器可能将请求分发到任何一台可用服务器上，如果想保证获得正确的session会话要比单机情况下困难的多。大致可以有如下集中处理方式进行session管理。
1.session复制
一种早起企业应用系统使用较多的服务器集群session管理机制。应用服务器开启web容器的session复制功能，session在各个服务器间同步session对象，每台服务器都保有所有用户session信息。优点时在服务器发生宕机时不会导致session数据丢失，而服务器使用session只要在本机获得。虽然方法简单、获取速度也很快，但是不能用在集群数量较多的情况下：服务器数量很多的时候，集群服务器之间的session复制要浪费大量的通信，占用服务器和网络的大量资源，系统负担大，并且在访问量很大时，每台服务器保存大量的session信息，可能会出现内存不够session使用的情况。大型网站并不适用。
2.session绑定
此方法可以通过利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将属于同一ip的请求分发到同一台服务器，这是负载均衡服务器必须在http协议层上工作，这样可以将同一ip打到固定的服务器，保证服务器获取，这种方法也被称作会话黏滞。
但是这种方案显然不符合高可用的特性，一旦一台服务器宕机，那么该机器的session信息就会丢失。
3.利用cookie记录session
早期企业通常使用的一种方法，将会话session记录在客户端，每次请求将session放在请求中发送给服务器，服务器处理完请求后将修改后的session响应给客户端。
这种方式的缺点：session大小收到cookie大小的限制，能记录的信息有限；每次请求响应都需要传输cookie，影响性能；当用户关闭cookie，访问会错误。但是cookie简单易用、可用性高、支持服务器线性伸缩，大部分应用的session信息又比较小，实际上许多网站或多或少的使用cookie进行session会话记录。
4.session服务器
通过session服务器可以做到：可用性高、伸缩性好、性能较优、信息大小没有限制等有点。利用独立部署session服务器（集群）统一管理session，应用每次读写session都访问session服务器，可以理解为共享一个服务器---session服务器。这种将服务器的状态分离的方式，分为无状态应用服务器和有状态的session服务器，对这两种服务器的不同特性需要分别设计架构。
在有状态的session服务器实现方式中：比较简单的方式是利用分布式缓存、数据库等，在这些产品的基础上进行包装，使其符合session的存储和访问要求。如果业务场景对session管理要求较高，比如利用session服务器集成单点登录（sso）、用户服务等功能，则需要开发专门的session服务平台。
高可用的服务
可以复用的服务模块为业务产品提供基础公共服务，大型网站的复用服务通常独立分布式部署，被具体应用远程调用。可复用的服务通常也是一种无状态服务，因此可以使用负载均衡的失效转移策略实现高可用的服务。具体实践还有几种高可用的服务策略。
1.服务分级管理。
运维上将服务器进行分级管理，核心应用和服务优先使用更好的硬件，响应速度也格纹迅速。例如：用户即使付款比能不能评价商品更重要，所以在整个系统中服务也是分层的。
在服务部署上也进行必要的隔离，避免故障的连锁反应。低优先级服务通过启动不同的线程或者不同的虚拟机进行隔离，而高优先级的服务器则需要部署在不同的物理机上，核心服务和数据甚至需要部署在不同的低于的数据中心。也就是说越高级的服务考虑的事情也就越多，甚至要考虑很多不可抗力发生后依然不正系统的高可用（海啸、地震之类）。
2.超时设置。
因为有时会发生服务器宕机、现成死锁等原因，导致应用对服务端的调用失去响应，导致用户访问长时间无响应，同时还占用资源，不利于访问请求及时转移到正常服务器上。这是会设置服务调用的超时时间，一旦超时，通信框架会抛出异常，应用程序根据服务调度策略，可以选择继续重试或将请求转移到提供相同服务的其他服务器上。
3.异步调用
有些应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求事变的情况。例如用户注册操作需要调用三个服务，将用户信息写入数据库、发送注册成功系统邮件、给用户开通对应权限。如果采用同步服务调用，邮件系统发生错误而无法开通对应权限，最终导致用户注册失败。但是采用异步的调用方式，应用程序将用户注册信息发送到消息队列后立即返回给用户注册成功的信息，而用户信息写入数据库、发送邮件、开通权限之间并不会因为邮件系统的错误而导致注册失败，只是用户收到注册邮件的时间稍晚一点。
但不是所有的服务都适用于异步调用的方式，对于获取用户信息等调用，若果采用异步方式调用会延长响应时间、得不偿失。对于那些必须确认服务调用成功才能进行下一步操作的服务也不可以使用异步的方式。只有服务之间没有先后关系、生产者消费者关系时才适合用异步调用的方式。
4.服务降级（保证核心功能的正常使用，在峰值时需要对服务进行降级）
当服务访问处于峰值时，可能因为大量的并发调用而性能下降，严重时服务器可能宕机。为了保证核心应用和功能的正常运行，需要对服务进行降级。降级有两种手段：拒绝服务和关闭服务。
拒绝服务：1.拒绝低优先级服务的调用，减少调用并发数，确保核心应用的正常使用；2.随机拒绝部分请求，解决资源让另一部分清酒得以成功，避免要死大家一起上的情况。对于随机拒绝服务：有些用户不可使用但是周围的人可以使用，自己重新请求就可以使用，这种用户体验会好一些，让用户产生可能时网络不好导致的错觉。
关闭服务：关闭部分不重要的服务，或者服务内关闭部分不重要的功能，从而节约系统开销，为重要的服务让出资源。
5.幂等性设计
应用调用服务失败，系统会调用请求重新发送到其他服务器，但是这个失败可能是一个虚假的失败，比如疑问网络延迟等原因，导致服务已经处理成功、但是系统没有收到响应，这是应用重新提交请求就会导致服务的重复调用。
服务的重复调用是无法避免的，应用层也不必考虑服务是否真的失败，只要没有得到响应，就可以认定为访问失败，并重试调用服务。因此在服务层就要确保服务：在一次调用和重复调用的结果相同，即服务具有幂等性。
有些服务具有天然的幂等性，比如用户性别的更改，不论设置多少次，男性依然为男性，年龄也可以做类似的设想，但是如果时转账的操作，那么问题就会复杂，需要通过交易编号等信息进行服务调用有效期校验，只有有效的操作才能继续执行。
大量内容来自于李智慧老师的《大型网站技术架构》，侵权请联系我删除。如果有不对的对方也欢迎大家之初，感谢大家。