关于本人《CentOS下用Tomcat+Zookeeper+Nginx+Solr完美搭建SolrCloud平台》文中几个问题的答疑

问题一、Tomcat、Zookeeper、Solr、SolrCloud和Nginx的作用以及相互间的关系？

答：

　　Solr是一个功能强大的企业级开源搜索引擎，可以单机使用，也可以集群部署。集群部署时就是SolrCloud。

　　Solr由一个或多个Core组成，每个Core代表一个索引库，里面包含了索引数据和配置信息，就像数据库软件（如MySQL、Oracle、SQL Server）一样可以创建一个或多个数据库，每个数据库存放各自的表结构和数据。

　　SolrCloud由多个Solr节点组成一个分布式的集群搜索引擎服务，用时髦的话说就是云服务。一个SolrCloud集群一般至少要有三个Solr节点，可以根据需要增加节点数量，奇偶数无所谓。但不管有多少个Solr节点，其中有一个节点为主（Master）节点，其余节点为备（Slave）节点。Master节点只有一个，Slave节点可以有多个。Master节点与Slave节点中的配置信息是一致的。

　　Master节点是SolrCloud集群中的领导者（Leader），由它来统筹各个节点的运作。现在问题来了，组建SolrCloud的目的就是为了提高冗灾的高可用性，确保集群中有服务器（或Solr服务）宕机的情况下仍能正常使用Solr搜索服务，那如果Master节点发生故障导致宕机会出现什么情况呢？毫无疑问，没有Leader（Master节点的服务），其余节点就不知道该怎么办了，整个服务也就不正常了。那Master宕机后，SolrCloud会不会自动将其它Slave节点中找一个节点来转变成Master节点呢？答案是，按理SolrCloud应该可以来做这件事，但现在是个开源的世界，开源的项目有很多，SolrCloud的维护开发团队可以直接利用现有的开源项目来实现Slave和Master转化，没必要自己再写一堆代码去实现这个别人已经免费提供组件服务的功能。

　　那如何实现Slave和Master的自动转化呢？对了，Zookeeper（以下简称ZK）。ZK是一个免费的开源分布式应用程序协调服务软件。它在整个SolrCloud集群中起到两个作用：

　　1、选举Leader。SolrCloud集群中的所有Solr由ZK来决定谁是Master，谁是Slave。当Master节点宕机后，由ZK在所有的Slave节点中自动选择一个节点转变为Master节点，使整个SolrCloud正常运行。当原来的Master节点修复回来集群中来时，ZK会告诉这个节点它已经不是Master了，原来的Master节点就变成了Slave节点。

　　2、同步。ZK会自动同步所有Solr节点中的配置信息，以确保Master节点宕机后，Slave节点上的配置信息是正确的最新的。

　　要注意的是：ZK集群要有2n+1个节点，简单的说就是奇数个节点。部署的时候，如果是偶数个节点就会出问题；但如果部署的时候是奇数个，运行中有一个节点出现故障变成偶数个是没有关系的。还有，ZK集群可以单独部署，也可以部署在Solr节点的服务器上，ZK的节点数量不一定要与Solr节点的数量一致。

　　Tomcat是干什么用的呢？这个大家应该都能知道，它是一个Web服务软件，Solr要以网页的形式发布出来，就需要有Web服务软件来支撑。所以理论上你用其它Web服务也是可以发布Solr服务的。

　　Nginx是一个很强大的免费开源高性能Web和反向代理服务软件，说直接点就是个基于网页服务的负载均衡软件。本项目中可用可不用。

问题二：有人问我的这方案中已经用了Zookeeper，Solr集群已经可以进行分布式查询了，为何还要用Nginx呢？

答：

　　Nginx是个免费的负载均衡服务软件，用不用都不影响SolrCloud集群的搭建和使用。

