明道内容搜索业务的成长历程

  依稀记得2011年的时候，明道还是一个名不见经传的产品，刚刚起步，搜索的重要性还没有那么大，数据库的搜索完全能够支撑现有的业务，没错就是 'like' 。

  到了2012年年底，当我们拥有一定数据量的时候，搜索的速度就跟不上明道的步伐了，于是我们寻求一种能够代替数据库搜索的一种能够支持海量数据搜索的解决方案，最终我们选择了solr。

  在用solr做搜索的时候，我们的数据已经进行了横向切分，按照企业纬度把数据分别存储在几台服务器上，所以我们第一版的solr采用的也是跟数据存储一样的方案，不同的数据服务器对应不同的solr服务器，根据企业进行路由，搜索慢的问题得到了有效的解决。并且我们对文档内容也支持检索，我们的做法是把基础数据先转换为二进制数据放到rabbitmq队列里，然后用windows服务根据基础数据的文档URL将文档内容读取，然后再索引到solr里，实现文档内容的检索。但是也有一些不足的地方，搜索不准确，主要原因是我们选用的分词器本身是进行内容碎片分词，查询也遵循同样的分词方式，可能一句话只包含了关键词的一个字，这样的搜索是毫无意义的。

  在2015年年中的时候，根据明道业务的发展，我们为了企业能够更加便捷的通过明道和外部写作成员进行协作，按照企业进行数据切分已经不适合现有业务了，我们决定对数据再次进行聚合，并对消息内容采用NoSql存储，并做分布式和读写分离，使得我们的系统更加的健壮，能够支撑更大的数据量。于此同时，solr也同步进行了比较大的改动，我们应用了solrcloud来支撑我们之后的搜索业务。

  在此次的搜索模块改版的时候，我们吸取了前面的教训，因为明道在快速的成长，对搜索系统的灵活性要求也更高，所以我们这次在定义solr的collection的时候，采用了动态属性，加字段变成了在实体类里多增加一个字段这么简单的事情。并且对之前的搜索模块做了重写，使得扩展性得到了有效的保证，比如我们这次需要对知识中心加入到全文搜索里，我们只需要十几分钟就可以搞定了。

  关于改版之前的搜索不准的问题，在此次也进行了优化，我们使用了对中文分词较好的IK分词器，并且对用户输入的词进行分词之后，再进行临近搜索处理，保证用户输入的关键词能够全命中。其实本来solr的排序就是按照权重排序的，不用这么做，这些结果也会排到最前面。但是明道的理念是，最近的内容是对用户越有用，所以我们不得不考虑时间概念，所以必须让用户的搜索更加精准的匹配内容。

  在做搜索的过程中也是遇到各种各样的问题

  比如，我们有一个客户发现包含类似MH370这样的字母加数字的内容，在搜的时候如果只输入MH37是搜不到的，我在solr里用分词器一看，果然，IK分瓷器的是不会对字母数字进行拆分的，认为是一个词，我查了各种资料，发现也没找到解决方案，最后只能自己对这种搜索关键词做拆分。

  再比如，我们的rabbitmq的消费端(Windows服务)是使用多线程进行索引的，然后我发现有很多错误日志抛出来，但是solr的logging里就是不报错，最后发现，原来是C#默认的最大并发请求数是2，于是设置了C#的最大并发请求数 System.Net.ServicePointManager.DefaultConnectionLimit = 100; 就好了。

   类似的坑也是数不胜数。

   如果有朋友也在solr搜索方面也有一些见解，欢迎一起探讨，互相学习。