任务队列与单例模式思考
Python 单例模式深度解析：从任务队列的多实例问题谈起1. 问题的起源在开发 AssociationRuleTaskQueue（关联规则任务队列）时，我们遇到了一个关于“实例唯一性”的疑问： “我在运行 from core.task_queue import rule_task_queue 的时候，其实就会运行一次 rule_task_queue = AssociationRuleTaskQueue() 对吗？所以每一次导入都会实例化一次对吗？” 这个疑问触及了 Python 两个核心机制：模块导入机制 和 类实例化机制。本文将以此为切入点，深入解析 Python 的 __new__ 方法与单例模式（Singleton Pattern）。 2. Python 模块导入机制：天然的“单例”首先回答你的疑问：每一次导入并不会都实例化一次。 Python 的模块（Module）对象在整个解释器进程中是全局唯一的。当你执行 import core.task_queue 或 from core.task_queue import rule_task_queue 时，Python...
防火墙大乱斗：iptables、ufw、firewalld 到底是什么关系？
作为一个 Linux 用户，你肯定经历过这样的时刻：想开个 80 端口，搜到一条命令是 iptables -I INPUT -p tcp --dport 80 -j ACCEPT。换了台 Ubuntu 服务器，教程又让你用 ufw allow 80。到了 CentOS 7/8，系统告诉你 iptables 过时了，请用 firewall-cmd --add-port=80/tcp。 这时候你可能会想：为什么 Linux 有这么多防火墙？它们是竞争关系？替代关系？还是根本就是同一个东西换了层皮？ 今天我们就来把这团乱麻彻底理清楚。 一、 核心真相：它们都只是“遥控器”首先要揭露一个真相：iptables、ufw、firewalld，严格来说都不是真正的防火墙。 Linux 真正的防火墙藏在操作系统内核里，它的名字叫 Netfilter。 **Netfilter (内核态)**：它是 Linux 内核的一个框架，负责在网络协议栈中“抓包”、修改包、过滤包。它是真正的干活人，住在内核空间，普通用户接触不到。 用户态工具：iptables、ufw、firewalld...
再见 Conda？Python 极速包管理器 uv 上手指南
Python 的环境管理一直是个让开发者头秃的问题。 从最早的 pip + venv，到科学计算必备的 conda，再到后来追求项目隔离的 poetry 和 pdm，我们手里的工具越来越多，但困惑也越来越多： “Conda 解析依赖太慢了，一直在转圈圈。”“听说 Anaconda 公司改了协议，公司用要收费了？”“Poetry 很好用，但是安装依赖有时候卡很久。” 就在大家在这个泥潭里挣扎时，uv 横空出世。它号称是“Python 的 Cargo（Rust 的包管理器）”，主打一个字：快。 今天我们就来聊聊这个用 Rust 编写的 Python 包管理新星，看看它是否有资格终结这场“环境管理之战”。 一、 为什么要换掉 Conda？很多 Python 初学者（尤其是搞数据科学的）入行安装的第一个软件就是 Anaconda。但随着时间推移，Conda 的问题逐渐暴露： 慢：这是最大的槽点。当你安装一个复杂的库（比如 PyTorch）时，Conda 的依赖解析（Solving environment）能让你等到怀疑人生。 臃肿：Anaconda...
面试造航母：普通开发者真的需要担心“千万级并发”吗？
“如果有 1000 万并发，你的系统怎么设计？” 这大概是后端面试中最经典，也最让人无语的问题之一。 作为一个在中小厂摸爬滚打多年的普通开发者，我常常看着自己负责的系统——QPS（每秒查询率）峰值不到 50，日活几千人——陷入沉思：我这辈子真的能遇到千万级并发吗？ 今天我们就来戳破这个泡沫，聊聊并发的真相，以及作为普通开发者，我们真正应该关心什么。 一、 别被“并发”忽悠了首先，我们要厘清几个被混淆的概念。 1. 网页资源多 = 并发高？有人告诉你：“一个网页加载要请求 50 个图片、CSS、JS，如果有 1 万个人访问，那就是 50 万并发啊！” 这是典型的偷换概念。 CDN 的存在：现代 Web 开发，静态资源（图片、CSS、JS）通常都放在 CDN 上，根本不会打到你的后端服务器（API Server）。 浏览器限制：浏览器对同一个域名的并发连接数是有限制的（通常 6-8 个）。 长连接：HTTP/1.1 和 HTTP/2 复用了 TCP 连接。 所以，前端资源的请求量，跟后端服务的并发压力，完全是两码事。 2. 用户量大 = 并发高？“我们系统有...
PostgreSQL：数据库界的“瑞士军刀”，真的能取代 Redis 吗？
最近，技术圈里刮起了一股“反简化”的风潮，其中最响亮的口号之一就是：“你其实不需要 Redis，一个 PostgreSQL 就够了。” 作为一个习惯了 MySQL + Redis 黄金搭档的开发者，听到这话的第一反应通常是：“疯了吧？Redis 是内存数据库，PostgreSQL 是关系型数据库，这俩能是一回事？” 但当你深入了解 PostgreSQL（简称 PG）之后，你会发现它早已不是一个简单的“关系型数据库”了。它更像是一个无所不能的数据库平台。 今天我们就来聊聊这位“全能选手”，以及它是否真的有底气取代 Redis。 为什么大家都在谈论 PostgreSQL？在 MySQL 称霸 Web 开发的年代，PostgreSQL 常被贴上“学院派”、“配置复杂”的标签。但随着版本迭代，PG 凭借其强大的扩展能力（Extensions）和先进的特性，逐渐成为了架构师的心头好。 它支持： 关系型数据（标准的 SQL，比 MySQL 更严格更强大）。 JSON 文档（JSONB 类型，查询性能甚至超越 MongoDB）。 ...
架构演变史：你以为的“前后端分离”可能只是冰山一角
作为一名后端开发者，你是否也有过这样的困惑： “前端把代码打包成一堆 HTML/CSS/JS 给我，我把它丢在我的 Nginx 或者静态目录里部署，这不就是以前的 MVC 吗？这也能叫前后端分离？” “隔壁组的前端自己在服务器上跑了个 Node.js 服务（React/Vue），然后调我的 Java/Python 接口，用户直接访问他们的服务，这才是真正的分离吧？” 其实，这两种模式都属于“前后端分离”，只是处于演变历史中的不同阶段，或者说是为了解决不同问题而诞生的架构模式。 今天，我们就来一场时空穿越，聊聊 Web 开发架构的前世今生，帮你彻底理清这些概念。 第一阶段：混沌初开 —— 传统的服务端渲染 (Classic SSR / MVC)在 2010 年以前（PHP、JSP、ASP.NET、早期的 Django/Rails 时代），Web 开发的主流是 **服务端渲染 (Server-Side Rendering)**。 工作模式 浏览器向服务器发送请求。 后端（PHP/Java/Python）接收请求，查询数据库。 后端使用模板引擎（JSP, Jinja2,...
显存去哪了？深度学习框架显存管理机制与多模型共存指南
在使用 MinerU、Stable Diffusion 或 LLM 本地部署时，我们经常会遇到一种“灵异现象”：模型明明跑完了，任务也结束了，但显存（VRAM）占用依然居高不下。如果有两个模型想在同一张显卡上轮流跑，经常会因为前一个模型“占着茅坑不拉屎”而导致后一个模型 OOM（Out Of Memory）。 为什么显存会“无休止”地扩张？为什么框架不愿意把显存还给操作系统？这背后其实是一套精心设计的“贪婪”机制。 今天我们就来扒一扒深度学习框架（以 PyTorch 为例，TensorFlow 同理）的显存管理底层逻辑，以及如何在单卡上优雅地运行多个模型。 一、 为什么显存“只吃不吐”？很多开发者会发现，Python 脚本运行过程中，显存占用往往是一条只增不减的曲线。这其实是因为框架内部实现了一个 Caching Allocator（缓存分配器）。 1. 昂贵的系统调用在 GPU 上分配内存（cudaMalloc）和释放内存（cudaFree）是系统级调用，这些操作非常“昂贵”，会强制 GPU...
开发安全指北：ORM 防住了 SQL 注入，那“文件名注入”呢？
在现代 Web 开发中，ORM（对象关系映射）框架的普及极大地降低了 SQL 注入的风险。很多开发者（包括以前的我）因此产生了一种错觉：“只要我用了 SQLAlchemy 或 Django ORM，我的后端就是安全的。” 然而，现实往往会给你一记响亮的耳光。最近我在做安全排查时被告知存在“文件注入”和“文件名注入”风险。这让我意识到，Web 安全远不止 SQL 注入那么简单。 今天我们就来聊聊，除了 SQL 注入，开发过程中还有哪些容易被忽视的“注入”陷阱，以及我们该如何防御。 一、 文件名注入与路径遍历 (Path Traversal)这是很多初级甚至中级开发者最容易踩的坑。 1. 场景还原假设你有一个上传头像的功能，后端代码可能是这样写的： 1234567import osdef upload_avatar(file): # 直接使用用户上传的文件名 filename = file.filename save_path = os.path.join('/var/www/uploads', filename) ...
SQLAlchemy 踩坑：我只想复制一张表，却意外触发了“联表继承”
在 Python 后端开发中，我们经常使用 SQLAlchemy 作为 ORM 框架。最近在做项目时，我遇到了一件非常有意思的事情，或者说是一个“经典的误解”。 事情是这样的：我有一个现成的文件表 File，它的结构定义得很完美。随着业务发展，我需要创建一个备份表 BackupFile，要求它的结构跟 File 表 完全一致。 作为一个崇尚 DRY (Don’t Repeat Yourself) 原则的程序员，我的第一反应当然是——继承！ 于是我写出了类似这样的代码： 123456789101112131415from sqlalchemy import Column, Integer, String, ForeignKeyfrom sqlalchemy.orm import declarative_baseBase = declarative_base()class File(Base): __tablename__ = 'file' id = Column(Integer, primary_key=True) filename =...
工具-MinerU高显存占用解决方案
在文档智能处理（Document AI）领域，MinerU 是一款强大的开源 PDF 解析工具，能够精准提取文档中的 Markdown 内容、公式和表格。然而，在实际工程落地中，直接将几百页的 PDF 扔给模型处理，往往会面临一个棘手的问题——显存（VRAM）爆炸。 本文将结合一段 Python 实战代码，深入剖析为什么大文件会导致显存溢出，并阐述一种基于“单页拆分”的优化策略及其背后的原理。 1. 痛点：为什么大文件会让显存“烟花”？MinerU（以及大多数基于 Transformer 或视觉编码器的模型）在处理文档时，需要将输入内容转换为高维向量表示。要回答“为什么拆分后显存就不炸了”，我们需要深入到深度学习模型的显存占用机制。 1.1 显存都去哪儿了？在深度学习推理（Inference）过程中，显存主要被以下几部分占用： 模型权重（Model Weights）： 这是固定的。不管你输入是一个字还是一万个字，加载模型本身（如 InternVL、LayoutLM 等）就需要占用几个 GB 的显存。这部分是“入场费”。 中间激活值（Activations）与临时缓冲区：...
