SolrCloud使用教程、原理介绍发布于2013 年 8 月 24 日，属于搜索分类，7,446 浏览数SolrCloud 是基于 Solr 和 Zookeeper 的分布式搜索方案，是正在开发中的 Solr4.0 的核心组件之一，它的主要思想是使用 Zookeeper 作为集群的配置信息中心。
它有几个特色功能：①集中式的配置信息②自动容错③近实时搜索④查询时自动负载均衡。
下面看看 wiki 的文档：1、SolrCloudSolrCloud 是指 Solr 中一套新的潜在的分发能力。
这种能力能够通过参数让你建立起一个高可用、容错的 Solr 服务集群。
当你需要大规模，容错，分布式索引和检索能力时使用SolrCloud(solr 云)。
看看下面“启动”部分内容，快速的学会怎样启动一个集群。
后面有 3 个快速简单的例子，它们展现怎样启动一个逐步越来越复杂的集群。
检出例子之后，需要翻阅后面的部分了解更加细节的信息。
2、关于 SolrCores 和 Collections 的一点儿东西对于单独运行的 Solr 实例，它有个东西叫 SolrCore(Solr.xml 中配置的),它是本质上独立的索引块。
如果你打算多个索引块，你就创建多个 SolrCores。
当同时部署SolrCloud 的时，独立的索引块可以跨越多个 Solr 实例。
这意味着一个单独的索引块能由不同服务器设备上多个 SolrCore 的索引块组成。
我们把组成一个逻辑索引块的所有 SolrCores 叫做一个独立索引块儿(collection)。
一个独立索引块是本质上一个独立的跨越多个 SolrCore 索引块的索引块，同时索引块尽可能随着多余的设备进行缩放。
如果你想把你的两个 SolrCore Solr 建立成 SolrCloud,你将有 2 个独立索引块，每个有多个独立里的 SolrCores 组成。
3、启动下载 Solr4-Beta 或更高版本。
如果你还没了解，通过简单的Solr 指南让自己熟悉Solr。
注意：在通过指南了解云特点前，重设所有的配置和移除指南的文档.复制带有预先存在的 Solr 索引的例子目录将导致文档计数关闭Solr 内嵌使用了Zookeeper 作为集群配置和协调运作的仓储。
协调考虑作为一个包含所有 Solr 服务信息的分布式文件系统。
如果你想用一个其他的而不是 8983 作为 Solr 端口，去看下面’ Parameter Reference’部分下的关于solr.xml 注解例 A:简单的 2 个 shard 集群这个例子简单的创建了一个代表一个独立索引块的两个不同的 shards 的两个 solr 服务组成的集群。
从我们将需要两个 solr 服务器，简单的复制例子目录副本作为第二个服务器时，要确保没有任何索引存在。
1 2 rm -r example/solr/collection1/data/*cp -r example example2下面的命令启动了一个 solr 服务同时引导了一个新的 solr 集群1 2 3 cd examplejava -Dbootstrap_confdir=./solr/collection1/conf-Dcollection.configName=myconf -DzkRun -DnumShards=2 -jar start.jar •-DzkRun 该参数将促使一个内嵌的 zookeeper 服务作为 Solr 服务的部分运行起来。
•-Dbootstrap_confdir=./solr/collection1/conf 当我们还没有 zookeeper 配置时，这个参数导致本地路径./solr/conf 作为“myconf”配置被加载.“myconf”来自下面的“collection.configName”参数定义。
•-Dcollection.configName=myconf 设置用于新集合的配置名。
省略这个参数将导致配置名字为默认的“configuration1”•-DnumShards=2 我们打算将索引分割到逻辑分区的个数。
浏览 http://localhost:8983/solr/#/~cloud 地址，看看集群的状态。
你从 zookeeper 浏览程序能看到 Solr 配置文件被加载成”myconf”，同时一个新的叫做”collection1”的文档集合被创建.collection1 下是碎片列表，这些碎片组成了那完整的集合。
现在我们想要启动我们的第二个服务器;因为我们没明确设置碎片 id ，它将自动被设置成shard2，启动第二个服务器，指向集群1 2 cd example2java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar•-Djetty.port=7574 只是一种用于让 Jetty servlet 容器使用不同端口的方法•-DzkHost=localhost:9983 指向全体包含集群状态的 Zookeeper 服务.这个例子中，我们运行的是一个内嵌在第一个 solr 服务器中的独立的 Zookeeper 服务.默认情况下，一个内嵌的Zookeeper 服务运行在 9983 端口上。
如果你刷新浏览器，你现在在 collection1 下应该看到两个shard1 和 shard2。
接下来，索引一些文档。
如果你想要快速完成一些，像 java 你能够使用 CloudSolrServer solrj 的实现和简单的用 Zookeeper 地址初始化它就可以了.或者也可以随便选择某个 solr 实例添加文档，这些文档自动的被导向属于他们的地方。
1 2 3 4 cd exampledocsjava -Durl=http://localhost:8983/solr/collection1/update-jar post.jar ipod_video.xmljava -Durl=http://localhost:8983/solr/collection1/update-jar post.jar monitor.xmljava -Durl=http://localhost:8983/solr/collection1/update-jar post.jar mem.xml现在，发起一个获得覆盖整个集合的分布式搜索服务搜索到的任何一个服务的结果的请求：1 http://localhost:8983/solr/collection1/select?q=*:*如果在任一个点你希望重新加载或尝试不同的配置,你能通过关闭服务器后简单的删除solr/zoo_data 目录方式删除所有 zookeeper 的云状态。
例 B：简单的支持副本的两个碎片集群有先前的例子，这个例子通过再创建 shard1 和 shard2 副本很容易创建起来。
额外的 shard 副本用于高可用性和容错性，或用于提高集群的检索能能力。
首先，通过前一个例子，我们已经有两个碎片和一些文档索引在里面了。
然后简单的复制那两个服务:1 2 cp-r example exampleB cp-r example2 example2B然后在不同的端口下启动这两个新的服务，每个都在各自的视窗下执行1 2 3 4 cd exampleBjava -Djetty.port=8900 -DzkHost=localhost:9983 -jar start.jar cd example2Bjava -Djetty.port=7500 -DzkHost=localhost:9983 -jar start.jar刷新 zookeeper 浏览页面，核实 4 个 solr 节点已经启动，并且每个 shard 有两个副本，因为我们已经告诉 Solr 我们想要 2 个逻辑碎片，启动的实例 3 和 4 自动的被负值为两个 shards 的副本。
现在，向任何一个服务器发送请求来查询这个集群1 http://localhost:7500/solr/collection1/select?q=*:*多次发送这个请求，来研究 solr 服务的日志。
你应该能够发现 Solr 实现跨副本的负载均衡请求，用不同的服务满足每一个请求。
浏览器发送请求的服务器里有一个顶层请求的日志描述，也会有被合并起来生成完成响应的子请求的日志描述。
为了证明故障切换的可用性，在任何一个服务器（除了运行 Zookeeper 的服务器）运行窗口下按下CTRL-C。
一旦那个服务实例停止运行，就向剩余运行的服务器的任何一个发送另一个查询请求，你应该仍然看到完整的结果。
SolrCloud 能够持续提供完整查询服务直到最后一个维护每一个碎片的服务器当机.你能通过明确地关闭各个实例和查询结果来证明这种高可用性。
如果你关掉维护某一个碎片的所有服务器，请求其他服务器时将会返回 503 错误结果。
要想从依然运行的碎片服务中返回可用的正确文档，需要添加shards.tolerant=true 查询参数。
SolrCloud 用多主服务+监控者服务实现。
这意味着某写节点或副本扮演一种特殊角色。
你不需要担忧你关掉的是主服务或是集群监控，如果你关掉它们中的一个，故障切换功能将自动选出新的主服务或新的监控服务，新的服务将无缝接管各自的工作。
任何 Solr 实例都能被升级为这些角色中的某个角色。
例 C：支持副本和完整 zookeeper 服务的两个碎片集群例 B 的问题是可以有足够多的服务器保证任何一个损坏的服务器的信息幸存下来，但确只有一个包含集群状态的 zookeeper 服务器。
如果那台 zookeeper 服务器损坏，分布式查询将仍然工作在上次zookeeper 保存的集群状态下，可能没有机会改变集群的状态了。
在 a zookeeper ensemble(zookeeper 集群)中运行多个 zookeeper 服务器保证 zookeeper 服务的高可用性。
每个 zookeeper 服务器需要知道集群中其他服务器，且这些服务器中的一个主服务器需要提供服务。
例如： 3 台组成的 zookeeper 集群允许任一个故障，而后通过剩余 2 个协商一个主服务继续提供服务。
5 台的需要允许一次 2 个服务器故障。
对于用于生产服务时，推荐运行一个额外的 zookeeper 集群而不是运行内嵌在 Solr 里面的zookeeper服务。
在这里你能阅读更多关于建立 zookeeper 集群的知识。
对于这个例子，为了简单点我们将用内嵌的 zookeeper 服务。
首先停止 4 个服务器并清理 zookeeper 数据1 rm-r example*/solr/zoo_data我们将分别在 8983，7574，8900，7500 端口运行服务。