谈谈ELK具体是啥

原创已于 2024-11-26 15:23:50 修改

· 1k 阅读

27 ·

版权

文章标签：

#elk #redis #java #spring #数据库 #缓存 #全文检索

于 2024-11-11 08:00:00 首次发布

MySQL数据库基础知识大全专栏收录该内容

44 篇文章

订阅专栏

一、ElasticSearch

提供了一个分布式的全文搜素引擎
是基于Lucence(java语言开发的)实现的
基于Restful web接口
基于倒排索引的理念
索引(index):就是一类文档对象的集合，对应的是表
文档(document)：对应的一条一条的数据
IK中文分词器：ik_smart、ik_max_word

二、LogStash主要组件

Shipper:日志收集

负责监控本地日志文件的变化，及时把日志文件的最新内容收集起来

通常，远程代理端(agent)只需要运行这个组件即可
Indexer:日志存储

负责接受日志并写入到本地文件
Search and Storage

允许对事件进行搜索和存储
Web Interface

基于web的展示界面

三、Kibana

3.1 Kibana概述

一个针对ElasticSearch的开源分析及可视化平台
搜索、查看存储在ElasticSearch索引中的数据
通过各种图标进行高级数据分析及展示
让海量数据更容易理解
操作简单，基于浏览器可以让用户在界面中快速的创建仪表盘(dashbroad)实时展示ElasticSearch查询动态

3.2 Kibana主要功能

ElasticSearch无缝集成。Kibana架构为ElasticSearch定制，可以将任何结构化和非结构化加入ElasticSearch索引，Kibana还充分利用了ElasticSearch的强大搜索和分析功能
整合数据，复杂数据分析：可以根据海量数据创建柱形图、饼图、折线图等等，提升了ElasticSearch分析能力。
数据可视化还可以让业务各个岗位都可以直观的了解数据
接口灵活
配置简单，可视化多数据源
简单数据导出

大数据中比较推荐Flume来收集日志。

四、Echarts可视化工具

apache是一个软件基金会，里面都是开源的，是不同组织或者个人或者公司贡献的
kafka消息中间件，大数据领域中80%选择使用kafka
RabbitMQ:消息队列，保证消息的顺序性，异步实现，有延迟的特性，工作模式(简单模式、工作队列模式、发布订阅模式、路由模式、主题模式、RPC模式)

工作队列模式：消息在多个消费者之间进行轮询消费，每个消费者消费的数据是不一样的。合理分发数据(ack+qos)
路由模式：生产者将数据发送到交换机，通过交换机将数据发送到指定的队列中(路由键和绑定键进行匹配)，多个消费者可以消费到同样的数据。
发布订阅模式：群发
主题模式：升级版的路由模式
Message Queue：消息队列，存储消息数据
Exchange：交换机。常用三种类型：direct、fanout、topic。根据不同的路由规则将数据路由到队列中
RoutingKey:路由键，需要和BandingKey一起使用
BandingKey：绑定键，绑定队列和交换机
虚拟主机：RabbitMQ中管理资源
Redis：可以做缓存，可以做数据库，是非关系型数据库，单线程，键值型
基于内存存储的，不安全，需要持久化，Redis支持持久化策略有两种：RDB、AOF
缓存遇到的问题：缓存穿透、缓存击穿、缓存雪崩、缓存一致性问题
缓存一致性：我们使用缓存时，先查询缓存，缓存中没有数据才会查询数据库。如果缓存数据是存在的，但是数据库中数更新了，用户是读取不到新数据的，也就是说缓存和数据库中的数据不一致了。

五、解决缓存一致性问题，目前有四种解决方案

第一种方案：先更新缓存，再写数据库

这种方案是最差的一种方案，因为写数据库失败了，缓存中会有脏数据

第二种方案：先写数据库，再更新缓存

写数据库失败的概率比写缓存失败概率高的多，因为数据库有很多约束，比如外键、锁、超时特性

如果写数据库失败了，缓存也不会更新，这样数据还是一致的。

如果写数据库成功了，但是缓存失败了，可以下次请求再写入缓存，或者写在一个事务中

所以第一种要比第二个方法好的多

但是会造系统资源的浪费，因为写缓存的内容是需要进行复杂的计算或者是筛选出来的数据。尤其是写多读少的场景，浪费的系统资源更严重。

既然更新缓存比较浪费系统资源，用删除来代替

第三种方案：先删除缓存，再写数据库

基本上没有什么问题，但是可能遇到这种情况，就是写请求删除完缓存后，再写数据库中卡顿了，还没有写完数据库，这个时候一个读请求过来，会读取到数据库的旧值并写入到缓存中。之后读请求的写数据库成功。那么就会造成缓存不一致的问题发生，我们可以采取延迟双删，再写完数据库后再删除一次缓存，但是第二次删除需要评估系统处理读和写请求的时间，根据这个时间进行sleep time的设置。

第四种方案：先写数据库，再删除缓存

基本没有什么问题，最多读取到一次脏数据。我们在使用缓存时是可以容忍极低概率的脏数据

但是还有一种问题：缓存失效

读请求写缓存卡顿了，然后写请求写执行完(删除缓存了)，读请求才把旧值写入到缓存中。但是这种情况出现的概率的是极低，读的速度一般都比写的速度快。而且还是刚好缓存失效。