Solr

概述
Solr是一个高性能，采用Java5开发，基于Lucene的全文搜索服务器。同时对其进行了扩展，提供了比Lucene更为丰富的查询语言，
同时实现了可配置、可扩展并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文搜索引擎。


工作方式
文档通过Http利用XML 加到一个搜索集合中。
查询该集合也是通过http收到一个XML/JSON响应来实现。
它的主要特性包括：高效、灵活的缓存功能，垂直搜索功能，高亮显示搜索结果，通过索引复制来提高可用性，
提供一套强大Data Schema来定义字段，类型和设置文本分析，提供基于Web的管理界面等。


需求场景
查询和搜索，我们直接查询数据库MySQL。查询数据库主要有一些局限性：
比如多表查询效率低，大文本字段不好建立索引和搜索，复杂的条件查询和搜索功能不够强大，或者说不够简单。
使用Solr的话，就很简单地解决了以上问题。

以上需求，或者说关系型数据库mysql的问题，只是目前的一点理解。
虽说能够使用MySQL和Sorl解决实际中的问题，但毕竟都是中低难度的问题（自认为如此哦）。
非要说深入理解，剖析Solr的好处，MySQL是否“干的过”Solr，真心不懂。
单独搞MySQL，够你研究5年以上，DBA毕竟是个传说。
Solr，想搞懂，也得好多年。

个人同时学习Java服务端、Android、iOS、Web前端，目标是能够解决工作中最常见的问题，并不想要
深入学习有限的几种技术，比如MySQL，达到那种“再难的问题，也可以搞定”的程度。


我对Solr的8点理解
1.定义数据源接口，获得数据。
比如定义MySQL查询语句，把一个表或多个表的数据，导入到Solr中。
这个地方我觉得特别“不公平”，数据都是从别的地方搞过来的。外界的数据如果会变化，意味着，必须处理“数据同步”。
实时性要求不高的情况下，可以每天“全量更新”。要求高的情况下，单条数据的变化，需要“实时更新-单条”。
因此，Solr和Mysql并不是“直接竞争”关系，而是“互补”的关系。
2.把Mysql等数据源的数据，导入到Solr中去。
Solr定义数据，可以理解成一张很大的表，包含了很多字段，比如可以包含mysql中3个表的所有字段。
这样，查询就不存在“多表”的问题。
既然是一张表，建立索引，查询就很快了。
3.自带缓存功能。
Mysql，Solr，Redis等数据源或者有能力获得数据和管理数据的组件，只要需要，就可以提供“缓存”功能。
Solr简化了查询，缓存就更容易了。
4.索引和全文搜索。
Solr底层采用Lucene建立索引，全文索引，这样可以实现更多的“搜索功能”，可以说增强了Mysql的查询。
5.站内搜索的另外一种形式。
百度等搜索引擎，可以为网站提供“站内搜索”功能，他们爬去数据可以是公开的URL的形式。
如果需要和百度等合作，可以申请使用百度的搜索API，将站内数据，更友好，更快速地告诉百度。
而Solr和百度提供的搜索相关接口就基本一样，只不过是处在我们的管理之下。
6.简洁使用的管理界面。
后台有Web界面，导入数据，更新，可以通过可视化的操作来管理，比较方便。
7.功能服务化。
Solr提供的查询等功能，有Java等多种语言的实现。
建立数据结构，导入数据，维护缓存和实时性，最重要的就是“查询”和“搜索”了。
8.最大的“隐患”。
只用Mysql管理数据和查询的时候，我们必须并且只需要保障mysql的“高可用性”。
不能出任何问题，如果只用1个Mysql，意味着我们需要实时监控Mysql是否可用，如果出了问题，我们需要立即修复它。
如果是多台Mysql，我们需要用主从，或者更复杂的主从。

现在用了Solr，意味着，我们很多查询和搜索，优先使用Solr，不再使用Mysql。
这个时候，为了“高可靠性”，我们也必须保障Solr是靠谱的。
单台Solr服务器，可靠性怎么样，我不太清楚。
无论单台Solr是否靠谱，多台Solr更加靠谱，这都意味着
“我们程序中必须可靠的基础服务更多了”。

常见的必须“高可用性”的服务有
a.Mysql
b.Redis
3.Nginx
4.Solr
高可用性的服务越多，意味着我们的程序越复杂。
大部分的公司，都是中小型企业。
大部分的应用，都是为了快速推出，看看是否有效果。
真正需要保障“高可靠性”的项目，是很少的，如果遇到了，是很幸运的。