elasticsearch读写怎么应对长尾延迟

长尾效应[1]

分布式系统，即使有极少数机器请求响应时间较长，也有大概率导致用户请求的响应时间变长。

长尾效应不可避免

节点情况各不相同，最常见因素是“垃圾回收”，某个节点都stop the wrold，任务处理自然响应慢一点。而垃圾回收，就像是去厕所大号一样，有规律，但时间点不一定好控制。叠加其他因素交叉在一起，整体上是不能做到保证每个节点都是同等的响应时间。

举个例子，分布式下某一任务受极少数节点影响，就像约好同事们下班一起去团建，6点集合，这时有的同事要加班、有的同事要给公交卡充钱等等，实际聚齐的时间一定会超过6点。

长尾效应对elasticsearch读写的影响

elasticsearch路由目的就是要确保文档均匀分布到分片，只要是跨分片操作都会发生长尾效应，从而拖累操作，使处理时间变长，进行影响读写能力。

写

bulk下CRUD操作都有，多个文档，跨分片、路由策略、分布场景，自然会响应时间变长，单位写能力下降。[2]

读

ES默认使用Query then fetch的搜索类型。它发送查询到每个shard找到所有匹配的文档。

elasticsearch读写怎么应对长尾效应

两个出发点：一是加强节点本身的能力；二是回避跨节点操作；

• 节点：感知状态（自适应副本选择ARS）[3] 巡检监控节点健康情况，确保节点都是高效率地工作；通过算法来确定任务总能路由到“最佳”副本上。
• 任务：分类划小 分类：批写文档事先分类，可以路由一个节点上 划小：将需要长时间运行的请求打散成一连串小请求，使其可以与其它短时间任务交错执行，批写量不要太大。