ElasticSearch核心之——分布式特性

ES支持集群模式，是一个分布式系统，其好处主要有两个∶

es集群由多个ES 实例组成。不同集群通过集群名字来区分，可通过 clustername 进行修改，默认为elasticsearch。每个ES实例本质上是一个 JVM 进程，且有自己的名字，通过 nodename 进行修改

ES集群相关的数据称为 cluster state ，主要记录如下信息∶节点信息，比如节点名称、连接地址等；索引信息，比如索引名称、配置等

可以修改 cluster state 的节点称为master节点，一个集群只能有一个 cluster state 存储在每个节点上，master维护最新版本并同步给其他节点

master节点是通过集群中所有节点选举产生的，可以被选举的节点称为 master-eligible 节点 ，相关配置如下: nodemaster: true

处理请求的节点即为coordinating节点，该节点为所有节点的默认角色，不能取消。路由请求到正确的节点处理，比如创建索引的请求到master节点

存储数据的节点即为data节点，默认节点都是data类型，相关配置如下∶ nodedata: true

谈及副本和分片两个概念之前，我们先说一下这两个概念存在的意义： 解决系统可用性和增大系统容量

我们想象这样一个场景，我们的数据只存放在一台ES服务器上，那么一旦这台ES出现宕机或者其他不可控因素影响的话，我们除了丧失了服务的可用性外，可能还存在着数据丢失的可能。同时，单机服务的存储容量也无法应对项目对大数据量的要求。

系统可用性可以分为 服务可用性 和 数据可用性

服务可用性 含义为：当前服务挂掉后，是否有其他服务器顶替当前节点提供服务支持。

数据可用性 含义为：当前服务挂掉后，存储在当前服务器上的数据，是否还可以对外提供访问和修改的服务。

副本可以理解为是某个数据的复制体，副本和源数据内容一致。副本的存在可以有效地满足系统可用性的需求，比如说，我们可以在原有节点的基础上复制一个和源节点一模一样的节点，这样一旦原有节点挂掉了，另外一个节点也还是可以替代源节点提供服务，而且复制出来的节点拥有和源节点一样的数据，这样也保障了数据可用性。

我们在上一小节讲到可以使用副本来解决系统可用性的问题，但是这里存在一个问题，不管存在多少个副本（节点），都无法增大源节点的存储空间。在这个问题上，ES引入了Shard分片这个概念来解决问题。

看完分片的特点后可能还有人不太清楚到底什么是分片，其实分片是n/1个源节点数据。比如说原ES集群中只有一个主节点，所有的索引数据都存储在这个节点上。现在我们将某个索引数据分成3份，分别存放在3个ES节点上，那么每台ES服务器上就各自有1个分片shard。该索引的所有节点Shard分片的集合，就是索引的全部数据。

下面我们来演示一下：

为了更好的了解ES的分片机制，大家不妨在上面的案例上进一步思考两个问题：

答案是不能。原因是我们创建索引时定义的分片数量只有3个，且都已经落在了3个节点上。所以即使再增加多一个节点，也不会有对应的Shard分片可以落在新的节点上，并不能扩大 test_shard_index 的数据容量。

答案是不能。因为新增的副本也是分布在这3个节点上，还是利用了同样的资源。如果要增加吞吐量，还需要新增节点。

通过上面两个问题，相信大家已经可以认识到分片的重要性，分片数过小，会导致后续无法通过增加节点实现水平扩容；（副本）分片数过大会导致一个节点上分布过多分片，造成资源浪费，同时会影响查询性能

集群健康状况，包括以下三种: green健康状态，指所有主副分片都正常分配； yellow指所有主分片都正常分配，但是有副本分片未正常分配； red表示有主分片未分配

我们可以通过这个api查看集群的状态信息： GET _cluster/health

我们也可以通过cerebro或者head插件来直接获取当前集群的状态

需要注意的是，即使当前集群的状态为 red ，也并不代表当前的ES丧失了提供服务的能力。只是说未被分配主分片的索引无法正常存储和操作而已。

这里故障转移的意思是，当ES集群出现某个或者多个节点宕机的情况，ES实现服务可用性的应对策略。

这里我们新建一个分片为3，副本为1的索引，分片分别分布在三个节点，此时集群为 green

当master节点所在机器宕机导致服务终止，此时集群会如何处理呢

我们可以看到，从node1主节点宕机到ES恢复集群可用性的过程中，ES有着自己的故障转移机制，保障了集群的高可用性。我们也可以在自己的本地上去进行试验，建好索引后，kill掉主节点，观察集群状态就行。

同时，此时就算node2宕机了，那么node3也能够很快的恢复服务的提供能力。

