GoofySatoshi's Blog

  今天学习了 Seata 分布式事务的其他模式，包括 XA 模式、TCC 模式和 Saga 模式，以下是详细整理： 一、XA 模式 核心特点 连接持有机制：XA 模式会持有数据库连接（如 MySQL 的  Connection  对象）直至两阶段提交完成，在此期间连接无法释放，可能影响数据库连接池性能。 注解使用：需同时使用  @GlobalTransactional （保证分布式事务的提交/回滚）和  @Transactional （保证本地事务正常提交）两个注解。 两阶段流程：1. 一阶段：各分支事务执行本地业务逻辑，但不提交，仅记录日志并等待全局协调。2. 二阶段：事务协调者（TC）根据全局事务状态，决定所有分支事务执行  commit （提交）或  rollback （回滚）。 优缺点 优点：强一致性，依赖数据库原生 XA 协议，无需侵入业务代码。 缺点：长期持有连接导致性能损耗大，不适合高并发场景，一般不推荐使用。 二、TCC 模式 核心概念 TCC 模式将分布式事务分为三个阶段，需手动实现业务逻辑： 1. Try：资源检查与预留（如扣减库存前检查库...

一、为什么需要 Sentinel 拉模式？Sentinel 默认的内存模式存在明显缺陷：限流规则仅存储在客户端内存中，应用重启后规则全部丢失，无法满足生产环境的规则持久化与统一管理需求。 拉模式是 Sentinel 规则持久化的核心方案之一，其核心逻辑是客户端主动通过定时轮询，从外部存储（如 MySQL、本地文件）拉取规则，并结合 SPI 扩展机制实现自定义数据源，彻底解决“重启失效”问题。本文将完整拆解拉模式的实现流程，基于 MySQL 存储规则，适配 Spring Boot 场景。 二、拉模式与 SPI 的关系在动手实现前，先理清两个关键概念，避免与推模式混淆： 概念 作用说明拉模式 客户端通过定时任务主动轮询外部存储（如 MySQL），获取最新规则并加载到 Sentinel，实时性取决于轮询间隔。SPI 扩展机制 Sentinel 提供  ReadableDataSource  接口作为 SPI 扩展点，允许自定义“规则读取逻辑”，框架启动时自动扫描加载。 三、完整实现步骤（基于 MySQL + Spring Boot）1. 环境准备：引入依赖在  pom.xml  中添...

Sentinel源码学习笔记一、客户端与服务端的交互流程 1. 连接建立：客户端启动时通过配置的服务端地址（如  spring.cloud.sentinel.transport.dashboard.server ）与Sentinel Dashboard建立长连接（HTTP长轮询或WebSocket），定期发送心跳包保持连接。2. 数据同步： 客户端将实时统计的监控数据（QPS、异常数等）通过长连接上报给服务端，服务端在控制台展示实时监控图表。 服务端通过长连接向客户端推送规则配置（流控、熔断等），客户端接收后更新本地规则缓存并生效。3. 指令交互：服务端可通过控制台手动触发客户端规则更新、熔断状态重置等指令，客户端接收后执行对应操作并返回结果。 二、自动配置类（以Spring Cloud整合为例）的核心逻辑  SentinelAutoConfiguration  是核心自动配置类，主要执行以下操作： 1. 初始化核心组件：注册  SentinelResourceAspect  切面，通过AOP拦截被  @SentinelResource  注解标记的资源（方法/接口...

Sentinel 控制台用法与工作原理学习笔记一、流控规则配置 基础控制维度：支持对 QPS（每秒查询率）和并发线程数进行控制。 三种流控模式： 直接关系：直接针对接口配置流量规则，可设置 QPS 或并发线程数阈值，当触发阈值时直接对该接口进行限流。 关联关系：适用于存在关联的服务，例如调用 A 服务的请求过多时，可配置当 A 服务的 QPS 或并发线程数达到阈值后，对关联的 B 服务进行流量控制，避免因 A 服务过载影响 B 服务。 链路关系：针对具有调用关系的链路进行配置，可对链路上的特定节点或多个节点限流，进而控制整个链路的流量。需注意：1.7 版本后，链路控制功能需在配置文件中设置 WebContextUtile 参数为 false 才能生效。 三种流控类型： 快速失败：当接口请求超过设定阈值（QPS 或并发线程数）时，直接返回失败结果。 接口预热：服务启动时，通过模拟线程加载缓存等资源，避免刚启动就被大量流量击垮，逐渐提升接口处理能力至阈值。 排队等待：可设置超时时间，请求会进入队列等待处理。若超时则被剔除并返回失败；未超时则正常响应。例如，阈值设为 20 时，每秒...

一、Sentinel 基础概念与服务雪崩背景（一）服务雪崩现象剖析服务雪崩是微服务架构中的严重问题：当某服务因高并发不堪重负，其依赖链上的其他服务会受波及，影响层层传递，最终导致大量服务瘫痪。 服务不可用的核心原因包括： 程序 Bug：隐藏错误在特定场景（输入、环境、业务）下触发，导致服务异常。 高并发冲击：突发请求远超服务器承载能力，资源被耗尽，无法及时处理请求。 硬件故障：服务器硬件老化、损坏等物理问题，直接导致服务停运。 缓存击穿：热点数据缓存过期瞬间，大量请求穿透缓存直达后端，造成服务压力激增。 （二）服务雪崩解决方案概述应对服务雪崩的常见方案有四类： 超时机制：为服务调用设超时时间，超时未响应则返回默认结果（如 false），避免调用方长时间等待。 服务限流：限制单位时间内通过的请求数，拦截超额流量并返回“服务繁忙”提示，保护服务不被压垮。 资源隔离：划分独立资源池（线程池、数据库连接等）给不同服务/模块，某资源池耗尽不影响其他服务。 熔断降级：若被调用服务频繁错误或崩溃，直接返回默认结果，防止影响在服务链蔓延。 （三）微服务流量治理技术选型对比微服务...

