Elasticsearch和MongoDB分片及高可用对比

本文旨在对比Elasticsearch和MongoDB高可用和分片的实现机制。

Elasticsearch

ES天生就是分布式的，那她又是如何做到天生分布式的？

通过ES官方指南我们可以知道：

一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成，它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

当一个节点被选举成为主节点时，它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。任何节点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。

作为用户，我们可以将请求发送到集群中的任何节点，包括主节点。每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

Elasticsearch 是利用分片将数据分发到集群内各处的。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。

一个分片可以是主分片或者副本分片。索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。

我们在创建一个索引的时候，可以定义其主分片数量和副本分片数量：

PUT /blogs

{

   "settings" : {

      "number_of_shards" : 3,

      "number_of_replicas" : 1

   }

}

如果主分片和副本分片都集中在一个节点上，那是没办法做到高可用的。ES的集群监控状态会返回yellow。因此，我们需要启动更多的节点来承载副本分片。

此时，如果再增加一个节点至集群，Node 1 和 Node 2 上各有一个分片被迁移到了新的 Node 3 节点，现在每个节点上都拥有2个分片，而不是之前的3个。

如果NODE1宕机了，ES会选举一个新的主节点，并将R1、R2分片提升为主分片。以此来达到高可用的目的。

现在我们大致知道了ES的高可用和分片的方式，但是几个细节任然需要继续深入：

ES是通过hash(文档ID) % 主分片数来确认分片的位置的，因为ES的主分片数量不可变
主分片在每次文档的写操作执行前，都会确认大多数副本分片处于存活状态。我们可以通过配置参数调整为只要主分片状态 ok 就允许执行写操作或必须要主分片和所有副本分片的状态没问题才允许执行写操作
跨分片查询时，客户端发送一个 search 请求到 Node 3 ， Node 3 会创建一个大小为 from + size 的空优先队列。

Node 3 将查询请求转发到索引的每个主分片或副本分片中。每个分片在本地执行查询并添加结果到大小为 from + size 的本地有序优先队列中。

每个分片返回各自优先队列中所有文档的 ID 和排序值给协调节点，也就是 Node 3 ，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。
Elasticsearch 增加了一个 translog ，或者叫事务日志，在每一次对 Elasticsearch 进行操作时均进行了日志记录。一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了 translog。translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时候，它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。
Elasticsearch使用了类bully的算法来实现选主。对所有可以成为master的节点根据nodeId排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。

如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举。

MongoDB

MongoDB通过复制集(Replica Set)来实现高可用。

复制集提供了数据的冗余备份，并在多个服务器上存储数据副本，提高了数据的可用性，并可以保证数据的安全性。

复制还允许您从硬件故障和服务中断中恢复数据。

主节点负责所有的写操作，从节点同步主节点的数据。仲裁节点不维护数据集，只参与选主过程。

MongoDB是通过oplog来实现复制集间的数据同步。当主节点完成写操作后，从节点会检查自己的local数据上的oplog集合，找出最近一条记录的时间戳。然后查询主节点上的oplog集合，找出大于此时间戳的记录。最后将这些oplog查到到本地集合中并执行oplog中的操作。

MongoDB实例每个两秒就会向其他成员发送一个心跳包来判断其他成员的存活状态。如果复制集的主节点不可用了，那么系统就会触发一次选主。

选主需要时间，在选主的过程中，复制集是没有主节点的，所有的成员都变成只读状态。

MongoDB也是采用Bully算法选主，选主时，有资格成为主节点的副本节点就会向其他节点发起一个选举，希望别的节点选择其作为主节点。若赞成票过半则设置自己为主节点。有反对票时，保持自己为从节点。

复制集中的其他成员在收到选主请求时，会判断发起节点的数据版本是否过低。如过低则投反对票。

MongoDB分片时，需要引入路由服务器（mongos）和配置服务器（config servers）。配置服务器是一个独立的mongod进程，保存集群和分片的元数据，即各分片包含了哪些数据的信息。路由服务器起到一个路由的功能，供程序连接。本身不保存数据，在启动时从配置服务器加载集群信息。

MongoDB通过分片键（Shard Keys）对集合进行划分。每个分片集合只能有一个分片键,分片后分片键不可修改。目前支持两种分片策略，范围分片和hash分片。一旦分片键选择完成，数据就以数据块（chunk）为单位（默认64MB）根据分片键分散到后端1或多个分片上。mongos记录每个块中的数据量，达到某个阈值，就检查是否需要拆分块。如拆分块，mongos更新config server的块元数据,config server诞生新块，修改旧块的范围(拆分点)。

查询时，查询请求不包含shard key，则mongos必须将查询分发到所有的shard，然后合并查询结果返回给客户端。查询请求包含shard key，则直接根据shard key计算出需要查询的chunk，向对应的shard发送查询请求。

插入时，必须包含shard key，mongos根据shard key算出文档应该存储到哪个chunk，然后将写请求发送到chunk所在的shard。更新、删除请求的查询条件必须包含shard key或者_id，如果是包含shard key，则直接路由到指定的chunk，如果只包含_id，则需将请求发送至所有的shard。

参考文献

https://www.elastic.co/guide/en/elasticsearch/guide/master/distributed-cluster.html

https://docs.mongodb.com/manual/core/replica-set-elections/

https://docs.mongodb.com/manual/sharding/