转贴请声明引用：
旧架构弊端
配置多，以前是全人工，麻烦
主从机器有改的时候，需要修改建索引配置，同步配置，nginx配置。
大数据切分：
简单切分视频索引：大索引+小索引
大索引太大，放到普通机器上时，搜索性能太慢，所以现在是放到共享内存提高性能，但这样的机器就两台，当并发高的时候，需要更好的cpu，由于搜索计算比较多，并发高的时候，即使现在有16线程cpu也顶不住，容易并发瓶颈，此时应急启用普通机器，由于没有大内存，并不能达到解救的问题，而且放共存内存还有个安全隐患：
索引同步时需要双倍大小的空间，共享内存有限,机器重启后索引会丢失。 数据集中一台机器，计算消耗大，单机cpu不能线性补足，所以需要分布式计算来补足，特别是搜索命中比较多结果的时候，现架构响应很慢。
搜索业务扩展：
需要知道哪些搜索业务布置在哪些机器，需要记录文档，但是服务的变更太多，文档更新也频繁。
升级
solr扩展包布署，需要逐个更替，停止nginx代理–》停止服务–》更换升级包——》重启服务–》启动nginx的代理
新架构解决了什么问题?
新架构引入zookeeper 开源项目
Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统
Zookeeper 从设计模式角度来看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，
一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应，从而实现集群中类似 Master/Slave 管理模式
cloud做到了管理多个jvm 索引 ，配置方便： 大数据切分多片解决性能问题：
视频索引重建只需要1小时（以前3小时左右，不稳定），客户搜索使用的视频完全重建也只需要1个半钟完成（以前5个小时左右，不稳定 ）。
方便之处，建索引程序可以方便布置在集群里机器，当某机器资源紧张时迁移到其它比较闲的机器上，暂时放在内存比较充足的机器上。
同数据源提交给多server，
视频同源过滤提交到另一个collection,过滤掉的视频大概有几百万左右数据，但依然不影响建索引时间。而且还可以提供完整的视频数据搜索，例如在空间，或者开放平台上的视频搜索。
任意结点做更新与搜索：
数据可以提交到该集群里的任意结点，自动转发到目标solrcore更新
任意结点的搜索，结点上发现没有solrcore处理该请求时会抛给远程solrcore来处理，所以nginx上配置的代理 一般不用作变化
持久化更新：
每个更新都会先写入tlog日志，保证更新的持久化。以前写到内存的索引会因为机器挂掉的原因而导致数据丢失，现在有了持久化更新可以考虑做增量的更新，比如删除更新
准实时搜索
删除的更新可以及时可见，将已删除的视频从索引搜索去掉。暂时还没在新架构使用，这个需要测试与调优再上线。
业务变更与升级
扩展包集中管理 ：
与war包分离，升级不重新打包war。暂时由rsync同步第三方包到集群里每一台机器的统一位置，每一个搜索服务可能的扩展包都不一样，所以需要在solrconfig.xml配置取对应的扩展包位置。
这个与以前的作法不同，以前是将扩展的包跟原生的solr打包在一起，这样升级需要停止原来的服务再切换。
热布署：
现在是将实现的扩展包通过rysnc同步到各个机器 ，然后reload 一下solrcore，这个过程是原子操作，可以无缝切换，，一般不需要达到重启服务级别。
solr新版本升级
新起结点替换旧结点，不资源允许的情况下，可以保留两套，主要做升级切换 使用。
建索引框架变更，IndexBridge—->indexing
以前大部分搜索的建索引都是使用IndexBridge，那么为什么 要更换另一个框架呢：
以前所有搜索业务的预处理过滤器都写到IndexBridge框架上，经过这么多年的沉淀，这个框架已经变得很臃肿，特别是因为多人经手后，不同人的代码写法不同，它的维护性变更得更麻烦。
特别是版本的维护变得更难，因为引用的第三方包使用的是ivy管理 ，但如果版本号没更改就提交，所有人看到的都不一样，有时发布的时候发现比最新的版本号还最新，好像大家都没有提交版本的习惯了。
鸟儿爱美，不仅需要羽毛之美，还需要鸣声婉转之美;