一、引言：Nacos Config 的核心定位在 Spring Cloud 微服务架构中，配置管理是保障服务弹性与可维护性的关键环节。Nacos Config 作为官方推荐的配置中心，不仅实现了配置的集中存储与动态推送，还通过SPI 机制适配 Spring Boot 自动配置，解决了传统本地配置“修改需重启”“环境配置混乱”等问题。 本文基于源码视角，从配置加载优先级、事件驱动的变更流程两大核心维度展开，同时补充一致性保障、多环境管理、安全加密等生产级关键特性，形成完整的 Nacos Config 知识体系。 二、配置文件加载逻辑与优先级排序Nacos Config 本质是 Spring Boot 自动配置的扩展，其配置加载依赖 Bootstrap 上下文与 Spring 环境（Environment） 的初始化顺序，最终形成明确的优先级规则（优先级从高到低）： 优先级排序 配置文件类型 核心作用与场景 1（最高） 服务名-环境名.yaml 如 order-service-dev.yaml，针对特定服务+特定环境的精准配置（如开发环境的数据库地址），优先级最高，覆盖所...

前言在使用 Hexo 搭建个人博客时，当我们终于把hexo生成的页面挂载到github页面后，每次提交博客都需要使用hexo clean && hexo g && hexo d来部署很麻烦，可以借助github actions来实现流水线布置，我们每次提交源代码到github存放源码的分支上，一旦监听到源代码的push事件，流水线就会就会自动拉取环境自动部署，所以我们需要一个存放源代码的分支，以及我们的发布分支，可以使用git命令创建这两个分支，自动CI/CD,github需要密钥用来保证项目拉取和部署的权限，需要在本地生成ssh的密钥，公钥用来拉取项目，私钥用来部署推送更新页面，而且github对于npm安装有频率限制，我们可以通过配置国内镜像源+缓存配置，避免每次全量拉取，提高依赖安装以及部署的速度 一.分支规划与准备工作为了清晰分离源代码和部署文件，我们需要创建两个分支： source 分支：存放 Hexo 源代码（包括 Markdown 文章、配置文件、主题文件等） main 分支：存放 Hexo 生成的静态网页文件，用于 Gi...

一、引言Nacos 作为阿里开源的分布式服务发现与配置管理平台，2.X 版本在架构上进行了协议升级（HTTP→gRPC）、存储结构优化（嵌套 Map→扁平分层）、一致性增强（Distro→Raft） Nacos 2.X 主要核心优化： 协议升级：gRPC 长连接替代 HTTP，降低通信开销，提升实时性； 存储优化：扁平分层注册表替代嵌套 Map，提升查询与同步效率； 事件驱动：解耦模块依赖，增强扩展性； 健康检查：服务端主动探活替代客户端心跳，减少客户端负担； 一致性增强：Raft+Distro 混合协议，平衡一致性与性能。 二、服务注册核心源码剖析服务注册是 Nacos 的基础能力，2.X 版本通过 gRPC 长连接异步通信替代 1.X 的 HTTP 短连接，同时优化了实例存储与一致性逻辑。 （一）客户端：发起注册请求客户端核心是封装实例信息、建立 gRPC 连接并发送注册请求，关键类集中在 nacos-naming-client 模块。 入口类：NacosNamingService 客户端对外暴露的注册入口，负责参数预处理与代理分发： 1234567891011121...

Nacos 核心源码学习笔记Nacos 作为微服务架构中核心的服务注册发现与配置中心，其底层设计与实现逻辑对理解微服务治理至关重要。本文从源码入口、服务注册、心跳检测、集群一致性四个核心维度，梳理 Nacos 关键机制的实现原理。 一、源码入口与初始化机制1. 源码入口定位分析 Nacos 源码时，可通过启动脚本定位启动类，或直接聚焦服务发现核心 Jar 包（如 nacos-discovery）。其初始化逻辑依赖 Spring Boot SPI 机制，核心流程如下： 在 META-INF/spring.factories 中配置自动配置类（如服务发现场景的 NacosDiscoveryAutoConfiguration）； 启用 Jar 包时，Spring 容器通过 @EnableAutoConfiguration 触发自动配置类加载； 自动配置类初始化 NacosServiceRegistry（服务注册）、NacosDiscoveryClient（服务发现）等核心组件，并向 Nacos 服务端发起请求，建立基础通信链路。 二、服务注册流程与高并发设计1. 核心注册流程 客户...

一、服务调用方式对比在 Spring Cloud 中，引入 OpenFeign 之前，常使用 Ribbon（负载均衡器）与 RestTemplate 进行服务间调用。但此方式代码耦合性强，维护性与可读性差，修改不便。而 Spring Cloud OpenFeign 采用依赖注入方式调用，如同调用本地 service，极大提升了代码的简洁性与可维护性。 二、OpenFeign 使用步骤 引入依赖：在项目中引入 OpenFeign 的相关 Maven 依赖。 添加注解：在 Spring Boot 启动类上添加 @EnableFeignClients 注解，开启 Feign 客户端功能。 定义接口： 方式一：在自定义的 SDK 中定义带有 @FeignClient 注解的接口。 方式二：自行定义 OpenFeign 接口，该接口用于声明服务调用方法。 注入使用：将定义好的 Feign 接口注入到需要调用的地方，即可实现服务间的远程调用。三、OpenFeign 接口参数处理 默认 @RequestBody：若接口参数未添加其他注解，OpenFeign 默认添加 @Reque...