　　如果你只是学习和玩一玩SolrCloud的，或者是开发SolrCloud下应用的，完全可以不用Nginx；但如果你是要将SolrCloud的项目部署在服务器集群上给用户使用，或者要交付给相应的企业进行部署使用的，建议你加上这个Nginx（当然，如果资金充足，建议使用硬件类负载均衡服务器）。

　　为什么要用Nginx呢？

　　在SolrCloud集群中，会有很多个Solr节点，每个Solr节点一般都有一个固定IP，有n个Solr节点，就会有n个IP，IP1、IP2、IP3、.......、IPn。在使用过程中，无论你访问前面的哪个IP，都是可以正常使用整个SolrCloud集群的功能的，如果是开发或者学习时，你知道哪些节点是正常的哪些节点是不正常的，而且你肯定是会去访问正常的节点（或者将不正常的节点修复后再使用）。

　　但在项目交付给客户后，使用者要登录你们开发的系统，一般都会通过一个域名或者一个固定IP（注意，这里写的是一个）来访问。那问题来了，如果你们公布出去的那个IP所在的节点出现故障了会怎么样？使用者肯定是不能正常使用你们的系统了啊，那怎么办呢，总不能把所有节点的IP都公布出去，让使用者一个一个试吧。

　　所以这个时候我们就需要一个解决方案，在所有的Solr节点以外额外增加一个IP（假设为IP0），我们将这个IP0公布出去，让使用者在访问IP0的时候能自动跳转到正在正常运行的Solr节点的IP上，这样就不用担心用户不能访问SolrCloud了。

　　解决方案有两种：

　　一种方案是通过DNS域名解析服务，设置一个域名，并创建n个同名域名分别指向IP1-IPn。这种方案要求要有一个域名并且有域名解析服务器支撑，而且这种方式因为是轮循的，无法跳过故障节点，总会有人被跳转到故障的节点上导致无法访问系统。

　　第二种方案就是增加一个负载均衡服务，负载均衡服务有硬件类的也有软件类的，硬件类的比较稳定，但价格昂贵。所以在我的方案中采用了免费的开源Nginx负载均衡服务软件。Nginx可以设置所有访问某个IP或域名的请求自动跳转到列表中的某个IP，并将结果返回给访问者，同时Nginx会自动记录故障节点的IP，在下一次新的访问请求时自动跳过故障节点的IP。

　　采用Nginx服务，我们假设Nginx服务节点的IP为IP0，我们可以把这个IP0公布出去（或者公布指向这个IP0的域名）。当第一个访问者访问IP0的时候，Nginx会将这个访问请求转给IP1的Solr节点；当第二个访问者访问IP0的时候，Nginx会将这个访问请求转给IP2；以此类推。如果Nginx发现某个IP（假设为IP3）被访问几次后都无法连通，Nginx就会把这个IP3记录下来，后面的所有请求就不会被转IP3，这样就能实现后面的访问都能正常访问到正常运行的Solr节点。

　　同时，因为这个轮跳机制，所有的访问请求就被平均分配到所有的Solr节点上，每个Solr节点的请求数就被平均了，也就实现了均衡负载。不然所有访问者都访问同一个Solr节点的话，这个Solr节点就很容易出现请求压力过大导致运算过大而响应延缓甚至直接宕机，而其余节点闲得无所事事，资源浪费。

问题三：按照该文中一步一步 *** 作后发现，打开http://solr1.jyga.com:9998/solr/是空白页面。

答：

　　本文中的solr1.jyga.com是我自己设置的一个域名，要有域名服务器解析才能正常使用（或者得在自己访问系统用的电脑里修改hosts文件才能正常使用，修改hosts文件方法大家可以百度）。

　　如果你有自己的域名解析服务器，你可以在域名解析服务器里设置一下，也可以修改成你们自己的域名；如果你们没有域名解析服务，那你们可以将solr1.jyga.com改为对应的solr节点的IP地址，然后通过这个IP地址来访问。