当前位置: 首页 > news >正文

ElasticSearch那些事儿(九)

学习ElasticSearch目前为止,踩过以下几个坑:

  1. 集群搭建不成功
  2. 未使用内网IP,导致恢复缓慢
  3. 未使用队列及logstash,导致数据丢失
  4. Master和DataNode未分离,导致集群不稳定
  5. Logstash吞吐量问题
  6. Logstash如何创建Mapping
  7. head插件安装错误

犯了这么多错误基本上都是使用不当、以偏概全的原因,以为看了一点文档,就凭直觉可以猜测到系统的所有内容,造成了后续问题的不断涌现,下面就逐一说一下淌坑过程

集群搭建不成功

一开始是在单机上玩ElasticSearch的,上生产环境肯定要使用它的集群功能,但文档说只需要在elasticsearch.yml中设置cluster.namenode.name即可,ElasticSearch节点启动时会自动发现集群并加入到集群,但全部设置完毕后,竟无法使各个节点组成集群,最后发现这种方法只在一台机器上有效,而要组成集群,需要在每台节点做以下配置:

 

discovery.zen.ping.unicast.hosts: ["Node1_IP:9300", "Node2_IP:9300", "Node3_IP:9300"]

ElasticSearch一般会开两个端口,一个是集群维护端口,如上面的9300; 一个是对外提供的端口,默认是9200。

未使用内网IP,导致恢复缓慢

在部署集群时,我挑选了几台配置相近的同网段机器,但当时其中一台机器操作系统没有加载内网网卡,为了偷一下懒,便直接使用了外网IP,集群是跑起来了,运行了一段时间也没有什么问题,但随着流量越来也大,终于有一天Master突然down掉了,我当时心想,ElasticSearch集群本身具有故障转移功能,马上会分配一个Master节点,然后我只需要把原先的Master节点重启即可,然而重启了之后,通过head页面查看恢复情况,发现集群长时间处于黄色状态(有replica shard丢失),而丢失的shard一直处于未分配状态,并没有如我预期的:启动后,该节点可以重用在磁盘上的shard数据,上报给Master,不需要数据拷贝,立马恢复为绿色状态。过了几分钟后,我发现恢复的shard数正以缓慢的速度增加,便推导出这样的错误结论:ElasticSearch在某一台机器挂掉后,只会从primary shard复制数据,即便节点迅速恢复,也不会复用该节点上的数据,如果是这种实现方式,我认为这种恢复速度是无法接受的,顿时产生了无法继续使用下去的念头,当时的心情是无比失落的。

而ElasticSearch的使用是相当广泛的,我们熟知的世界最大同性交友网站也是使用它来实现搜索功能的,所以可以断定是我的使用方法有问题,要么是我选的版本不稳定,要么是其他的原因,而稳定版一般出问题的几率不大,因此在换版本之前,需要找其他方面的原因,很久之前看过一篇google的slide,上面有一页介绍了不同介质数据的传输速度:外网的传输速度在10ms级别,而内网却在20微秒级,这种速度的差异便会造成以下几个方面的影响

  • 集群无法提供正常服务:因为每个请求,ElasticSearch节点都会经过转发和收集两个过程,如果使用外网网卡,便会造成延迟大,访问量上不去,而流量到达一定程度后,集群很快便无法提供正常服务
  • 由于ES集群已经无法正常服务,所以down机、恢复困难一系列综合症的情况便会陆续发生

后续我将集群切到了内网中,再测试重启某一个节点,便不会再出现恢复一个节点需要半天的情况了。

slide

未使用队列或logstash,导致数据丢失

最初用到的架构非常简单: 使用ES(ElasticSearch缩写)集群作为存储,beats和rsyslog作为shipper向ES集群发送数据,使用这种架构的主要原因是配置简单,ES本身是一个高可用集群,直接把数据发过去就好。而自己心里还产生了为什么会有ELK架构,感觉Logstash是多余的想法,在发生了几次down机之后,才发现之前的想法很傻很天真,之前的架构也有明显的问题

