使用成熟（不成熟的可能会违背下面的一些话）的开源工具时，就怕你想不到，不怕工具做不到。你能想到的功能那些大牛肯定也想到了，否则你也是大牛。 所以你需要做的就是熟读它的API，遇到问题就找API，但是有时候API不会那么清楚明了的描述你所需要的功能，所以你又要做的就是去猜，猜你的需求可 以如何做，再去对应到API里的内容，如果一段时间内没有找到，并不说明工具没有提供该功能，可能是你猜的方向不对，所以你还要做的就是理清方向，重新去 猜，这时候往往就能猜到结果并且找到工具对应的解决方法。下面举个例子（我实际碰到的）： 对solr（不了解的可以到网上查资料，资料甚多） 研究的时间也有2个多月了，从搭环境自己搞搞，到研究各种查询语法，再到各种功能（如cache,sharding,replication,分布式查询 等）的集成，最后到查看源码并修改源码（虽然不提倡自己修改开源工具的源代码，但是总有一些蛋疼的需求需要这样做，下面会有说明），这条路下来并不是很平 坦，solr简单做其实很简单，但是你若需要一些强大的功能的话你就不得不熟悉它的全部API（到最后，我觉得solr用一本几百页的书来讲的话估计也讲 不完全，甚是强大啊，强大之处我不细谈，因为很多）。就像今天就碰到了一个比较蛋疼的需求，查询固定小时内的结果，之前我在用solr的时候对时间类型的 字段使用的是string类型来存储，因为这样甚是简单，不像solr提供的date,tdate,pdate 等时间类型，solr提供的时间类型的索引是GST格式的，查出来之后是需要进行转换的并且需要转换两次才能变为我们可接受的格式，所以往往都用 string类型来存储时间类型的字段。对于今天这个需求如果再使用string类型存储的话就没辙了，好吧，改用tdate(比date,pdate效 率会高点)吧，弄好之后经理说转换两次太麻烦，还是用string吧，好，我忍，改回string类型，可是需求不能实现，完了，我跟经理说我再想想吧 （我是真这么说的）。接下来进入我的内心活动：用string的话我是要把时间值的小时数取出来再去查询，可是string类型（不分词的话）是取不出小 时数的，那么你要取出小时数，我就用正则表达式取出，我就猜，正则表达式不是有group的含义吗，我给小时指定一个group，页面不是就能拿到这个小 时数了吗，于是google：solr 正则表达式，一篇文章一篇文章得的找，看到了一个貌似可行的方法，好，实现之，最后搞起了，美美的搞起了。 搞 完此蛋接着又来一蛋，将solr增量索引的时间间隔改为秒级的（solr官方只提供分钟级别的间隔），好吧，改就改，看看源码，完了，源码里指定了 Calender.MINUTER,不能再配置文件里配置之，算了把源码改为SECONDS吧，又搞起。可我发现solr默认使用的是java的 Timer类来实现定时增量更行索引的，该定时器的特点是一个任务执行中，如果过了一定的时间间隔新的任务会被加到任务队列中，然后等第一个任务执行完第 二个任务也开始执行（并不等待间隔时间），这种定时器的缺点是任务容易阻塞，有时候会造成资源使用过量并且不提供线程池的概念，好吧，我看着不爽，改为 ScheduleExecutorService吧，这个定时器的特点是一个任务执行完（不管你执行多久）我总要等待固定的时间间隔再开始第二个任务，这 种模式是不是很好，并且它提供线程池的概念，大大减少了资源竞争的疟疾。 从以上可以看出成熟的开源工具还是会有一些不符合要求的动能，我们可以完善并且在开源工具官网上commit你的代码，算是为开源世界做的一点贡献吧。 好了，这些纯属个人开发的一些经验，以后还会朝着这个方向走。