大型网站技术架构：核心原理与案例分析——高可用

快来打我* 2022-12-13 11:25 148阅读 0赞

![在这里插入图片描述][20201011105216130.png_pic_center]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center]

# 高可用的应用 #

应用层的显著特点是无状态性，所谓无状态的应用是指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等，请求提交到任意服务器，处理结果都是完全一样的。

## 通过负载均衡进行无状态服务的失效转移 ##

## 应用服务器集群的Session管理 ##

业务总是有状态的，在交易类的电子商务网站，需要有购物车记录用户的购买信息，用户买次购买请求都是向购物车中添加商品等。Web应用中将这些多次请求修改使用的上下文对象称为会话Session，单机情况下，Session可由部署在服务器上的Web容器（如JBoss）管理。在使用负载均衡的集群环境中，由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上，所以保证每次请求依然能获得正确的Session比单机时要复杂很多。集群环境下，Session管理主要的手段：Session复制、Session绑定、l利用Cookie记录Session、Session服务器

### Session复制 ###

Session复制是早期企业应用系统使用较多的一种服务器集群Session管理机制。应用服务器开启Web容器的Session复制功能，在集群中的几台服务器之间同步Session对象，使得每台服务器上都保存所有用户的Session信息，这样任何一台机器宕机都不会导致Session数据的丢失，而服务器使用Session时，也只需在本机获取。这种方案虽然简单，从本机读取Session信息也很快速，但只能使用在集群规模比较小的情况下。当集群规模较大时，集群服务器间需要大量的通信进行Session复制，占用服务器和网络的大量资源，系统不堪负担。而且由于所有用户的Sessioin信息在每台服务器上都要备份，在大量用户访问的情况下，甚至会出现服务器内存不够Session使用的情况。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 1]

### Session绑定 ###

Session绑定可以利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上（也可以根据Cookie信息将同一用户的请求总是分发到同一台服务器上，当然这时负载均衡服务器必须工作在HTTP协议层上）。这样在整个会话期间，用户所有的请求都在同一台服务器上处理，即Session绑定在某台特定的服务器上，保证Session总能在这台服务器上获取。这种方法又称为会话粘滞。但是Session绑定的的方案显然不符合系统高可用的需求，因为一旦某个服务器宕机，那么该机器上的Session也就不复存在了，用户请求切换到其他机器后因为没有Session而无法完成业务处理。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 2]

### 利用Cookie记录Session ###

早期企业应用系统使用C/S架构，一种管理Session的方式是将Session记录在客户端，每次请求服务器的时候，将Sessoin放在请求中发送给服务器，服务器处理完请求后再将修改过的Session响应给客户端。网站没有客户端，但可以用浏览器支持的Cookie记录Session。利用Cookie记录Session也有一些缺点，比如受Cookie大小限制，能记录的信息有限；每次请求响应都需要传输Cookie，影响性能；如果用户关闭Cookie，访问就会不正常。事实上，许多网站都或多或少地使用Cookie记录Session。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 3]

### Session服务器 ###

利用独立部署的Sesion集群同意管理Session，应用服务器每次读写Session时，都访问Session服务器。对于有状态的Session服务器，一种简单的方法是**利用分布式缓存、数据库等，在这些产品的基础上进行包装**，使其符合Session的存储和访问要求。如果业务场景对Session管理有比较高的要求，比如利用Session服务集成单点登录(SSO)、用户服务等功能，则需要**开发专门的Session服务管理平台**。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 4]

# 高可用的服务 #

可复用的服务也是无状态服务，有以下几点高可用服务策略：分级管理、超时设置、异步调用、服务降级、幂等性设计。  
运维上将服务器进行分级管理，核心应用和服务优先使用更好的硬件，在运维响应速度上更加迅速。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离，高优先级的服务则需要部署在不同的物理机上，核心服务和数据甚至需要部署在不同地域的数据中心。在应用程序中设置服务调用的超时时间，一旦超过，通信框架就抛出异常，应用程序根据服务调度策略，可以选择继续重试或将请求转移到提供相同服务的其他服务器上。应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。服务层保证服务重复调用和调用一次产生的结果相同（幂等性）。

# 高可用的数据 #

![在这里插入图片描述][20201011154307123.png_pic_center]

## CAP原理 ##

一个提供数据服务的存储系统无法同时满足数据一致性Consistency、数据可用性Availibity、分区耐受性Partition Tolerance（系统具有网络分区的伸缩性）。

## 数据备份 ##

数据冷备：定期将数据复制到某种存储介质上并物理存档保管  
数据热备：异步热备和同步热备。异步方式是指多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写操作成功响应时，只写成功了一份，存储系统将会异步地写其他副本。同步方式是指多份数据副本的写入操作同步完成，即应用程序收到数据服务系统的写成功响应时，多份数据都以写操作成功。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 5]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 6]

## 失效转移 ##

失效转移操作分为三个部分：失效确认、访问转移、数据恢复。系统确认一台服务器是否宕机的手段有两种：心跳检测和应用程序访问失败报告。对于应用程序的访问失败报告，控制中心还需要再次发送心跳检测进行确认，以免错误判断服务器宕机，因为一旦进行数据访问的失效转移，就意味着数据存储多份副本不一致，需要进行后续一系列复杂的操作。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 7]  
确认某台数据存储服务器宕机后，就需要将数据读写访问重新路由到其他服务器上。对于完全对等存储的服务器，当其中一台宕机后，应用程序根据配置直接切换到对等服务器上。如果存储不是对等的，那么就需要重计算路由，选择存储服务器。因为某台服务器宕机，所以数据存储的副本数目会减少，必须将副本的数目恢复到系统设定的值，否则，再有服务器宕机，就可能出现无法访问转移（所有副本的服务器都宕机），数据永久丢失的情况。

[20201011105216130.png_pic_center]: /images/20221123/d9a4923d25924ec08a6d04c83f33de02.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/2fd6558f6a2a415d87cf8f0e0b5cdedf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/5e3dfa8e0ae44d7ab854d025e552fce2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/ce39d083d7da4d59ab1c96fc97240496.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/937e9d9796064b2695032d4997aeb98a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/86c537acd42642c39b40fd7ad9bf66e1.png
[20201011154307123.png_pic_center]: /images/20221123/2755cd95fa0947ccb8c1f5045c1d3457.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/bfb84963c7e640c3800287265bef23cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221123/1bdff8b4b3f2486791960e44e7a85354.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221123/71f292352ae84e429663a4768c4d1c44.png