小菜鸟

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 版本对比：架构演进与核心差异解析

Hadoop 从 1.x 到 2.x 的演进是一次架构级别的重大升级，核心目标是解决 1.x 版本的性能瓶颈和单点问题。本文将详细对比两个版本的组成结构、核心缺陷与改进，重点解析 2.x 引入的 YARN 架构如何重塑 Hadoop 的资源管理与任务调度能力。

hadoop1.x版本：基础架构与核心缺陷

Hadoop 1.x 是 Hadoop 的早期版本，奠定了分布式存储与计算的基础，但架构设计存在明显局限性。

1.x 核心组成

Hadoop 1.x 由三个核心模块构成，形成 “存储 - 计算 - 工具” 的基础架构：

• Common：提供 Hadoop 各组件通用的工具类（如 I/O 操作、配置管理、安全机制等），是其他模块的基础依赖。
• HDFS（Hadoop Distributed File System）：分布式文件系统，负责海量数据的存储，核心组件为 NameNode（主节点）和 DataNode（从节点）。
• MapReduce：集 “计算框架” 与 “资源调度” 于一体的模块，负责分布式任务的拆分、并行执行和结果聚合。

1.x 架构缺陷：为何需要升级？

Hadoop 1.x 的 MapReduce 架构存在三大核心问题，严重限制了集群的扩展性和性能：

1. JobTracker 成为系统瓶颈

在 1.x 中，JobTracker 同时承担两大核心职责：

• 资源管理：负责集群中 CPU、内存等资源的分配与监控；
• 作业控制：负责 MapReduce 任务的拆分（Map/Reduce 阶段）、任务调度、进度跟踪和容错。

这种 “一身二任” 的设计导致 JobTracker 成为集群的性能瓶颈，尤其在大规模集群（数千节点）中，JobTracker 的内存和 CPU 压力极大，难以支撑高并发任务。

Hadoop简介：分布式系统的基石与核心架构详解

Hadoop 作为 Apache 基金会开发的分布式系统基础架构，彻底改变了海量数据的存储与处理方式。它允许用户在不深入了解分布式底层细节的情况下，轻松开发分布式程序，充分利用集群的算力和存储能力。本文将从 Hadoop 的核心组成、架构原理、配置实践到适用场景进行全面解析，帮你快速掌握 Hadoop 的核心知识。

Hadoop 核心价值：为什么选择 Hadoop？

在大数据时代，传统单机系统无法应对 PB 级甚至 EB 级数据的存储和计算需求。Hadoop 的出现解决了三大核心问题：

• 分布式存储：通过 HDFS 实现海量数据的分布式存储，突破单机存储上限；
• 分布式计算：通过 MapReduce 框架将复杂任务分解为并行子任务，利用集群算力高效处理；
• 易用性：屏蔽分布式底层细节，开发者只需关注业务逻辑，无需手动管理节点通信、数据分片等问题。

Log4j2 与 Kafka 集成：实时日志收集方案

将 Log4j2 与 Kafka 集成，可实现日志的实时收集与分布式处理，为日志分析、监控告警等场景提供数据基础。以下是具体实现细节与实践要点：

集成准备：依赖与核心组件

必要依赖

• kafka-clients：提供 Kafka 生产者客户端功能，负责将日志消息发送到 Kafka 集群。
• log4j-core：Log4j2 核心库，内置 KafkaAppender（全类名 org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender），实现日志到 Kafka 的输出。

1
2
3
4
5
6
7
8
9
10
11

<!-- Maven 依赖配置 -->
<dependency>
  <groupId>org.apache.kafka</groupId>
  <artifactId>kafka-clients</artifactId>
  <version>2.6.0</version> <!-- 需与 Kafka 集群版本兼容 -->
</dependency>
<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.11.1</version>
</dependency>

核心原理

KafkaAppender 作为 Log4j2 的输出组件，其工作流程如下：

1. 应用程序通过 Log4j2 的 Logger 接口记录日志（如 LOGGER.info("测试日志")）。
2. Log4j2 捕获日志事件，传递给 KafkaAppender。
3. KafkaAppender 内部初始化 Kafka 生产者，根据配置将日志格式化后发送到指定主题。
4. 日志消息持久化到 Kafka 分区，供下游系统（如 Flink、Elasticsearch）消费处理。

Log4j2 配置详解

配置文件（通常为 log4j2.xml）需定义日志输出格式、Kafka 连接信息及日志级别，示例配置解析如下：

传输层简析：数据传输的可靠保障与核心协议

传输层是 TCP/IP 协议栈中承上启下的关键层级，位于网络层之上、应用层之下，负责为应用程序提供端到端的高效数据传输服务。它弥补了网络层（如 IP 协议）的不可靠性，通过封装复杂的控制逻辑，为上层应用屏蔽了底层网络的细节差异。无论是浏览网页、发送邮件还是视频通话，都依赖传输层协议确保数据准确、有序地到达目的地。

传输层的核心作用

传输层的设计目标是解决 “端到端数据传输的可靠性与效率” 问题，具体功能包括：

1. 可靠传输保障：
   网络层（如 IP 协议）仅负责将数据包从源地址传送到目标地址，不保证数据不丢失、不重复、按序到达。传输层通过差错控制（如校验和）、重传机制（如超时重传）和顺序控制（如序号与确认号），确保数据完整、有序地交付给应用层。
2. 流量与拥塞控制：
   根据接收方的处理能力（流量控制）和网络负载情况（拥塞控制），动态调整发送速率，避免接收方缓冲区溢出或网络因过载而瘫痪。
3. 端到端通信标识：
   通过 “端口号” 区分同一设备上的不同应用程序（如 HTTP 用 80 端口，HTTPS 用 443 端口），确保数据能准确交付给目标应用。
4. 两种服务模式：
   提供面向连接（如 TCP）和无连接（如 UDP）两种服务，满足不同应用对可靠性和效率的需求（如文件传输需要可靠传输，视频通话更注重实时性）。

传输层与网络层的本质区别

传输层与网络层均涉及 “数据传输”，但核心定位截然不同：