一些有意思的观点
各种地方听到的观点想法,并不 100%正确、甚至是有偏见的,但是很有参考意义。
Elasticsearch 是一个实时的分布式搜索和分析引擎。它可以帮助你用前所未有的速度去处理大规模数据。ElasticSearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于 RESTful web 接口。Elasticsearch 是用 Java 开发的,并作为 Apache 许可条款下的开放源码发布,是当前流行的企业级搜索引擎。设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便。
Elasticsearch 是一个分布式、可扩展、实时的搜索与数据分析引擎。大致上,它有以下重要特征:
这篇文档主要介绍如何配置测试环境、搭建ES集群。
就 ZooKeeper 来说,只明白原理是不够的,因为实际场景非常多,在不同场景下 ZooKeeper 几乎都有不同的应用模式,不过幸运的是 ZooKeeper 已经有一个比较完善的客户端 Curator,在生产环境下几乎不需要投入太多人力就可以解决大部分集群协调问题。
把服务器名、资源名记录到zk里。
通过调用Zookeeper节点创建的API接口就可以创建一个顺序节点,并且在API返回值中会返回这个节点的完整名字,利用此特性,可以生成全局ID,其步骤如下
程序分布式的部署在不同的机器上,将程序的配置信息放在zk的znode下,当有配置发生改变时,也就是znode发生变化时,可以通过改变zk中某个目录节点的内容,利用watcher通知给各个客户端从而更改配置。
Zookeeper的两大特性:
利用其两大特性,可以实现集群机器存活监控系统,若监控系统在/clusterServers
节点上注册一个Watcher监听,那么但凡进行动态添加机器的操作,就会在/clusterServers节点下创建一个临时节点:/clusterServers/[Hostname]
,这样,监控系统就能够实时监测机器的变动情况。
集群需要有一个Master,比如MySQL中需要有一个Master来负责写请求。ZooKeeper的强一致性可以保证这样的Master是唯一的。
集群中的每个节点可以定时在一个命名空间内创建节点,但只有一个客户端能创建成功,此时其成为Master。
分布式锁用于控制分布式系统之间同步访问共享资源的一种方式,可以保证不同系统访问一个或一组资源时的一致性,主要分为排它锁和共享锁。
共享锁又称为读锁,若事务T1对数据对象O1加上共享锁,那么当前事务只能对O1进行读取操作,其他事务也只能对这个数据对象加共享锁,直到该数据对象上的所有共享锁都被释放。
在需要获取共享锁时,所有客户端都会到/shared_lock下面创建一个临时顺序节点,如果是读请求,那么就创建例如/shared_lock/host1-R-00000001的节点,如果是写请求,那么就创建例如/shared_lock/host2-W-00000002的节点。
不同事务可以同时对一个数据对象进行读写操作,而更新操作必须在当前没有任何事务进行读写情况下进行,通过Zookeeper来确定分布式读写顺序,大致分为四步。
其释放锁的流程与独占锁一致。
上述共享锁的实现方案,可以满足一般分布式集群竞争锁的需求,但是如果机器规模扩大会出现一些问题,下面着重分析判断读写顺序的步骤3。
针对如上图所示的情况进行分析
可以看到,host1客户端在移除自己的共享锁后,Zookeeper发送了子节点更变Watcher通知给所有机器,然而除了给host2产生影响外,对其他机器没有任何作用。大量的Watcher通知和子节点列表获取两个操作会重复运行,这样会造成系能鞥影响和网络开销,更为严重的是,如果同一时间有多个节点对应的客户端完成事务或事务中断引起节点小时,Zookeeper服务器就会在短时间内向其他所有客户端发送大量的事件通知,这就是所谓的羊群效应(惊群效应)。
可以有如下改动来避免羊群效应。
/shared_lock/[Hostname]-请求类型-序号
的临时顺序节点。此方案改动主要在于:每个锁竞争者,只需要关注/shared_lock节点下序号比自己小的那个节点是否存在即可。
先进入队列的请求操作先完成后,才会开始处理后面的请求。FIFO队列就类似于全写的共享模型,所有客户端都会到/queue_fifo这个节点下创建一个临时节点,如/queue_fifo/host1-00000001。
创建完节点后,按照如下步骤执行。
最终的合并计算需要基于很多并行计算的子结果来进行,开始时,/queue_barrier节点已经默认存在,并且将结点数据内容赋值为数字n来代表Barrier值,之后,所有客户端都会到/queue_barrier节点下创建一个临时节点,例如/queue_barrier/host1。
创建完节点后,按照如下步骤执行。
ZooKeeper 是分布式的、开源的分布式应用程序协调服务,原本是 Hadoop、HBase 的一个重要组件。它为分布式应用提供一致性服务的软件,包括:配置维护、域名服务、分布式同步、组服务等。
只要是具备 CP(CAP 取 CP)特点的分布式 KV 系统,原则上都可以作为 ZooKeeper 的替代品,但是选择时仍然要考虑设计原理上的差异、落地方案的成熟程度及业务场景实际所需。
ZooKeeper的连接与会话就是客户端通过实例化ZooKeeper对象来实现客户端与服务器创建并保持TCP连接的过程。
配置多个实例共同构成一个集群对外提供服务以达到水平扩展的目的,每个服务器上的数据是相同的,每一个服务器均可以对外提供读和写的服务,这点和 redis 是相同的,即对客户端来讲每个服务器都是平等的。
zookeeper 提供了三种集群选举方式:
默认的算法是 FastLeaderElection,所以这里主要分析它的选举机制。
主要看这个类,只有 LOOKING 状态才会去执行选举算法。每个服务器在启动时都会选择自己做为领导,然后将投票信息发送出去,循环一直到选举出领导为止。
1 | public void run() { |
它是 zookeeper 默认提供的选举算法,核心方法如下。可以与本文上面的流程图对照。
1 | public Vote lookForLeader() throws InterruptedException { |
在投票完成后,需要将投票信息发送给集群中的所有服务器,它包含如下内容。
目前有 5 台服务器,每台服务器均没有数据,它们的编号分别是 1,2,3,4,5,按编号依次启动,它们的选择举过程如下:
描述 Leader 选择过程中的状态变化,这是假设全部实例中均没有数据,假设服务器启动顺序分别为:A,B,C。
不会,ZooKeeper 更倾向于保持一致性,如果配置中的部分服务器不可用,那么整个集群都是不可用的。
最近有点迷 ARPG,但是自己的 T470P 上只有一个 Ubuntu 系统,所以买了一个 2422 的固态往上面装个 Win10,Linux 下构建启动盘还是蛮多坑的,下面记录一下操作流程,免得以后忘了。