我们知道，我们创建的文档最终会存储在分片上，那么在分布式集群的基础上，ES集群是怎么判断当前该文档最终应该落在哪一个分片上呢？

很显然，我们需要一个可以实现文档均匀分布到各个分片上的映射算法，那么常见的随机算法和round-robin（轮询）算法可以满足需要吗？答案是不可以，这两个算法虽然可以实现文档均匀分布分片的存储需要，但是当我们通过 DocumentId 查询文档时，ES并不能知道这个文档ID到底存储在了哪个节点的分片上，所以只能够从所有分片上检索，时间长。如果我们为这个问题建立一个文档和分片映射关系的表，虽然确实可以快速定位到文档对应的存储分片，但是当文档的数据量很大的时候，那么检索的效率也会随之变低。

对于上面这个问题，ES提供的解决方法是 建立文档到分片的映射算法

es 通过如下的公式计算文档对应的分片：

hash算法 保证可以将数据均匀地分散在分片中

routing 是一个关键参数，默认是文档id，也可以自行指定

number_of_primary_shards 是主分片数

我们可以看到，该算法与主分片数相关， 这也是分片数一旦确定后便不能更改的原因

我们已经知道了ES是如何将文档映射到分片上去了，下面我们就来详细讲解一下文档创建、读取的流程。

脑裂问题，英文为 split-brain ，是分布式系统中的经典网络问题，如下图所示:

3个节点组成的集群，突然node1的网络和其他两个节点中断

解决方案为 仅在可选举master-eligible节点数大于等于quorum时才可以进行master选举

在讲文档搜索实时性之前，先讲一下倒排索引的不可变更特性。由于倒排索引一旦生成，不可变更的特定，使得其有着以下3点好处：

下面，将针对Lucene实现文档实时性搜索的几个动作进行讲解，分析其是如何在新增文档后实现ES的搜索实时性的。

我们从上面的描述中知道，当我们新增了一个文档后会新增一个倒排索引文件 segment ，但是 segment 写入磁盘的时间依然比较耗时（难以实现实时性），所以ES借助文件系统缓存的特性， 先将 segment 在缓存中创建并开放查询来进一步提升实时性 ，该过程在es中被称为refresh。

在refresh之前文档会先存储在一个buffer中，refresh时将 buffer中的所有文档清空并生成 segment

es默认每1秒执行一次refresh，因此文档的实时性被提高到1秒 ，这也是es被称为近实时(Near Real Time)的原因

reflush虽然通过 将文档存放在缓存中 的方式实现了秒级别的实时性，但是如果在内存中的segment还没有写入磁盘前发生了宕机，那么其中的文档就无法恢复了，如何解决这个问题呢

ES 引入 translog 机制。写入文档到 buffer 时，同时将该操作写入 translog 中。

translog文件会即时写入磁盘(fsync)，在ES 6x中，默认每个请求都会落盘，我们也可以修改为每5秒写一次，这样风险便是丢失5秒内的数据，相关配置为indextranslog。同时ES每次启动时会检查translog 文件，并从中恢复数据。

flush 负责将内存中的segment写入磁盘，主要做如下的工作:

Reflush和Flush执行的时机

ES的做法是 首先删除文档，然后再创建新文档

我们上面提到，新增文档是通过新建segment来解决，删除文档是通过维护del文件来进行的，假如现在我们设置的 reflush 时间间隔为1秒，那么一小时单个ES索引就会生成3600个segment，一天下来乃至一个月下来会产生的segment文件数量更是不可想象。为了解决Segment过多可能引起的性能下降问题，ES中采用了Segment Merging（即segment合并）的方法来减少segment的数量。

执行合并操作的方式有两种，一种是ES定时在后台进行 Segment Merging 操作，还有一种是我们手动执行 force_merge_api 命令来实现合并操作。

一、NodeJS介绍：

NodeJS是一个让开发者可以快速创建网络应用的服务器端JavaScript平台，同时运用JavaScript进行前端与后端编程，开发者可以更专注于系统的设计以及保持其一致性。

在这篇文章中，我们将向您介绍如何在Ubuntu1404服务器上开始您的NodeJS神奇之旅。

二、如何安装发行稳定版的NodeJS

Ubuntu 1404为了保证跨平台服务体验的一致性，在它的仓库中默认包含了一个版本为01025的NodeJS，这个可能不是最新版本，但是却一定是标准发行版本。

要想获取这个版本的NodeJS，我们只要通过apt包管理工具来安装就可以。在安装之前，最好先更新一下apt包管理工具的本地索引，然后再从Ubuntu仓库中安装NodeJS。

sudo apt-get update

sudo apt-get install nodejs

