Sphinx是什么阿蒙在这里就不解释了，直接进正题吧。
官方提供的API接口实在是太简陋了，完全是从PHP迁移到C#的，对于不熟悉Sphinx的开发人员来说，颇费一番功夫才能明白如何去调用各个方法，而且在网络连接上未使用连接池，这对于工作在Nginx或lighttpd这类单进程单线程的Web Server下的PHP来说，的确是比较好的，但对于工作在IIS下的.NET程序就不那么令人愉悦了。
在这个前提下，于是决定自己动手开发一个Sphinx的客户端类库。
Sphinx协议是很简单的，但是其中也隐含着一些陷阱，例如今天在测试接口时，发现的一些问题：
1、按时间(DateTime)或整型(Int32)过滤结果时，始终报错：“invalid or truncated request”，在网上搜索半天无果，只有自己动眼看服务端源码（伸手党不好做:-(）。
在源码中发现了，分析范围过滤的方式的相关代码：
代码
{
case SPH_FILTER_RANGE:
tFilter.m_uMinValue = ( iVer>=0x114 ) ? tReq.GetUint64() : tReq.GetDword ();
tFilter.m_uMaxValue = ( iVer>=0x114 ) ? tReq.GetUint64() : tReq.GetDword ();
break;
case SPH_FILTER_FLOATRANGE:
tFilter.m_fMinValue = tReq.GetFloat ();
tFilter.m_fMaxValue = tReq.GetFloat ();
break;
case SPH_FILTER_VALUES:
{
bool bRes = ( iVer>=0x114 )
? tReq.GetQwords ( tFilter.m_dValues, g_iMaxFilterValues, "invalid attribute set length %d (should be in 0..%d range)" )
: tReq.GetDwords ( tFilter.m_dValues, g_iMaxFilterValues, "invalid attribute set length %d (should be in 0..%d range)" );
if ( !bRes )
return false;
}
break;
default:
tReq.SendErrorReply ( "unknown filter type (type-id=%d)", tFilter.m_eType );
return false;
}
原来Sphinx的服务端在客户端代码版本高于0x114时，是以8字节长整型来读取的最大最小值，问题找到了，将所有进行范围过滤的值在发送到服务端之前都转换为Int64，再写入流中，OK，问题解决。
2、用Socket不要用TcpClient - -
在做压力测试时，Socket通信的性能明显好于TcpClient，而且TcpClient在压力测试过程中，经常报错，目前尚未去查找原因，不过用Socket的话，工作得非常好。
目前该类库还在测试中，可能还会遇到其他问题，慢慢补充。
前几天遇到的问题，今天终于得到解决。
今天到公司之后，写了一个telnet的测试程序，分别在公司内网、服务器环境、在加拿大的同事机器上、湖南朋友的机器上、以及在其他几个公司就职的同事机器上运行了一下。
每次运行，telnet 1000次LVS的VIP的80端口，公司内网测试结果失败了20%，其他测试均全部通过，因此断定了问题出在内网环境中。
找来公司网管一起分析这个问题，怀疑是出在公司使用的一个叫“网康”的软件上，但排查后，也非出在这个东西上，因为它是基于域名过滤的- -，郁闷！
无意中，换了几个IP测试，发现除了LVS的这一个VIP之外其他的VIP都是可以成功通过测试，于是决定换一个VIP来转发80端口的请求，谁知新建一个VIP之后，故障VIP居然神奇的正常了 - -
尽管这个灵异现象解决得十分不完美，but... it's work!!!!
昨天晚上公司的网站换了lvs + nginx + iis的架构，因为公司网站用的.NET开发，又因为不知道在Mono下能否跑，因此还是逃不开IIS。
最前端是lvs + keepalived接受用户访问，然后转发到三台nginx中，nginx做反向代理到后端的IIS，今天到公司后，不少同事反应，访问网站时快时慢，偶尔还出现访问失败的现象，即使静态页面也是这样，起初以为是内网的原因，公司网管检查了反应慢的同事电脑，排除各种原因后，现象依然存在，于是开始怀疑是昨晚的调整造成的，看了一下lvs的master，连接数很低，查看nginx服务器，80端口有不少fin_wait1状态，看了一下nginx的日志，应该是lvs做健康检查造成的，直到下班，原因未查到～
下班之后，回到家中，不甘心，又开始排查这个问题，但无论怎么访问网站，即使用webbench做压力测试，lvs连接统计超过白天的100倍也没能出现，访问失败的情况，而且静态页面在这种情况下还能正常访问，这让我百思不得其解......
难道还是内网问题吗？
从Tokyo Tyrant官网上看，它是兼容Memcached协议的，但在实际使用中发现以下两个问题：
1、在保存值到服务器时，Memcached的API会对值进行一次序列化，并且把值的原类型（一个整型，Memcached自己定义的），保存到服务器上，但是TTServer是无法保存的，每次get回来的类型值都是0（Memcached的API定义的0为ByteArray），造成无法将返回值自动反序列化，要解决这个问题，看来只有在存入前自己序列化一次，取出时再自己反序列化，比较不爽。
2、Memcached中的超时时间对TTServer无效，即所有数据如果存入TTServer如果不显式删除，它将永远存在。要解决这个问题，只有包装存入的值了，自己实现超时的功能。
Memcachedb没有问题1，但有问题2...