小菜鸟

Lucene 分析器（Analyzer）：文本处理的核心组件

Lucene 的分析器（Analyzer）是文本预处理的核心模块，负责将原始文本转换为可用于索引和检索的词项（Term）。它由字符映射器（Character Mapper）、分词器（Tokenizer） 和过滤器（Filter） 三部分组成，三者按顺序协同工作，形成完整的文本处理流水线。

字符映射器（Character Mapper）：文本预处理

字符映射器是分析器的第一个环节，作用于原始文本字符流，在分词前进行字符级别的预处理，确保后续分词和过滤的准确性。

核心功能

• 字符编码转换：将非 Unicode 编码（如 GBK）的文本转换为 Unicode，避免字符乱码。
• 非法字符过滤：移除不可打印字符（如控制字符、特殊符号）或自定义过滤规则（如过滤 emoji）。
• 字符标准化：统一字符形式（如将全角字符 “ａ” 转换为半角 “a”，或将 “℃” 转换为 “c”）。

特点

• 仅处理单个字符，不涉及词的拆分，是文本处理的 “第一道净化工序”。
• Lucene 中通常通过 CharFilter 抽象类实现，常见实现如 HTMLStripCharFilter（移除 HTML 标签）。

分词器（Tokenizer）：文本拆分为词条

分词器是分析器的核心环节，负责将预处理后的字符流拆分为词条（Token）—— 即包含词项文本及附加信息的单元。

核心功能

• 按规则拆分文本：根据语言特性或自定义规则拆分（如英文按空格 / 标点拆分，中文按词库拆分）。
• 记录词条元信息：为每个词条添加偏移量（在原始文本中的起止位置）、长度、类型（如 “数字”“英文单词”）等信息，用于后续检索和高亮显示。

常见实现

• StandardTokenizer：Lucene 默认分词器，支持多语言，能识别字母、数字、邮箱、IP 等格式，按非字母 / 数字字符拆分。
• WhitespaceTokenizer：仅按空格拆分，不处理标点（如 “hello,world” 拆分为 “hello,world”）。
• CJKTokenizer：针对中日韩语言的分词器，按双字拆分（如 “中国”→“中国”，“北京”→“北京”）。
• 自定义分词器：结合词库或机器学习模型（如 Jieba 分词的 Lucene 适配版），提升中文等复杂语言的分词精度。

过滤器（Filter）：词条流的精细化处理

过滤器接收分词器输出的词条流，对每个词条进行二次处理，进一步优化词项质量，使索引更精准、检索更高效。多个过滤器可串联使用，形成 “过滤链”。

Eureka 服务发现：微服务间通信的核心机制

在微服务架构中，服务发现是实现服务间动态通信的关键。Eureka 不仅提供服务注册功能，还通过 DiscoveryClient 组件让服务消费者能够自动发现注册中心中的可用服务实例，无需硬编码服务地址。本文详细介绍 Eureka 服务发现的实现方式与核心用法。

服务发现的核心作用

服务发现解决了以下问题：

• 动态地址管理：服务实例的 IP、端口可能动态变化（如扩容、迁移），消费者无需手动更新地址；
• 负载均衡基础：通过获取服务的多实例列表，消费者可实现简单的负载均衡（如轮询、随机）；
• 服务可用性校验：结合 Eureka 的健康检查，确保消费者只调用健康的服务实例。

Eureka 服务发现的实现方式

Eureka 服务发现主要通过 DiscoveryClient 接口实现，该接口由 Spring Cloud 提供，封装了与 Eureka Server 交互的细节。

1. 核心依赖

服务消费者需引入 Eureka Client 依赖（与服务注册的依赖一致）：

Eureka 架构深度解析：基于 AP 原则的服务发现设计

Eureka 作为 Netflix 开源的服务发现组件，其架构设计严格遵循AP 原则（可用性优先，兼顾分区容错性），通过独特的集群模式和自我保护机制，在分布式系统中实现了高可用的服务注册与发现能力。本文将从分布式系统的 CAP 取舍出发，详解 Eureka 的架构设计、核心机制及与 Zookeeper 的本质区别。

分布式系统的 CAP 取舍：为什么 Eureka 选择 AP？

在分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance） 三者不可兼得，必须根据业务场景取舍：

• 一致性（C）：所有节点同时看到相同的数据（强一致性）；
• 可用性（A）：集群中任一节点故障时，其他节点仍能正常响应请求；
• 分区容错性（P）：网络分区（部分节点通信中断）时，系统仍能继续工作（分布式系统必选）。

因此，分布式系统只能在 CP（优先一致性）或 AP（优先可用性）中选择：

• CP 系统：保证数据一致，但网络分区时可能暂时不可用（如 Zookeeper）；
• AP 系统：保证服务可用，但数据可能短暂不一致（最终一致）（如 Eureka）。

Spring Cloud：微服务架构的一站式解决方案

Spring Cloud 是基于 Spring Boot 的微服务生态系统，它整合了一系列组件，为微服务架构提供了完整的解决方案。从服务注册发现到配置管理，从负载均衡到熔断降级，Spring Cloud 简化了微服务开发的复杂性，成为企业级微服务架构的主流选择。

Spring Cloud 与微服务的关系

微服务是一种架构风格（将单体应用拆分为独立服务），而 Spring Cloud 是实现这种风格的技术集合。它基于 Spring Boot 的自动配置特性，提供了微服务所需的核心能力（如服务通信、容错、监控等），让开发者无需从零构建这些基础设施，专注于业务逻辑。

与 SOA 架构相比：

• SOA 依赖企业服务总线（ESB）整合服务，通信协议重（如 SOAP），服务粒度较粗；
• 微服务无需集中式总线，通过轻量级 API（如 REST）通信，服务粒度更细，且 Spring Cloud 提供了更灵活的服务治理能力。

Spring Cloud 的核心价值

Spring Cloud 的核心目标是解决微服务架构中的共性问题，主要体现在：

MyBatis 分页深度解析：从原理到工程实践（含自定义插件与 PageHelper 实战）

MyBatis 分页是企业级开发中高频需求，核心分为逻辑分页（内存分页）和物理分页（数据库层面分页）两类。系统梳理 MyBatis 分页的实现方式，包括逻辑分页原理、自定义物理分页插件深度解析、第三方插件（PageHelper）整合，以及工程化最佳实践，帮助你彻底掌握分页逻辑并规避性能陷阱。

MyBatis 分页的两种核心类型

在深入代码前，需先明确两种分页的本质区别，这是选择分页方案的基础：

逻辑分页：MyBatis 原生 RowBounds

RowBounds 是 MyBatis 内置的逻辑分页工具，无需额外配置，但仅适用于小数据量场景。

原理剖析

• 核心属性：offset（起始索引，默认 0）、limit（每页条数，默认 Integer.MAX_VALUE）；
• 执行流程：
  1. MyBatis 执行 SQL 时，先查询全表数据到 ResultSet；
  2. 通过 RowBounds 跳过 offset 条数据，读取 limit 条数据到内存；
  3. 丢弃剩余数据，返回截取后的结果。

使用示例

（1）Mapper 接口