如果Ubuntu软件仓库中的包正好是你所需要的，那么上述步骤就是在Ubuntu1004下安装NodeJS的全部操作过程。大多数情况下，我们还希望也安装一份NodeJS的包管理工具：npm，您可以通过以下命令安装：

sudo apt-get install npm

NPM将让使得安装NodeJS的模块或者源码包变得非常简单。

在您运行NodeJS的时候请一定要注意，因为与别的工具包相冲突的原因，Ubuntu仓库中可执行的名字是nodejs而不是node。

下面，我们将讨论NodeJS更多种灵活的安装方式。

三、如何通过PPA来安装NodeJS？

一个让你可以保持获得NodeJS最新版本的替代方案是加入由NodeSource维护的PPA（Personal Package Archive）私有包档案。这个方式可以让你获得比Ubuntu仓库更多的NodeJS版本。

首先：你得安装PPA以获得访问它内容的权限。

curl -sL https://debnodesourcecom/setup | sudo bash -

通过上面的命令，PPA将加入到您的系统配置中，并且自动的更新您的本地包缓存，安装完成之后，您可以像之前一样通过apt-get来安装NodeJS。

solo apt-get install nodejs

这里的nodejs安装包包含了nodejs二进制执行文件以及npm可执行文件，所以您无须另外安装npm，然而，为了使一些NPM包能正常工作（比如那些需要多源代码编译的包），你还需要安装build-essentials包。

sudo apt-get install build-essential

四、如何使用NVM来安装？

还有一种使用apt来安装NodeJS的替代方案是使用一个特别设计的工具叫NVM，它的标准叫法是NodeJS版本管理工具（Nodejs Version manager）。

使用NVM，您可以安装多个可方便控制的独立NodeJS环境，它将给您最新版本NodeJS的请求权限，但也将允许你根据APP的需要而使用旧版本的NodeJS。

在开始之前，我们需要从Ubuntu仓库中先安装一些依赖包，NVM将利用这些工具来编译需要的组件：

sudo apt-get update

sudo apt-get install build-essential libssl-dev

一旦这些依赖包安装完成，您可以通过NVM的GitHub项目主页将安装脚本下载下来。版本号可能不尽相同，但是正常来说你可以通过以下方式来下载和安装：

curl https://rawgithubusercontentcom/creationix/nvm/v0161/installsh | sh

上面的命令将下载并且运行安装脚本，安装脚本将把软件安装到你home目录的~/nvm目录下，同时也会在~/profile加入必要的配置。

为了使~/profile的配置生效，您可能需要退出并重新登录您的账户，当然，也可以通过source命令来重新导入~/profile的配置：

source ~/profile

现在你已经安装了NVM，你可以安装NodeJS的各个独立版本。为了找出当前的NodeJS可安装版本，你可以敲入以下命令：

nvm ls-remote

回车可能会显示如下内容：

v0116

v0117

v0118

v0119

v01110

v01111

v01112

v01113

如你所见，当前NodeJS的最新可安装版本是v01113，你可以通过如下命令安装这个版本的程序：

nvm install 01113

通常情况下，NVM会自动切换到最新安装的版本，你可以通过以下命令告诉NVM指定使用已经安装的版本：

nvm use 01113

当你使用NVM安装NodeJS，它的可执行名称是node，通过以下信不信你可以知道当前所使用的NodeJS版本：

node -v

显示：

v01113

如果你安装了多个版本的NodeJS，你可以通过以下命令列出已安装版本：

nvm ls

如果你想把其中一个版本设置为默认的版本，你可以这样：

nvm alias default 01113

现在当一个请求发生时，01113这个版本将自动被选择，您也可以通过这样的别名引用它：

nvm use default

每个版本都将保持其独立的模块和包，并且通过独立的NPM来管理它们，你可以使用NPM的普通模式来为NodeJS项目安装独立的第三方包，它将安装到NodeJS的/node_modules目录下：

npm install express

如果你想将第三方包安装成全局模式（将与其它使用同一个版本NodeJS的项目共用），那么通过使用-g参数就可以实现：

npm install -g express

这个时候包将安装到下面这个目录：

~/nvm/node_version/lib/node_modules/package_name

全局模式安装的包将只允许你在命令行下使用，如果你想在在本地项目中使用，你还需要将它连接进来：

npm link express

如果需要帮助，你可以通过以入命令获取帮助：

npm help

