es本身是具备很好的使用特性的，我指的是他的部署方面的，至于后期的使用和运维那还是很一眼难尽的。
我们从这一篇开始就着重于es的一些原理性的的一些探讨，当然我们也会有一些操作性的，业务性的会分为多个栏目来写。比如前面我写的操作实战的一篇，后面还会不断补充的，https://blog.csdn.net/liuwenqiang1314/article/details/135882607?spm=1001.2014.3001.5501

一、部署模式

我们一般有三种部署模式：
1、本地单节点部署：这种一般是我们在开始学习的时候，快速的部署搭建一个节点开始使用，如果你想验证一个什么功能，这种方式是不错的。
2、本地多节点部署集群：这种模式其实就是我们所称的伪集群了，这种集群并不具备分布式的真正特性，当这一个机器挂了，整个集群直接就无了。适合在我们学习分布式理论或者原理的学习，不具备实战特性。
3、多机器部署的集群：这种模式一般是在一个机器上部署一个es节点，然后多台机器的多个节点组成一个集群。这种模式是我们生产实践中常用的，也可以用在ece认证考试中。当然了，实际生产可能机器配置很高，这时候我们为了让资源利用最大化，可以在一个机器上部署一个或者一个以上的节点。这个后面我们说资源预估的时候再说。

二、关于配置

es的启动中，配置文件是一个非常重要的东西，当然了，尤其是我们在启动一个集群的时候，需要配置很多东西。但是他有这么几个概念需要明确一下先。

1、自动发现

我们说es集群的各个节点之间是通过9300端口（默认）来通信的，并且通过这个通信发现彼此的存在，而且他存在自动发现机制，不需要你修改任何配置，节点之间就可以自动发现彼此，从而形成集群。
这个我们就不演示了，因为实际没人这么用，因为你完全依赖自动发现结果就是每次启动端口都不固定，这次是9200下次就是9201我们实际开发中不会这么用的，都是在配置文件中显式的声明。

2、开发模式和生产模式

• 开发模式：开发模式其实就是默认配置，没配置集群发现，如果你只是简单的学习，不需要es的引导检查，因为引导检查巨麻烦，所以es提供了一个设置项，discovery.type=single-node,此项配置为指定节点为单节点来绕过引导检查。
• 生产模式：当用户修改了有关集群的相关配置，就会触发生产模式，生产模式下，服务启动就会触发es的引导检查或者叫做启动检查（bootstrap checks）,这个机制就是在服务启动之前做一些重要的配置项进行检查，检查其配置值是否合理。引导检查包括对jvm大小，内存锁，虚拟内存，最大线程数，集群发现相关配置进行的检查，如果某一项或者几项配置不合理，es会拒绝启动服务，并且在开发模式下属于一些警告的信息在生产模式下会升级为错误信息输出，引导检查及其严格，之所以宁可拒绝启动服务也要阻止用户启动就是为了防止用户在对es基本使用不了解的前提下启动服务而导致的后期性能问题无法解决或者解决起来很棘手，因为一旦服务以某种不合理的配置启动，时间久了之后可能会产生问题，那时候可能已经难以维护，所以这种操作虽然有了门槛，但是避免了以后的问题，算是未雨绸缪了。

3、单节点模式

单节点启动节点会自己选举自己成为active master节点，每个节点都是自己形成一个集群，也会绕过引导检查。

discovery.type:single-node

4、核心配置项

