网站页面能够完整的展现在用户面前,需要经过很多环节,任何一个环节出问题都可能会导致页面不可用。一般情况下为了提高系统可用性,会采用较昂贵的硬件设备。但是硬件故障也是常态的,高可用架构设计的一个主要目的就是保证在硬件故障时服务依然可用、数据能够保存且被访问。主要手段就是的冗余备份和失效转移。
1,分层模型
典型的分层模型是三层,即应用层、服务层和数据层,各层之间相对独立。
应用层:负责具体业务逻辑的处理。
服务层:可复用的服务。
数据层:数据的存储和访问。
2,应用层高可用
当负载均衡设备通过心跳检测等手段检测到某台服务器不能用的时候,就将其从集群列表中剔除,并将请求分发到集群中其他可用的服务器上。
应用的一个显著特点就是无状态性。所谓的无状态的应用是指:应用服务器不保存业务的上下文信息,而仅根据每次请求提交的数据进行相应的业务逻辑处理,多个服务器之间完全对等,请求提交到任意服务器,处理结果都是一样的。
事实上,业务总是有状态的。将多次请求修改使用的上下文对象称作会话(Session)。session和cookie总是成对出现,不过可以简单理解为:cookie数据存放在客户的浏览器上,session数据放在服务器上。
在集群情况下,负载均衡服务器可能会将请求分发到任何一台服务器上,保证每次请求都获得正确的session主要有以下几种手段。
session复制
应用服务器开启web容器的session复制功能,在集群中的服务器之间同步session对象,使得每台服务器都保存所有用户的session信息。
优点
简单。
从本机读取,速度快。
缺点
集群规模较大时,集群之间进行同步session,占用网络等。
由于session在每台服务器都有备份,当大量用户访问时,服务器内存可能不够session使用。
session绑定
利用负载均衡的源地址hash算法实现,负载均衡服务器总是将来源于同一个ip的请求分发到同一台服务器上。这样在整个会话期间用户的所有请求都被这台服务器获取,这种方法又称为会话黏滞。
缺点
当某台服务器挂了,那该机器的session就不复存在,用户请求切换到其他机器后因为没有session而无法完成业务处理。
利用cookie记录session
将session记录通过cookie保存在客户端,每次请求服务器时,都将session放在请求中发送给服务器,服务器处理完之后再将修改的session响应给客户端。
优点
cookie简单易用,可用性高,支持应用服务器线性伸缩,大部分session信息较小。
缺点
cookie大小限制,能记录信息有限。
每次请求都要传输cookie,影响性能。
如果用户关闭cookie,访问就会不正常。
session服务器
利用独立部署的session服务器集群统一管理session。这种解决方案实际上是将应用服务器的状态分离,分为无状态应用服务器和有状态的session服务器。
对于有状态的session服务器,一种比较简单的方法是利用分布式缓存、数据库等,在这些产品上进行包装,使其符合session的存储和访问要求。如果业务场景对session管理有比较高的要求,比如利用session服务集成单点登录(SSO)等,需要开发专用session服务管理平台。
3,服务层的高可用
可复用的服务模块通常独立分布式部署,被具体应用远程调用(RPC)。可复用的服务也是无状态的服务,因此可以使用类似负载均衡的失效转移策略。
除此之外还有如下几点策略:
分级管理
运维上将服务器分级管理,核心应用和服务使用更好的硬件,运维响应速度也格外迅速。
同时在部署上也进行必要隔离,防止故障的连锁反应。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离,而高优先级的服务则需要部署在不同的物理机上,核心服务和数据甚至要部署在不同的数据中心。
超时设置
由于服务器宕机、线程死锁等原因,可能导致应用程序对服务端的调用失去响应,进而导致用户长期得不到响应,同时还占用应用程序的资源,不利于将访问转移到正常的服务器上。
因此需要设置服务调用的超时时间,一旦超时抛出异常。
异步调用
应用对服务的调用通过消息队列等异步方式完成,避免一个服务失败导致整个应用请求失败的情况。
对于获取用户信息的调用,采用异步的方式会延长响应时间。对于那些必须确认调用成功才能进行下一步的服务也不适合异步调用。
服务降级
在访问高峰期,比如双十一等,服务器可能因为大量并发访问导致性能下降,为了保证核心应用和功能的正常运行,需要对服务进行降级。主要有两种手段:
拒绝服务
拒绝低优先级应用的调用,减少调用并发数。
随机拒绝部分请求,节省资源,让另一部分请求成功。
关闭功能
关闭部分不重要的服务。
服务内关闭部分不重要的功能。
幂等性设计
应用调用服务失败后,会将请求重新发送到其他服务器,但是这个失败可能是虚假的失败。如服务处理成功了,但是因为网络故障导致应用没有收到相应,这时应用重新提交请求就导致服务重复调用。
服务的重复调用是无法避免的,应用层也不关系服务是否真的失败,只要没收到成功响应,就可以认为调用失败并重试调用。因此必须在服务层保证重复调用和一次调用的结果相同,即服务具有幂等性。
有些服务天然具有幂等性,如性别的设置。但是对于转账之类的交易,就比较复杂,需要通过交易编号等信息进行校验。
4,数据存储高可用
由于数据存储服务器上保存的数据一般都不相同,当某一台服务器宕机后,数据访问请求不能任意切换到集群中的其他服务器上。保证数据存储高可用的手段主要是数据备份和失效转移。
数据备份:保存的数据有多个副本,任意副本的失效都不会导致数据的永久丢失,从而实现数据完全的持久化。
失效转移:当一个数据副本不可访问时,可以快速切换数据的其他副本,保证系统可用性。
4.1,CAP
分布式系统有三个特性:
一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本),换句话就是说,任何时刻,所用的应用程序都能访问得到相同的数据。
可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性),换句话就是说,任何时候,任何应用程序都可以读写数据。
分区容错性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择,换句话说,系统可以跨网络分区线性的伸缩和扩展。
CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。
高可用、数据一致是很多系统设计的目标,但是分区又是不可避免的事情,因此一般情况下满足P,C和A权衡考虑满足。
4.2,数据一致性
数据的一致性一般分为如下几点:
数据强一致
各个副本的数据在物理存储中总是一致的;数据更新操作结果和操作响应总是一致的,即操作响应通知更新失败,那么数据一定是没有被更新,而不是处于不确定的状态。
数据用户一致
数据在物理存储中各个副本的数据可能是不一致的,但是终端访问的时,通过纠错和校验机制,可以确定一个一致性的且正确的数据给用户。
数据的最终一致
这是一致性最弱的一种,即物理存储的数据可能是不一致的,终端用户访问到的数据也可能是不一致的(同一用户连续访问,结果不同;或者不同用户同时访问,结果不同),但是系统经过一段时间的调整,数据最终会一致。
因为很难满足数据的强一致性,综合考虑一般是达到存储系统的用户一致,保证最终用户访问数据的正确性。
4.3,数据备份
冷备
定期将数据复制到某种存储介质中并物理存档保管,如果系统存储损坏,就从冷备的设备中恢复。
优点
简单,成本和技术难度较低。
缺点
不能保证数据的最终一致,由于是定期备份,因此备份设备中的数据比系统中的陈旧,如果系统数据丢失,则从上个备份点之后的数据都丢失了。
不能保证数据可用性,从冷备存储恢复数据需要较长时间,这段时间无法访问数据,系统不可用。
热备
异步热备
多份数据副本的写入操作异步完成,应用程序收到数据服务系统的写入操作响应时,只写入了一份,存储系统会异步写入其他副本。
在异步写入下,存储服务器分为主存储服务器(master)和从存储服务器(slave),应用程序正常情况下只连接master,然后通过异步线程写入到slave中。
同步热备
多份数据副本写入操作同步完成。
为了提高性能,应用程序并发的向多个存储服务器同时写入,然后等待所有存储服务器都返回成功之后,再通知写入成功。
传统的关系型数据库几乎都提供了数据实时同步备份的机制,关系型数据库热备机制就是通常所说的master-slave机制,实践中通常使用读写分离的方法来访问数据库。
4.4,失效转移
失效转移操作由三部分组成:失效确认、访问转移、数据恢复。
失效确认
系统确认一台服务器宕机的手段有两种:
心跳检测
应用程序访问失败,访问失败之后还要再发一次心跳,避免误判
访问转移
路由到可用的存储服务器
数据恢复
因为某台服务器宕机,所以存储的副本数会减少,必须将副本的数目恢复到系统的设定值,否则,再有服务器宕机时,可能出现无法访问转移,数据永久丢失。
5,待续
近期沉迷于《当你沉睡时》,周末的两天在去韶关的大巴上把剧给刷完了。不得不说,现在的韩剧已经不是当年那种车祸,失忆,兄妹一类的剧情了,题材越来越新颖,部分还反应社会现实,值得我们学习。国民初恋——秀智好漂亮啊啊啊啊啊啊啊啊!
刷完了剧又该好好学习了,要是我能在梦里学会这些知识,或者提前梦到自己的未来多好。
Stay Hungry, Stay Foolish.
领取专属 10元无门槛券
私享最新 技术干货