- 博客(841)
- 资源 (15)
- 收藏
- 关注
RSS订阅原创 MySQL服务端连接约2小时才释放背后的原因是什么
MySQL 应用层的 wait_timeout 默认是 8 小时，但内核层面的 TCP 保活检测触发更早。连接约 2 小时才释放，最常见的原因是 Linux 操作系统默认的 TCP Keepalive 保活探测机制触发，其次是 MySQL 空闲超时参数被主动配置为 2 小时，也可能由中间网络设备的会话超时导致。应用程序使用MySQL的user lock，在MySQL客户端与MySQL服务端连接建立后，接着通过网络工具模拟drop数据丢包，此时再尝试拿锁，一直提示锁存在，约2小时后才可以加锁成功。
2026-09-03 08:42:28
167
原创 MySQL服务器连接什么时候释放
通过网络工具静默丢弃数据包（DROP）时，MySQL 服务器端不会立刻感知到连接中断，连接释放时机取决于连接当前的运行状态和对应的超时参数。执行后会返回参数名和对应取值，可直接对应上文中提到的 wait_timeout 、 net_read_timeout 等配置项。注意：如果此时正在执行大查询，SQL 本身会继续运行直到完成，只是结果无法送达客户端，需等写超时到达后才会释放连接和线程资源。如果是返回 RST 复位的拒绝策略（如 REJECT），服务器收到后会立即释放连接。
2026-09-02 21:20:13
149
原创 为什么 Nginx 默认不重试 POST 请求？
幂等：同一个请求执行 1 次和 N 次，服务端的资源最终状态完全一致，且不会产生额外副作用。非幂等：多次执行会导致资源状态重复变化、产生额外副作用（如重复扣款、重复下单）。
2026-08-25 21:18:56
206
原创 在nginx中，proxy_next_upstream off是什么含义
proxy_next_upstream off 表示完全关闭 Nginx 的上游节点自动故障重试机制。请求被分发到 upstream 组内某一台后端服务器后，无论发生连接失败、读写超时，还是后端返回错误响应，Nginx 都不会自动切换到组内其他节点重试，而是直接将当前结果返回给客户端。
2026-08-25 21:14:55
172
原创 发布过程中，Gunicorn 进程重启会中断正在处理的请求吗？
在 Gunicorn 的 master-worker 架构下，发布重启对正在处理的请求的影响，核心取决于重启使用的信号/操作方式。生产常用的优雅重启/热升级在正常耗时下不会中断请求，仅超时或强制终止场景会导致请求失败。
2026-08-03 21:16:58
222
原创 Flink 简单例子
我们用Flink最经典的入门案例——来演示完整流程：模拟从端口源源不断接收文本数据流，Flink实时统计每个单词的累计出现次数，全程低延迟、自动维护计数状态。
2026-07-25 23:02:34
658
原创 Flink的使用场景
摘要： Apache Flink作为流批一体的分布式计算引擎，凭借低延迟、高吞吐及精准状态管理等特性，广泛应用于多领域实时数据处理： 实时ETL与数仓：实现数据全链路实时同步、分层加工与多源融合。 实时分析：支撑大屏、报表与用户行为分析，秒级刷新业务指标。 风控反欺诈：通过CEP毫秒级识别交易异常、刷单等风险。 实时推荐：动态优化推荐策略与营销触达。 物联网监控：处理设备时序数据，实现异常检测与工业质检。 事件驱动系统：如订单状态变更自动触发业务流程。 流批一体：统一逻辑处理实时与离线数据，保障口径一致。
2026-07-25 22:56:54
309
原创 Kafka + Flink实时时流处理场景
以业界最主流的 Kafka + Flink 组合为例，架构分为四层，是实时大屏、实时风控、实时推荐等业务的标准落地方案。
2026-07-21 21:29:46
299
原创 MySQL 中 CURRENT_TIMESTAMP 到底取的是 INSERT 时间，还是 COMMIT 时间？
MySQL中定义为DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP的timestamp字段，在INSERT时会取语句开始执行时的时间（不是COMMIT时间）。实验表明：即使INSERT语句执行耗时10秒或事务延迟提交，updated_ts仍记录INSERT开始时刻。ON UPDATE仅在后续UPDATE操作时触发，不会因COMMIT而更新。若显式指定该字段值则以指定值为准。
2026-07-10 23:21:32
230
原创 主库“写入过 binlog，但后来主库 binlog 文件里看不到了”
文章摘要：MySQL主从复制中可能出现主库binlog丢失而从库保留事务的情况。典型场景是主库事务已写入binlog缓存并发送给从库，但未持久化(sync_binlog≠1)，此时主库宕机导致binlog尾部丢失。排查需关注：主库sync_binlog和innodb_flush_log_at_trx_commit配置、半同步设置、主库crash记录，以及从库binlog是否包含超出主库末尾的GTID/position。核心结论：主库未持久化的事务可能通过复制保留在从库binlog中。
2026-07-04 23:23:56
235
原创 简单概括主库上 Executed_Gtid_Set 是什么时候更新的
MySQL主库的Executed_Gtid_Set更新时机总结：主库事务提交成功后（存储引擎提交完成）才会更新到@@GLOBAL.gtid_executed，与binlog写入时间不同步。半同步复制中，after_sync模式下主库需等待从库ACK后才提交存储引擎，此时GTID尚未加入Executed_Gtid_Set；after_commit模式下主库先提交后等待ACK，GTID会立即加入。注意@@GLOBAL.gtid_executed与mysql.gtid_executed表存在差异，前者反映实时状态
2026-07-04 23:19:03
220
原创 对象存储的适用场景
补充：互联网发展早期，也会用GFS、早期HDFS这类分布式文件系统承载海量数据，但这类系统面向离线批量处理设计，小文件性能差，没有原生HTTP接口，不适合直接对外提供互联网访问，POSIX兼容的设计也带来了额外的架构复杂度。对象存储原生基于HTTP/HTTPS的RESTful API，天然适配互联网场景，支持跨地域访问、精细化权限管控、签名鉴权，可直接作为网页、APP的后端存储。SAN需要专用存储网络，NAS的NFS/SMB协议不适合公网传输，防火墙穿透难、安全性差，无法直接支撑网页、APP的资源访问。
2026-07-04 15:57:27
237
原创 湖仓一体架构概览
这是湖仓一体架构的核心差异化设计：特征存储不独立建设底层存储，离线特征直接落地在数据湖中，仅在线特征独立部署低延迟存储，从根源解决训练-服务一致性问题。在湖仓一体（Lakehouse）架构下，三者并非独立堆叠，而是基于统一的底层存储与元数据体系形成分层协作的数据流，核心是。需要我补充一份基于开源组件（Iceberg + Spark + Feast）的落地技术栈清单吗？，彻底避免传统架构下的数据冗余与口径不一致问题。
2026-06-30 23:03:11
467
原创 Data Lakes vs Data Warehouses vs Feature Stores
数据仓库、数据湖和特征存储是企业数据架构中三个互补的层级系统，各有不同定位。数据仓库用于结构化业务分析和BI报表；数据湖存储全量原始数据，支持探索式分析；特征存储则专注于机器学习特征的全生命周期管理。三者协作形成数据流转体系：数据湖为底层数据源，数据仓库加工业务分析数据，特征存储提供模型所需特征数据。选型需根据业务需求，分别适用于传统分析、数据探索和机器学习场景。三者并非替代关系，而是共同构建完整的数据服务体系。
2026-06-30 22:55:49
347
原创 几句话概括，MySQL 半同步中，after_commit 与 after_sync 有什么区别
MySQL半同步复制中，AFTER_SYNC和AFTER_COMMIT的主要区别在于主库等待从库ACK的时机。AFTER_SYNC是主库在binlog刷盘后、引擎提交前等待从库确认，确保事务持久化到至少一个从库后才提交，安全性更高，是5.7+的默认模式。而AFTER_COMMIT是主库先提交事务再等待从库ACK，存在主库提交后从库未确认的短暂风险期，可能导致数据不一致。简言之，AFTER_SYNC优先保证数据安全，AFTER_COMMIT优先提升可见性但风险更高。两种模式都仅保证从库接收事务到relay l
2026-06-30 22:47:49
201
原创 Kubernetes 与 Docker Compose：异同详解
Docker Compose = 单机多容器“启动脚本”，简单轻便，服务于开发测试；Kubernetes = 容器集群“操作系统”，功能强大复杂，服务于生产集群；二者不是竞争替代关系，而是开发与生产的上下游搭档。
2026-06-01 21:20:00
303
原创 Linux 系统进程全状态详解（内核底层+用户实操双视角）
Linux 进程状态分为内核源码定义的真实状态（基于 task_struct 结构体）和 用户态 ps/top 命令展示的简化状态，二者一一对应但视角不同。下面从底层原理、触发场景、实操表现、问题排查、状态流转5个维度，全面拆解所有状态，同时覆盖传统基础状态、现代内核新增状态、用户态修饰符、高频故障场景。
2026-05-09 18:58:34
279
1
原创 MLOps 超全详解
DevOps 让普通软件工业化，MLOps 让人工智能模型工业化；没有 MLOps，AI 只能做Demo、做试点；有了 MLOps，AI 才能真正规模化落地到生产业务。
2026-05-06 21:07:10
900
原创 端侧推理：全面解析与深度洞察
本质：将AI计算从云端数据中心下沉到离用户/数据源最近的终端设备，实现"数据不出设备"的智能处理闭环。本地执行：模型推理在终端硬件上完成，无需数据上传至云端服务器资源受限：运行环境通常有CPU/GPU算力、内存、存储和功耗的严格限制轻量高效：需通过模型优化适配端侧硬件，平衡精度与性能实时响应：消除网络传输延迟，实现毫秒级决策。
2026-05-03 15:45:39
980
原创 vLLM 全部8种部署方式（按从简单到企业级排序，附适用场景+最简命令）
适用：本地开发、调试、二次开发、嵌入RAG/Agent项目。特点：张量并行TP、流水线并行PP，拆分模型到多卡/多机。适用：快速搭OpenAI兼容接口、临时测试、内网小服务。适用：70B、110B、MoE大模型，单张GPU放不下。能力：流量分发、限流、熔断、接口统一域名、隐藏后端实例。适用：线上高并发、多GPU节点、自动扩缩容、灰度发布。特点：集群化管理、故障自愈、负载均衡、多模型统一调度。适用：单机GPU服务器、私有化部署、环境统一隔离。适用：政务、金融、涉密内网，不能联网。
2026-05-02 17:51:43
466
原创 vLLM全解析：定义、用途与竞品对比
vLLM（Very Large Language Model inference） 是由加州大学伯克利分校LMSYS团队于2023年6月开源的高性能大模型推理与服务引擎，专注解决大模型部署中的显存效率低、吞吐量瓶颈、延迟高三大核心问题。核心技术创新PagedAttention（分页注意力）：借鉴操作系统虚拟内存管理思路，将KV缓存分割为固定大小的块，内存浪费控制在4%以内，支持动态分配与释放，单卡可服务更多请求。
2026-05-02 17:20:22
392
原创 大模型部署全流程深度解析
准备阶段：明确业务需求→选择模型→规划硬件→搭建环境优化阶段：量化（INT4/INT8）→并行策略（TP/PP）→推理引擎选择（vLLM/TensorRT-LLM）→KV缓存配置服务化阶段：封装API→配置负载均衡→设置扩缩容规则→接口测试部署阶段：容器化（Docker）→编排（K8s）→灰度发布→全量上线运维阶段：监控指标→日志分析→告警处理→性能优化→版本迭代。
2026-05-02 17:07:26
1197
原创 大模型训练框架全景解析（2026最新）
大模型训练框架生态呈现分层化、专业化趋势：通用框架（PyTorch/TensorFlow/JAX）提供基础能力，分布式专用框架（DeepSpeed/Megatron/FSDP）解决超大规模训练痛点，集成框架（NeMo/PyTorch Lightning）降低工程化门槛。选型核心原则：小规模模型选易用性，大规模模型选性能，超大规模模型选混合方案。同时需考虑团队技术栈、硬件环境与项目阶段，灵活组合不同框架优势，实现高效训练与快速迭代。
2026-05-02 16:21:52
730
原创 一文看懂大模型有哪些架构
大模型架构围绕Transformer三大基础范式扩展，形成多元生态。选择架构应匹配任务：理解优先选Encoder-Only，生成优先选Decoder-Only，转换任务选Encoder-Decoder，复杂场景选MoE或混合架构，超长序列考虑Mamba等新兴架构。
2026-05-02 15:52:42
529
原创 RAG全面解析:从原理到应用场景
Chroma等（向量库）+ BGE/M3E（嵌入模型）+ 通义千问/GLM（大模型）凑在一起，就是一套标准极简 RAG 系统。
2026-05-01 16:22:41
259
原创 claude-context 本地部署方案
本文介绍了一种完全离线的本地化解决方案，用于对接本地部署的Claude-Code。该方案采用全本地架构，包括本地Milvus向量数据库、Ollama开源嵌入模型、本地构建的MCP索引服务和本地Claude-Code客户端，无需依赖任何云端API。安装过程包括配置Docker、Node.js、pnpm和Ollama环境，启动本地Milvus向量库和嵌入模型，构建Claude-Context服务，并进行本地代码库索引。通过配置本地MCP服务，用户可以在断网环境下使用本地Claude-Code检索项目代码。该方案
2026-04-26 12:08:33
656
1
原创 claude-context -- 让AI 能深度理解和检索代码库
claude-context是Zilliz开发的开源MCP插件，为AI编程助手提供语义代码搜索能力。它通过将代码库转化为向量数据库索引，实现自然语言查询代码功能，解决AI处理大型代码库时的关键痛点：上下文窗口限制、手动传递低效、代码理解不全和跨模块协作难。核心技术包括代码AST解析、向量嵌入、混合搜索和智能分块。提供多个变体版本满足不同场景需求，适用于大型项目开发、代码重构、Bug调试等场景，显著提升开发效率并降低40%+Token成本，是AI编程助手的"代码理解增强器"。
2026-04-26 11:34:03
487
原创 OpenClaw新会话记忆加载过程
在 OpenClaw 里，新会话刚启动时，记忆不是一次性全塞给模型，而是走一套非常固定、轻量的初始化加载 + 按需召回流程。下面用最清晰、最贴近源码逻辑的方式讲：新会话开始时，记忆的完整使用流程。
2026-04-24 22:20:43
388
原创 OpenClaw记忆系统
OpenClaw记忆系统采用文件即真相的设计理念，以纯Markdown文件为核心存储，配合SQLite+向量数据库的混合索引，实现持久化、可检索、可管理的AI记忆能力。核心是三层记忆架构与智能检索-召回机制，确保模型只“记住”写入磁盘的内容，无隐藏状态。
2026-04-24 22:15:50
504
原创 一文读懂人工智能，机器学习，深度学习，神经网络，Transformer
定义：让机器具备感知、推理、决策、理解、创造等类人智能的技术总称。包含内容传统人工智能（非机器学习）符号推理、规则系统、专家系统、搜索算法、博弈算法知识图谱（规则推理）、自动逻辑证明现代人工智能（机器学习方向）传统机器学习深度学习其他分支模糊控制、进化算法（遗传算法）、机器人控制、多智能体AI：范围最大机器学习：AI里“靠数据学习”的路线深度学习：机器学习里“用深层神经网络”的路线神经网络：深度学习的模型本体：神经网络中，当前大模型的核心底座。
2026-04-17 22:26:48
2400
2
原创 AI agent中的skill
在AI Agent（智能体）领域，Skill（技能） 可以直白理解为：智能体为了完成具体任务，所具备的标准化、可直接调用的执行能力单元。
2026-03-23 20:54:08
185
原创 主流AI Agent
以下是按商业产品、开源框架、特定领域应用分类的主流AI Agent汇总，覆盖通用助手、开发协作、企业自动化等场景，信息截至2026年3月。
2026-03-23 20:47:49
1283
原创 OpenClaw与Claude Code的Skill比较
两者的Skill系统在核心设计理念、基础结构与使用体验上几乎一致，共享Agent Skills的技术基因，是AI智能体能力扩展的标准化解决方案。差异主要体现在执行效率、扩展自由度与生态定位上，用户可根据需求选择更适合的平台，而无需重新学习技能开发范式。需要我整理一份SKILL.md的最小兼容模板（包含必要元数据与触发示例），让你能快速写出同时适配两者的技能吗？
2026-03-18 21:13:21
475
原创 OpenClaw与Claude Code相似之处
两者虽定位有别（Claude Code专注编程专家，OpenClaw偏向通用智能体），但在技术基础、交互范式与核心能力上高度一致，均代表AI辅助开发的重要方向。OpenClaw可视为Claude Code的社区扩展版，提供更灵活的部署与定制选项，而Claude Code则具备官方支持与更稳定的企业级特性。
2026-03-18 21:01:50
332
原创 OpenClaw与大模型通信过程：详细图文教程（2026最新）
完整通信链路：用户指令→渠道适配→网关调度→模型思考→MCP工具调用→技能执行→结果反馈→模型优化→最终回复→用户。核心结论：通过三层架构+MCP协议+Agent循环，OpenClaw与大模型实现“理解→规划→执行→反馈→优化”的全链路通信，把自然语言指令转化为本地可执行操作。下面用可视化图表+实操示例，完整拆解每一步通信细节。{“role”: “system”, “content”: “你是文件管理助手，可调用file-manager技能”},“图片”: [“jpg”, “png”, “webp”],
2026-03-13 21:46:56
877
原创 MySQL Group Replication (MGR)选主中是如何保证数据不丢失的
所以，你提到的“数据最新程度”之所以是第三优先级，是因为在它之前，底层共识协议已经保证了所有进入待选池的节点数据都是一致且完整的。但在MGR的机制中，数据一致性有更底层的保底设计，不会因此而丢失数据。因此，如果一个高权重的节点数据略微落后，而一个低权重的节点数据最新，按照标准流程，那个高权重但数据稍旧的节点会被选中。虽然选出的节点可能不是数据最新的，但它一定是数据一致的。· 在选主时，这些数据落后的节点会被自动排除在候选名单之外，它们没有资格参与竞选。· 集群会忽略它的高权重，等待真正数据完整的节点竞选。
2026-02-27 21:34:14
421
原创 MySQL Group Replication (MGR)选主策略
在 MySQL Group Replication (MGR) 的单主模式中，当主库发生故障时，剩余的节点会自动触发新的主库选举。选举过程遵循一套严格的优先级规则，确保选出数据最完整且符合配置策略的节点。· 若集群中存在低于 MySQL 8.0.17 的节点，选举会优先考虑主版本号较低的节点（例如 5.7 节点优先于 8.0），因为低版本节点无法作为从库复制高版本的数据。综上所述，MGR 的新主选举是一个层层筛选、数据优先的过程，在保证集群可用性的前提下，最大限度地避免数据丢失，并兼顾了管理员的可控性。
2026-02-27 21:24:27
363
原创 在MySQL中，出现Executed_Gtid_Set 乱序增长的场景
由于各事务提交速度不同，后面的可能先执行完，导致Executed_Gtid_Set在尾部出现暂时不连续。并行复制导致的尾部临时空洞通常无需干预，而因手动跳过、参数误操作或主机崩溃导致的永久性不一致，则需要通过重建同步或数据校验来处理。在MySQL中，Executed_Gtid_Set 乱序增长通常指的是该集合中出现非连续的区间（即“空洞”）。若之前已执行到N，跳过N+1，集合会变成 1-N : N+2-M，形成永久空洞。从库记录的GTID集合因此多于重启后的主库，这种不一致在集合中表现为“多余的区间”。
2026-02-17 17:35:37
191
原创 MySQL主从库复制中，主库如何查找对应日志文件位置
GTID 自动定位：从库告诉主库“我有什么”，主库自己计算“你需要什么”，并通过内置的“索引”（Previous_gtids_log_event）智能地找到从哪里开始提供。在基于 GTID 的复制中，从库发送已执行的 GTID 集合后，主库查找对应日志文件位置的过程，本质上是一个 “智能计算” 而非简单的“文件指针跳转”。这个过程的核心，就是主库利用二进制日志中特殊标记（Previous_gtids_log_event）的索引功能，快速定位到从库缺失事务的起始点。⚙️ 主库的“三步定位法”
2026-02-17 17:25:40
355
深入理解linux内核 第三版 Daniel P. Bovet &Marco Cesati 勘误
2011-03-07
sqlite嵌入式编程实例
2012-06-20
ndiswrapper 最新版本下载 ndiswrapper-1.57.tar.gz
2012-03-07
Spreadsheet-ParseXLSX-0.16.tar.gz
2014-11-26
Linux下使用USB转串口获取GPS数据
2012-03-01
Linux下sqlite3编程实例
2012-06-20
git post-update
2017-07-30
rt5370驱动
2012-03-20
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人