lucene分布式架构-满足高并发的实时检索需求

                                                                                                                 一洽在线客服系统

          最近一洽在人工客服对话的基础上增加了智能应答服务，一洽对待服务质量的态度永远是7*24小时永不间断，上线前必须做到的标准如下：

           1.允许出现单节点故障

           2.可在负载过高时随时添加集群节点

           3.所有集群内的server可同时操作知识库的索引，包括创建和读取

           4.索引需要有多层备份

           5.用最少的服务器资源做最高效的工作

           

           业务应用场景：

           1.saas平台多人使用

           2.单体知识库容量小，知识库数量众多

           3.查询请求量很大

          根据以上要求研发和运维团队也都提出了自己的架构方案。

          同事A（方案一）：使用hadoop做lucene的分布式索引（网络上到处都有架构方案，唯一的要求是成本高，成本高）

          同事B（方案二）：同一台机器部署多个个server 共用同一个机器上的索引文件 然后对索引的写操作使用redis做分布式锁来做伪集群（不可不说这也是一种方案，确实从最大程度上满足了第5条标准）

          同事C（方案三）： 做一个索引同步的中间件，配合redis的分布式锁来达到索引实时同步，同时满足每台server上都有一份完成的索引文件。

          同事D（方案四）：分布式server集群，公用同一个网络磁盘作为索引目录，同时对网络磁盘进行多重备份，看起来很简单，唯一担心的是网络磁盘的读写效率。    

          方案一和方案二就不多说了，有钱的可以选择方案1，对自己没要求对客户不负责的可以选择方案二。

          这里和大家分享下一洽在实施方案三和方案四的过程中遇到的坑和解决方案，供大家参考。

          方案三架构如下：

          

      1.在每次写完毕后删除掉write.lock那么在文件监控到某个目录下write.lock出现时即有索引的更新

      2.等待获取write.lock锁可保证索引文件已经写完毕，避免碎片文件多次同步

      3.将分布式锁交给中间件是保证每次索引写完毕后必须先同步完索引才能继续进行写入

     

      此方案经过运维童鞋废寝忘食的工作，中间件终于诞生，经过长时间的压测，方案运行状态良好，但这个方案的弊端也很明显，如果某个客户的知识库很大那么其索引文件必定也很大，过大的索引文件在服务器组间的复制性能会影响到客户的使用。

      无奈之下放弃了这个节约服务器资源的方案，转而进行hadoop的分布式集群架构， 各种考虑分组、hash来提升集群的性能尽量满足众多企业同时拥有自己的知识库同时频繁修改的业务场景，就在集群方案测试通过后之前最不看好的方案四被那个不屈不挠的同事发现了可实施的具体方案，下面就给大家介绍下方案四在一洽是如何进行实施和测试的。

  

       方案四架构如下：出奇的简单，但测试效果确出奇的高效稳定。

       

        1.所有的server都共用同一个索引文件目录

        2.针对同一索引目录的写操作使用分布式锁进行控制

        重点要说明的事NAS这个东西，这里的NAS云盘在一洽的系统架构中指的是阿里云刚刚推出的分布式文件存储系统，这里就不打广告了应该各家云服务器提供商会陆续提供此种类型的服务，测试结果如下：

        24小时 1000个线程同时不间断的向nas的1000个不同的索引目录写入索引，同时进行正常的索引查找服务，测试出来的最大搜索延迟为200MS，平均获得查询结果的时长在50MS内，可见此方案的性价比之高，同时nas作为挂载云盘可同时挂载多个来进行扩容以及hash后的分片服务。

         根据测试结果我们目前上线的智能问答系统采用的就是第四种方案，第一种方案作为备份。当然如果您也想试试方案四的话一定记得给NAS做备份哦。

         任何一种系统架构都不是完美的，只要能满足今后很长一段时间的需求以及有可行的扩展方案它就是一个好的架构，希望有同类业务场景需求的同学，我们的经验能给你们带来一些帮助^_^