提高 Elasticsearch 写入速度（记一次线上 Kafka 消息积压问题处理）

线上集群告警，消费 Kafka 消息写入 Elasticsearch ，写入速度慢，产生消息积压问题。

临时去掉 ES 副本，解决紧急问题，无法从根本解决提高 Kafka 消费速度提高 ES 写入速度，使用 ES bulk api，批量写入数据 关于批量写入的最佳值大小问题

整个批量请求都需要由接收到请求的节点加载到内存中，因此该请求越大，其他请求所能获得的内存就越少。 批量请求的大小有一个最佳值，大于这个值，性能将不再提升，甚至会下降。 但是最佳值不是一个固定的值。它完全取决于硬件、文档的大小和复杂度、索引和搜索的负载的整体情况。
幸运的是，很容易找到这个 最佳点 ：通过批量索引典型文档，并不断增加批量大小进行尝试。 当性能开始下降，那么你的批量大小就太大了。一个好的办法是开始时将 1,000 到 5,000 个文档作为一个批次, 如果你的文档非常大，那么就减少批量的文档个数。
密切关注你的批量请求的物理大小往往非常有用，一千个 1KB 的文档是完全不同于一千个 1MB 文档所占的物理大小。 一个好的批量大小在开始处理后所占用的物理大小约为 5-15 MB。

max.poll.records <= 吞吐量
单次poll调用返回的最大消息数，如果处理逻辑很轻量，可以适当提高该值。
一次从kafka中poll出来的数据条数,max.poll.records条数据需要在在session.timeout.ms这个时间内处理完
默认值为500

consumer.poll(1000) 重要参数
新版本的Consumer的Poll方法使用了类似于Select I/O机制，因此所有相关事件（包括reblance，消息获取等）都发生在一个事件循环之中。
1000是一个超时时间，一旦拿到足够多的数据（参数设置），consumer.poll(1000)会立即返回 ConsumerRecords records。
如果没有拿到足够多的数据，会阻塞1000ms，但不会超过1000ms就会返回。