ksearch系统开发过程中遇到的KFC性能问题

前天ksearch性能压测过程中发现一个很奇怪的问题，跟了3天，case做了无数个，终于发现问题所在，还是KFC（KuaFu Communication）的问题。然后想起来，去年实时搜索上线前夕，也遇到一个很奇怪的问题，最后定位出来也是KFC的问题，异常郁闷，所以这里记录一下。

ksearch的服务框架：search和merge两种角色，search负责真正的存储和检索，通过行结构做灾备，列结构获得大数据量和高QPS；merge对外提供服务，对内转发请求给相应列的search机器；search和merge之间的网络和角色，是通过kfc管理的。search的每一列负责同一个key的请求，merge通过key_send转发请求到相应search机器。kfc对我们来说是一套黑盒系统，只是听老大说很nb，很多部门都在用；使用过程中碰到了很多蛋疼的问题。以后有这种涉及到性能的大型系统，千万不要信黑盒系统，不管别人说它多么nb。

case 1： 2行6列search，merge复用第一行的前两台机器

现象：通过merge压测时，如果把query落在单独一列，不管是高并发还是低并发，由于search服务能力很强，可以很轻松把merge网络压满，达到10K的qps；用abench -r压也可以轻松达到8K以上没有异常。但是如果query落到所有列上，低并发情况下，可以达到10K；如果用高并发压，发现qps只能达到5K左右；用abench -r压2K的qps都会有很多超时，和预期相差很大。看merge机器，不管是进程还是系统，都远远没有达到瓶颈；而且search机器也很空闲。由于下周就要上线，相当操蛋。

针对这个问题，我们做了以下实验：

1.  只压到两列的query，结果跟压全列query一样，说明不是机器规模问题。

2.  调整query返回结果大小，发现高并发下qps跟返回结果大小成反比，即返回结果越小，qps越高；而实际上返回结构大小，search处理时间几乎不会变化。 说明还是网络的问题。

3. 分析log发现，不管高并发还是低并发，search机器处理query的平均时间没有变化，但merge机器观察到search的latency却有很大变化。网络通信我们用的是kfc，说明问题出在kfc身上。

还有其他一些，不一一列了，最后确认是同一台机器复用search和merge，触发了kfc的性能问题；通过调整系统部署解决。

case 2: 2行22列，3台merge

现象：merge总是观察到批量超时，每次一有query超时就超一批，对超时query分析发现，每一批中一般只有一个大卖家，其他都是小卖家。大卖家超时是可以预期的，小卖家超时却没办法解释。

case做了一大堆，纠结到最后发现是因为，kfc分发消息时使用Round-Robin方式，假设有10个server提供服务，来了1000个query，他会为RR的为每个server分100个query，而不是哪个server闲着就分配给哪个。这样就有问题了，如果有一个大卖家堵住了一个server，其他的query就在他后面排队，等到第一个大卖家超时，后面堵着的所有卖家都超时了。