从Elasticsearch来看分布式系统架构设计

从Elasticsearch来看分布式系统架构设计

  mp.weixin.qq.com

点击上方“匠心零度”，选择“设为星标”

作积极的人，而不是积极废人

 

 

 

来源：https://dwz.cn/gPfuoLwo

分布式系统类型多，涉及面很是广，不一样类型的系统有不一样的特色，批量计算和实时计算就差异很是大。这篇文章中，重点会讨论下分布式数据系统的设计，好比分布式存储系统，分布式搜索系统，分布式分析系统等。

咱们先来简单看下Elasticsearch的架构。

Elasticsearch 集群架构

Elasticsearch是一个很是著名的开源搜索和分析系统，目前被普遍应用于互联网多种领域中，尤为是如下三个领域特别突出。一是搜索领域，相对于solr，真正的后起之秀，成为不少搜索系统的不二之选。二是Json文档数据库，相对于MongoDB，读写性能更佳，并且支持更丰富的地理位置查询以及数字、文本的混合查询等。三是时序数据分析处理，目前是日志处理、监控数据的存储、分析和可视化方面作得很是好，能够说是该领域的引领者了。

Elasticsearch的详细介绍能够到官网查看。咱们先来看一下Elasticsearch中几个关键概念：

• 节点（Node）：物理概念，一个运行的Elasticearch实例，通常是一台机器上的一个进程。

• 索引（Index），逻辑概念，包括配置信息mapping和倒排正排数据文件，一个索引的数据文件可能会分布于一台机器，也有可能分布于多台机器。索引的另一层意思是倒排索引文件。

• 分片（Shard）：为了支持更大量的数据，索引通常会按某个维度分红多个部分，每一个部分就是一个分片，分片被节点(Node)管理。一个节点(Node)通常会管理多个分片，这些分片多是属于同一份索引，也有可能属于不一样索引，可是为了可靠性和可用性，同一个索引的分片尽可能会分布在不一样节点(Node)上。分片有两种，主分片和副本分片。

• 副本（Replica）：同一个分片(Shard)的备份数据，一个分片可能会有0个或多个副本，这些副本中的数据保证强一致或最终一致。

用图形表示出来多是这样子的：

 

 

• Index 1：蓝色部分，有3个shard，分别是P1，P2，P3，位于3个不一样的Node中，这里没有Replica。

• Index 2：绿色部分，有2个shard，分别是P1，P2，位于2个不一样的Node中。而且每一个shard有一个replica，分别是R1和R2。基于系统可用性的考虑，同一个shard的primary和replica不能位于同一个Node中。这里Shard1的P1和R1分别位于Node3和Node2中，若是某一刻Node2发生宕机，服务基本不会受影响，由于还有一个P1和R2都仍是可用的。由于是主备架构，当主分片发生故障时，须要切换，这时候须要选举一个副本做为新主，这里除了会耗费一点点时间外，也会有丢失数据的风险。

Index流程

建索引（Index）的时候，一个Doc先是通过路由规则定位到主Shard，发送这个doc到主Shard上建索引，成功后再发送这个Doc到这个Shard的副本上建索引，等副本上建索引成功后才返回成功。

在这种架构中，索引数据所有位于Shard中，主Shard和副本Shard各存储一份。当某个副本Shard或者主Shard丢失（好比机器宕机，网络中断等）时，须要将丢失的Shard在其余Node中恢复回来，这时候就须要从其余副本（Replica）全量拷贝这个Shard的全部数据到新Node上构造新Shard。这个拷贝过程须要一段时间，这段时间内只能由剩余主副原本承载流量，在恢复完成以前，整个系统会处于一个比较危险的状态，直到failover结束。

这里就体现了副本（Replica）存在的一个理由，避免数据丢失，提升数据可靠性。副本（Replica）存在的另外一个理由是读请求量很大的时候，一个Node没法承载全部流量，这个时候就须要一个副原本分流查询压力，目的就是扩展查询能力。

角色部署方式

接下来再看看角色分工的两种不一样方式：

 

 

Elasticsearch支持上述两种方式：

1.混合部署（左图）

• 默认方式。

• 不考虑MasterNode的状况下，还有两种Node，Data Node和Transport Node，这种部署模式下，这两种不一样类型Node角色都位于同一个Node中，至关于一个Node具有两种功能：Data和Transport。

