开江网站建设,广州平面设计学徒招聘,wordpress 08影院2.0,2019还有人做网站淘宝客吗从Elasticsearch来看分布式系统架构设计 - 知乎
分布式系统类型多#xff0c;涉及面非常广#xff0c;不同类型的系统有不同的特点#xff0c;批量计算和实时计算就差别非常大。这篇文章中#xff0c;重点会讨论下分布式数据系统的设计#xff0c;比如分布式存储系统涉及面非常广不同类型的系统有不同的特点批量计算和实时计算就差别非常大。这篇文章中重点会讨论下分布式数据系统的设计比如分布式存储系统分布式搜索系统分布式分析系统等。
我们先来简单看下Elasticsearch的架构。
Elasticsearch 集群架构
Elasticsearch是一个非常著名的开源搜索和分析系统目前被广泛应用于互联网多种领域中尤其是以下三个领域特别突出。一是搜索领域相对于solr真正的后起之秀成为很多搜索系统的不二之选。二是Json文档数据库相对于MongoDB读写性能更佳而且支持更丰富的地理位置查询以及数字、文本的混合查询等。三是时序数据分析处理目前是日志处理、监控数据的存储、分析和可视化方面做得非常好可以说是该领域的引领者了。
Elasticsearch的详细介绍可以到官网查看。我们先来看一下Elasticsearch中几个关键概念
节点Node物理概念一个运行的Elasticearch实例一般是一台机器上的一个进程。索引Index逻辑概念包括配置信息mapping和倒排正排数据文件一个索引的数据文件可能会分布于一台机器也有可能分布于多台机器。索引的另外一层意思是倒排索引文件。分片Shard为了支持更大量的数据索引一般会按某个维度分成多个部分每个部分就是一个分片分片被节点(Node)管理。一个节点(Node)一般会管理多个分片这些分片可能是属于同一份索引也有可能属于不同索引但是为了可靠性和可用性同一个索引的分片尽量会分布在不同节点(Node)上。分片有两种主分片和副本分片。副本Replica同一个分片(Shard)的备份数据一个分片可能会有0个或多个副本这些副本中的数据保证强一致或最终一致。
用图形表示出来可能是这样子的 Index 1蓝色部分有3个shard分别是P1P2P3位于3个不同的Node中这里没有Replica。Index 2绿色部分有2个shard分别是P1P2位于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支持上述两种方式
混合部署左图 默认方式。不考虑MasterNode的情况下还有两种NodeData 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保持连接而一个系统的连接数是有上限的这样连接数就会限制集群规模。还有就是不能支持集群的热更新。分层部署右图 通过配置可以隔离开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目前支持存储在本地文件系统中同时支持niofsmmapsimplefssmb等不同加载方式性能最好的是直接将索引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也支持这种形式的架构。
总结
上述两种架构各有优势和不足对于某些架构中的不足或缺陷思路不同解决的方案也大相径庭但是思路跨度越大收益一般也越大。
上面只是介绍了分布式数据存储/搜索/分析等等系统在存储层的两种不同架构方式希望能对大家有用。但是分布式系统架构设计所涉及的内容广细节多权衡点众如果大家对某些领域或者方面有兴趣也可以留言后面再探讨。
