小菜鸟

ELK 日志管理系统：从架构到实战配置详解

在分布式系统中，日志分散在多个服务器节点，传统的单机日志查询方式效率极低。ELK（Elasticsearch、Logstash、Kibana）作为开源日志管理的标杆方案，通过日志采集、处理、存储、检索和可视化的全链路能力，实现了分布式日志的集中化管理。本文将深入解析 ELK 的架构、核心组件功能及实战配置。

ELK 架构与核心组件

ELK 并非单一工具，而是由三个互补组件构成的生态系统，形成 “日志采集→处理→存储→可视化” 的完整闭环：

（ELK 核心链路：日志源 → Logstash/Beats → Elasticsearch → Kibana）

1. Elasticsearch：分布式搜索与存储引擎

核心定位：日志的存储中心和检索引擎，基于 Lucene 实现分布式全文搜索。
关键特性：

• 分布式架构：自动分片（Shard）和副本（Replica），支持水平扩展和高可用；
• 实时索引：日志写入后秒级可查，支持复杂的聚合分析（如按时间统计错误数）；
• RESTful API：通过 HTTP+JSON 接口操作数据，易用性高；
• 动态映射：自动识别日志字段类型（如 IP、日期），无需预定义表结构。

2. Logstash：日志采集与处理管道

核心定位：日志的 “搬运工” 和 “清洁工”，负责从多源采集日志、过滤清洗、格式化后转发。
核心组件：

• Input：日志输入源（文件、Kafka、数据库、syslog 等）；
• Filter：日志处理层（解析非结构化日志、过滤无用字段、类型转换等）；
• Output：日志输出目的地（Elasticsearch、Kafka、HDFS 等）。
  特点：支持 200 + 插件，灵活性强，但资源消耗较高（适合后端服务器部署）。

3. Kibana：日志可视化与分析平台

核心定位：ELK 的 “前端界面”，提供日志检索、仪表盘、报表等可视化功能。
核心功能：

• Discover：实时搜索日志，支持模糊匹配、字段筛选；
• Visualize：生成柱状图、折线图、地图等可视化图表；
• Dashboard：组合多个图表，构建业务监控面板（如系统错误率趋势、接口响应时间分布）；
• Alerting：设置日志阈值告警（如 ERROR 日志 5 分钟内超过 100 条触发告警）。

ELK 核心组件配置实战

1. Elasticsearch 配置（elasticsearch.yml）

核心配置集中在集群管理、数据存储和网络设置：

Hadoop RPC：NameNode 和 DataNode 之间，是怎么”打电话”的？

Hadoop 是分布式系统，组件散落在不同节点上。

• NameNode 在 hadoop1 上
• DataNode 在 hadoop2、hadoop3 上
• ResourceManager 在 hadoop4 上

它们之间要通信——DataNode 要定期给 NameNode 发心跳、汇报块信息；Client 要向 NameNode 查文件位置。

它们怎么通信？ 靠 RPC（远程过程调用）。

RPC 做的事：让你调用远程机器上的方法，像调用本地方法一样。

// 本地调用：直接调
dataNode.sendHeartbeat(blockReport);

// 远程调用：看起来也是直接调，但实际上跨了网络
nameNodeProxy.sendHeartbeat(blockReport);  // 这个调用会跑到 NameNode 那台机器上执行

RPC 屏蔽了网络通信的细节——你不用管 Socket、不用管序列化、不用管连接管理，写代码的时候感觉像是在调本地方法。

四层架构概览：RPC 是怎么把本地调用”包装”成网络调用的

Hadoop RPC 采用分层设计，从下到上分为 序列化层、函数调用层、网络传输层 和 服务器端处理框架，每层专注于特定功能，共同支撑远程调用流程。

graph TD
    A[应用层<br/>远程方法调用] --> B[函数调用层<br/>反射+动态代理]
    B --> C[序列化层<br/>对象-字节流转换]
    C --> D[网络传输层<br/>TCP/IP 通信]
    D --> E[服务器端处理框架<br/>Reactor 事件驱动]
    note[四层协同 将本地方法调用转为跨节点通信]

MyBatis 缓存机制深度解析：从 Cache 接口到装饰器模式

MyBatis 缓存是提升查询性能的核心组件，通过减少重复数据库访问，大幅降低系统开销。其缓存体系基于 Cache 接口构建，采用 装饰器模式 实现 “基础存储 + 功能增强” 的灵活扩展，同时通过 CacheKey 保证缓存键的唯一性。从 “缓存体系架构→Cache 接口与实现→CacheKey 生成逻辑→实战配置” 四个维度，彻底拆解 MyBatis 缓存的底层机制。

MyBatis 缓存体系总览

