分布式系统类型多，涉及面十分广，不同类型的零碎有不同的特点，批量计算和实时计算就差异十分大。这篇文章中，重点会探讨下分布式数据系统的设计，比方分布式存储系统，分布式搜寻零碎，分布式剖析零碎等。

咱们先来简略看下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也反对这种模式的架构。

总结

上述两种架构，各有劣势和有余，对于某些架构中的有余或缺点，思路不同，解决的计划也天壤之别，然而思路跨度越大，收益个别也越大。

下面只是介绍了分布式数据（存储/搜寻/剖析等等）零碎在存储层的两种不同架构形式，心愿能对大家有用。然而分布式系统架构设计所波及的内容广，细节多，衡量点众，如果大家对某些畛域或者方面有趣味，也能够留言，前面再探讨。