old

  • 在某一个节点down掉后,如果不马上恢复,在不了解beats负载均衡机制的前提之下,很难判断数据还会不会发送给down掉的节点,而新增一个节点,需要修改所有beat的配置,即这里至少要使用一个负载均衡器给所有ES节点做负载均衡
  • ES是一个高可用集群,但目前还没有足够的使用经验,所以可能今后还会出现集群故障的问题,而出故障,很可能造成数据的丢失,为了避免这种情况发生,需要在beats和ES集群之间构建一套可持久化的队列,最简单的队列是redis,而logstash放在redis两边分别作为生产者和消费者。想到的方案便是beats->logstash->redis->logstash->ES,这样便解决了丢数据的问题,当然最新版的logstash可以将数据持久化到磁盘上,也许可以对此模型进行简化

Logstash和Redis的使用都非常简单,这里就不一一介绍,值得注意的是,如果要使用redis做持久化,需要使用Redis的List的方式,而不是Sub-Pub的方式,以下是具体的架构图,箭头的方向是数据流动的方向。

new

Master和DataNode未分离,导致集群不稳定

在ES集群中,节点分为Master、DataNode、Client等几种角色,任何一个节点都可以同时具备以上所有角色,其中比较重要的角色为Master和DataNode:

  • Master主要管理集群信息、primary分片和replica分片信息、维护index信息。
  • DataNode用来存储数据,维护倒排索引,提供数据检索等。

可以看到元信息都在Master上面,如果Master挂掉了,该Master含有的所有Index都无法访问,文档中说,为了保证Master稳定,需要将Master和Node分离。而构建master集群可能会产生一种叫做脑裂的问题,为了防止脑裂,需要设置最小master的节点数为eligible_master_number/2 + 1

脑裂的概念:
如果你有2个Master候选节点,并设置最小Master节点数为1,则当网络抖动或偶然断开时,2个Master都会认为另一个Master挂掉了,他们都被选举为主Master,则此时集群中存在两个主Master,即物理上1个集群变成了逻辑上的2个集群,而当其中一个Master再次挂掉时,即便它恢复后回到了原有的集群,在它作为主Master期间写入的数据都会丢失,因为它上面维护了Index信息。

根据以上理论,我对集群做了如下更改,额外选取3个独立的机器作为Master节点,修改elasticsearch.yml配置

 

node.master = true
node.data = false
discovery.zen.minimum_master_nodes = 2

修改其他节点配置,将其设置为DataNode,最后挨个重启

 

node.master = false
node.data = true

Logstash吞吐量问题

在使用了新的架构后,我发现了当流量上来后,Redis的队列会持续增长,消费速度跟不上生产速度,造成的问题是数据在Redis中堆积,图表展示有大量的延迟。解决这个问题有以下几个思路

  1. 可能是ES插入速度太慢,需要调整参数提升插入性能
  2. 可能是Logstash吞吐量低,需要增加每次向Redis拿数据的缓存、增加向ES输出的缓存、增加线程数、增加每次批量操作的content length

对于ES调优中,我调整了线程数,增加线程队列,增大shard数,但都没有解决问题。

而Logstash调优,我首先调整了LS_HEAP_SIZE参数,让Logstash可以同时处理大量的数据,然后主要专注在调整Logstash的Input和Output插件参数上,插件中可以设置线程数、batch_count数值等,而当我将Redis插件参数改为batch_count=>10000后,发现队列不再一直增长了,它会涨到一定程度后,瞬间减少到2-3位数,即队列的长度在一定范围内浮动,当时欣喜若狂,以为自己解决了,但跑了大概5个小时候,发现队列又开始不断增长了,问题并没有得到解决。而产生解决了的假象应该是我增加了Logstash内存的原因,数据只是先把Logstash内存填满,再开始填队列,而填满Logstash内存花了几个小时,关键的Logstash到ES的吞吐量还是没有上去,在access日志中,无论如何也无法让bulk API的content length增加,如下图中的长度一直维持在2K左右。

accesslog

