【关于分布式查询方案的讨论】
【关于分布式查询方案的讨论】
1、通过服务端缓存结果实现搜索
客户端C1向服务器发出【查询请求(key,GUID,IP,PORT)】，服务端S1把这个【请求(key,guid,ip,port)】插入到【查询请求队列

(key,GUID,IP,PORT,inserttime)】里，然后“线程a”扫描【查询请求队列】，然后从【用户在线列表（IP,PORT）】里随机选出十

个人把这个【请求(key,guid)】发送给他们.然后这些人查询自己本地的lucene索引，然后把前5个【查询结果

(title,shortdesc,path,createdate,modifydate,guid)】发送给服务器,服务器里的“线程b”收到查询结果后，先放入【查询结果

缓存(用hashtable来做，key是guid，value是一个inerttime和ilits组成的结构,list里的item和查询结果的结构一样)】，如果一个

guid的结果数目已经有50个或者从now减去inerttime大于【结果超时时间(可配置)】，就从【查询请求队列】里通过这个guid找到当

初请求人的IP和port，把这个结果发给查询请求者，同时通过guid删除【查询请求队列】和【查询结果缓存】里的相关数据。 "线程

c "扫描【查询请求队列】通过now和inerttime比较，删除超时的查询请求。

缺点：
随机选择的这10个人也许都没有这个key的结果
服务器缓存结果的压力很大
所有的客户端和服务端要保持一个TCP长连接，或者UDP模仿的可靠连接，比较浪费资源

补充:
服务端和客户端通讯可用socket也可以用remoting。
客户端发出查询后可能会等好长时间，所以要做成异步模式，等查询结果出拉之后以提示的方式报告给用户。

2、进行P2P搜索
客户端先从服务器的在线列表里随机获取10个在线人员的IP和端口，通过服务器辅助进行UDP打洞，然后给这10个客户端发起查询请

求，返回的结果缓存在本地队列达到50条或者超时之后，显示出来。

缺点：有的路由设备的NAT类型不支持UDP穿透，所以有时候这个方法会不灵

补充：关于UDP打洞的原理网上有好多介绍

------解决方案--------------------
太深奥了……