分布式系统的另外一方面就是复制(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: 我们仍然忽略了一个重要的章节，就是保证所有文档的持久化.