最后,我采用了替换Logstash版本的策略,更新了时下最新的5.1.1版本,由于新版的配置和旧版配置不一样,所以认真研究了一下配置,在这个过程中,我发现了一个-b参数可以修改批量插入的大小,也许就是我需要的。果然,将这个参数由默认的125改为了1000,顺利的解决了这个难题,同时也证明了并不是版本问题,还是使用问题,而这个参数也正是修改content length的方法,顺便说一下,如果你使用nginx作为负载均衡器,你需要同时增加client_max_body_size参数,避免产生content length过大而返回413错误码。

Logstash如何创建Mapping

当使用Logstash进行转发时,有可能你的数据都在一个Index中,当然你也可以设置不同的Index,这篇文章中就有根据type来划分Index的方法,不管划不划分Index,都会默认生成一个或多个mapping结构,mapping结和不同的type即对应MySQL中的数据库和表结构信息,当然我这里不是为了说明它们的区别,而是我们无法自定义字段的类型。

这会产生各种各样的问题,比如它会默认产生analyzed类型的string字段,会自动将带有连接符的字符串分为两个字符串输出,即"idc-1"这样的字符串会输出为"idc"和"1",这并不是我想要的,让我相当困扰,而Mapping在生成后是无法修改字段的,除非你换一个新的字段。

解决这个问题的方法并不在mapping上,而我却花了很多时间在这个上面,最终答案却是使用template,在template中可以定义你需要的mapping,这样便解决以上问题。到此,我还是不能完全理解里面的机制,以后抽空了解后再补上。

head插件安装失败

上文有介绍head插件,它是一个可以显示集群状态及操作ES集群的UI,可以取代官方的X-Pack,后者只有30天的试用期,因为创业公司,能用免费的尽量采用免费的。在集群中,有几个节点安装该插件会失败,提示:Unable to veryfy checksum for download plugin ...,google上查了一圈仍然没有找到解决办法,最后试着手动将该插件下载然后解压到/usr/share/elasticsearch/plugins/目录下,并将目录改为head即可解决该问题。

以上问题是我这段时间来碰到的坑,每个都花了不少时间去解决,自己也比较幸运,花在上面的时间没有白费。因为个人觉得这个技术栈实在是比较好,而资料主要以英文的为主,把自己的经历写下来,希望今后不再犯同样的错误,也希望可以帮助其他使用该技术的同学。


http://www.taodudu.cc/news/show-8456979.html

相关文章:

  • 代码注释之程序猿天真可爱无国界!
  • 一文看懂TCP/IP中的相关知识
  • 开发数据产品+AI产品通关上岸课程
  • AI产品经理-借力
  • 七种令人惊叹的人工智能工具
  • cin.ignore()
  • delete 与 delete[ ] 区别
  • C++信号处理 [ signal()函数 raise()函数 ]
  • C++存储类
  • 第13章 宣泄的拥抱
  • 【附源码】Java计算机毕业设计喜枫日料店自助点餐系统(程序+LW+部署)
  • Java实现餐厅自助点餐系统【附源码】
  • 微信小程序java高校食堂窗口自助点餐系统uniapp
  • 基于微信小程序的食堂窗口自助点餐系统设计与实现-计算机毕业设计源码+LW文档
  • 自助点餐系统(三)
  • JAVA实现自助点餐系统【附源码】
  • 【Vue H5项目实战】从0到1的自助点餐系统—— 项目页面布局(Vue3.2 + Vite + TS + Vant + Pinia + Nodejs + MongoDB)
  • P5706 【深基2.例8】再分肥宅水 C语言
  • 再分肥宅水
  • (JAVA)P5706 【深基2.例8】再分肥宅水
  • 【洛谷算法题】P5706-再分肥宅水【入门1顺序结构】Java题解
  • 洛谷P5706 再分肥宅水
  • (已更新)市肥宅中心论坛类小程序源码 apache协议开源
  • 从Hello world到算法! 第12题【再分肥宅水】
  • 知乎网论文重查入口 快码论文
  • 维普论文查重入口降重
  • 维普论文查重入口官网?paperpass降重后的报告怎么下载
  • 犹如白皮书般详细的Css文本控制总结
  • IDT + FisherVector (by C++)我的实践
  • java语言中数组中的每个数据称为_一、Java语言基础(4)_方法和数组——数组...