共计 5250 个字符，预计需要花费 14 分钟才能阅读完成。
零碎的可用性（Availability）是形容利用零碎可无效拜访的个性。
根本策略
咱们都晓得，硬件故障是常态，网站的高可用架构设计的次要目标就是保障服务器硬件故障时服务仍然可用、数据仍然保留并可能被拜访。
实现上述 高可用架构的次要伎俩是数据和服务的冗余备份及生效转移，一旦某些服务器宕机，就将服务切换到其余可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。
一个典型的网站设计通常遵循应用层、服务层、数据层的根本分层架构模型。各层之间具备绝对独立性，应用层次要负责具体业务逻辑解决；服务层负责提供可复用的服务；数据层负责数据的存储与拜访。
在应用层，能够通过负载平衡设施将一组服务器组成一个集群独特对外提供服务，当负载平衡设施通过心跳检测等伎俩监控到某台服务器不可用时，就将其从集群列表中剔除，并将申请散发到集群中其余可用的服务器上，使整个集群放弃可用，从而实现利用高可用。
服务层的状况和应用层相似，也是通过集群形式实现高可用，只是 这些服务器被应用层通过分布式服务调用框架拜访，分布式服务调用框架会在应用层客户端程序中实现软件负载平衡，并通过服务注册核心对提供服务的服务器进行心跳检测，发现有服务不可用，立刻告诉客户端程序批改服务拜访列表，剔除不可用的服务器。
位于数据层的服务器状况比拟非凡，为了保障服务器宕机时数据不失落，数据拜访服务不中断，须要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。当数据服务器宕机时，应用程序将拜访切换到有备份数据的服务器上。
高可用应用层
应用层次要解决网站利用的业务逻辑，因而有时也称作业务逻辑层，用户的申请都是由这层来解决，而大多数状况下申请都是无状态的。
通过负载平衡进行生效转移
负载平衡，顾名思义，次要应用在业务量和数据量较高的状况下，当单台服务器不足以承当所有的负载压力时，通过负载平衡伎俩，将流量和数据摊派到一个集群组成的多台服务器上，以进步整体的负载解决能力。
当服务器集群中的服务器都可用时，负载平衡服务器会把用户的申请散发到任意一台服务器上进行解决，而当某台服务器宕机时，负载平衡服务器通过心跳检测机制发现该服务器失去响应，就会把它从服务器列表中删除，而将申请发送到其余服务器上，申请在任何一台服务器中解决都不会影响最终的后果。
集群的 Session 治理
不过事实上，业务总是有状态的，例如在交易类的电子商务网站，须要有购物车记录用户的购买信息。在应用负载平衡的集群环境中，因为负载平衡服务器可能会将申请散发到集群任何一台应用服务器上，所以保障每次申请仍然可能取得正确的 Session 比单机时要简单很多。
集群环境下，Session 治理次要有以下几种伎俩。
Session 复制
Session 复制是晚期利用零碎应用较多的一种服务器集群 Session 管理机制。它的原理是在集群中的服务器之间同步 Session 对象，使得每台服务器上都保留所有用户的 Session 信息，而服务器应用 Session 时，只须要在本机获取即可。
这种计划尽管简略，从本机读取 Session 信息也很疾速，但只能应用在集群规模比拟小的状况下。当集群规模较大时，集群服务器间须要大量的通信进行 Session 复制，占用服务器和网络的大量资源，零碎不堪负担。
Session 绑定
Session 绑定能够利用负载平衡的源地址 Hash 算法实现，负载平衡服务器总是将来源于同一 IP 的申请散发到同一台服务器上。这样在整个会话期间，用户所有的申请都在同一台服务器上解决，保障 Session 总能在这台服务器上获取。
然而 Session 绑定的计划显然不合乎咱们对系统高可用的需要，因为 一旦某台服务器宕机，那么该机器上的 Session 也就不复存在了，用户申请切换到其余机器后因为没有 Session 而无奈实现业务解决。
Session 服务器
目前的支流计划是应用 Session 服务器。利用独立部署的 Session 服务器（集群）对立治理 Session，应用服务器每次读写 Session 时，都拜访 Session 服务器。
这种解决方案事实上是将应用服务器的状态拆散，分为无状态的应用服务器和有状态的 Session 服务器，而后针对这两种服务器的不同个性别离设计其架构。
对于有状态的 Session 服务器，一种比较简单的办法是利用分布式缓存如 Redis 等，在这些产品的根底上进行包装，使其合乎 Session 的存储和拜访要求。
高可用服务层
服务模块为业务产品提供根底公共服务，这些服务通常都独立分布式部署，被具体利用近程调用。服务是无状态的，因而能够应用相似负载平衡的生效转移策略实现高可用。除此之外，具体实际中，还有以下几点高可用的策略。
分级管理
运维上将服务器进行分级管理，外围利用和服务优先应用更好的硬件，在运维响应速度上也有更高优先级。例如，用户及时付款购物比能不能评估商品更重要，所以订单、领取服务比评估服务有更高优先级。
同时在服务部署上也进行必要的隔离，防止故障的连锁反应。低优先级的服务通过部署在不同的容器或虚拟机上进行隔离，而高优先级的服务则须要部署在不同的物理机上，外围服务和数据甚至须要部署在不同地区的数据中心。
超时设置
因为服务端宕机、线程死锁等起因，可能导致应用程序对服务端的调用失去响应，进而导致用户申请长时间得不到响应，同时还占用应用程序的资源，不利于及时将拜访申请转移到失常的服务器上。
能够在应用程序中设置服务调用的超时工夫，一旦超时，通信框架就抛出异样，应用程序依据服务调度策略，可抉择持续重试或将申请转移到提供雷同服务的其余服务器上。
异步调用
利用对服务的调用通过音讯队列等异步形式实现，防止一个服务失败导致整个利用申请失败的状况。如提交一个新用户注册申请，利用须要调用三个服务：将用户信息写入数据库，发送账户注册胜利邮件，开明对应权限。如果采纳同步服务调用，当邮件队列阻塞不能发送邮件时，会导致其余两个服务也无奈执行，最终导致用户注册失败。
如果采纳异步调用的形式，应用程序将用户注册信息发送给音讯队列服务器后立刻返回用户注册胜利响应。而记录用户注册信息到数据库、发送用户注册胜利邮件、调用用户服务开明权限这三个服务作为音讯的消费者工作，别离从音讯队列获取用户注册信息异步执行。即便邮件服务队列阻塞，邮件不能胜利发送，也不会影响其余服务的执行，用户注册操作可顺利完成，只是晚一点收到注册胜利的邮件而已。
当然不是所有服务调用都能够异步调用，对于获取用户信息这类调用，采纳异步形式会缩短响应工夫，得失相当。对于那些必须确认服务调用胜利能力持续下一步操作的利用也不适宜应用异步调用。
服务降级
在网站拜访高峰期，服务可能因为大量的并发调用而性能降落，重大时可能会导致服务宕机。为了保障外围利用和性能的失常运行，须要对服务进行降级。降级有两种伎俩：拒绝服务及敞开服务。
拒绝服务：回绝低优先级利用的调用，缩小服务调用并发数，确保外围利用失常应用；或者随机回绝局部申请调用，节约资源，让另一部分申请得以胜利。
敞开性能：敞开局部不重要的服务，或者服务外部敞开局部不重要的性能，以节约零碎开销，为重要的服务和性能让出资源。例如淘宝在每年的“双十一”促销中，在零碎最忙碌的时段敞开“评估”、“确认收货”等非核心服务，以保障外围交易服务的顺利完成。
幂等性设计
利用调用服务失败后，会将调用申请从新发送到其余服务器，然而这个失败可能不是真正的失败。比方服务曾经解决胜利，但因为网络故障利用没有收到响应，这时利用从新提交申请就导致服务反复调用，如果这个服务是一个转账操作，就会产生严重后果。
服务反复调用是无奈防止的，应用层也不须要关怀服务是否真的失败，只有没有收到调用胜利的响应，就能够认为调用失败，并重试服务调用。因而必须在服务层保障服务反复调用和调用一次产生的后果雷同，即服务具备幂等性。
高可用数据层
不同于高可用的利用和服务，因为数据层服务器上保留的数据不同，当某台服务器宕机的时候，数据拜访申请不能任意切换到集群中其余的机器上。
保证数据存储高可用的伎俩次要是数据备份和生效转移机制。数据备份是保证数据有多个正本，任意正本的生效都不会导致数据的永恒失落，从而实现数据齐全的长久化。而生效转移机制则保障当一个数据正本不可拜访时，能够疾速切换拜访数据的其余正本，保证系统可用。
对于数据层的“守护神”缓存服务，也须要保障简略的高可用。对于缓存服务器集群中的单机宕机，如果缓存服务器集群规模较大，那么单机宕机引起的缓存数据失落比例和数据库负载压力变动都较小，对整个零碎影响也较小。
扩充缓存服务器集群规模的一个简略伎俩就是所有利用共享同一个分布式缓存集群，独自的利用只须要向共享缓存集群申请缓存资源即可。并且通过逻辑或物理分区的形式将每个利用的缓存部署在多台服务器上，任何一台服务器宕机引起的缓存生效都只影响利用缓存数据的一小部分，不会对利用性能和数据库负载造成太大影响。
CAP 原理
在探讨高可用数据服务架构之前，必须先探讨的一个话题是，为了保证数据的高可用，零碎通常会就义另一个也很重要的指标：数据一致性。
高可用的数据层有如下几个层面的含意：
- 数据持久性：保证数据可长久存储，在各种状况下都不会呈现数据失落的问题。
- 数据可用性：即便存在损坏的正本，也须要保证数据是能够拜访的。
- 数据一致性：数据多个正本之间内容须要放弃雷同。
CAP 原理认为，一个提供数据服务的存储系统无奈同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Patition Tolerance，零碎具备跨网络分区的伸缩性）这三个条件，如图所示。
在大型利用中，数据规模总是疾速扩张的，因而可伸缩性即分区耐受性必不可少，规模变大当前，机器数量也会变得宏大，这时网络和服务器故障会频繁呈现，要想保障利用可用，就必须保证数据可用性。所以在大型网站中，通常会抉择强化分布式存储系统的可用性（A）和伸缩性（P），而在某种程度上放弃一致性（C）。
一般说来，数据不统一通常呈现在零碎高并发写操作或者集群状态不稳（故障复原、集群扩容……）的状况下，利用零碎须要对分布式数据处理系统的数据不一致性有所理解并进行某种意义上的弥补和纠错，以避免出现利用零碎数据不正确。
CAP 原理对于可伸缩的分布式系统设计具备重要意义。因为难以满足数据强一致性，零碎通常会综合老本、技术、业务场景等条件，联合应用服务和其余的数据监控与纠错性能，使存储系统达到用户统一，保障最终用户拜访数据的正确性。
数据备份
数据备份是一种古老而无效的数据保护伎俩，晚期的数据备份伎俩次要是数据冷备。冷备的长处是简略和便宜，老本和技术难度都较低。毛病是不能保证数据最终统一，因为数据是定期复制，因而备份设施中的数据比零碎中的数据古老，如果零碎数据失落，那么从上个备份点开始后更新的数据就会永恒失落。同时也不能保证数据可用性，从冷备存储中复原数据须要较长的工夫，而这段时间无法访问数据，零碎也不可用。
因而，数据冷备作为一种传统的数据保护伎俩，仍然在网站日常运维中应用，同时在网站实时在线业务中，还须要进行数据热备，以提供更好的数据可用性。数据热备可分为异步热备形式和同步热备形式。
异步形式是指多份数据正本的写入操作异步实现，应用程序失常状况下只连贯主存储服务器，数据写入时，由主存储服务器的写操作代理模块将数据写入本机存储系统后立刻返回写操作胜利响应，而后通过异步线程将写操作数据同步到从存储服务器。
同步形式是指多份数据正本的写入操作同步实现，即应用程序收到数据服务零碎的写胜利响应时，多份数据都曾经写操作胜利。然而当应用程序收到数据写操作失败的响应时，可能有局部正本或者全副正本都曾经写胜利了（因为网络或者系统故障，无奈返回操作胜利的响应）。
延长浏览：【分布式—要点】数据复制
生效转移
若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都须要从新路由到其余服务器，保证数据拜访不会失败，这个过程叫作生效转移。生效转移操作由三局部组成：生效确认、拜访转移、数据恢复。
判断服务器宕机是零碎进行生效转移的第一步，零碎确认一台服务器是否宕机的伎俩有两种：心跳检测和应用程序拜访失败报告。对于应用程序的拜访失败报告，控制中心还须要再一次发送心跳检测进行确认，免得错误判断服务器宕机。
确认某台数据存储服务器宕机后，就须要将数据读写访问从新路由到其余服务器上。对于齐全对等存储的服务器（几台存储服务器存储的数据齐全一样），当其中一台宕机后，应用程序依据配置间接切换到对等服务器上。如果存储是不对等的，那么就须要从新计算路由，抉择存储服务器。
因为某台服务器宕机，所以数据存储的正本数目会缩小，必须将正本的数目复原到零碎设定的值，否则，再有服务器宕机时，就可能呈现无法访问转移（所有正本的服务器都宕机了），数据永恒失落的状况。因而零碎须要从衰弱的服务器复制数据，将数据正本数目复原到设定值。