背景介绍：
改造前
1.网关异步向mq发报文数据；
2.monitor-proxy监听mq获取报文数据，解析后入库(db2，报文数据包含xml请求报文和一些概要信息)；
生产上部署15个监控代理实例，交易量7000w每天；数据库主备，磁盘容量10T左右；
问题：
1.交易量大的情况下，导致很多批量插入等待，数据库服务器资源紧张；
2.交易量会越来越大，数据库存储容量扩展困难；
3.数据量大，监控管理查询很慢（100w，查询大概需要5分钟）；
针对以上3个问题，最后谈论使用elasticsearch存储和查询监控数据。改造后：
改造后的
监控代理使用es java api根据当天日期建立索引，批量向es集群中插入数据；
分词用默认分词，mapping自动映射，为了后续增加需求方便，不需要直接修改代码；
es中批量处理有两种方式：1.根据提供的批量处理器(processor)可设置条数阈值，数据大小阈值，自动触发提交；
2.使用批量处理api，手动提交数据；
我们使用第二种，第一种存在问题，当条数没有达到阈值时，是不会提交的，可能数据延迟很严重，不符合我们查询近实时性；我们的监控代理使用队列存储从mq获取的数据，线程池从队列里获取数据入es，入es就有chunksize。
es从index buffer刷新到文件系统缓存（filesystem cache）设置是60s；这个设置比较重要，应该根据需求设置，影响es服务器资源。
es-gateway对外提供查询数据rest服务，查询有字段匹配，短语查询，分词查询。
es容量规划，数据备份等，都是根据实际需求。
压测es和监控代理，es集群稳定性测试，注意：在es master主节点挂掉后，会有短暂的影响（1-2s）会停止服务，如果交易量比较频繁，比较大，应该保障es集群的稳定性；压测es，1使用jmeter压测，我们es机器比较差4c 7g，es tps达到2w/s。
网友评论