Elasticsearch Replication

Replication

分布式系统的另外一方面就是复制(replication)了. 通过复制我们可以得到2个主要的好处:

  • High Availability (HA高可用性). 如果一个节点挂了,另外一个节点能从它趴下的地方应头顶上,如果一个节点上面持有索引分片,而另一个节点持有该分片的副本,那么我们的数据就有了一个备份.
  • 拥有数据多个副本的另一个好处就是 scalability (可伸缩性). 我们没有理由不通过增加副本来提高搜索能力,而我们只需要简单的增加几个副本或从节点(slave nodes)就能提升我们搜索的吞吐,何乐而不为呢.

一般有两种方式来实现复制: Push Replication(推模式) 和 Pull Replication(拉模式). Elasticsearch 使用的是Push Replication(推模式).

Push Replication

工作起来非常简单, 当你往 [master] 主分片上面索引一个文档,该分片会复制该文档(document)到剩下的所有 [replica] 副本分片中,这些分片也会索引这个文档.

缺点

  • 同一个文档重复索引多次,相比拉模式而言,要传输相对较少的数据(众所周知,Lucene索引速度非常快).
  • You index the same document several times, but we transfer much less data compared to Pull replication (and Lucene is known to index very fast).
  • 这就需要在并发索引的时候进行一些微妙的控制,比如对同一个文档进行非常频繁的索引,在主分片和副本分片上面执行索引操作的时候,你必须保证每次更新是按照正确的顺序,或者通过版本(versioning)来拒绝旧版本的操作,而拉模式就没有这个问题.

优点

  • 一旦文档索引完毕,那么该文档在所有的分片及副本上都是立即可用的. 索引操作会等待直到确认所有的副本也执行了同样的索引操作(注意: 如果需要,你也可以使用异步复制). 这意味着索引的实时性. 然后你只需要 refresh 一下 IndexReader 就能搜索到新的数据了.
  • 这样的架构能让你非常方便的在节点之间进行切换,假如包含主分片(primary shard)的节点挂了,我们能够很快的进行切换,因为其它的分片和主分片都是一模一样的.

Pull Replication

拉模式是一种主从方式(master – slave)(Solr 用的就是这种). 当一个文档在master上面进行索引,并且数据通过commit操作产生了新的段文件(segment),这个时候,从节点(slave)把这些段文件(segments)拉到自己的机器然后再执行相应的刷新操作,并保证lucene能够使用这些新的数据.

缺点

  • 需要在master上面执行commit操作来产生这些段文件(segment),这样slave才能够执行pull操作. 不知道你还记不记得前面说过,lucene的commit的开销是非常大的,如果可能,commit次数越少越好.
  • 数据的传输会有不必要的冗余. 在分布式系统里面,网络通常来说是非常宝贵的资源(如果你跑在EC2上面,那将更加宝贵,$$$) 并且最终要移动的数据会越来越多,举例来说,如果你有2个段文件,里面包含了文档,文档里面的字段都是存储的(stored fields),并且Lucene决定要合并这2个段文件,那么你也必须要传输这部分数据(合并之后的段文件),因为这是一个新的段文件,但是实际上你传输的是一份相同的数据.

这将造成一个这样的局面,所有的slaves确实是在master后面. 也可能是确实没有理由每次都进行commit或者花大量时间来传输一个大的段文件。但是至少意味着你的slave会丢失 high availability,并且不可能当成是一个实时的slave(a real time high available slave). 实时搜索不可能存在,并且(使用拉模式)也不可能有这种1秒的刷新率,然后lucene就能实时搜索.

NEXT: 我们仍然忽略了一个重要的章节,就是保证所有文档的持久化. 

相关推荐