分布式系统设计策略

标签: 分布 系统 设计 | 发表时间:2018-08-07 15:08 | 作者:linyinpeng1989
出处:http://www.iteye.com

摘自 《深入分布式缓存:从原理到实践》

 

分布式系统本质是通过低廉的硬件攒在一起以获得更好地吞吐量、性能以及可用性等。分布式系统有一些通用的设计策略,也是在分布式环境下普遍关心的几个问题:

  • 如何检测你还活着?
  • 如何保障高可用
  • 容错处理
  • 重试机制
  • 负载均衡

1. 心跳检测

在分布式环境中,一般会有多个节点来分担任务的运行、计算或程序逻辑处理。通常采用 心跳检测 来判断节点是否可用。

 



 

如上图所示,Client请求Server,Server转发请求到具体的Node获取请求结果。Server需要与三个Node节点保持心跳连接,确保Node可以正常工作。

 

若Server没有收到Node3的心跳时,Server认为Node3失联。失联代表并不确定是否是Node3故障,有可能是Node3处于繁忙状态,导致调用检测超时;也有可能是Server与Node3之间链路出现故障或闪断。所以心跳不是万能的,收到心跳可以确认节点正常,但是收不到心跳却不能认为该节点已经宣告“死亡”。此时,可以通过一些方法帮助Server做决定: 周期检测心跳机制、累计失效检测机制

 

周期检测心跳机制
Server端每间隔 t 秒向Node集群发起监测请求,设定超时时间,如果超过超时时间,则判断“死亡”。

 

累计失效检测机制
 在周期检测心跳机制的基础上,统计一定周期内节点的返回情况(包括超时及正确返回),以此计算节点的“死亡”概率。另外,对于宣告“濒临死亡”的节点可以发起有限次数的重试,以作进一步判断。

 

通过周期检测心跳机制、累计失效检测机制可以帮助判断节点是否“死亡”,如果判断“死亡”,可以把该节点踢出集群。

 

2. 高可用设计

系统高可用性的常用设计模式包括三种: 主备(Master-Slave)模式、互备(Active-Active)模式和集群(Cluster)模式

 

1) 主备模式

主备模式就是Active-Standby模式,当主机宕机时,备机接管主机的一切工作,待主机恢复正常后,按使用者的设定以自动(热备)或手动(冷备)方式将服务切换到主机上运行。在数据库部分,习惯称之为MS模式,即Master/Slave模式,这在数据库高可用性方案中比较常用,但存在Master到Slave的数据延时风险,尤其是跨地域复制。如MySQL、Redis等就采用MS模式保证高可用。

 



 

 

2) 互备模式

互备模式指两台主机同时运行各自的服务工作且相互监测情况。在数据库高可用部分,常见的互备是MM模式,即Multi-Master模式,指一个系统存在多个master,每个master都具有read-write能力,需根据时间戳或业务逻辑合并版本。比如分布式版本管理系统Git,可以理解成Multi-Master的解决方案,具备最终一致性。

 

3) 集群模式

集群模式是指有多个节点在运行,同时可以通过主控节点分担服务请求。如Zookeeper。集群模式需要解决主控节点本身的高可用问题,一般采用主备模式。

 

如TFS(Taobao File System),它涉及到NameServer、DataServer两类节点。NameServer存放元数据,而具体的业务数据存放于DataServer。多个DataServer就是集群模式的运行状态,NameServer作为主控节点。为了保障NameServer的高可用,通过Heart Agent机制做心跳检测来负责NameServer的主备切换(主备模式)。




 
 

3. 容错性

 容错就是IT系统对于错误的包容能力,确切地说是容故障而非错误。容错的处理是保障分布式环境下相应系统的高可用或者健壮性。

 

以TFS为例,TFS集群需要容错(整个集群宕掉咋办?)、NameServer需要容错、DataServer也需要容错。NameServer主要管理了DataServer和Block之间的关系。如每个DataServer拥有哪些Block,每个Block存放在哪些DataServer上等。同时,NameServer采用了主备模式,主NameServer上的操作会重放(同步)到备NameServer,如果主NameServer出现问题,可以实时切换到备NameServer。另外NameServer和DataServer之间也会有定时的心跳机制,DataServer会把自己拥有的Block发送给NameServer,NameServer会根据这些信息重建DataServer和Block的关系。

 

另外,缓存失效雪崩问题也可以进行一定的容错处理,提升系统健壮性。比如,我们使用缓存通常都是先检查缓存是否存在,如果存在则直接返回缓存内容,如果不存在就直接查询数据库然后再缓存查询结果返回。因此,如果我们查询的某一些数据实际上不存在,就会造成每一次请求都查询DB,给数据库造成较大的压力。这种情况下,一个比较巧妙的方法是,将这个不存在的key预先设定一个值并存入缓存(过期时间不宜过长),避免大量请求透传到DB中。

 

4. 负载均衡

负载均衡集群:其关键在于使用多台集群服务器共同分担计算任务,把网络请求及计算分配到集群可用服务器上去,从而达到可用性及较好地用户体验。

 


 

负载均衡器有硬件解决方案,也有软件解决方案。硬件解决方案有著名的F5,软件有LVS、HAProxy、Nginx等。

 

以Nginx为例,负载均衡有如下几种策略:

  • 轮询:即Round Robin,根据Nginx配置文件中的顺序,依次把客户端的Web请求分发到不同的后端服务器
  • 最少链接:当前谁连接最少,分发给谁
  • 基于权重:配置Nginx把请求更多地分发到高配置的后端服务器上,把相对较少的请求分发到低配服务器


