软件设计：Elasticsearch实战-磁盘IO被打满

作者:编程一生更新于： 2020-04-13 15:58:29

　　ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTfulweb接口。Elasticsearch是用java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。

　　背景

　　事情是这样的。一天下午4点42分左右。业务反馈我开发的服务在测试环境出现问题，返回资源数据是0。查日志发现是ES访问超时。相当于数据库挂了。持续了20多分钟自己恢复。

　　咨询了ES团队，最终得到下面的答复：

　　当前集群现状:

　　1）当前集群数据IO最高的索引为XXX，数据量很小(100mb)

　　2)但是读写都很大(读>1000QPS,写>1000QPS)，使用的是线下环境的机器

　　3)索引分了10个片，4个副本问题

　　分析:

　　1)线下环境的机器之前了解到测试环境硬盘性能本来就很差,这个需要业务SRE一块来确定

　　2)查询的时候，会一次性查询10个片，这样可能会查10台机器的数据，很容易出现木桶效应，造成集群的性能下降

　　3)写入的时候，虽然是做了10个分片，看起来能加大写能力，但是机器数少，导致结果是每台机器分布了5个分片，等效于只做了2个分片，完全没有扩大写的能力

　　建议:

　　1)升级硬件，换成SSD

　　2)分片改成2个，这样读能力比以前肯定有提升，写能力等价

　　3)数据量很小，建议直接换成Redis

　　我自己做了调查。测试环境ES有十台VM（非本地ESB磁盘）作为服务器。其中一台IO被打满。其他机器负载、IO都很低。对于这个问题，ES团队给出的答复是：

　　ES的服务负载均衡、发现机制是自己写的，一般不会出现问题，

　　Client仅仅对官方的客户端做了简单的封装，

　　当然最好是可以对官方的客户端进行改造，

　　但是我们现在的人力明显不行，只能继续沿用老的客户端使用；

　　我们预计在10月份左右会出一个自研的客户端，

　　会尽量避免出现一台机器导致部分查询出现问题，

　　但是也避免不了，

　　ES内部的服务发现机制，我们改变不了，除非改ES

　　调查

　　1.需要换成本地磁盘，测试环境也是我们的正式环境。是否能直接替换成物理机？多少台合适？怎么可以平滑替换？

　　没有必要换成物理机。因为ES内存最多能用32G。内存多出来的是浪费用不上，有物理机也是隔成VM来用。

　　原来10台VM是足够的，只需要同等数量替换。

　　有机器替换功能。替换时原理是先申请机器部署。然后点击机器替换。会一台台的将分片赶到新机器上。一台下完自动下线老机器。

　　2.我们测试环境有10台服务器，10个分片，4个副本，写/读QPS大概是7：6。究竟几个分片几个索引更合理？

　　因为每个分片和副本是同步写。写比例大，副本多会对性能有很大影响。分片替换需要重建索引，很难平滑。所以只将副本数减少为一个分片1个。

　　3.程序方面有没有可以优化的？

　　在ES上层增加tair缓存。在进行数据更新操作时是单个数据读取。采用tair有更好的事务性，并减少了对ES的压力。ES只处理复杂查询请求。

　　我们建立一个网站或应用程序，并要添加搜索功能，但是想要完成搜索工作的创建是非常困难的。我们希望搜索解决方案要运行速度快，我们希望能有一个零配置和一个完全免费的搜索模式，我们希望能够简单地使用JSON通过HTTP来索引数据，我们希望我们的搜索服务器始终可用，我们希望能够从一台开始并扩展到数百台，我们要实时搜索，我们要简单的多租户，我们希望建立一个云的解决方案。因此我们利用Elasticsearch来解决所有这些问题及可能出现的更多其它问题。