MyBatis 提供 两级缓存，本质上均基于 Cache 接口实现，核心区别在于 “作用范围” 和 “生命周期”：

核心设计思想：装饰器模式

MyBatis 缓存的灵活性源于 装饰器模式：

• 基础组件：PerpetualCache 实现最基本的缓存存储（基于 HashMap），是所有缓存的 “底层容器”；
• 装饰器组件：如 LruCache（LRU 淘汰）、BlockingCache（并发控制）、SerializedCache（序列化）等，通过包装 PerpetualCache 或其他装饰器，动态增强缓存功能；
• 组合能力：可按需组合多个装饰器（如 “LRU 淘汰 + 序列化 + 日志”），满足复杂业务需求。

Cache 接口：缓存的标准定义

Cache 接口是 MyBatis 缓存的顶层规范，定义了缓存的 7 个核心行为，所有缓存实现类均需遵守该接口：

Hadoop 1.x 到 2.x：JobTracker 扛不住了，所以有了 YARN

Hadoop 1.x 能跑，但跑不大。

当集群从几十台扩展到几百台、几千台的时候，JobTracker 扛不住了——它既要管资源分配，又要管任务调度，还要管容错，一个节点撑所有，成了单点瓶颈。

2.x 的核心改进就一件事：把 JobTracker 拆了。

拆成 ResourceManager（管资源）和 ApplicationMaster（管单个作业）。这个拆分，就是 YARN。

1.x 的架构：JobTracker 一身兼两职

Hadoop 1.x 有三个核心模块：

• Common：通用工具库
• HDFS：分布式存储
• MapReduce：计算 + 资源调度，全在 JobTracker 身上

JobTracker 扛了三件事：

1. 资源管理：集群里谁有多少 CPU、多少内存，它管
2. 任务调度：每个 Map/Reduce 任务怎么分、怎么跑，它管
3. 容错处理：任务失败了怎么重试，它还管

这个设计在集群小的时候没问题，集群大了就出事了。

1.x 的三个硬伤

硬伤1：JobTracker 是单点瓶颈

所有任务调度、资源分配都要经过 JobTracker。集群到几百个节点时，JobTracker 的 CPU 和内存就被撑爆了，任务提交变慢、响应变慢，整个集群卡在 JobTracker 上。

硬伤2：JobTracker 挂了，整个集群瘫痪

1.x 的 JobTracker 没有备份机制。它一挂，所有正在跑的任务全失败，新的任务也提交不了。恢复只能重启，重启还要 replay 日志，期间集群不可用。

硬伤3：资源分配僵化，利用率低

1.x 把资源分成固定数量的 Map Slot 和 Reduce Slot：

• Map 任务只能用 Map Slot
• Reduce 任务只能用 Reduce Slot

如果 Map 任务跑完了，Map Slot 空着也不能给 Reduce 用；如果 Reduce 任务多，Reduce Slot 不够就只能排队。资源是固定的，不能灵活调配。

Hadoop 简介：分布式系统的基石，到底在解决什么问题？

数据量到了 PB 级，单机装不下，单机算不动。这就是 Hadoop 要解决的问题。

Hadoop 做了两件事：

• 存储：把数据分散到多台机器上存（HDFS）
• 计算：把任务分散到多台机器上算（MapReduce）

它把分布式系统的复杂度封装起来，让你写代码的时候感觉像是在操作单机——不用管节点挂了怎么办、数据怎么分片、任务怎么协调。

核心组件：存储和计算，各管一摊

Hadoop 由两个核心组件构成：HDFS（存）和 MapReduce（算）。一个管数据放哪，一个管数据怎么处理。

HDFS：数据怎么存

HDFS 是分布式文件系统，把大文件切成一块一块（默认 128MB），分散到不同节点上存，每块存多份副本防丢。

三个角色：

读写流程：

graph TD
    A[客户端 Client] -->|元数据操作/数据读写| B[NameNode<br/>主节点]
    A -->|数据块读写| C[DataNode1] & D[DataNode2] & E[DataNode3]
    B -->|元数据同步| F[SecondaryNameNode<br/>辅助节点]
    B -->|心跳检测/块报告| C & D & E
    note1[NameNode 管理元数据,不存储实际数据]
    note2[DataNode 存储数据块,执行读写操作]
    note3[SecondaryNameNode 辅助元数据管理,非备份]

• 写文件：Client 问 NameNode”块存哪” → NameNode 返回 DataNode 列表 → Client 直接写 DataNode
• 读文件：Client 问 NameNode”块在哪” → NameNode 返回 DataNode 列表 → Client 直接从 DataNode 读

关键点：NameNode 只传”地址”，不传”数据”。 数据读写都在 Client 和 DataNode 之间直接走，NameNode 不参与，不然它扛不住。