本文共 1938 字，大约阅读时间需要 6 分钟。

1.记一次线上es问题:写入找不到主节点

背景描述: 某天早上突然收到容器的流量告告警,network ingress usage high: 63289.54 KB/s 即网络入口使用量过高…开始还没在意,因为没发现影响到上线的业务…信息过少也不好排查。。。直到数据中心那边说每天定时小时级别写入数据到es集群的任务出现问题挂了…我才赶紧把运维拉了进来让运维帮忙分析…

首先数据的小伙伴抛出了一个异常信息出来:

Caused by: ClusterBlockException[blocked by: [SERVICE_UNAVAILABLE/2/no master];]        at org.elasticsearch.cluster.block.ClusterBlocks.globalBlockedException(ClusterBlocks.java:158)        at org.elasticsearch.cluster.block.ClusterBlocks.globalBlockedRaiseException(ClusterBlocks.java:144)        at org.elasticsearch.action.bulk.TransportBulkAction.executeBulk(TransportBulkAction.java:204)        at org.elasticsearch.action.bulk.TransportBulkAction.doExecute(TransportBulkAction.java:151)        at org.elasticsearch.action.bulk.TransportBulkAction.doExecute(TransportBulkAction.java:71)        at org.elasticsearch.action.support.TransportAction.doExecute(TransportAction.java:149)        at org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:137)

可以看出应该是在执行批量写入的时候抛出了一个服务不可用没有master的异常信息

运维的大佬也抛出了一个master节点异常带宽流量的截图问题:

可以看出单台机器带宽都过3G了，运维让我排查是不是有什么大量查询的语句在执行,我赶紧取监控中心上看，确实有个qps=100的接口在调用,但是我本地连接es通过分组聚合发现每次查询出来的数据量非常少的。不应该产生这么大的带宽…问题就僵住了.后面运维通过抓包分析发现里面的信息都是集群状态相关的信息让我取排查业务逻辑有没有取频繁拉取集群状态的逻辑。。。

接口的逻辑很简单就是elasticsearchTemplate.indexExists判断索引是否存在和一个es查询接口…点进去看发现并没有获取集群状态的相关操作…唯一可疑的就是elasticsearchTemplate.indexExists但通过debug没有发现,后面发现有个aop的逻辑里面有个打点逻辑会调用下面这个api

elasticsearchTemplate.typeExists(stringBuffer.toString(),Constant.ES_DSL_LOG)	return client.admin().cluster().prepareState().execute().actionGet()				.getState().metaData().index(index).getMappings().containsKey(type);

果然通过debug发现每次都会获取集群的状态,并且每次返回的数据量都有35mb左右…调用一次就会从es集群拉取一次,很疑惑为什么没有缓存,后面通过百度了解可能和有关

即采用tcp来连接es集群:

优势：

​ 启动速度快，不需要像前者那么多的socket连接。

不足之处：

​ 因为它不想前者那样知道集群、索引、分片的这些信息，所以在分发数据和查询上没前者快，不能直接发送到指定的节点或直接从某个节点去取数据，需要ES在其中进行一些额外的转发才能完成。

推测:

​ 即tcp的连接方式不知道集群的状态信息,也就是不会加入到es集群当中取，也就是master节点更新集群状态信息时不会同步到应用服务器,如果缓存则会有不一致的问题。因此只能通过实时拉取

转载地址：http://jmkji.baihongyu.com/