solr在lucene外边做了一层厚厚的封装，主要是为了简化二次开发，提供了一些成熟的解决方案。
solr和solrCore
solr可以对多个core进行综合管理，并接受请求选择特定的一个或者多个core执行相关任务。下面来回答什么是solr的core。
core从文件结构的角度来看的话，主要包括一份索引（也可能还包括拼写检查的索引）、一堆配置文件。最主要的配置文件是：solrconfig.xml和schema.xml。solrconfig.xml从整体上对core进行了配置，例如索引的存放路径、字段的最大长度（maxFiedlLength）、写锁的超时时间（writeLockTimeout）、锁类型（lockType）、是否压缩索引（useCompoundFile）、内存索引缓冲区大小（ramBufferSizeMB）、合并因子（mergeFactor）、删除策略、自动提交策略、缓存设置等，它好比是一份组装机器人的说明书，里面详细描述了各个部件（handler）的参数。schema.xml主要是对索引的配置，例如分词器、字段名称+索引方法+存储方式+分词方式、唯一标识字段等，它好比是机器人学习的学习方法，机器人主动或被动接受特定数据，按照配置转化成索引，然后通过其部件（handler）展示出来，例如：search、moreLikeThis、spellCheck、factedSearcher等。
core从功能方面来说的话，主要是通过各种handler进行工作，这个在上文中也提及过。solr的功能之多让我想到瑞士军刀，看图：
常见的有：morelikeThis、search、 spellCheck、dataImport等。
然而不同的部件有复杂简易之分，我们常见的searchHandler就比较复杂，他包括多个零件（component）。
多个component进行组合就可以完成特定的工作。（以下代码摘自：SearchHandler.java）
for( SearchComponent c : components ) {
rb.setTimer( subt.sub( c.getName() ) );
c.process(rb);
rb.getTimer().stop();
}
以上文字主要简单白话了solr的core是个什么东西！那么solr怎么控制这些core进行工作呢？
例如我们输入：http://localhost:8080/solr3.5/core1/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on
这个是检索的目的是：检索core1下的所有内容，并返回前10条。
solr通过request获取requestPath，解析出对应的core名称（这里coreName=core1），然后获取core实例（找到相应的机器人）。
然后解析出select指令，明确告诉core是进行检索任务，任务的具体参数通过solrRequestParser进行解析。solrRequestParser可以看出是将url转换成core识别指令的“翻译器”。下面core就可以调用相应的handler执行任务了。
从外往里看，solr可以看成是：
solr Manager -> solr core -> handler -> component
简单说说solr的分布式（version：solr3.5）
当一个索引越来越大，一个服务器放不下了，怎么办？
当一个大索引的单次请求慢得想死，怎么办？
选择分布式吧！他能将索引进行切分放到不同的服务器上（shards），还可以将处理的计算压力进行分摊。他会将各个shard上的结果进行合并，并“完美”的呈现给您！
然而、但是......solr的分布式并不完美。最主要的就是idf的计算问题。这个问题会在单个shard进行打分运算过程中就发生了，如果每个shard在计算过程中实时去其他shards去获取df和文档总数，请求的消耗是不能忍受的。要解决这个问题就得在每个shard中实时保存每个单词的df和文档总数。
简单说说solr的服务发布方式和客户端solrJ
solr部署在服务器上，提供各种服务。服务发布的方式主要是基于http协议的，传输数据格式为xml、json，不同开发语言都可以通过socket编程进行访问。官方的java客户端就是solrJ，他利用HttpClient进行客户端开发。
我曾经毫无理由的怀疑过这种方式——如果我要用标准的webService，然后又不想改动太多源码，是不是还得通过slorJ做个中间桥梁？是不是无缘无故的多了一次http请求？虽然有embedded！感觉就是solr的这层服务接口被http侵入得有点深。深入的研究后续跟进= =。
为什么solr没有multiSearcher？
lucene3.5中的multiSearcher已经过时了，取而代之的是multiReader。
If you are using MultiSearcher over IndexSearchers, please use MultiReader instead; this class does not properly handle certain kinds of queries.
从lucene早起版本开始，或者说是受数据库思想的影响，会将数据按照某一性质进行划分，放到不同的索引里面。理由是便于管理、防止单一索引过大。如果需要同时检索多个索引，自然就用到了multiSearcher。到了solr发现一个core中只能一份索引，于是纠结solr为什么没有multiSearcher？难道solr不担心单一索引过大吗？难道同时检索多个索引就得使用它并不完善的distributedSearch吗？当时这个思想一直影响了我对solr的好感。
现在“改革开发”的思想就是：在业务需求下，不支持对多个索引同时进行检索。当单个索引的检索压力出现效率问题后，再考虑分布式检索，将数据分发到不同的shards上。如果不是单次检索的运算量瓶颈，而是并发量带来的压力，考虑使用负载均衡。这里很类似于mongodb，并发压力大作replSet，单库太大做sharding。