2025-06-14 的今天参与了腾讯云架构师北京技术同盟的线下活动，今天的主题是 **「AI 时代下的架构设计」**，很有幸成为架构师同盟的一员，我将总结分享下今天的内容。

![image.png](https://blog.liushigong.cn/static/img/6ab44cbd6a100ba6aa2825b489762ce1.image.webp)

## 「AI 时代下的架构设计」

今天分享的主要有4个主题，确实收货满满

![image.png](https://blog.liushigong.cn/static/img/7bd1b034041671254b20f47a0f0204b1.image.webp)

### AI 时代下的数据治理

这一篇主题是我比较感兴趣的，之前了解 AI 的时候，就思考过 AI 在大数据处理中的应用，如何通过 AI 来实现业务中各种的数据统计与分析，此处老师分享的是数据治理。

在一些企业中，创建了数据湖仓，对应的数据来源可能从不同的子公司或者其他途径获取，其中不同子公司的数据字典词义相同，但是其语义不同，造成了数据湖仓中的数据分析的紊乱。

当出现此类情况时就需要我们的数据治理，如果数据字典数据量少的情况下，人工处理也是可以的，但是往往真实情况中数据字典量会非常庞大，这个时候我们就需要用到 AI 来治理我们的数据。

#### 数据治理实现思路

数据治理需要制定数据标准，数据规范，可通过 AI 由以下几种方式进行实现

* 智能对话/业务咨询
* 业务术语、业务描述的生成
* 智能识别、智能匹配

在治理的过程中，可以结合「需求文档、设计文档、产品原型、培训文档」等资料训练模式，结合 SQL 给出业务语义，从而实现统一标准规范

![image.png](https://blog.liushigong.cn/static/img/c32f8e2e6c65b43d41db6cc4b1269bb6.image.webp)

![image.png](https://blog.liushigong.cn/static/img/07c90344b902dc7798fe61f7b93cd891.image.webp)

#### AI 数据分级分类的实现思路：向量词

需要专业可靠的词库，否则专业词会被拆分，将会影响最终匹配结果，所以我们要继续完善词库信息

![image.png](https://blog.liushigong.cn/static/img/e756d8b8d6469e882491d025d918b511.image.webp)

![image.png](https://blog.liushigong.cn/static/img/20eb56be55cdc94309e7391c9cc2c5ab.image.webp)

#### 要点回顾

![image.png](https://blog.liushigong.cn/static/img/a39e86c1ee4112114913dd388242a854.image.webp)

#### 总结

![image.png](https://blog.liushigong.cn/static/img/16c0ee63e806ce404d1eff2a4260944e.image.webp)

以上为我在会议中的手画图，整体的数据治理流程就是通过将业务数据导入与采集，然后结合 AI 进行数据治理，统一规范标准后入数据湖仓，接下来通过数据分析与统计，回写到业务数据中进行展示，由此形成闭环。

### AI 时代智能数据存储与处理解决之道

嗯~这一篇在讲结合 AI 的云存储的底层实现，感觉像是在介绍腾讯云产品，直接跳过吧

### AI 驱动下的社交电商架构升级

这一篇是由闫国旗闫老师讲述的电商业务，围绕社交电商的核心业务场景，深入剖析 AI 技术如何针对这些场景的业务痛点，提供智能化解决方案。同时，阐述为实现这些 AI 应用，社交电商架构在数据层、应用层、基础设施层的升级路径，展现 AI 驱动下社交电商架构从理论到实践的完整升级过程。

开始讲述的电商的发展历程，从电商到社交，在到现在的短视频（忘记名词了），再到电商中 AI 的落地实现

* 以业务问题为导向
* 轻量级起步 + 快速验证
* 利用已有平台能力（无需从零训练模型）

接下来讲述基于电商的实际业务中的 AI 实现，其中包含

* 商品搜索
* 商品转链 - 文字染色，推广文案，文案敏感词检测（风控）
* 内容种草 - 数据洞察，内容创作
* 私域投放 - 流量引入

![image.png](https://blog.liushigong.cn/static/img/48def3e4da1c5892263552626174636d.image.webp)

![image.png](https://blog.liushigong.cn/static/img/594936b22c29604f77dc94beabb44a7f.image.webp)

#### 一些 AI 经验

**深度释放模型CoT能力**

业务问题结构化拆解，将复杂场景转化为“问题链”再通过CoT分步处理。使用提示词模板固定推理框架。

**精准划定AI能力输出边界**

利用传统技术在内容安全、数据隐私、业务合规等方面做兜底方案。特别是在线业业务，通过输出审计便于后期追溯和选代。

**以点带线提升业务短板**

采用高ROI场景切入策略，在问题边界明确、数据的可获得性，收益价值可量化三个方面进行筛选。要考虑能力的复用与价值链的延伸与技术资产沉淀。

#### 目标

AI大模型通过打造基于消费场景的专业化助理、深化用户消费意图的多维度心智解析，以及将商品文案、营销素材等内容生成能力进行标准化封装输出，实现社交电商导购从需求捕捉到内容服务的全链路智能化升级，为商家降低运营成本的同时提升用户消费体验。

**基于消费场景的AI助理**

从“通用服务”到“场景专家。以线带面，基于用户场景，实现用户、商品与服务的连接。

**用户消费意图理解**

借助大模型的理解能力和情感分析能力，实现对用户消费意图的深度洞察。

**内容生成能力优化**

从“零散输出”到“标准化能力”，完成内容从“量”到“质”转变，拒绝制造“内容垃圾”。

#### 总结

闫老师宣讲的内容更多的偏向于业务上的 AI 应用，更多的是让我们有一种产品思维去考虑在电商中如何应用 AI。

### AI 技术赋能从产品设计到交付的效率

这位老师想从自己创业产品作为切入点，结果大多数是个人介绍的经理，唯一干货就是通过 cursor 生成项目代码，要保证代码可控，可以结合原型、UI自主生成代码，等有机会玩一玩，到时候出一篇文章来讲讲，唯一的缺点就是收费，差点意思。

腾讯云架构师城市沙龙 - 「AI 时代下的架构设计」

今天来聊下自己作为三方时，如何保证自己api接口的安全；之前讨论的 [三方接口 - 调用过程中的一些反向思考](https://blog.liushigong.cn/post/47) 是调用方视角，现在切换到服务方视角，正好形成完整闭环。

## 作为第三方服务提供方：如何打造安全、高性能的接口堡垒

作为第三方服务提供方，保障接口的安全性与性能不仅是技术责任，更是商业信誉的基石。攻击者虎视眈眈，调用方期望毫秒级响应，任何疏漏都可能导致数据泄露、服务瘫痪或客户流失。以下是如何构建坚不可摧且迅捷如风的接口体系：

### 一、筑牢安全防线：多层级纵深防御

1. **认证(Authentication) - “你是谁？”**
   * **强凭证机制：**
     + **API Keys：** 基础方案，需结合HTTPS、IP白名单、使用频率限制。**严格保密**，定期轮换。
     + **OAuth 2.0：** 行业标准授权框架，支持`Client Credentials`(服务间)、`Authorization Code`(用户授权)等流程。使用短期有效的`Access Token`。
     + **JWT (JSON Web Tokens)：** 自包含令牌，可携带声明(Claims)。**必须签名(JWS)** 或加密(JWE)，验证签名有效性、过期时间(`exp`)、生效时间(`nbf`)、受众(`aud`)等。
   * **多因素认证(MFA)：** 对敏感操作(如密钥管理、配置变更)强制启用MFA。

MFA

多因素身份验证（Multi-factor Authentication，MFA）是一种安全系统，是为了验证一项交易的合理性而实行多种身份验证。

MFA是通过结合两个或三个独立的凭证：用户知道什么（知识型的身份验证），用户有什么（安全性令牌或者智能卡），用户是什么（生物识别验证）。单因素身份验证（SFA）与之相比，只需要用户现有的知识。虽然密码口令身份验证很适合网站或者应用程序的访问，但是在网络在线金融交易方面还是不够安全。

2. **授权(Authorization) - “你能做什么？”**

   * **RBAC (基于角色的访问控制)：** 定义清晰的角色（如`admin`, `read-only`, `billing`），分配最小必要权限。
   * **ABAC (基于属性的访问控制)：** 更细粒度，根据请求属性（用户属性、资源属性、环境属性）动态决策。
   * **Scope/Permission：** 在OAuth 2.0/JWT中使用`scope`或自定义权限声明，精确控制API端点或操作权限。
3. **传输安全 - “路上防窃听篡改”**

   * **强制HTTPS (TLS 1.2+)：** 所有通信必须加密。禁用弱密码套件，使用强证书。
   * **HSTS (HTTP Strict Transport Security)：** 强制浏览器使用HTTPS连接。
   * **证书绑定(Certificate Pinning)：** 在移动SDK中可考虑使用，防止中间人攻击(风险较高需谨慎)。
4. **请求安全 - “验明正身，过滤恶意”**

   * **输入验证与净化：**
     + **严格Schema验证：** 对所有输入参数(Path, Query, Header, Body)使用JSON Schema、Protobuf等强类型定义进行校验。
     + **白名单过滤：** 对字符串类型字段(如分类、状态)使用枚举白名单。
     + **防范注入：** 对可能用于拼接SQL、命令、LDAP查询的参数进行严格转义或使用参数化接口。
   * **防重放攻击(Replay Attack)：**
     + **Nonce：** 要求请求携带唯一随机数(Nonce)，服务端记录并校验其唯一性(可设较短有效期)。
     + **时间戳(Timestamp)：** 要求请求携带当前时间戳，服务端校验时间偏差(如±5分钟)。
     + **(推荐) Nonce + Timestamp组合使用。**
   * **速率限制(Rate Limiting)：**
     + **多维度限流：** 按API Key、IP、用户ID等维度设置配额(如每秒/每分钟/每天请求数)。
     + **分级限流：** 不同客户套餐设置不同阈值。
     + **智能限流：** 对异常流量模式(如突发、扫描)进行动态抑制。使用令牌桶、漏桶算法。
     + **明确响应：** 返回`429 Too Many Requests`，携带`Retry-After`头部提示。
   * **API 网关：** 集中实施认证、授权、限流、SSL终止、路由等策略，是安全防护的核心枢纽。
5. **数据安全 - “敏感信息滴水不漏”**

   * **敏感数据脱敏：** 在日志、响应中自动屏蔽密码、密钥、身份证号、银行卡号等。
   * **最小化返回原则：** 响应中仅包含必要字段，避免泄露过多信息。
   * **加密存储：** 数据库中的敏感数据(密码、令牌、支付信息)必须使用强加密算法(如AES-256)加密存储，密钥安全管理(HSM/KMS)。
   * **符合合规要求：** GDPR, CCPA, PCI DSS, HIPAA等(根据业务领域)。
6. **审计与监控 - “一切行为皆可追溯”**

   * **详尽审计日志：** 记录所有关键操作(登录、配置变更、数据访问)的：时间、主体(谁)、对象(什么资源)、动作、结果、来源IP。
   * **安全事件监控：** 实时监控异常登录、权限变更、高频失败尝试、越权访问等可疑行为，并告警。
   * **定期安全审计：** 进行渗透测试、代码安全扫描、配置审计。

### 二、追求极致性能：构建闪电般的响应

1. **高效架构设计 - “根基稳固”**

   * **无状态设计：** RESTful原则，方便水平扩展。
   * **微服务化：** 按功能拆分服务，独立部署、伸缩。
   * **选择合适的数据库：** 关系型(SQL)用于事务/复杂查询，NoSQL(如Redis/MongoDB/Cassandra)用于高吞吐/低延迟/灵活模式。读写分离、分库分表。
   * **异步与非阻塞：** 使用异步框架(如Node.js, Vert.x)或非阻塞I/O库(NIO)处理高并发连接。耗时操作(发邮件、报表生成)放入消息队列(Kafka, RabbitMQ)异步处理。
2. **缓存策略 - “速度的艺术”**

   * **多级缓存：**
     + **客户端缓存：** 引导调用方合理使用`Cache-Control`/`ETag`。
     + **CDN缓存：** 缓存静态资源或读多写少、变更不频繁的API响应(需设置合适缓存策略)。
     + **网关/代理缓存：** (如Nginx)缓存后端响应。
     + **应用层缓存：** (如Redis, Memcached)缓存数据库查询结果、复杂计算结果、Session。
     + **数据库缓存：** (如MySQL Query Cache, Redis作为缓存层)。
   * **缓存失效：** 精心设计失效策略(过期时间TTL、主动失效、写时失效)保证数据一致性。
3. **优化数据访问 - “数据库不是瓶颈”**

   * **索引优化：** 分析慢查询，为高频查询字段建立合适索引。避免全表扫描。
   * **减少查询次数：** 使用JOIN(谨慎避免性能陷阱)、批量操作(Batch Insert/Update)、预加载(Eager Loading)。
   * **避免`SELECT *`：** 只查询需要的字段。
   * **连接池：** 高效管理数据库连接。
4. **代码与算法优化 - “精雕细琢”**

   * **高效算法与数据结构：** 选择时间复杂度/空间复杂度更优的方案。
   * **避免过度序列化/反序列化：** 选择高效的序列化协议(Protobuf, MessagePack, Avro > JSON/XML)。
   * **减少不必要计算：** 缓存计算结果、延迟加载。
   * **资源池化：** 复用对象、线程、连接。
   * **代码Profiling：** 使用性能分析工具(如JProfiler, VisualVM, Py-Spy)定位热点(Hotspot)进行优化。
5. **弹性与扩展性 - “遇强则强”**

   * **水平扩展：** 通过增加无状态应用服务器实例应对流量增长。容器化(Docker)和编排(K8s)是关键。
   * **自动伸缩(Auto Scaling)：** 基于CPU、内存、请求队列长度等指标自动增减实例。
   * **负载均衡：** 使用L4/L7负载均衡器(Nginx, HAProxy, 云LB)均匀分发流量，并具备健康检查能力。
   * **资源隔离：** 不同客户/租户的资源(CPU、内存、连接、线程池)进行隔离(如cgroups, 命名空间)，避免相互影响。
   * **优雅降级：** 在系统压力过大时，暂时关闭非核心功能或返回简化数据，保障核心服务可用。
6. **性能监控与调优 - “持续改进的眼睛”**

   * **关键指标监控：**
     + **应用层：** QPS/TPS、平均/分位响应时间(P90, P95, P99)、错误率、吞吐量。
     + **系统层：** CPU、内存、磁盘I/O、网络I/O。
     + **数据库层：** 查询耗时、连接数、慢查询、锁等待。
     + **缓存层：** 命中率、内存使用、响应时间。
     + **队列层：** 队列长度、消费延迟。
   * **分布式追踪(APM)：** 集成Jaeger, Zipkin, SkyWalking等工具，可视化请求链路，精准定位性能瓶颈。
   * **日志分析：** 集中分析日志，发现潜在性能问题和优化点。
   * **容量规划与压测：** 定期进行压力测试，模拟峰值流量，评估系统容量极限，指导扩容策略。

### 三、开发者体验：安全与性能的润滑剂

* **清晰详尽的文档：** 提供交互式文档(Swagger UI/Redoc)，包含认证方式、请求/响应示例、错误码、限流策略、最佳实践。
* **健壮的SDK：** 提供主流语言的SDK，封装认证、重试、序列化等复杂逻辑，降低接入门槛和出错概率，提升性能(如连接复用)。
* **沙箱环境(Sandbox)：** 提供测试环境供开发者集成调试，不影响生产。
* **状态页与通知：** 公开服务状态页，及时发布维护、故障通知，建立透明沟通渠道。

### 总结：安全与性能的双螺旋上升

作为可信赖的三方服务提供者，安全与性能并非独立命题，而是相互交织、共同演进的双螺旋结构：

1. **安全是性能的保障：** 一次安全事件导致的停服或数据恢复，其性能损失远超任何优化带来的收益。安全措施(如限流)本身也是保护后端性能不被恶意流量冲垮的关键。
2. **性能增强安全体验：** 快速的认证授权响应、实时的安全监控告警，都依赖高性能的基础设施支撑。冗长的延迟可能迫使调用方放松安全重试策略。
3. **持续演进：** 威胁模型在变，流量模式在变，技术也在革新。唯有建立**持续监控、定期评估、快速迭代**的机制，拥抱零信任架构、服务网格(Service Mesh)、eBPF等新技术，才能在安全与性能的平衡木上稳步前行。

**打造卓越的三方服务，意味着将每一次接口调用都视为一次庄严承诺——承诺数据固若金汤，承诺响应迅如疾风。这不仅是技术挑战，更是构建长期信任与商业价值的核心工程。**

三方接口 - 如何保证自己的接口安全

在现代分布式系统和微服务架构中，调用第三方服务（API、SDK、数据库、外部平台）已成为常态。然而，这种依赖关系犹如在复杂水域航行，潜藏着诸多“暗礁险滩”。忽视这些问题轻则导致功能异常，重则引发系统崩溃或数据灾难。本文将深入剖析调用三方服务时最棘手的六大问题及其化解之道。

## 与三方之间的交互

在工作中，或多或少的都会接触一些三方接口的调用，例如最普遍的短信、实名认证、人脸识别、发票识别，还有一些是系统之间的交互调用，例如购买的用友财务系统、物流系统等等。由于系统之间的隔离性，我们无法得知其他系统的运行情况，但是又需要调用其接口产生紧紧地耦合性，此时我们就需要思考如何处理三方的可用性与数据一致性

市面上大多数的三方接口，都是通过http协议进行调用，通过提供账号与密钥，调用时内部通过签名密钥等加密信息进行传输。在调用过n家三方后，我总结了一些调用中的问题与解决，以及一些自主的思考，对此类业务做出一套完整处理流程

## 调用三方存在的问题

### 接口调用失败或超时

在所有的问题中，调用失败或者超时是最常见的情况，对于业务上来说，如果是同步调用，我们在调用自己业务的同时，也会调用三方业务，如果三方失败那我们接口也失败，抛出异常进行提示，事务回滚，业务结束没啥问题，那如果是异步调用的呢，我们调用的三方需要后台处理，或者是执行时间过长，存在中间状态，过段时间三方会回调回来，这时候如果调用失败了，或者三方没有回调回来呢？

接下来我们解决一下以上的情况

**手动重试**

在业务支持上的范围上，记录三方调用的结果状态，如果调用失败人工可进行重试，像在工作中推送用友的财务单据失败，业务自行重试推送即可

**定时自动重试**

另一种业务情况就需要系统自行重试处理，例如一直没有回调，需要系统定时查询结果的（但凡需要回调的三方，一般都会提供主动查询结果的接口），通过定时扫描，主动进行重试，并且提供重试次数限制。

**设置超时时间**

同时为每次调用设置连接超时(ConnectTimeout)和读超时(ReadTimeout)，避免无限等待拖垮自身系统。

### 数据幂等性问题

在三方的调用过程中，经常会遇到因超时或失败触发的重试，导致请求被多次提交；或者由于网络抖动，导致请求已成功处理，但响应丢失，客户端误判失败而重试；再或者是三方服务设计缺陷，没有实现幂等接口。

**唯一请求ID**

客户端为每个业务请求生成全局唯一ID，并在首次调用时传递给三方。三方服务根据此ID判断请求是否已处理。

请求ID的支持

有的三方没有唯一ID的处理，就需要我们本地自行处理，对调用三方的单据进行推送的唯一性校验处理

### 并发问题

解决了数据幂等问题，来继续聊下三方接口的并发问题。

在多线程/多进程/多实例同时操作三方服务的时候，实际需要三方服务会对我们的流量进行支持，往往实际三方的并发支持并不乐观

**协调机制**

可以通过锁控制对共享资源的访问；或者阻塞队列进行串行化处理，将可能冲突的操作放入队列，由单线程/单进程顺序处理（牺牲部分并发性），

### 基于三方服务的高可用

什么叫基于三方服务的高可用呢？其核心就是三方服务故障时，不能对我们现有的系统功能产生任何影响，保障我们服务的高可用，不能过度依赖单一三方服务实例或供应商，往往其承诺的可用性低于自身系统要求，导致自身系统对三方故障无抵抗力。

**多备三方与服务熔断**

多备三方是指在某些重要的业务领域，我们不能让一家三方来卡主我们系统的命脉，需要进行多家备选，在实际业务中能随时切换。当某一家三方系统故障时，根据错误率，可随时自动切换到备选的方法，其中熔断器是保障自身高可用的核心防线，在必要时设计自身系统的冗余度和容错能力。

熔断器模式(Circuit Breaker)

复杂一些的实现，可以统计失败率，当失败率超过阈值，自动“熔断”对三方的调用，直接快速失败，定期探测恢复。有点类似服务发现

### 接口调用的日志记录

在与三方沟通的过程中，报文是必不可少的内容，这点大家都应该深有体会，没有报文就无法排查问题，工作中就问题就会不太好处理

**报文的请求响应记录**

在请求三方的时候，需要将调用的请求入参与响应进行完整的输出，同时在入口（如网关）生成全局唯一的TraceID，贯穿整个调用链（包括三方调用），实现端到端追踪，必要时落到数据库进行存储

### 三方监控

对于服务监控是比不可少的内容，但是三方的服务监控，往往是很少人会去关注的内容，由如“盲人摸象”，故障发生后业务产生了影响才被动感知。

**监控指标与智能报警**

监控三方服务的可用性，同时也可以监控延迟、错误率、流量等指标，根据约定的SLA（如99.9%可用性，P99延迟<500ms）量化评估三方服务实际表现是否符合承诺。将三方调用纳入Jaeger、Zipkin、SkyWalking等APM工具的追踪范围。同时需要保证智能化，设置合理阈值、报警窗口期、升级策略；避免噪声报警。

## 总结：拥抱复杂性，构筑韧性

调用第三方服务绝非简单的“即插即用”。它要求开发者具备深刻的分布式系统思维和容错设计理念。通过识别接口失败、幂等性、并发、高可用、日志、监控这六大核心挑战，并积极采用重试熔断、唯一ID、乐观锁/分布式锁、多活冗余、结构化日志追踪、全方位监控等最佳实践，我们才能有效驾驭依赖的复杂性，构建真正高可用、高可靠、可观测性强的现代应用系统。

**记住：对三方的每一次调用，都应视为一次可能失败的冒险。充分的准备和缜密的设计，是航向稳定性的唯一罗盘。**

三方接口 - 调用三方中的一些反向思考

线上的CPU飙升是每个系统都绕不开的话题，这是典型的线上性能问题的排查场景，除了CPU飙升，还有 **频繁GC**、**内存打满** 等问题，在工作的过程中，我们或多或少的都会接触到此类的一些问题，接下来我结合生产案例来讲述下排查的思路

## Java进程的CPU飙升

### 问题现象

监控系统报警：order-service Java 进程 CPU 使用率持续超过 300%，服务响应时间飙升，部分请求超时失败。

### 问题定位与分析

#### 确认 CPU 负载来源 (操作系统层面)

首先通过 `top` 指令查看当前占用CPU较高的进程PID；可以通过以下指令快速查询前5个CPU最高的线程

```
shell

ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head -n 5
```

观察到 java 进程 PID 为 12345 的进程 CPU 占用率稳定在 300%+，远超其他进程。确认是 Java 进程本身的问题，而非系统其他进程或外部因素（如病毒）。

接下来通过 `top -Hp [PID]` 命令 查看进程内线程,执行 `top -Hp 12345` 观察到有 3-4 个线程 (nid=0x4a3b, nid=0x4a3c, nid=0x4a3d) 的 CPU 使用率持续在 90%-99% 之间。记录下这些高 CPU 线程的 PID (这里是十六进制的 nid，即 Native Thread ID)。

#### 获取 Java 线程快照 (JVM 层面)

提示

通过 `print` 命令可以将线程PID转为16进制，根据该16进制值去打印的堆栈日志内查询，查看该线程所驻留的方法位置。

使用jvm内置 jstack 命令抓取线程转储 `jstack -l 进程ID`

```
shell

jstack -l 12345 > jstack_12345.log
```

可以多次抓取（间隔 5-10 秒，抓 3-5 次）：因为线程状态是瞬时的，多次抓取有助于发现持续活跃的线程。将输出保存到文件 jstack\_12345\_1.log, jstack\_12345\_2.log 等。

#### 分析线程转储

将 top -Hp 中线程的十进制 PID (Linux 线程 PID) 转换为十六进制。

通过 `print` 命令可以将线程PID转为16进制，`printf "%x\n" 19003` (假设 top -Hp 看到的十进制线程 PID 是 19003) -> 输出 `0x4a3b`。

根据该16进制值去打印的堆栈日志内查询，在 jstack\_12345.log 文件中通过 `grep '0x4a3b' jstack_12345.log -A100` 搜索这个十六进制值(nid=0x4a3b)来查看该线程所驻留的方法位置。

```
java

"Order-Processing-Thread-7" #32 daemon prio=5 os_prio=0 tid=0x00007f8ea422e800 nid=0x4a3b runnable [0x00007f8e8a7f1000]
java.lang.Thread.State: RUNNABLE
    at com.example.orderservice.InventoryManager.lockStock(InventoryManager.java:105)
    at com.example.orderservice.InventoryManager.lambda$lockStockForItems$0(InventoryManager.java:87)
    at com.example.orderservice.InventoryManager$$Lambda$45/0x00000008000b2840.apply(Unknown Source)
    at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
    at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
    at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
    at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
    at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
    at com.example.orderservice.InventoryManager.lockStockForItems(InventoryManager.java:89)
    at com.example.orderservice.OrderService.createOrder(OrderService.java:55)
    ...
```

直接分析

可以通过 `jstack 【进程PID】| grep 【线程转换后十六进制】-A10`  直接查询线程的十六进制进行定位分析，利用grep定位线程id，打印后续10行信息。例如：`jstack 373 | grep '0x196' -A10`

**关键观察点**

* 线程状态： RUNNABLE - 表示线程正在执行或等待 CPU 时间片（这正是高 CPU 的特征）。
* 线程名： "Order-Processing-Thread-7" - 是应用自定义的线程池线程，指向订单处理逻辑。
* 堆栈顶部： com.example.orderservice.InventoryManager.lockStock(InventoryManager.java:105) 这是线程当前正在执行（或最近执行）的代码位置。这是**最直接的线索！**

在找到线索的同时，再次检查其他几次 jstack.log 快照的输出中，同一个 nid 的线程是否 **持续** 停留在 `InventoryManager.lockStock` 方法附近。如果是，这基本锁定了问题代码区域。

观察其他高 CPU 线程 (nid=0x4a3c, 0x4a3d) 的堆栈。发现它们 **几乎完全相同**，都卡在 lockStock 方法，只是线程名不同 (Order-Processing-Thread-8, -9 等)。这表明多个线程在执行同一段有问题的代码。

### 排查思路总结

* 监控报警确认： CPU 飙升告警 -> 登录服务器确认。
* 系统层面定位进程： top -> 确认高 CPU 进程是目标 Java 进程 (PID=12345)。
* 定位进程内高 CPU 线程： top -Hp 12345 -> 记录高 CPU 线程的 十进制 PID -> 转换为 十六进制 nid (printf "%x")。
* 获取线程快照： jstack -l 12345 > jstack.log (务必多次抓取！)。
* 关联分析线程： 在 jstack.log 中搜索 nid=0x... (上一步转换的十六进制值) -> 找到对应的 Java 线程堆栈。
* 聚焦问题堆栈

> 1. 检查 **线程状态** (RUNNABLE 是重点)。
> 2. 查看 线程名 (自定义线程名能快速定位业务模块)。
> 3. 精读堆栈顶部 (当前执行点) 的方法和行号。
> 4. 对比多次快照，看高 CPU 线程是否持续停留在相同代码位置。

* 结合代码分析： 根据堆栈顶部的类名、方法名、行号 (InventoryManager.java:105)，查看对应源代码，理解逻辑，分析为何会消耗大量 CPU (死循环？ 密集计算？ 锁竞争自旋？ 资源争用？)。
* 根因定位与解决： 根据代码分析结果，确定是算法问题、死循环、锁设计缺陷还是其他资源瓶颈，制定并实施解决方案（优化算法、修复死循环、重构锁策略、扩容资源等）。
* 验证与预防

> 1. 修复后，在预发布/压测环境模拟场景验证。
> 2. 添加针对性的监控（如特定方法的执行时间、特定锁的等待时间）。
> 3. 加强代码审查，特别是并发和循环逻辑。
> 4. 进行定期的压力测试。

### 新玩法：show-busy-java-threads 脚本

以上是我们传统的玩法，总结一下就是:

top命令找出消耗CPU高的Java进程及其线程id：

* 开启线程的显示模式（top -H，或者打开top后按H）。
* 按cpu使用率排序（top缺省就是按CPU的使用率降序）。
* 记下Java进程id及其CPU高的线程id。

查看消耗CPU高的线程栈：

* 用进程id作为参数，jstack出有问题的Java进程。
* 手动转换线程id成16进制（可以使用 `printf %x pid`）。
* 在jstack输出中查找16进制的线程id（`jstack -l pid > test.txt | grep16进制的值`）

查看对应的线程栈，分析问题。查问题时，会要多次上面的操作以分析确定问题，这个过程太繁琐太慢了。现在我们来认识一下阿里的一个工具脚本 **show-busy-java-threads**

* 安装方法: <https://github.com/oldratlee/useful-scripts/blob/master/docs/install.md>
* 使用方法: <https://github.com/oldratlee/useful-scripts/blob/master/docs/java.md#-show-busy-java-threads>

#### 安装

从官方文档上可以看到有3种安装方式，此处推荐使用直接在网络上下载脚本

```
sh

# 下载脚本
wget --no-check-certificate https://raw.github.com/oldratlee/useful-scripts/release/show-busy-java-threads

# 运行脚本
sh ./show-busy-java-threads
```

#### 用法

基本命令

```
sh

# 从所有运行的Java进程中找出最消耗CPU的线程（缺省5个），打印出其线程栈
show-busy-java-threads

# 缺省会自动从所有的Java进程中找出最消耗CPU的线程，这样用更方便
# 当然你可以手动指定要分析的Java进程Id，以保证只会显示你关心的那个Java进程的信息
show-busy-java-threads -p <指定的Java进程Id>

show-busy-java-threads -c <要显示的线程栈数>

# 多次执行
show-busy-java-threads <重复执行的间隔秒数> [<重复执行的次数>]

# 记录到文件以方便回溯查看
show-busy-java-threads -a <运行输出的记录到的文件>

# 指定jstack输出文件的存储目录，方便记录以后续分析
show-busy-java-threads -S <存储jstack输出文件的目录>
```

注意事项

```
sh

# 如果Java进程的用户 与 执行脚本的当前用户 不同，则jstack不了这个Java进程
# 为了能切换到Java进程的用户，需要加sudo来执行，即可以解决：
sudo show-busy-java-threads

# 对于sudo方式的运行，JAVA_HOME环境变量不能传递给root，
# 而root用户往往没有配置JAVA_HOME且不方便配置，
# 显式指定jstack命令的路径就反而显得更方便了
show-busy-java-threads -s <指定jstack命令的全路径>
2.2.3 其他命令

# -m选项：执行jstack命令时加上-m选项，显示上Native的栈帧，一般应用排查不需要使用
show-busy-java-threads -m
# -F选项：执行jstack命令时加上 -F 选项（如果直接jstack无响应时，用于强制jstack），一般情况不需要使用
show-busy-java-threads -F
# -l选项：执行jstack命令时加上 -l 选项，显示上更多相关锁的信息，一般情况不需要使用
# 注意：和 -m -F 选项一起使用时，可能会大大增加jstack操作的耗时
show-busy-java-threads -l
```

示例

```
sh

$ show-busy-java-threads
[1] Busy(57.0%) thread(23355/0x5b3b) stack of java process(23269) under user(admin):
"pool-1-thread-1" prio=10 tid=0x000000005b5c5000 nid=0x5b3b runnable [0x000000004062c000]
   java.lang.Thread.State: RUNNABLE
    at java.text.DateFormat.format(DateFormat.java:316)
    at com.xxx.foo.services.common.DateFormatUtil.format(DateFormatUtil.java:41)
    at com.xxx.foo.shared.monitor.schedule.AppMonitorDataAvgScheduler.run(AppMonitorDataAvgScheduler.java:127)
    at com.xxx.foo.services.common.utils.AliTimer$2.run(AliTimer.java:128)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

[2] Busy(26.1%) thread(24018/0x5dd2) stack of java process(23269) under user(admin):
"pool-1-thread-2" prio=10 tid=0x000000005a968800 nid=0x5dd2 runnable [0x00000000420e9000]
   java.lang.Thread.State: RUNNABLE
    at java.util.Arrays.copyOf(Arrays.java:2882)
    at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
    at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572)
    at java.lang.StringBuffer.append(StringBuffer.java:320)
    - locked <0x00000007908d0030> (a java.lang.StringBuffer)
    at java.text.SimpleDateFormat.format(SimpleDateFormat.java:890)
    at java.text.SimpleDateFormat.format(SimpleDateFormat.java:869)
    at java.text.DateFormat.format(DateFormat.java:316)
    at com.xxx.foo.services.common.DateFormatUtil.format(DateFormatUtil.java:41)
    at com.xxx.foo.shared.monitor.schedule.AppMonitorDataAvgScheduler.run(AppMonitorDataAvgScheduler.java:126)
    at com.xxx.foo.services.common.utils.AliTimer$2.run(AliTimer.java:128)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

......
```

上面的线程栈可以看出，CPU 消耗最高的 2 个线程都在执行 `java.text.DateFormat.format`，业务代码对应的方法是 `shared.monitor.schedule.AppMonitorDataAvgScheduler.run`。可以基本确定：

* AppMonitorDataAvgScheduler.run 调用 DateFormat.format 次数比较频繁。
* DateFormat.format 比较慢。（这个可以由 DateFormat.format 的实现确定。）

多执行几次 show-busy-java-threads，如果上面情况高概率出现，则可以确定上面的判定。因为调用越少代码执行越快，则出现在线程栈的概率就越低。脚本有自动多次执行的功能，可以指定 **重复执行的间隔秒数/重复执行的次数** 参数。

分析 `shared.monitor.schedule.AppMonitorDataAvgScheduler.run` 实现逻辑和调用方式，以优化实现解决问题。

## MySQL的CPU使用率飙升

首先，我们要对问题定位而不是盲目的开启什么慢日志，在并发量大并且大量SQL性能低的情况下，开启慢日志无意是将MySQL推向崩溃的边缘。

### 问题定位

当时遇到这个情况，分析了当前的数据量、索引情况、缓存使用情况。目测数据量不大，也就几百万条而已。接下来就去定位索引、缓存问题。

经过询问，发现很多查询都是走MySQL，没有用到缓存。既然没有用到缓存，则是大量请求全部查询MySQL导致，可以通过下面的命令查看:

```
sql

show processlist;
```

以此来找出哪些查询可能是瓶颈，并据此进行优化。

#### 了解下 show processlist

通常我们通过 `Top` 检查发现 mysql CPU 或者 io wait 过高 那么解决这些问题都离不开 `show processlist`。`show processlist` 是显示用户正在运行的线程，需要注意的是，除了root用户能看到所有正在运行的线程外，其他用户都只能看到自己正在运行的线程，看不到其它用户正在运行的线程。除非单独个这个用户赋予了`PROCESS` 权限。

注意

`show processlist` 只显示前100条 我们可以通过 `show full processlist` 显示全部。

`show processlist` 显示的信息都是来自MySQL系统库 `information_schema` 中的 `processlist` 表。所以使用下面的查询语句可以获得相同的结果：

```
sql

SELECT * FROM information_schema.processlist;
SELECT * FROM information_schema.processlist WHERE TIME > 5 ORDER BY TIME DESC;
```

#### show processlist 参数分析

* Id：登录mysql后，系统分配的connection\_id表示线程的唯一标识，可以使用函数connection\_id()查看。当需要kill一个语句的时候会用到。前面我们说了show processlist显示的信息时来自information\_schema.processlist表，所以这个Id就是这个表的主键。
* User：就是指启动这个线程的用户,如果是system user，它是指由服务器产生的非客户线程，以在内部处理任务。
* Host：记录了发送请求的客户端的IP和端口号。通过这些信息在排查问题的时候，我们可以定位到是哪个客户端的哪个进程发送的请求。
* db：当前执行的命令是在哪一个数据库上。如果没有指定数据库，则该值为 NULL 。
* Command：显示当前连接的执行的命令，一般就是休眠或空闲（sleep），查询（query），连接（connect）。这个参数很复杂，有兴趣可以单独去了解
* Time：表示该线程处于当前状态的时间，单位是秒。
* State：显示使用当前连接的sql语句的状态，请注意，state只是语句执行中的某一个状态，一个 sql语句，已查询为例，可能需要经过copying to tmp table，Sorting result，Sending data等状态才可以完成
* Info：一般记录的是线程执行的语句，对于长时间运行的查询，这可以是有用的调试信息。默认只显示前100个字符，也就是你看到的语句可能是截断了的，要看全部信息，需要使用 `show full processlist`。

### 问题分析

通过上述发现类似很多相同的SQL语句，一直处于query状态中。`select id form user where user_code = 'xxxxx'`;

初步分析可能是 `user_code` 字段没有索引导致，接着查询user表的索引情况：`show index form user;`
发现这个字段是没有建立索引。增加索引之后，该条SQL查询能够正常执行。没隔一会，又发生大量的请求超时问题。

接着进行分析，发现是开启了慢日志查询。大量的SQL查询语句超过慢日志设置的阀值，于是将慢日志关闭之后，速度瞬间提升,但还不是理想状态。

紧接着将部分实时查询数据的SQL语句，都通过缓存(redis)读写实现。观察一段时间后，基本维持在了70%~
80%。

### 排查思路总结

其实本次事故的解决很简单，就是添加索引与缓存结合使用。不推荐在这种CPU使用过高的情况下进行慢日志的开启。因为大量的请求，如果真是慢日志问题会发生日志磁盘写入，性能贼低。

直接通过MySQL `show processlist` 命令查看，基本能清晰的定位出部分查询问题严重的SQL语句，在针对该SQL语句进行分析。一般可能就是索引、锁、查询大量字段、大表等查询问题导致。再则一定要使用缓存系统，降低对MySQL的查询频次。对于内存调优，也是一种解决方案。

线上性能问题 - CPU 飙升100%+

偶尔需要搭建mysql环境，每次百度也够费劲的，而且还不一定会成功，所以急需一本自己的安装手册，在有需要的时候能随时翻阅，提高效率。

## 下载

当前维护和支持的 MySQL 版本（如果想要下载的版本找不到，就使用下面不在维护的链接中）

> <https://dev.mysql.com/downloads/mysql/>

不再维护和支持的旧版本的

> <https://downloads.mysql.com/archives/community/>

当前我安装的是维护版本 8.0.40

```
shell

wget https://cdn.mysql.com//Downloads/MySQL-8.0/mysql-8.0.40-linux-glibc2.28-x86_64.tar.xz
```

## 安装

下载完以后进行解压

```
shell

tar -xf mysql-8.0.40-linux-glibc2.28-x86_64.tar.xz
```

将解压的文件夹重名为mysql且移动到对应安装目录下，默认是 /usr/local

```
shell

mv mysql-8.0.40-linux-glibc2.28-x86_64 /opt/mysql
```

编辑配置文件 /etc/my.cnf

```
shell

vim /etc/my.cnf
```

my.cnf 填充内容
以下内容中，需要将socket、basedir、datadir地址修改为当前安装的mysql路径

```
shell

###### [client]配置模块 ######
[client]
default-character-set=utf8mb4
socket=/opt/mysql/mysql.sock

###### [mysql]配置模块 ######
[mysql]
# 设置MySQL客户端默认字符集
default-character-set=utf8mb4
socket=/opt/mysql/mysql.sock

###### [mysqld]配置模块 ######
[mysqld]
port=3306
user=mysql
# 设置sql模式 sql_mode模式引起的分组查询出现*this is incompatible with sql_mode=only_full_group_by，这里最好剔除ONLY_FULL_GROUP_BY
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
basedir=/opt/mysql
datadir=/opt/mysql/data
socket=/opt/mysql/mysql.sock
server-id = 1

# MySQL8 的密码认证插件 如果不设置低版本navicat无法连接
default_authentication_plugin=mysql_native_password

# 禁用符号链接以防止各种安全风险
symbolic-links=0

# 允许最大连接数
max_connections=1000

# 服务端使用的字符集默认为8比特编码的latin1字符集
character-set-server=utf8mb4

# 创建新表时将使用的默认存储引擎
default-storage-engine=INNODB

# 0: 表名将按指定方式存储，并且比较区分大小写;
# 1: 表名以小写形式存储在磁盘上，比较不区分大小写；
lower_case_table_names=0
max_allowed_packet=16M

# 设置时区
default-time_zone='+8:00'
```

添加用户，分配权限

```
shell

groupadd mysql
useradd -g mysql mysql

chown -R mysql.mysql /opt/mysql
chmod 777 /opt/mysql/data -R
```

初始化数据库

```
shell

cd /opt/mysql
bin/mysqld --user=mysql --basedir=/opt/mysql --datadir=/opt/mysql/data --initialize
```

编辑 mysql.server，找到以下属性，将其修改为对应mysql安装路径

```
shell

basedir=/opt/mysql
datadir=/opt/mysql/data
```

将脚本添加为服务启动项，可通过 service mysql start/status/stop 启动服务

```
shell

cd /opt/mysql
cp ./support-files/mysql.server /etc/init.d/mysql
chmod +x /etc/init.d/mysql
chkconfig --add mysql
```

启动服务

```
shell

service mysql start
```

重置密码

```
shell

# 设置软连接
ln -s /opt/mysql/bin/mysql /usr/bin
# 登录
mysql -uroot -p
```

设置密码

```
shell

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '新密码';
```

设置远程访问

```
shell

# 被连接的数据库的用户名、其中“%”表示允许所有机器能访问root用户
create user root@'%' identified by '新密码';
grant all privileges on *.* to root@'%' with grant option;
```

查询授权

```
shell

use mysql;
select host,user,plugin,authentication_string from user;
```