cluster.name:集群名称，节点根据集群名称来确定是否和其他节点属于同一个集群，从而加入对应的集群。
node.name:节点名称，集群内唯一即可。
node.role:节点的角色配置，不同的角色以字符串的数字方式进行配置。
network.host:节点对外提供服务的地址以及集群内通信的地址，就是你对外用api访问都是这个地址，他们内部节点通信也是这个ip,就是端口不同。如果你配置为本地地址(127.0.0.1)，那么当前节点仅会在本地去发现其他节点，另外修改此配置会触发生产模式从而执行引导检查，但是生产环境一般是一个机器一个节点，每个节点都要和其他服务器形成发现，所以这个配置一般是本机内网地址。他们节点之间内网通信。
http.port:对外提供服务的端口号，默认是9200-9299,单节点默认9200，多个节点要是在一台机器，他们就在9200-9299中获得，一般一百个端口够了，没人会在一个机器部署超过一百个节点。
transport.port:节点之间的通讯端口，默认是9300-9399，节点之间tcp通信的，也是一百个，原理同上。
discovery.seed_hosts:集群初始化的种子节点，可配置部分或者全部节点，大型集群可以通过嗅探机制发现其余没配置的节点，如果你去参加认证考试，我建议配全部，因为保险。
cluster.initial_master_nodes:节点初始active master节点，必须是有master角色的节点，他们是用来初始化投票master用的，也就是必须是候选节点，但是不是必须配置所有候选节点，配置一两个差不多了，一个宕机了还有一个备用，他们也能发现，生产模式下启动新集群的时候，必须明确列出在第一次选举中计算其选票的候选节点，第一次成功启动形成集群之后，cluster.initial_master_nodes从每个节点中的配置中，删除配置，后续你重启集群或者向集群添加新节点的时候，就不用配了。他已经存在于集群元数据中了，除非你删了data文件夹，那你就需要重配置了。

5、我的配置

后面我所有的操作都是在一个集群下的操作，我列出我的三个节点的配置。
节点1配置

cluster.name: levi-cluster
node.name: node1
network.host: 127.0.0.1
http.port: 9201
discovery.seed_hosts: ["127.0.0.1"]
cluster.initial_master_nodes: ["node1","node2","node3"]
xpack.security.http.ssl.enabled: false
xpack.security.enabled: false
xpack.security.transport.ssl.enabled: false

节点2配置

cluster.name: levi-cluster
node.name: node2
network.host: 127.0.0.1
http.port: 9202
discovery.seed_hosts: ["127.0.0.1"]
cluster.initial_master_nodes: ["node1","node2","node3"]
xpack.security.http.ssl.enabled: false
xpack.security.enabled: false
xpack.security.transport.ssl.enabled: false

节点3配置

cluster.name: levi-cluster
node.name: node3
network.host: 127.0.0.1
http.port: 9203
discovery.seed_hosts: ["127.0.0.1"]
cluster.initial_master_nodes: ["node1","node2","node3"]
xpack.security.http.ssl.enabled: false
xpack.security.enabled: false
xpack.security.transport.ssl.enabled: false

然后启动集群就可以了，你可以看到我其实啥也没咋改就是简单改了几个启动发现的配置和地址ip，端口。并且我们目前不涉及对于权限的认证，所以我把8.0默认开启的xpack的权限管理的都配置为false了。
而且我是在本地机器开了三个不同端口的节点，因为我机器资源比较大所以就这么整了，你也可以使用多台机器或者多个虚拟机都可以。

然后我们启动Kibana来链接上集群，我们使用GET _cat/nodes?v来看下启动是不是成功了。

我们可以看到他已经启动成功了。

三、关于主从模式(leader/follower)

首先es使用的就是主从模式架构，其实分布式集群还有一种叫做分布式哈希表模式（DHT），其区别在于：

• 主从模式适合节点数量不多，并且节点的状态改变（节点加入和离开）不频繁的场景。
• 分布式哈希表支持每小时数千个节点的加入和离开。响应大约在4-10跳。
  es使用的场景中一般不会一个集群有太多节点，一般不建议超过一千个，节点的数量远远小于主节点所能维护的连接数，并且也一般不经常有节点加入和离开，处于相对稳点的网络中，所以它选择了主从模式。

四、总结

我们这里对于一些简单的预备原理做了描述，对于你启动的一些建议做了解释。但是你也会看到很多概念没提，比如节点角色咋配，密码权限我也都注释了，其他的一些概念都没说，这个不急，我们先把环境搭建起来，后面关于操作，关于原理和源码都会慢慢展开。