场景

svc1.jar 中有一个 TestController类，当前源代码工程 demo 依赖了这个 svc1.jar。
当前 demo 工程启动正常，TestController 被初始化，TestController中提供的接口 /svc1/test1、/svc1/test2、/svc1/test3 均可以正常访问。
因接口 /svc1/test2 对应的方法中逻辑处理不满足需求，需要对这个方法进行重写处理。
该接口在 svc1.jar 包，不能直接修改源代码。

AI Agent是什么？

AI Agent，也称为“智能体”，在计算机和人工智能技术领域中，是指那些展现出一种或多种智能特征的软件或硬件实体。这些特征包括自治性、反应性、社会性、预动性、思辨性、认知性等，使其能够在特定环境中自主行动。简单说，AI Agent = 大模型（大脑）+ 记忆系统（存储器）+ 规划模块（指挥官）+ 工具使用 （手脚）。它不是单一技术，而是一套 “让 AI 自主做事” 的系统架构。

OpenAI对AI Agent的定义着重于其作为一个以大型语言模型为核心的系统，这个系统具备自主理解感知、规划、记忆和使用工具的能力，使其能够自动完成复杂的任务。AI Agent的基本框架包含四个主要模块：记忆、规划、工具使用和行动。

引言

在人工智能与大型语言模型（LLM）快速发展的今天，如何让模型安全高效地访问外部数据和服务成为关键挑战。MCP（Model Context Protocol） 协议应运而生，它通过标准化的通信机制，为AI模型与外部资源架起桥梁。MCP 协议使用 JSON-RPC 来编码消息，JSON-RPC 消息必须使用 UTF-8 编码。MCP协议目前定义了三种传输机制用于客户端-服务器通信：

• stdio：通过标准输入和标准输出进行通信

• SSE：通过 HTTP 进行通信，支持流式传输。（协议版本 2024-11-05 开始支持，即将废弃）

• Streamble HTTP：通过 HTTP 进行通信，支持流式传输。（协议版本 2025-03-26 开始支持，用于替代 SSE）

MCP 协议要求客户端应尽可能支持 stdio。MCP 协议的传输机制是可插拔的，也就是说，客户端和服务器不局限于 MCP 协议标准定义的这几种传输机制，也可以通过自定义的传输机制来实现通信。

Streamable HTTP是MCP协议推荐的下一代传输机制，基于标准HTTP实现动态流式升级，支持无状态服务和云原生部署。相比SSE，它无需专用端点，兼容CDN/API网关，灵活切换流式响应（如长文本生成进度推送），适合分布式系统与弹性扩展场景。官方计划逐步淘汰SSE，推荐优先采用Streamable HTTP以实现高效、可扩展的远程通信。

双 Token 原理概述

• Access Token：短期有效（如 30 分钟），用于接口鉴权，存放用户身份与权限信息。
• Refresh Token：长期有效（如 7 天），仅用于在 Access Token 过期后“换取”新的两个 Token。
• 无感刷新：用户在 Access Token 过期后，客户端自动携带 Refresh Token 请求刷新，服务器验证 Refresh Token 后下发新的 Access/Refresh Token，用户无须重新登录。

引言

在现代软件开发中，单体应用的臃肿和僵化已成为一大痛点。如何构建一个既能快速迭代核心功能，又能灵活扩展业务模块的系统？插件化架构提供了一种优雅的解决方案。PF4J作为轻量级Java插件 框架的代表，为这一目标奠定了基础。而PF4J-Spring和SBP则在此基础上，针对Spring Boot生态进行了深度优化。

转载自：https://blog.csdn.net/bruce128/article/details/134042861

到今年已经工作十一个年头了，把这些年自己出现在自己身上或者同事身上的问题记录下来。

转载自：https://mp.weixin.qq.com/s?__biz=MzU1OTgyMDc3Mg==&mid=2247485037&idx=1&sn=7d71b552adda07e6bb38d9aca72aece9&chksm=fc103ce6cb67b5f01817f2850415eec829442d077b3fdddb4a316ec23ace6efa6af768548918&token=949133520&lang=zh_CN&scene=21#wechat_redirect

问题所在

相信大家都遇到过因为数据库全表扫描生成大对象，然后系统疯狂 GC，引发系统卡顿的问题。能看到这样的 GC 日志：

1

2021-11-20T01:28:52.240+0800: 108542.888: [GC pause (G1 Humongous Allocation) (young) (initial-mark), 0.1276229 secs]

然后就是常规操作，jmap 下，MAT 看看内存，看到底是哪条 SQL 搞的鬼。

MySQL中的间隙是指索引中两个索引键之间的空间，间隙锁用于防止范围查询期间的幻读，确保查询结果的一致性和并发安全性。

概念解释

记录锁（Record Lock）

记录锁也被称为行锁，顾名思义，它是针对数据库中的行记录进行的锁定。

比如：

1

SELECT * FROM `user` WHERE `id`=1 FOR UPDATE;

上面的SQL会在 id=1 的行记录上加上记录锁，以阻止其他事务插入，更新，删除这一行。

间隙锁（Gap Lock）

间隙锁就是对间隙加锁，用于锁定索引范围之间的间隙，以避免其他事务在这个范围内插入新的数据。间隙锁是排它锁，阻止了其他事务在间隙中插入满足条件的值。

临键锁（Next-Key Lock）

临键锁由记录锁和间隙锁组合而成，它在索引范围内的记录上加上记录锁，并在索引范围之间的间隙上加上间隙锁。这样可以避免幻读（Phantom Read）的问题，确保事务的隔离性。

切记：间隙锁的区间是左开右开的，临键锁的区间是左开右闭的。

Name Server 负责维护整个 RocketMQ 集群中各个 Broker 的路由信息，客户端通过与 Name Server 交互获取消息发送或者消费的路由信息。

下面详细解释一下 Name Server 的功能：

1.Redis主从架构的分布式锁的执行流程

在Redis主从架构中，写入的都是 master Redis实例，master 主实例会向 slave 从实例同步key。

一个业务线程 通过向主Redis实例中写入 key-value 来实现加分布式锁，加锁后开始执行业务代码。

具体如下图所示：

当前，这里也涉及到一个核心问题： 锁过期了，业务还没执行完， 怎么办？

锁过期问题,大概的解决方案 有2种：

1：模拟CAS乐观锁的方式，增加版本号

2：watch dog自动延期机制（推荐）

现在聚焦的问题： master Redis实例挂掉了，slave 从Redis 还没有完成复制，导致 Redis分布式锁失效，怎么办？