导读

• 最近线上有个关键报错：

Wrapped by: java.io.IOException: 
Request POST https://xxx/_search?search_type=xxx HTTP/1.1 yielded text/plain;charset=ISO-8859-1, 
should be json: HTTP/1.1 429 Too Many Requests

报错分析

如何看懂异常日志呢？

• 先知道异常日志的输出规则。
• 异常名，细节信息，路径 的概念如下图。（参考：https://www.lmlphp.com/user/58062/article/item/671925/）
  
• 异常名+细节信息以先进后出（FILO）的顺序打印，即：打印内容最下方的异常最早被抛出，逐渐导致上方异常被抛出。
• 路径以先进先出（FIFO）的顺序打印，即：位于打印内容最上方的位置最早被该异常经过，逐层向外抛出。
• tips：这也是为什么叫异常栈了，栈就是先进后出（FILO）

报错的猜想

• 猜想一：调用es的search api，入参有问题，因为看到关于json的报错。
• 猜想二：429 Too Many Requests 导致。

生产情况分析

1. 偶发产生这个报错
2. 产生这个报错的入参不固定
3. 入参再次请求没有产生报错
4. 报错时 CPU 和 内存 没有告警

我个人认为合理的猜想

• 根据异常日志的输出规则，json异常是在最先输出，再结合生产情况的分析，我更倾向 429 是真实报错原因，json的异常是返回结果时，es返回的不是json串，所以json解析报错。

429报错怎么产生的？

查找资料

百度

• 关键字：es 429

elastic中文社区

• https://elasticsearch.cn/question/8753
• https://elasticsearch.cn/question/2632

书籍

• 书名：Elasticsearch 源码解析与优化实战
  

github

• https://github.com/elastic/elasticsearch

关键资料总结

bulk

• bulk：es 批量增删改操作（特殊情况：index/delete操作转变成了只包含一条文档的bulk请求）

高IO (IO密集型)

• 频繁写入操作会导致高IO，占内存和磁盘，IO密集型建议使用脚本语言进行编码，比如python，相对编码简单，编码效率快。

高CPU(CPU密集型)

• 频繁查询操作会导致高CPU，占CPU，CPU密集型建议使用编译型语言进行编码，比如C、C++、Java和C#

es接收请求队列

• 每个节点都有一个线程池队列，可以容纳若干个请求，具体取决于您使用的 Elasticsearch 版本。队列已满时，将拒绝新请求。

es使用场景

• “tagline” : “You Know, for Search”

我个人分析429产生的原因

• 在查询的时候会触发429，降低并发查询频次，提高写入速度。

ES的优化

• 参考文章：https://blog.csdn.net/wmj2004/article/details/80804411
• elasticsearch.yml 中增加如下设置

indices.memory.index_buffer_size: 20%
indices.memory.min_index_buffer_size: 96mb

# Search pool 设置 search 的线程数和队列数
thread_pool.search.size: 5
thread_pool.search.queue_size: 100
# 这个参数慎用！强制修改cpu核数，以突破写线程数限制
# processors: 16
# Bulk pool 设置 bulk 的线程数和队列数
#thread_pool.bulk.size: 16
thread_pool.bulk.queue_size: 300
# Index pool 设置  Index 的线程数和队列数
#thread_pool.index.size: 16
thread_pool.index.queue_size: 300
# 设置 filedata cache 大小
indices.fielddata.cache.size: 40%
# 设置节点之间的故障检测配置
discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 6
discovery.zen.fd.ping_interval: 30s

• 索引优化配置

PUT /_template/elk
{
      "order": 6,
      "template": "logstash-*",    #这里配置模板匹配的Index名称
      "settings": {
        "number_of_replicas" : 0,    #副本数为0,需要查询性能高可以设置为1
        "number_of_shards" :   6,    #分片数为6, 副本为1时可以设置成5
         "refresh_interval": "30s",
         "index.translog.durability": "async",
        "index.translog.sync_interval": "30s"

      }
}

最后聊两句

• 金发姑娘原则，对于项目的技术选型时，没有最好的技术，只有最适合的技术。
• 里面有很多我个人的猜测和思考，可能有不正确的地方，希望各位大佬多多指教评论。