• 当有index或者query请求的时候，请求随机（自定义）发送给任何一个Node，这台Node中会持有一个全局的路由表，经过路由表选择合适的Node，将请求发送给这些Node，而后等全部请求都返回后，合并结果，而后返回给用户。一个Node分饰两种角色。

• 好处就是使用极其简单，易上手，对推广系统有很大价值。最简单的场景下只须要启动一个Node，就能完成全部的功能。

• 缺点就是多种类型的请求会相互影响，在大集群若是某一个Data Node出现热点，那么就会影响途经这个Data Node的全部其余跨Node请求。若是发生故障，故障影响面会变大不少。

• Elasticsearch中每一个Node都须要和其他的每个Node都保持13个链接。这种状况下， - 每一个Node都须要和其余全部Node保持链接，而一个系统的链接数是有上限的，这样链接数就会限制集群规模。

• 还有就是不能支持集群的热更新。

2.分层部署（右图）：

• 经过配置能够隔离开Node。

• 设置部分Node为Transport Node，专门用来作请求转发和结果合并。

• 其余Node能够设置为DataNode，专门用来处理数据。

• 缺点是上手复杂，须要提早设置好Transport的数量，且数量和Data Node、流量等相关，不然要么资源闲置，要么机器被打爆。

• 好处就是角色相互独立，不会相互影响，通常Transport Node的流量是平均分配的，不多出现单台机器的CPU或流量被打满的状况，而DataNode因为处理数据，很容易出现单机资源被占满，好比CPU，网络，磁盘等。独立开后，DataNode若是出了故障只是影响单节点的数据处理，不会影响其余节点的请求，影响限制在最小的范围内。

• 角色独立后，只须要Transport Node链接全部的DataNode，而DataNode则不须要和其余DataNode有链接。一个集群中DataNode的数量远大于Transport Node，这样集群的规模能够更大。另外，还能够经过分组，使Transport Node只链接固定分组的DataNode，这样Elasticsearch的链接数问题就完全解决了。

• 能够支持热更新：先一台一台的升级DataNode，升级完成后再升级Transport Node，整个过程当中，能够作到让用户无感知。

上面介绍了Elasticsearch的部署层架构，不一样的部署方式适合不一样场景，须要根据本身的需求选择适合的方式。

Elasticsearch 数据层架构

接下来咱们看看当前Elasticsearch的数据层架构。

数据存储

Elasticsearch的Index和meta，目前支持存储在本地文件系统中，同时支持niofs，mmap，simplefs，smb等不一样加载方式，性能最好的是直接将索引LOCK进内存的MMap方式。默认，Elasticsearch会自动选择加载方式，另外能够本身在配置文件中配置。这里有几个细节，具体能够看官方文档。

索引和meta数据都存在本地，会带来一个问题：当某一台机器宕机或者磁盘损坏的时候，数据就丢失了。为了解决这个问题，可使用Replica（副本）功能。

副本（Replica）

能够为每个Index设置一个配置项：副本（Replicda）数，若是设置副本数为2，那么就会有3个Shard，其中一个是PrimaryShard，其他两个是ReplicaShard，这三个Shard会被Mater尽可能调度到不一样机器，甚至机架上，这三个Shard中的数据同样，提供一样的服务能力。

副本（Replica）的目的有三个：

• 保证服务可用性：当设置了多个Replica的时候，若是某一个Replica不可用的时候，那么请求流量能够继续发往其余Replica，服务能够很快恢复开始服务。

• 保证数据可靠性：若是只有一个Primary，没有Replica，那么当Primary的机器磁盘损坏的时候，那么这个Node中全部Shard的数据会丢失，只能reindex了。

• 提供更大的查询能力：当Shard提供的查询能力没法知足业务需求的时候， 能够继续加N个Replica，这样查询能力就能提升N倍，轻松增长系统的并发度。

问题

上面说了一些优点，这种架构一样在一些场景下会有些问题。

Elasticsearch采用的是基于本地文件系统，使用Replica保证数据可靠性的技术架构，这种架构必定程度上能够知足大部分需求和场景，可是也存在一些遗憾：

