小菜鸟

name相同问题

发表于 2022-07-27 更新于 2025-08-20 分类于微服务阅读次数： Valine：
本文字数： 2.9k 阅读时长 ≈ 3 分钟

OpenFeign 中 @FeignClient 名称冲突问题：contextId 的解决方案

在使用 OpenFeign 时，若多个@FeignClient接口的name（或value）属性相同，会导致 Spring 容器中 Bean 名称冲突，启动时报错：A bean with that name has already been defined and overriding is disabled。通过contextId属性可解决这一问题，本文将详细解析其原理和用法。

问题根源：Bean 名称生成规则

OpenFeign 在注册@FeignClient接口的配置 Bean 时，会根据特定规则生成 Bean 名称。核心逻辑在FeignClientsRegistrar类中，具体步骤如下：

获取客户端标识（clientName）
调用getClientName(Map<String, Object> client)方法生成唯一标识，优先级为：
contextId > value > name > serviceId
即：若配置了contextId则优先使用，否则依次 fallback 到value、name、serviceId。

// FeignClientsRegistrar.getClientName() 核心逻辑
private String getClientName(Map<String, Object> client) {
    String value = (String) client.get("contextId"); // 优先取contextId
    if (!StringUtils.hasText(value)) {
        value = (String) client.get("value"); // 其次取value
    }
    if (!StringUtils.hasText(value)) {
        value = (String) client.get("name"); // 再取name
    }
    if (!StringUtils.hasText(value)) {
        value = (String) client.get("serviceId"); // 最后取serviceId（已废弃）
    }
    // ... 校验逻辑
    return value;
}

注册配置 Bean
生成的clientName会作为 Bean 名称的前缀，拼接固定后缀FeignClientSpecification，最终注册到 Spring 容器：

阅读全文 »

查询优化

发表于 2022-07-27 更新于 2025-08-13 分类于 Elasticsearch 阅读次数： Valine：
本文字数： 3.7k 阅读时长 ≈ 3 分钟

Elasticsearch 6.x 查询优化：提升检索效率的核心策略

Elasticsearch 的查询性能直接影响业务响应速度，尤其在大规模数据场景下，优化查询链路、减少资源消耗至关重要。本文结合 6.x 版本特性，从缓存利用、慢查询诊断、文档模型设计等维度，详解查询优化的实用方案。

高效利用查询缓存：减少重复计算

Elasticsearch 内置多种缓存机制，可自动缓存高频查询结果，避免重复执行相同计算。合理配置缓存策略，能显著降低 CPU 和 IO 开销。

缓存类型及适用场景

Elasticsearch 6.x 主要依赖两种查询缓存：

缓存类型	作用范围	适用场景	缓存策略
Filter 缓存	过滤条件（`filter` 子句）	频繁执行的固定过滤条件（如状态、时间范围）	LRU（最近最少使用）淘汰
请求缓存	聚合结果、`count` 等无排序查询	高频聚合查询（如仪表盘统计）	基于查询哈希缓存结果

核心配置与优化

（1）启用 Filter 缓存

Filter 缓存默认开启，可通过以下配置调整缓存大小（占堆内存比例）：

1 2	# elasticsearch.yml 中配置 indices.queries.cache.size: 25% # 默认为10%，可提升至20%-30%（不超过堆内存的50%）

注意：仅 filter 子句会被缓存（query 子句因需计算得分，不缓存），建议优先用 filter 处理固定条件。

（2）启用请求缓存（Request Cache）

请求缓存默认对所有索引开启，缓存无排序的聚合、count 等查询结果：

阅读全文 »

分布式环境下面临的问题

发表于 2022-07-24 更新于 2025-07-31 分类于分布式阅读次数： Valine：
本文字数： 1.8k 阅读时长 ≈ 2 分钟

分布式环境下的核心挑战与复杂性

分布式系统通过将任务分散到多个节点协同工作，实现了算力、存储和可用性的扩展，但也因节点间的网络交互引入了单机系统不存在的复杂性。以下从底层问题出发，系统梳理分布式环境面临的核心挑战：

通信异常：分布式系统的 “天然短板”

分布式系统的节点间依赖网络通信，而网络本身的不确定性是所有问题的根源：

高延迟：跨节点请求需经过路由转发、协议解析等过程，延迟通常是单机内存操作的数万倍（毫秒级 vs 纳秒级），直接影响系统响应速度。
不稳定性：网络抖动、带宽波动可能导致数据包丢失或乱序，即使是稳定的局域网，也存在瞬时故障的概率。
成本叠加：复杂业务往往需要多节点协同（如微服务调用链），一次用户请求可能涉及数十次跨节点通信，任何一次通信异常都会放大整体失败风险。

网络分区（脑裂）：节点间的 “信息孤岛”

当网络故障导致系统被分割为多个独立子网（即 “网络分区”），各子网内的节点能正常通信，但子网间完全隔离，此时会引发 “脑裂” 问题：

集群管理混乱：若集群存在主节点（如分布式锁的协调者、数据库主库），各分区可能会独立选举新主节点，导致 “多主并存”，数据写入出现冲突。
数据一致性破坏：分区内的节点可能基于 “局部信息” 做出决策（如扣减库存），当网络恢复后，不同分区的操作结果无法合并，导致全局数据不一致。

示例：分布式存储系统中，若网络分区后两个子集群分别写入同一份数据，恢复连接后会面临 “数据版本冲突”，需复杂的合并策略解决。

三态问题：请求结果的 “薛定谔状态”

单机系统中，操作结果非成功即失败；但分布式环境中，由于网络延迟或故障，请求会出现第三种状态 ——超时，且无法判断超时的真实原因：

阅读全文 »

Shiro简介

发表于 2022-07-18 更新于 2025-08-22 分类于 Shiro 阅读次数： Valine：
本文字数： 4k 阅读时长 ≈ 4 分钟

Shiro 简介：轻量级 Java 安全框架的核心与实现

Apache Shiro 是一款功能强大且易于使用的开源安全框架，专注于解决 Java 应用中的身份认证、授权、会话管理和加密等安全问题。与 Spring Security 相比，Shiro 以其简洁的 API、灵活的配置和较低的学习成本，成为中小型应用和快速开发场景的首选安全框架。

Shiro 的核心功能

Shiro 围绕 “安全” 提供四大核心功能，覆盖了大多数应用的安全需求：

核心功能	说明
Authentication（身份认证）	验证用户身份（“你是谁”），如用户名密码登录、第三方登录（OAuth）等。
Authorization（授权）	控制用户权限（“你能做什么”），如判断用户是否有权限访问某个接口或按钮。
Session Management（会话管理）	管理用户会话（即使在非 Web 环境中），支持会话过期、存储、失效等。
Cryptography（加密）	提供安全的加密算法（如 MD5、SHA），用于密码加密、数据脱敏等。

Shiro 的架构与核心对象

Shiro 的架构设计清晰，通过一系列核心对象协同工作，实现安全功能。其整体架构如图所示，核心对象包括Subject、SecurityManager、Realms等。

1. 核心对象详解

（1）Subject

定义：与应用交互的 “当前操作用户”（可以是人类用户、第三方服务等）。
特点：
- 所有操作都通过Subject发起（如登录、权限验证）；
- 内部绑定到SecurityManager，实际功能由SecurityManager代理实现；
- 可通过SecurityUtils.getSubject()获取当前线程的Subject实例。