Solr的主从模式Master-Slave
如今，为了提高Solr的搜索速度，使其具有很好的容灾能力，往往会配置SolrCloud，但在Solr4之前，还有一种很流行的方式，Master-Slave模式，为什么要提及这种方式，因为我们公司目前用的就是这种方式。
引入Master-Slave
Solr在查询的时候，特别忌讳进行写操作，因为它是IO阻塞型的。现在的流行的Elasticsearch就对此有很好的改进。在引入Master-Slave以后，将读写分配到不同的服务器上，你可以使用master来做索引，然后使用slaves来做查询。
配置Master-Slave
1.在多台服务器上分别搭建好可以独立运行的Solr，参见这里。
2.指定其中的一台为Master，只需要在SolrConifg.xml中配置：
<requestHandler name=“/replication” class=“solr.ReplicationHandler” >
<lst name=“master”>
<!– 执行commit操作后进行replicate操作同样的设置’startup’, ‘commit’, ‘optimize–>
<str name=“replicateAfter”>commit</str>
<!– 执行startup操作后进行replicate操作–>
<str name=“replicateAfter”>startup</str>
<!– 复制索引时也同步以下配置文件–>
<str name=“confFiles”>schema.xml,stopwords.txt</str>
<!– 验证信息, 由用户自定义用户名–>
<str name=“httpBasicAuthUser”>root</str>
<!– 验证信息, 由用户自定义密码–>
<str name=“httpBasicAuthPassword”>root123</str>
</lst>
</requestHandler>
3.指定其他多有的服务为Slave，只需要分别配置：
<requestHandler name=“/replication” class=“solr.ReplicationHandler” >
<lst name=“slave”>
<!– 主服务器的URL, 对于多核同步配置,一一对应即可–>
<str name=“masterUrl”>http://127.0.0.1:8080/solr/core0</str>
<!– 60秒进行一次同步操作–>
<str name=“pollInterval”>00:00:60</str>
<!– 压缩机制,来传输索引, 可选internal|external, internal内网, external外网–>
<str name=“compression”>internal</str>
<!– 设置超时时间–>
<str name=“httpConnTimeout”>50000</str>
<str name=“httpReadTimeout”>500000</str>
<!– 验证信息, 要与master服务器匹配–>
<str name=“httpBasicAuthUser”>root</str>
<str name=“httpBasicAuthPassword”>root123</str>
</lst>
</requestHandler>
4.重启所有的master-slave服务即可。
SolrCloud与Master-slave主从模式对比
第一印象
SolrCloud是Solr4.0引入的，主要应对与商业场景。它很像master-slave，却能自动化的完成以前需要手动完成的操作。利用ZooKeeper这个工具去监控整个Solr集群，以了解集群间各个机器的工作状态。
配置的区别
从配置来看，SolrCloud和master-slave的主要区别在于是否有ZooKeeper节点。从下面这个配置概念图可知，SolrCloud集群最小的节点数都大于master-slave节点数，当然ZK节点不需要很强大，因为它只是用来监视和维护SolrCloud中的节点状态。
为什么有SolrCloud或者master-slave
- 分片（Sharding）
分片是在多台机器间拆分Solr索引。分片有时候是必须的，因为索引数据可能大到无法容纳在单台服务器上。通过分片，你可以在多台机器上分割索引，并持续增长而不会遇到问题。 - 近实时搜索和增量索引（NRT Search）
master-slave中每台机器上具有相同的索引数据，master负责索引数据，其他slaves负责检索数据。slaves在每隔固定的时间去master上拿新的索引数据。
SolrCloud在每个shard中都有一个leader，其他的replica与leader数据基本相同。leader的额外任务就是分发索引到该shard下的所有replica。发送到SolrCloud中的所有文档都会被路由给leader节点（当replica收到文档时，也就是要更新索引时，它会把该文档添加到事务日志中，然后报告给leader，由leader执行这个任务）。这样的机制可以分布式更新索引，并且是持久化的。 - 分布式查询和负载均衡（Load Balancing）
在master-slave中，查询哪个节点就只会返回该节点的数据。如果想用分布式搜索来查询某一个节点，可能需要外部负载均衡器的支持。
在SolrCloud中，分布式搜索可以自动被管理：查询任意一个节点，都会触发查询请求到其他shard中的某一个节点，只有聚合了所有分片的结果时，响应才返回。ZooKeeper知道所有的节点状态，一旦某个节点的挂了，就会向另一个节点发送查询请求。如果是leader节点挂了，还需要启动投票机制重新选leader。 - 高可用性（High Availability）
**在master-slave中，如果master节点挂了，那么其他节点还是可以继续查询操作的，但是不能索引数据了，除非再手动添加master节点。这样一来，在重启master之前的更新操作会失败。 **
在SolrCloud中，当ZooKeeper发现leader节点挂了，会立即启动投票机制重新选举leader。直到了leader被选出来，所有的更新操作都会记录在事务日志中，在leader选出来后，继续同步工作，确保没有数据丢失。
无论是master-slave还是SolrCloud模式，都可以提供replication机制。但是SolrCloud是自动处理路由和恢复，而master-slave在某个节点没有响应以后，需要一些手动的操作才能恢复。
master-slave配置会简单很多，而SolrCloud需要配置ZooKeeper，为了保证系统能持续不断的工作，还需要给ZooKeeper配置集群，需要额外的资源。
作者：yuhan_sining
链接：https://www.jianshu.com/p/6df7334d36c8
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
