记一次管道流的问题定位过程

背景：

云搜同一query多次查询，结果数目不一致，或者排序不稳定？

经过排查，结果数目不一致，是因为副本间数据不一致导致（build请求edoc偶发超时），而云搜的svc模式并不能保证同一个query落到一个副本上，所以出现了同query多次请求结果变化

而，排序不稳定，部分是因为，当多个doc打分相同的情况下，排序规则是根据索引中的docid来排的（注意，非主键id，而是从1开始算的），此docid从1开始根据如索引时间来递增，而在多副本的的build中，不同doc进入索引的时机并不能保证！

 

问题：

1： svc name 请求的随机性问题

如果svc 到pod 能保证hash 规则，那么所有的问题都不会发现，但问题并未真正解决

2： build如何保证不超时？

目前定位到的现象是，build请求edoc，请求到达edoc就已经超过了超时阈值3s，edoc的请求耗时在ms级别，所以不是edoc处理逻辑的问题，而是网络请求的问题：

a： 是否是edoc 节点太少?

b： edoc svc 模式负载不均，有多大的影响?

c： 是否在集群网络中svc name 请求有天然的缺陷？

 

3： 快速修复策略

加大超时阈值，重试次数 @hxx 无法评估能解决到什么地步

补发流程，udp 发送出来，使用外部工具进行补发到kafka

4： kafka streams 利用，剔除edoc服务

kafka topic A ---- kafka streams （edoc逻辑） ---kafka topic B

此架构能剔除掉edoc 模块，并且能保证build不会丢失文档，能保证结果数目一致，但是查询排序变动并不能解决！

缺陷： kafka架构需要变动，涉及到如何上线以及性能的问题

 

 

解决问题过程和遇到的问题

超时错误为：org.apache.thrift.transport.TTrans