ElasticSearch（以下简称 ES） 作为一个搜索引擎，能存储海量数据并且可以在非常短的时间内查询到应用系统想要的信息，且组件开源，因而使用比较广泛。在项目中使用 ES 时，一般都使用集群模式，而非单机模式，为什么呢？集群模式与单机模式相比，有什么优势呢？简单总结如下。
1. 高可用性
ES 作为一个搜索引擎，我们对它的基本要求就是存储海量数据并且可以在非常短的时间内查询到我们想要的信息。所以第一步我们需要保证的就是 ES 的高可用性。什么是高可用性呢？它通常是指，通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务，我们说系统的可用性是 100%，如果系统在某个时刻宕掉了，比如某个网站在某个时间挂掉了，那么就可以说它临时是不可用的。所以，为了保证 ES 的高可用性，我们就应该尽量减少 ES 的不可用时间。
那么怎样提高 ES 的高可用性呢？这时集群的作用就体现出来了。假如 ES 只放在一台服务器上，即单机运行，假如这台主机突然断网了或者被攻击了，那么整个 ES 的服务就不可用了。但如果改成 ES 集群的话，有一台主机宕机了，还有其他的主机可以支撑，这样就仍然可以保证服务是可用的。
那可能有的小伙伴就会说了，那假如一台主机宕机了，不就无法访问这台主机的数据了吗？那假如我要访问的数据正好存在这台主机上，那不就获取不到了吗？难道其他的主机里面也存了一份一模一样的数据？那这岂不是很浪费吗？
为了解答这个问题，这里就引出了 ES 的信息存储机制了。首先解答上面的问题，一台主机宕机了，这台主机里面存的数据依然是可以被访问到的，因为在其他的主机上也有备份，但备份的时候也不是整台主机备份，是分片备份的，那这里就又引出了一个概念：分片。
分片，英文叫做 Shard，顾名思义，分片就是对数据切分成了多个部分。我们知道 ES 中一个索引（Index）相当于是一个数据库，如存某网站的用户信息，我们就建一个名为 user 的索引。但索引存储的时候并不是整个存一起的，它是被分片存储的，ES 默认会把一个索引分成五个分片，当然这个数字是可以自定义的。分片是数据的容器，数据保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时， ES 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里，所以相当于一份数据被分成了多份并保存在不同的主机上。
那这还是没解决问题啊，如果一台主机挂掉了，那么这个分片里面的数据不就无法访问了吗？别的主机都是存储的其他的分片。其实是可以访问的，因为其他主机存储了这个分片的备份，叫做副本，这里就引出了另外一个概念：副本。
副本，英文叫做 Replica，同样顾名思义，副本就是对原分片的复制，和原分片的内容是一样的，ES 默认会生成一份副本，所以相当于是五个原分片和五个分片副本，相当于一份数据存了两份，并分了十个分片，当然副本的数量也是可以自定义的。这时我们只需要将某个分片的副本存在另外一台主机上，这样当某台主机宕机了，我们依然还可以从另外一台主机的副本中找到对应的数据。所以从外部来看，数据结果是没有任何区别的。
一般来说，ES 会尽量把一个索引的不同分片存储在不同的主机上，分片的副本也尽可能存在不同的主机上，这样可以提高容错率，从而提高高可用性。
假如你只有一台主机，那不就没办法了吗？分片和副本其实是没意义的，一台主机挂掉了，就全挂掉了。
2. 健康状态
针对一个索引，ES 中其实有专门的衡量索引健康状况的标志，分为如下三个等级。
- green。绿色，代表所有的主分片和副本分片都已分配。集群是 100% 可用的。
- yellow。黄色，代表所有的主分片已经分片了，但至少还有一个副本是缺失的。不会有数据丢失，所以搜索结果依然是完整的。不过，你的高可用性在某种程度上被弱化。如果更多的分片消失，你就会丢数据了。所以可把 yellow 想象成一个需要及时调查的警告。
- red。红色，代表至少一个主分片以及它的全部副本都在缺失中。这意味着你在缺少数据，搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。
如果你只有一台主机的话，其实索引的健康状况也是 yellow，因为只有一台主机，没有其他的主机可以放置副本，所以说，这就是一个不健康的状态，因此集群也是十分有必要的。
3. 存储空间
既然是集群，那么存储空间肯定也是联合起来的，假如一台主机的存储空间是固定的，那么集群相对于单机也有更多的存储空间，可存储的数据量也更大。
所以综上所述，项目中使用 ES 时，一般采用集群模式，而非单机模式。
文章参考：