已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [分布 系统 设计] 推荐:

分布式系统设计策略

- - 互联网 - ITeye博客
摘自 《深入分布式缓存:从原理到实践》. 分布式系统本质是通过低廉的硬件攒在一起以获得更好地吞吐量、性能以及可用性等. 分布式系统有一些通用的设计策略,也是在分布式环境下普遍关心的几个问题:. 在分布式环境中,一般会有多个节点来分担任务的运行、计算或程序逻辑处理. 如上图所示,Client请求Server,Server转发请求到具体的Node获取请求结果.

【分布式系统工程实现】GFS&Bigtable设计的优势

- hikerlive - 淘宝核心系统团队博客
目前,知名度比较高的通用存储系统包括:Google GFS&Bigtable,Amazon Dynamo,Microsoft Azure存储系统及Yahoo PNUTS. 其中,GFS&Bigtable,Azure存储系统及Yahoo PNUTS都有总控节点,Amazon Dynamo采用去中心化的P2P设计.

分布式系统的设计几个要注意的地方

- - CSDN博客推荐文章
最近在做系统升级,由于当时设计的局限,导致系统不停服,保证服务的做法非常麻烦. 当时再定方案的时候,由于自己在这方面没有经验,导致有些乐观. 到了实际做的时候,预期时间至少比预想的多了一周的时间,要知道,在. 互联网公司,一周的时间是个非常长的时间. 在这里总结一下分布式系统设计的大忌,本来想试着分一下级,但是还是算了,一来标准太多,无法制定一个合适的规则来界定;二来自己的经验也在增长,低调一下是自己也没详细的研究过超过5个分布式系统;三来做事情还是要严谨,不做没有十足把握的事情.

分布式日志收集系统Apache Flume的设计介绍

- - CSDN博客架构设计推荐文章
Flume是Cloudera公司的一款高性能、高可能的分布式日志收集系统. 现在已经是Apache Top项目. 同Flume相似的日志收集系统还有 Facebook Scribe, Apache Chuwka, Apache Kafka(也是LinkedIn的). Flume是后起之秀,本文尝试简要分析Flume数据流通过程中提供的组件、可靠性保证来介绍Flume的主要设计,不涉及Flume具体的安装使用,也不涉及代码层面的剖析.

[转] 分布式存储系统(GlusterFS, Swift, Cassandra)设计对比

- - 忘我的追寻
之前转过一篇分布式文件系统比较的文章, 几大分布式文件系统全方位比较,这里再从存储的角度转一个. 应该说者三个开源软件各自侧重的领域不一样,但是都具备分布式存储的特征,因此这篇文章主要是从存储的角度来进行对比. 1、 文件定位:三者均采用hash算法,另外amazon的Dynamo也是采用一致性哈希;还有采用中心路由的定位方式:如HBASE,HDFS.

高并发服务端分布式系统设计概要

- - 博客 - 伯乐在线
写这篇文章的目的,主要是把今年以来学习的一些东西积淀下来,同时作为之前文章《 高性能分布式计算与存储系统设计概要》的补充与提升,然而本人水平非常有限,回头看之前写的文章也有许多不足,甚至是错误,希望同学们看到了错误多多见谅,更欢迎与我讨论并指正. 我大概是从2010年底起开始进入高并发、高性能服务器和分布式这一块领域的研究,到现在也差不多有三年,但其实很多东西仍然是一知半解,我所提到的许许多多概念,也许任何一个我都不能讲的很清楚,还需要继续钻研.

分布式会话跟踪系统架构设计与实践

- - 美团点评技术团队
本文整理自美团点评技术沙龙第08期:大规模集群的服务治理设计与实践. 美团点评技术沙龙由美团点评技术团队主办,每月一期. 每期沙龙邀请美团点评及其它互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域. 目前沙龙会分别在北京、上海和厦门等地举行,要参加下一次最新沙龙活动. 赶快关注微信公众号“美团点评技术团队”.

基于分布式环境下限流系统的设计

- - Zhisheng的博客
就拿前些天的双十一的 “抢券活动” 来说,一般是设置整点开始抢的,你想想,淘宝的用户群体非常大,可以达到亿级别,而服务接口每秒能处理的量是有限的,那么这个时候问题就会出现,我们如何通过程序来控制用户抢券呢,于是就必须加上这个限流功能了. 1、服务接口所能提供的服务上限(limit)假如是 500次/s.

分布式文件系统FastDFS设计原理及技术架构

- - mysqlops
FastDFS是一个开源的轻量级分布式文件系统,由跟踪服务器(tracker server)、存储服务器(storage server)和客户端(client)三个部分组成,主要解决了海量数据存储问题,特别适合以中小文件(建议范围:4KB < file_size <500MB)为载体的在线服务. Storage server(后简称storage)以组(卷,group或volume)为单位组织,一个group内包含多台storage机器,数据互为备份,存 储空间以group内容量最小的storage为准,所以建议group内的多个storage尽量配置相同,以免造成存储空间的浪费.

[译] 支付核心系统设计:Airbnb 的分布式事务方案简介

- - IT瘾-dev
导读:微服务架构下的支付系统,由于其需要在性能和一致性之间做很多权衡,带来设计和实现的复杂性. Airbnb的支付系统需要对接全球很多个国家的支付系统,因此带来很大的复杂性. 本文详细论述了Airbnb如何使用分布式事务的相关技术来保证支付系统的数据一致性和性能,十分值得一读. 过去几年中,Airbnb一直在将其基础架构迁移到SOA.