小菜鸟

接口幂等性设计：确保重复请求安全处理的完整方案

接口幂等性是分布式系统设计中的关键特性，指多次执行相同请求时，系统最终状态与执行一次相同。这一特性可有效避免因网络重试、用户误操作等导致的数据重复或状态异常。本文将分析重复请求的成因，并提供从前端到后端的完整解决方案。

重复请求的常见场景

重复请求的产生可能源于客户端、网络或服务端，典型场景包括：

1. 客户端操作失误：
   • 用户快速点击提交按钮；
   • 刷新页面、使用后退 / 前进按钮重复提交表单；
   • 浏览器历史记录重复提交。
2. 网络与重试机制：
   • 网络延迟导致客户端未收到响应，触发重试；
   • 分布式系统中的请求重试机制（如 Feign 重试、消息队列重试）。
3. 系统设计缺陷：
   • 前端未禁用重复提交；
   • 后端未处理重复请求，导致重复写入数据库。

接口幂等性解决方案

确保幂等性需从前端防重和后端校验两方面入手，形成多层防护。

1. 前端防重：减少重复请求产生

前端是防止重复请求的第一道防线，通过限制用户操作和请求发送，从源头减少重复请求。

（1）禁用提交按钮

点击提交后立即禁用按钮，防止短时间内重复点击：

Elasticsearch Java API 全解析：从 TransportClient 到 RestHighLevelClient

Elasticsearch 提供了多种 Java API 用于与集群交互，其中 TransportClient（已过时）和 RestHighLevelClient（推荐）是最常用的两种。本文详细讲解这两种客户端的使用方法，包括索引管理、文档操作、查询等核心功能。

TransportClient（过时，了解即可）

TransportClient 基于 TCP 协议与 Elasticsearch 集群通信，在 Elasticsearch 7.0 后被标记为过时，8.0 完全移除。但部分旧系统仍在使用，此处简要介绍其核心用法。

依赖配置

1
2
3
4
5

<dependency>
    <groupId>org.elasticsearch.client</groupId>
    <artifactId>transport</artifactId>
    <version>5.4.0</version> <!-- 需与 Elasticsearch 版本匹配 -->
</dependency>

客户端初始化

1
2
3
4
5
6
7
8
9
10

import org.elasticsearch.client.transport.TransportClient;
import org.elasticsearch.common.settings.Settings;
import org.elasticsearch.common.transport.InetSocketTransportAddress;
import java.net.InetAddress;

// 创建客户端（连接到本地 9300 端口，Transport 协议默认端口）
TransportClient client = new PreBuiltTransportClient(Settings.EMPTY)
    .addTransportAddress(new InetSocketTransportAddress(
        InetAddress.getLocalHost(), 9300
    ));

核心操作示例

（1）索引管理

Elasticsearch 脑裂问题：原理、成因与解决方案

在 Elasticsearch 集群中，脑裂（Split Brain） 是一种严重的集群异常状态，指集群中同时存在多个主节点（Master），导致数据分片分配、请求路由混乱，最终引发数据不一致。本文详细解析脑裂的成因、检测方法及根治方案。

什么是脑裂？

Elasticsearch 集群依赖单一主节点（Master）维护集群状态（如分片分配、节点信息）。正常情况下，主节点由候选主节点（Master Eligible Node）选举产生，且集群中始终只有一个主节点。

脑裂发生时：
由于网络分区或节点通信中断，集群被分割成多个独立子集群。每个子集群都认为原主节点已宕机，从而各自选举出新的主节点。此时，集群中出现多个主节点，各自维护一套集群状态，导致：

• 数据写入分散在不同子集群，无法同步。
• 搜索请求命中不同主节点时，返回结果不一致。
• 分片分配混乱，可能出现重复或丢失。

脑裂的常见成因

网络问题（最主要原因）

• 网络延迟 / 分区：集群节点间网络不稳定（如交换机故障、防火墙拦截），导致部分节点无法与主节点通信。
• 网络超时：节点间心跳检测（Ping）超时，误认为主节点宕机。

节点负载过高

• 若主节点同时承担数据存储和计算任务（即既是 Master 又是 Data Node），当流量激增时，主节点可能因 CPU / 内存耗尽而 “假死”（无法响应心跳）。
• 其他节点长时间未收到主节点响应，判定主节点宕机，触发新主节点选举。

跨域问题详解：原因与解决方案

在 Web 开发中，跨域是前端与后端交互时常见的问题，其根源是浏览器的同源策略。本文将详细解释跨域的定义、产生原因，并提供多种解决方案，包括 Nginx 代理、JSONP 和后端配置等。

什么是跨域？

同源策略

浏览器的同源策略（Same-Origin Policy）是一种安全机制，限制不同源的网页之间的交互。同源指的是 “协议、域名、端口” 三者完全相同：

跨域的定义

当一个请求的 “协议、域名、端口” 与当前页面的源不一致时，该请求就是跨域请求。同源策略会阻止跨域请求的成功响应（如 AJAX 请求被拦截），但允许某些标签（如 <script>、<img>）的跨域加载。

跨域解决方案

方案一：Nginx 代理（推荐）

通过 Nginx 作为中间代理，将前端的跨域请求转发到后端，使浏览器认为请求是同源的，从而绕过同源策略。

配置示例：

Linux 交换分区（Swap）：虚拟内存的核心实现

Swap（交换分区 / 交换空间）是 Linux 系统中用于扩展内存能力的关键机制，它通过将磁盘空间模拟为 “虚拟内存”，解决了物理内存不足时的系统运行问题。理解 Swap 的工作原理和配置方法，对系统性能优化和稳定性保障至关重要。

Swap 的本质与核心价值

什么是 Swap？

Swap 是 Linux 内核使用的磁盘空间（分区或文件），用于临时存储物理内存中暂时不活跃的数据。当物理内存（RAM）不足时，内核会将这些 “不常用” 的数据转移到 Swap 中，释放物理内存给当前活跃的进程使用。

• 形象比喻：物理内存是 “高速缓存”，Swap 是 “备用仓库”—— 常用物品放在缓存，暂时不用的移到仓库，需要时再取回来。

Swap 的核心作用

• 避免 OOM 崩溃：当物理内存耗尽时，Swap 可防止进程因内存不足被内核强制杀死（OOM，Out Of Memory）。
• 支持内存密集型任务：如数据库服务、虚拟机、大数据处理等，这些任务可能短时间占用远超物理内存的空间。
• 实现系统休眠：休眠（Hibernate）时，内核会将内存中所有数据写入 Swap，下次开机时从 Swap 恢复状态。

Swap 的工作机制

内存页的 “换入” 与 “换出”

Linux 内存管理以 “页（Page，通常 4KB）” 为单位，Swap 的核心操作是内存页的 “换出”（从物理内存到 Swap）和 “换入”（从 Swap 到物理内存）：