• Replica带来成本浪费。为了保证数据可靠性，必须使用Replica，可是当一个Shard就能知足处理能力的时候，另外一个Shard的计算能力就会浪费。

• Replica带来写性能和吞吐的降低。每次Index或者update的时候，须要先更新Primary Shard，更新成功后再并行去更新Replica，再加上长尾，写入性能会有很多的降低。

• 当出现热点或者须要紧急扩容的时候动态增长Replica慢。新Shard的数据须要彻底从其余Shard拷贝，拷贝时间较长。

上面介绍了Elasticsearch数据层的架构，以及副本策略带来的优点和不足，下面简单介绍了几种不一样形式的分布式数据系统架构。

分布式系统

第一种：基于本地文件系统的分布式系统

 

 

上图中是一个基于本地磁盘存储数据的分布式系统。Index一共有3个Shard，每一个Shard除了Primary Shard外，还有一个Replica Shard。当Node 3机器宕机或磁盘损坏的时候，首先确认P3已经不可用，从新选举R3位Primary Shard，此Shard发生主备切换。而后从新找一台机器Node 7，在Node7 上从新启动P3的新Replica。因为数据都会存在本地磁盘，此时须要将Shard 3的数据从Node 6上拷贝到Node7上。若是有200G数据，千兆网络，拷贝完须要1600秒。若是没有replica，则这1600秒内这些Shard就不能服务。

为了保证可靠性，就须要冗余Shard，会致使更多的物理资源消耗。

这种思想的另一种表现形式是使用双集群，集群级别作备份。

在这种架构中，若是你的数据是在其余存储系统中生成的，好比HDFS/HBase，那么你还须要一个数据传输系统，将准备好的数据分发到相应的机器上。

这种架构中为了保证可用性和可靠性，须要双集群或者Replica才能用于生产环境，优点和反作用在上面介绍Elasticsearch的时候已经介绍过了，这里就就不赘述了。

Elasticsearch使用的就是这种架构方式。

第二种：基于分布式文件系统的分布式系统（共享存储）

 

 

针对第一种架构中的问题，另外一种思路是：存储和计算分离。

第一种思路的问题根源是数据量大，拷贝数据耗时多，那么有没有办法能够不拷贝数据？为了实现这个目的，一种思路是底层存储层使用共享存储，每一个Shard只须要链接到一个分布式文件系统中的一个目录/文件便可，Shard中不含有数据，只含有计算部分。至关于每一个Node中只负责计算部分，存储部分放在底层的另外一个分布式文件系统中，好比HDFS。

上图中，Node 1 链接到第一个文件；Node 2链接到第二个文件；Node3链接到第三个文件。当Node 3机器宕机后，只须要在Node 4机器上新建一个空的Shard，而后构造一个新链接，链接到底层分布式文件系统的第三个文件便可，建立链接的速度是很快的，总耗时会很是短。

这种是一种典型的存储和计算分离的架构，优点有如下几个方面：

• 在这种架构下，资源能够更加弹性，当存储不够的时候只须要扩容存储系统的容量；当计算不够的时候，只须要扩容计算部分容量。

• 存储和计算是独立管理的，资源管理粒度更小，管理更加精细化，浪费更少，结果就是整体成本能够更低。

• 负载更加突出，抗热点能力更强。通常热点问题基本都出如今计算部分，对于存储和计算分离系统，计算部分因为没有绑定数据，能够实时的扩容、缩容和迁移，当出现热点的时候，能够第一时间将计算调度到新节点上。

这种架构同时也有一个不足：访问分布式文件系统的性能可能不及访问本地文件系统。在上一代分布式文件系统中，这是一个比较明显的问题，可是目前使用了各类用户态协议栈后，这个差距已经愈来愈小了。HBase使用的就是这种架构方式。
Solr也支持这种形式的架构。

总结

上述两种架构，各有优点和不足，对于某些架构中的不足或缺陷，思路不一样，解决的方案也截然不同，可是思路跨度越大，收益通常也越大。

上面只是介绍了分布式数据（存储/搜索/分析等等）系统在存储层的两种不一样架构方式，但愿能对你们有用。可是分布式系统架构设计所涉及的内容广，细节多，权衡点众，若是你们对某些领域或者方面有兴趣，也能够留言，后面再探讨。