架构成长之路：分布式系统如何设计，看看Elasticsearch是怎么做的

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

我们先来简单看下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的数据层架构。

数据存储

（编辑：长春站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!