目前网上已有 pm2-zabbix 工具可以实现Zabbix对Node/greatcare/pm2-zabbixgit 3Zabbix Web管理后台导入模板文件 pm2-zabbix/install/zabbix-server/pm2-zabbixtemplatexml 4Nodejs服务器添加服务，根据服务器操作系统版本选择，并修改服务运行用户和使用PM2启动的Nodejs用户一致 RHEL/CentOS 7系列： cp pm2-zabbix/install/init/systemd/pm2-zabbixservice /usr/lib/systemd/system/ 修改目标文件 pm2-zabbixservice 文件内容 User项： User=root RHEL/CentOS 6或5系列： cp pm2-zabbix/install/init/sysv/pm2-zabbix /etc/initd/ 修改目标文件 pm2-zabbix 文件内容 DAEMON_USER项： DAEMON_USER=root 5新建软连接，根据自己服务器修改软连接指向的真实文件路径 mkdir -p /etc/zabbix ln -s /App/zabbix/etc/zabbix_agentdconf /etc/zabbix/zabbix_agentdconf ln -s /App/zabbix/bin/zabbix_sender /usr/bin/zabbix_sender ln -s `which node` /usr/bin/node ln -s `which pm2-zabbix` /usr/local/bin/pm2-zabbix 6启动 pm2-zabbix 服务 RHEL/CentOS 7系列： systemctl start pm2-zabbix RHEL/CentOS 6或5系列： service start pm2-zabbix 7修改Zabbix Agent配置文件 zabbix_agentdconf,添加包含其它配置 Include=/App/zabbix/etc/zabbix_agentdconfd/conf 8拷贝Zabbix Agent配置 cp pm2-zabbix/install/zabbix-agent/pm2-zabbixconf /App/zabbix/etc/zabbix_agentdconfd/pm2conf 9修改配置 pm2conf 内容 sudo -u 用户和第4步一致，同事修改 pm2-zabbix 路径 UserParameter=pm2processes,sudo -u root /usr/local/bin/pm2-zabbix --discover 10服务器终端执行程序 visudo 添加sudo配置 zabbix ALL=(ALL:ALL) NOPASSWD: /usr/local/bin/pm2-zabbix Defaults:zabbix !requiretty 11重启Nodejs服务器Zabbix Agent服务 /etc/initd/zabbix_agentd restart 12Zabbix Web管理后台设置Nodejs服务器添加链接 Template App PM2 模板 PM2守护进程CPU使用率 PM2守护进程内存占用 PM2管理的Node进程实例CPU使用率 PM2管理的Node进程实例内存占用 以上所述是小编给大家介绍的Zabbix添加Nodejs监控的方法，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对脚本之家网站的支持！

NLB群集可以支持WEB、FTP、***、ISA。那么我们今天就简单做一下基于WEB服务的NLB群集两个节点的实验。NLB群集可以保证web服务的高可用性，windows server 2008操作系统可以支持32个NLB节点。所有节点都在同时提供服务，所以，当其中一台服务器宕机的时候，其他节点服务器依然在提供服务，因此，NLB服务可以保证高可用性。

实验环境：

如上图所示：左边的服务器，我们更改计算机名为：NODE-1、右边服务器的计算机名为NODE-2，NODE-1的ip地址为：19216811，NODE-2的ip地址为：19216812。每台服务器都配置为一块网卡，一个群集ip：1921681254供外网用户访问

实验步骤：

首先，我们搭建NLB群集的环境，所以，我们应该先在两台服务器上安装NLB群集服务。在NODE-1上：

在NODE-2上重复上述步骤。

以上步骤，我们将两个节点的计算机群集环境都安装成功，下面，我们在群集上安装web服务，在node1上：

添加必需的功能

在node-2上，重复上述操作即可，web安装ok，为了验证群集实验是否是连续提供服务，我们还需要在node-1和node-2上创建不同的站点（为了验证实验结果）。此步骤略。。。

到这里，我们群集环境和安装的web服务都已经ok了，下面，就需要我们进行配置群集服务了，以保证群集的高可用性和可靠性。

在NODE-1上：创建新群集

下一步，设置优先级别

下一步，设置群集ip;1921681254

下一步，由于我们群集节点只添加了一块网卡，所以，我们选择“多播”。（原因，在博客里有相应的文章，请仔细阅读。）

删除“端口规则”

下一步，等待群集“已聚合”

Ok，我们已经完成了一个节点的配置，下面我们仍然在NODE-1上添加NODE-2群集

在NODE-1上：选择“添加主机到群集”

通过NODE-2的网卡ip地址连接到NODE-2上：

下一步，设置优先级别：

删除端口规则

两个节点主机全部聚合，此刻，NLB群集配置我们都已经完成了。下面我们进行测试，在client主机的IE输入群集ip进行访问，客户端client的ip地址是1921681100，首先在客户端client上ping群集的ip：1921681254

根据上图所示，客户机client和群集ip是通信的。然后我们再通过http://1921681254来访问web

默认情况下，node-1在提供服务，当我们将node-1模拟宕机后，我们再进行测试

Ok，测试已成功！！！