共计 1840 个字符，预计需要花费 5 分钟才能阅读完成。
咱们团队基于 Elasticsearch 开发了一款将数据从数据库实时同步至 Elasticsearch 的工具——搜寻平台，其实现形式次要是通过 flink 将数据库中已有的存量数据导入 Elasticsearch，并订阅数据表的 binlog，将实时改变也同步至 Elasticsearch。
问题发现
AIoT 团队在搜寻平台上保护了一个较大的索引，其写入均匀有 2k 到 3k 的 tps，查问也有数百 QPS。因为该索引较重要且占用资源较多，因而应用 Elasticsearch 的 template 性能将之独自部署在专用的机器上。
从 5 月底开始，写入此索引的 flink 实时工作就会偶现失败重启的状况，经排查，发现是写入 Elasticsearch 的申请超时导致的，联合过后机器的 cpu 占用等指标断定是写入 tps 过高导致 Elasticsearch 无奈接受，因而，将该索引所占的机器从 2 台降级到 3 台，并应用业务数据进行了一轮写入压测，发现能撑持业务方的写入速率，扩完后较长一段时间内，该索引也始终没有呈现问题，因而认为问题曾经被解决了。
问题排查
然而，在 6 月 22 日凌晨，上述问题再次出现，通过查看指标，发现过后的写入速率并无显著晋升。
1. 索引写入速率
既然不是由写入速率晋升造成的，那就接着排查其余可能占用 CPU 资源的行为。
2. 索引查问速率
3.jvm gc 次数
4. 节点 merge 速率
5. 节点写入队列长度
由上述指标能够看出，写入耗时过久是因为索引的其中一个节点写入队列过长，无奈及时处理写入导致的。然而在写入队列变长的过程中，节点的 gc，merge 等操作并无显著变动，索引的查问速率也没有显著晋升，因而猜想是某些具备非凡特色的文档导致 es 写入过慢导致的。
在上述猜想下，咱们的思路就变成了找出导致索引过慢的罪魁祸首文档。因而就从埋点数据中收集了很多慢索引文档，尝试手动索引，但均能很快索引实现。
然而线上问题仍旧存在，为了使业务不出问题，咱们从以下伎俩尝试修复线上问题：
1. 减速 Elasticsearch 的索引效率
- 调大索引的 refresh_interval 参数
- 批改 index.translog.durability 为 async 等
- 敞开局部字段的索引配置
2. 升高 flink 工作的写数据频率
然而每次尝试均以失败而告终，每次都是实时工作启动不久，写入就超时了。然而在一直排查问题过程中，发现了此问题的以下特色：
- 批量工作与实时工作的写数据 TPS 差不多，然而批量工作就不会有问题
- 每次出问题的机器都不是同一台
因而，不是机器的问题，应该也不是某些文档的问题（因为后续重建索引时会把之前实时工作同步的文档移到批量工作阶段同步）。因而，为了搞清楚 Elasticsearch 在这个阶段到底在做什么导致无奈写入数据，咱们选取了一个写入队列很长的节点，执行了数次 jstack 指令，获取 Elasticsearch 过程的执行堆栈后，发现其中的 8 个 write 线程很长时间都处于 WAITING 状态，其调用堆栈如下：
最初通过查看对应版本的 Elasticsearch 源代码，发现 Elasticsearch 的 write 线程在执行文档的索引操作时须要获取文档主键对应的锁，以避免不同线程同时批改同一篇文档，而出问题时，write 线程大部分工夫都是在期待这个锁，那就阐明很可能是因为实时工作往 Elasticsearch 批量写入的文档里很多都是同一个主键的，导致 write 线程的锁争用状况十分重大，起初通过剖析数据 binlog 验证了这个猜测。同时也能够解释上述两个问题：
- 因为批量工作是从数据库中获取数据，对同一个 id 的屡次批改并不会保留历史记录，只会存储以后快照，而实时工作的数据源来自数据库的 binlog，其中保留了数据表的所有改变，对同一个 id 屡次批改都会反复同步至 Elasticsearch
- 因为每次大量批改的数据 id 不同，因而路由到的节点也不同，导致每次都会在不同节点上出问题。
问题解决
在确定问题的具体起因之后，咱们批改了同步实时数据的 flink 工作，应用滚动窗口聚合一段时间内的 binlog，将之去重，在窗口完结时再把数据写往 Elasticsearch。通过这种形式，升高了反复 id 呈现的频率，然而会导致数据同步的时效性缩短一个窗口的工夫。与业务方协商后，将窗口定位 5s，并不会对业务造成影响，上线后终于解决了这个问题。
（本文作者：盛晓昌）
本文系哈啰技术团队出品，未经许可，不得进行商业性转载或者应用。非商业目标转载或应用本文内容，敬请注明“内容转载自哈啰技术团队”。