运维123 - 中间件
type: channel
link: https://www.sddts.cn/index.php/category/%E4%B8%AD%E9%97%B4%E4%BB%B6/
items: antirez 自动编程与 Vibe Coding 概念辨析
items: MySQL 在 2026 年不再是真正的开源软件技术分析
items: PentestOPS 渗透测试作业操作平台技术分析
items: Databasus 开源数据库备份工具技术分析
items: Redis NUMA 架构下的延迟性能优化案例分析
items: MySQL主从复制搭建实战：数据同步零丢失配置指南
items: Rails 8 使用 SolidQueue 替代 Redis 架构分析
items: rabbitmq 遇到的一些问题
items: 使用ja-netfilter激活datagrip访问mongodb2.6.11
items: sql_mode导致程序无法获取数据了

antirez 自动编程与 Vibe Coding 概念辨析
type: item
date: 2026-02-01T00:16:47+00:00
description: antirez 自动编程与 Vibe Coding 概念辨析一、新闻概述1. 标题Redis 创始人 antirez 提出"自动编程"概念：编程可自动化，愿景不可2. 发布时间2026 年 2 月 1 日3. 来源antirez 个人博客二、核心内容1. 事件摘要A. 主要内容Redis 创始人 Salvatore Sanfilippo（网名 antirez）在其博客发表文章，正式提出"自动编程"（Automatic Programming）这一术语，用于描述专业程序员使用 AI 辅助开发的工作方式，并将其与"Vibe Coding"（氛围编程）进行明确区分。B. 核心亮点提出 Automatic Programming 与 Vibe Coding 的本质区别强调代码所有权归属开发者以 Redis 为例阐述"愿景"的重要性核心论断：编程已可自动化，愿景尚不能2. 关键信息A. 术语定义Automatic Programming（自动编程）：程序员深度参与的 AI 辅助开发Vibe Coding（氛围编程）：用户笼统描述需求，几乎不参与生成过程B. 重要观点预训练数据是人类集体的"礼物"（collective gift）通过自动编程产生的代码属于开发者本人Redis 的成功源于其中蕴含的理念和愿景，而非技术新颖性C. 涉及领域AI 辅助编程、软件开发方法论、开发者工具3. 背景介绍A. 作者背景antirez（Salvatore Sanfilippo）是意大利程序员，Redis 数据库的创始人。他于 2009 年创建 Redis，该项目后被 GitHub、Instagram、Twitter 等公司广泛采用。2020 年，他宣布辞去 Redis 项目维护者角色，专注于个人创作。B. 相关上下文"Vibe Coding"一词由前 Tesla AI 总监、OpenAI 研究员 Andrej Karpathy 于 2024 年 2 月提出，描述一种"完全沉浸于氛围，拥抱指数级增长，忘记代码存在"的编程方式。该术语迅速流行，但也引发了关于 AI 编程方式的讨论。三、详细报道1. 两种 AI 编程方式的区分A. Vibe Coding（氛围编程）antirez 对 Vibe Coding 的定义：用户以非常笼统的方式描述需求对代码生成过程几乎不参与最多只是报告问题或不符合预期的地方适合让软件开发"民主化"，让非程序员也能创建软件antirez 认为 Vibe Coding 是可以接受的方式，它降低了软件开发的门槛。B. Automatic Programming（自动编程）antirez 提出的自动编程定义：程序员深度参与整个开发过程通过直觉、设计和持续引导来控制产出严格遵循开发者对软件的愿景愿景可以是高层次的架构，也可以细化到具体函数的实现2. 核心差异分析graph TB subgraph "Vibe Coding" A1[用户] -->|笼统描述| B1[AI] B1 -->|生成代码| C1[软件] A1 -.->|报告问题| B1 end subgraph "Automatic Programming" A2[程序员] -->|愿景+设计| B2[AI] A2 -->|持续引导| B2 A2 -->|代码审查| B2 B2 -->|生成代码| C2[软件] A2 -->|深度参与| C2 end维度Vibe CodingAutomatic Programming参与程度低，仅描述需求高，全程深度参与控制力度弱，被动接受结果强，主动引导方向适用人群非程序员、快速原型专业程序员代码理解可能不理解生成的代码完全理解并掌控代码愿景体现AI 主导开发者主导3. 代码所有权论述antirez 在文章中强调了一个重要观点：通过自动编程产生的代码属于开发者本人。他的论证逻辑：AI 模型的预训练数据来自人类集体贡献这些数据是一种"集体礼物"（collective gift）开发者使用 AI 工具时，是在利用这份集体智慧但最终产出的软件体现的是开发者的愿景和设计用 antirez 的原话说："it is the software you are producing"（这是你正在创造的软件）。4. Redis 案例分析antirez 以自己创建的 Redis 为例，阐述愿景的重要性：A. 技术层面Redis 在技术上并无太多新颖之处：基础数据结构（哈希表、链表、跳表等）标准网络代码内存数据库的常见实现B. 成功因素Redis 之所以成功，是因为其中蕴含的理念和愿景：简洁的 API 设计对性能的极致追求对开发者体验的重视清晰的使用场景定位这个例子说明：技术实现可以被复制或自动化，但产品愿景是独特的、不可替代的。5. 核心论断antirez 文章的核心论断…

MySQL 在 2026 年不再是真正的开源软件技术分析
type: item
date: 2026-01-23T21:45:13+00:00
description: MySQL 在 2026 年不再是真正的开源软件技术分析一、新闻概述1. 标题停止在 2026 年使用 MySQL，它不是真正的开源软件2. 发布时间2026 年 1 月 11 日3. 来源Optimized by Otto二、核心内容1. 事件摘要A. 主要内容Otto Kekalainen 发布文章呼吁在 2026 年停止使用 MySQL，转而使用 MariaDB。文章指出 MySQL 虽然使用 GPL 开源协议，但并非真正的开源项目，开发过程完全闭门进行，社区贡献受到限制。B. 核心亮点MySQL GitHub 提交量在 2025 年显著下降Oracle 收购后 MySQL 社区逐渐萎缩MySQL 技术质量从 2022 年开始明显下滑2025 年 MySQL 公布 123 个 CVE，而 MariaDB 仅 8 个2. 关键信息A. 涉及产品MySQL 8.0/8.4/9.5MariaDBPercona ServerTiDBB. 重要数据2025 年 MySQL CVE 数量：123 个2025 年 MariaDB CVE 数量：8 个全球 57% 的 WordPress 网站使用 MariaDBMySQL 9.5 写密集型工作负载吞吐量比 8.0 下降约 15%C. 历史背景2009 年 Oracle 收购 Sun Microsystems 和 MySQL2018 年 MySQL 8.0 发布2024 年 MySQL 8.4 LTS 发布2025 年 Oracle 大幅削减 MySQL 团队人员三、详细报道1. 开源性质问题A. 开发模式对比graph LR subgraph MySQL_开发模式 M1[Oracle 内部开发] --> M2[闭门开发] M2 --> M3[社区提交 PR] M3 --> M4[无反馈/被忽略] M4 --> M5[发布新版本] end subgraph MariaDB_开发模式 N1[GitHub 公开开发] --> N2[实时审查] N2 --> N3[社区参与讨论] N3 --> N4[Jira 公开追踪] N4 --> N5[透明发布] endB. MySQL 社区问题所有开发在闭门环境中进行公开 Bug 跟踪器并非 Oracle 实际使用的系统社区提交的 Pull Request 缺乏反馈代码变更通常被重写，原作者仅在博客中获小额提及Git 作者/提交者字段仅包含 Oracle 员工C. MariaDB 开放模式所有开发在 github.com/mariadb/server 实时进行任何人都可以提交 Pull Request 并获得审查所有 Bug 在 jira.mariadb.org 公开讨论符合真正开源项目的运作模式2. 技术质量下滑A. 关键技术问题版本问题影响MySQL 8.0.29ALTER TABLE 默认 in-place 有边界情况缺陷数据库崩溃、数据损坏MySQL 8.0.32一年后才完全修复用户数据风险持续MySQL 8.1仅作为短期预览版本功能不完整MySQL 8.4 LTS新功能极少用户失望MySQL 9.5写密集型工作负载性能下降 15%性能退化B. 版本发布问题8.0 系列被宣布为"常青"版本小版本引入功能变更而非仅修复 Bug6 年无新的主要版本（2018-2024）升级路径困难（5.7->8.0、8.0->8.4）大量功能废弃导致迁移复杂C. 性能退化对比graph LR A[MySQL 8.0] -->|基线性能| B[100%] B -->|MySQL 9.5| C[85%] C -->|下降| D[15%] D --> E[工作负载: 写密集型]3. 安全与透明度A. CVE 数量对比（2025）数据库CVE 数量独有 CVEMySQL123117MariaDB8-B. 安全处理方式差异MySQL：CVE 描述缺乏详细信息示例：CVE-2025-53067 仅说明"高权限攻击者可通过多种协议轻易利用"无可验证的漏洞细节用户必须信任 Oracle 声称已修复典型描述："Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server"真正的开源项目：安全问题在禁运期结束后完全公开代码修复可供全面审查可验证漏洞存在性和修复有效性社区可审查修复方案是否充分C. 安全影响分析graph TD A[闭源安全处理] --> B[缺乏详细信息] B --> C[无法验证漏洞] C --> D[无法审查修复] D --> E[完全依赖供应商信任] E -…

PentestOPS 渗透测试作业操作平台技术分析
type: item
date: 2026-01-21T22:38:13+00:00
description: PentestOPS 渗透测试作业操作平台技术分析一、项目概述PentestOPS（又称 PentesterOPS Dashboard）是由开发者 Mohamed Nasr（GitHub 用户名 0xBugatti）构建的综合性渗透测试作业管理平台。该平台旨在为渗透测试团队提供完整的项目生命周期管理能力，涵盖从项目立项、任务分配、漏洞发现跟踪到客户资产管理的全套工作流程。项目采用现代 Web 技术栈构建，包括 Next.js 14 前端、Express 后端和 MongoDB 数据库，支持单容器 Docker 部署，显著降低了部署复杂度。项目于 2025 年以 MIT 开源许可证发布，源代码托管于 GitHub。图 1: PentestOPS 系统架构图二、核心技术架构2.1 技术栈组成前端技术栈技术组件版本用途Next.js14.0.4React 应用框架（App Router）React18.2.0UI 库TypeScript5.3.3类型安全TailwindCSS3.4.0原子化 CSS 框架Editor.js2.31.0富文本编辑器核心Zustand4.4.7轻量级状态管理React Query3.39.3服务端状态管理Axios1.6.2HTTP 客户端Framer Motion10.16.16动画库后端技术栈技术组件版本用途Node.js18+运行时环境Express4.18.2Web 应用框架TypeScript5.3.3类型安全MongoDB7.0NoSQL 数据库Mongoose8.0.3ODM（对象文档映射）JWT9.0.2身份认证Helmet7.1.0安全头设置Multer1.4.5文件上传处理2.2 系统架构设计PentestOPS 采用经典的三层架构模式：表现层：基于 Next.js 14 App Router 构建的单页应用，使用 React 组件化开发模式，通过 TailwindCSS 实现响应式设计，支持暗色主题。应用层：Express RESTful API 服务，负责业务逻辑处理、数据验证、权限控制和文件管理等核心功能。数据层：MongoDB 文档型数据库，通过 Mongoose ODM 进行数据建模和关系映射，支持灵活的文档结构。三、核心功能模块3.1 项目管理项目管理模块是 PentestOPS 的核心功能，支持渗透测试项目的全生命周期管理：多视图支持：提供看板视图（Kanban Board）、表格视图和卡片视图，满足不同场景下的信息浏览需求任务关联：每个项目可关联多个任务，支持任务的拖拽排序和状态流转资产管理：项目可关联目标资产信息，便于跟踪测试范围客户关联：支持将项目与客户信息绑定，便于客户关系管理团队协作：支持多用户协作，实现任务分配和进度跟踪3.2 任务管理系统任务管理模块提供了类似 Jira 的专业任务管理能力：多维度筛选：支持按状态、优先级、负责人等多维度筛选任务子任务支持：支持创建子任务，实现任务的层级化管理富文本描述：使用 Editor.js 编辑器支持标题、段落、代码块、表格、引用等多种格式评论系统：支持线程化评论，便于团队沟通和决策记录附件功能：支持上传 PDF、DOCX、XLSX、CSV、ZIP 及图片等文件3.3 漏洞发现跟踪漏洞管理模块整合了 CWE（Common Weakness Enumeration）数据库：CWE 映射：每个漏洞发现可关联到标准的 CWE 分类严重程度分级：支持按 CVSS 评分或自定义等级分类版本历史：记录漏洞信息的变更历史，支持差异查看和版本恢复证据附件：支持上传截图、POC 代码等证据文件状态跟踪：从发现到确认、修复、验证的完整状态流转3.4 富文本编辑能力PentestOPS 集成了功能强大的 Editor.js 编辑器，支持 Notion 风格的文档编辑：插件名称功能描述@editorjs/header多级标题@editorjs/list有序/无序列表@editorjs/checklist待办清单@editorjs/quote引用块@editorjs/code代码块@editorjs/table表格@editorjs/delimiter分隔线@editorjs/marker高亮标记@editorjs/inline-code行内代码@editorjs/link链接@editorjs/image图片3.5 全文搜索系统实现了全局搜索功能，支持跨以下实体的全文检索：项目（Projects）任务（Tasks）漏洞发现（Findings）客户（Clients）资产（Assets）页面/检查清单（Pages/Checklists）搜索采用 MongoDB 的文本索引功能，实现高效的关键词匹配。四、安全设计分析4.1 认证与授权Pentest…

Databasus 开源数据库备份工具技术分析
type: item
date: 2026-01-15T12:45:53+00:00
description: Databasus 开源数据库备份工具技术分析一、背景与目标1. 项目背景A. 业务场景随着云计算和容器化技术的普及，数据库备份管理成为运维工作的核心环节。传统的备份方案存在以下痛点：需要编写复杂的脚本、缺乏统一的可视化管理界面、难以支持多种数据库类型、无法灵活配置存储目标和通知渠道。B. 痛点分析操作复杂：传统方案依赖命令行工具如 pg_dump、mysqldump，需要编写自动化脚本缺乏监控：备份任务执行状态难以及时掌握，失败发现滞后存储单一：难以同时支持本地存储和多种云存储服务协作困难：团队成员无法共享备份配置和查看备份历史2. 设计目标A. 功能目标支持 PostgreSQL、MySQL、MariaDB、MongoDB 四种主流数据库提供可视化的 Web 管理界面支持多种存储后端和通知渠道支持定时备份和加密B. 非功能目标安全性：备份文件 AES-256-GCM 加密，敏感数据不暴露易用性：提供直观的 UI，支持暗色/亮色主题可靠性：支持 Docker 容器化部署，自动重启可扩展性：支持团队协作，工作空间隔离，角色权限管理二、系统架构1. 整体架构graph TB subgraph 用户层 U1[管理员] U2[成员] U3[查看者] end subgraph Databasus应用层 W[Web界面] A[API服务] S[调度器] E[加密引擎] end subgraph 数据库连接层 PG[PostgreSQL] MY[MySQL] MR[MariaDB] MO[MongoDB] end subgraph 存储层 L[本地存储] S3[S3兼容存储] GD[Google Drive] FTP[SFTP/FTP] RC[Rclone] end subgraph 通知层 EM[邮件] TG[Telegram] SL[Slack] DC[Discord] WH[Webhook] end U1 --> W U2 --> W U3 --> W W --> A A --> S S --> PG S --> MY S --> MR S --> MO S --> E E --> L E --> S3 E --> GD E --> FTP E --> RC S --> EM S --> TG S --> SL S --> DC S --> WH2. 组件说明A. Web 界面提供 RESTful API 接口支持暗色和亮色主题切换响应式设计，支持移动端访问B. 调度器支持多种调度策略：每小时、每天、每周、每月、Cron 表达式智能压缩：4-8 倍空间节省，约 20% 性能开销C. 加密引擎使用 AES-256-GCM 算法加密备份文件零信任存储：加密后的备份文件即使泄露也无法解密敏感数据加密存储，日志中不暴露三、核心功能1. 支持的数据库数据库类型支持版本PostgreSQL12, 13, 14, 15, 16, 17, 18MySQL5.7, 8, 9MariaDB10, 11MongoDB4, 5, 6, 7, 82. 定时备份策略graph LR A[调度器] --> B{调度类型} B --> C[每小时] B --> D[每天] B --> E[每周] B --> F[每月] B --> G[Cron表达式] C --> H[执行备份] D --> H E --> H F --> H G --> H H --> I[压缩] I --> J[加密] J --> K[存储] K --> L[通知]3. 存储后端支持本地存储：直接存储在服务器磁盘云存储：S3、Cloudflare R2、Google Drive、Azure Blob Storage网络存储：NAS、SFTP、FTP扩展存储：通过 Rclone 支持 70+ 种存储服务4. 通知渠道邮件：SMTP 协议即时通讯：Telegram、Slack、DiscordWebhook：自定义 HTTP 回调四、安全设计1. 加密机制A. 备份文件加密算法：AES-256-GCM适用场景：所有存储到外部服务的备份文件安全性：即使存储服务被攻破，备份文件也无法解密B. 敏感数据保护数据库凭证加密存储敏感配置不在日志中显示错误信息中不包含敏感数据2. 访问控制A. 工作空间隔离不同项目/团队使用独立工作空间工作空间间数据隔离B. 角色权限角色权限查看者仅查看备份状态和历史成员管理数据库和备份任务管理员管理工作空间内所有资源所有者完全控制，包括删除工作空间C. 审计日志记录所有用户操作记录备份任务执行历史3. 只读用户原则Databasus 默认使用只读用户连接数据库不存储任何可以修改数据的凭证备份过程不会对源数据库产生写入操作五、部署方式1. 部署架构对比graph LR subg…

Redis NUMA 架构下的延迟性能优化案例分析
type: item
date: 2026-01-15T12:25:02+00:00
description: Redis NUMA 架构下的延迟性能优化案例分析一、事件概述1. 事件背景Redis 作为核心存储组件，对实时性要求非常高。在长期运行后，Redis 服务会出现性能下降，导致较大的查询延迟，拖慢整个链路的响应速度。2. 影响范围A. 影响功能Redis 数据库的所有查询操作B. 性能指标P99 延迟从 9.2ms 降至 5.7ms，下降约 37%3. 严重程度P2 级性能问题（核心业务响应速度受影响）二、问题分析1. 直接原因通过 HUATUO 系统观测指标分析，发现 Redis 延迟升高时，NUMA 页面迁移指标（huatuo_bamai_vmstat_numa_pages_migrated）同步升高，两者趋势一致。2. 根本原因（5 Whys 分析）A. 为什么出现这个问题？Redis 进程在 NUMA 架构下，内存分散在不同的内存节点上，访问远端节点内存时触发 NUMA balancing，导致页面迁移，在 page fault 中产生额外开销。B. 为什么内存会分散？负载变化导致 Redis 进程在 node 之间迁移AOF 备份产生的文件缓存持续占用内存，导致某个 node 可用内存减少，后续分配从另一个 node 进行C. 为什么没有自动优化？内核默认的 NUMA balancing 策略旨在提高访存速度，但对内存带宽敏感型的数据库服务，页面迁移本身的开销超过了收益。3. 深层反思容器化环境下，NUMA 架构与内存管理策略需要针对不同类型的负载进行调优，通用内核参数无法满足所有场景。三、问题定位过程1. 观测指标使用 HUATUO 提供的关键指标：huatuo_bamai_vmstat_numa_pages_migrated：系统级 NUMA 页面迁移次数huatuo_bamai_vmstat_container_numa_pages_migrated：容器级 NUMA 页面迁移次数nr_inactive_file：非活跃文件缓存页数nr_active_file：活跃文件缓存页数nr_free_pages：空闲内存页数2. 指标关联分析graph TD A[Redis 延迟升高] --> B[NUMA 页面迁移指标升高] B --> C[发现关联性] C --> D[AOF 操作] D --> E[nr_inactive_file 升高] E --> F[nr_active_file 升高] F --> G[nr_free_pages 下降] G --> H[跨 node 内存分配] H --> I[NUMA balancing 触发] I --> J[页面迁移开销] J --> A3. 现象总结触发 NUMA balancing 的两个条件：A. 进程迁移随着负载变化，Redis 进程会在 node 之间迁移，导致内存分散在两个内存节点上。B. 文件缓存占用Redis 定期进行数据备份（AOF），将数据保存在文件里。这些磁盘数据写完后一般不再使用，但仍留在文件缓存中，导致某个 node 可用内存特别少。四、解决方案1. 临时方案A. 提升内存水位参数将 vm.watermark_scale_factor 设定为 1000，使内核的 low 水位被设定为总内存的 1/10。B. 效果评估kswapd 可以频繁回收文件缓存，让 free 内存保持合理水平，内存分配不会被迫横跨节点，NUMA miss 减少到接近 0。2. 永久方案A. 提升内存水位调整 vm.watermark_scale_factor 参数B. 关闭 NUMA balancing对于内存带宽敏感型的数据库服务，关闭 NUMA balance 策略C. 实施计划测试环境验证参数调整效果生产环境分批次灰度调整五、技术细节1. vm.watermark_scale_factor 参数详解A. 参数作用控制内存水位的间距，影响内核的内存回收行为，主要是 kswapd 守护进程的唤醒和睡眠时机。B. 参数特性不改变 min 水位只影响 min 水位到 low 和 high 的间距默认值为 10（对应总内存的 0.1%）取值范围为 0-3000（即 0% 到 30%）C. 计算公式WMARK_LOW = WMARK_MIN + (zone->managed_pages * vm_watermark_scale_factor) / 10000 WMARK_HIGH = WMARK_LOW + (zone->managed_pages * vm_watermark_scale_factor) / 10000D. 推荐配置vm.watermark_scale_factor=10002. NUMA balancing 策略A. 工作原理NUMA balance 调度…

MySQL主从复制搭建实战：数据同步零丢失配置指南
type: item
date: 2026-01-15T10:04:51+00:00
description: MySQL主从复制搭建实战：数据同步零丢失配置指南一、概述1. 背景介绍在生产环境中运维MySQL数据库十年，主从复制是遇到最频繁的架构需求之一。无论是为了读写分离提升性能，还是为了数据容灾保障业务连续性，主从复制都是MySQL高可用架构的基石。2019年的一次惨痛经历至今记忆犹新：某电商平台大促期间，单机MySQL扛不住流量直接宕机，由于没有从库，数据恢复花了整整6个小时，直接损失数百万。这次事故之后，主从复制成为所有核心业务数据库的标配。A. 核心原理MySQL主从复制的核心原理是：主库将数据变更写入二进制日志（Binary Log），从库通过I/O线程读取主库的binlog并写入本地的中继日志（Relay Log），然后SQL线程读取中继日志并在从库上重放这些变更，从而实现数据同步。2. 技术特点MySQL 8.0/8.4 LTS版本在复制功能上有了重大改进：A. 基于GTID的复制全局事务标识符（GTID）让每个事务都有唯一标识故障切换时自动定位复制位点，无需手动指定binlog文件和位置支持自动故障转移，大幅简化运维复杂度B. 增强的半同步复制主库提交事务前必须收到至少一个从库的确认配合rpl_semi_sync_source_wait_for_replica_count参数可要求多个从库确认有效防止主库故障时的数据丢失C. 并行复制优化基于WriteSet的并行复制，大幅提升从库回放效率replica_parallel_type=LOGICAL_CLOCK配合binlog_transaction_dependency_tracking=WRITESET实测可将复制延迟从分钟级降到秒级D. 克隆插件支持MySQL 8.0.17+引入Clone Plugin从库初始化无需mysqldump或xtrabackup自动完成数据同步和复制配置3. 适用场景场景说明推荐配置读写分离主库写、从库读，分担主库压力异步复制 + 多从库数据容灾主库故障时快速切换到从库半同步复制 + GTID数据备份在从库执行备份，不影响主库性能异步复制 + 延迟从库数据分析报表查询在从库执行异步复制 + 专用从库跨地域部署多数据中心数据同步异步复制 + 压缩传输4. 环境要求组件版本要求说明MySQL Server8.0.35+ 或 8.4 LTS推荐使用8.4 LTS长期支持版本操作系统Rocky 9 / Ubuntu 24.04内核版本5.14+内存最低4GB，推荐16GB+InnoDB Buffer Pool需要足够内存磁盘SSD，IOPS 3000+binlog和数据文件分盘存储网络主从之间延迟<1ms同机房部署最佳本文实验环境：主库：192.168.1.100（master.example.com）从库：192.168.1.101（slave.example.com）系统：Rocky Linux 9.3MySQL：8.4.0 LTS二、准备工作1. 系统环境配置在主库和从库服务器上执行相同的系统配置：# 关闭SELinux（或配置相应策略） sudo setenforce 0 sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config # 配置防火墙 sudo firewall-cmd --permanent --add-port=3306/tcp sudo firewall-cmd --reload # 配置时间同步（主从时间必须一致） sudo dnf install -y chrony sudo systemctl enable --now chronyd # 验证时间同步状态 chronyc tracking # 配置主机名解析 echo "192.168.1.100 master.example.com master" | sudo tee -a /etc/hosts echo "192.168.1.101 slave.example.com slave" | sudo tee -a /etc/hosts # 优化系统参数 cat << 'EOF' | sudo tee /etc/sysctl.d/mysql.conf # 网络优化 net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_keepalive_time = 600 # 内存优化 vm.swappiness = 1 vm.dirty_ratio = 10 vm.dirty_b…

Rails 8 使用 SolidQueue 替代 Redis 架构分析
type: item
date: 2026-01-14T14:47:57+00:00
description: Rails 8 使用 SolidQueue 替代 Redis 架构分析一、背景与目标1. 项目背景 A. 业务场景 Rails 8 从默认技术栈中移除了 Redis。新的功能组件——SolidQueue（任务队列）、SolidCache（缓存）、SolidCable（实时消息传递）——完全运行在应用程序现有的关系数据库服务上。对于大多数 Rails 应用，可以不再依赖 Redis。 B. 痛点分析 Redis 虽然是快速、可靠的基础设施，但它增加了系统复杂性： - 需要单独部署、版本管理、补丁和监控服务器软件 - 需要配置持久化策略（RDB 快照、AOF 日志或两者） - 需要设置内存限制和淘汰策略 - 需要维护 Rails 与 Redis 之间的网络连接和防火墙规则 - 需要配置 Redis 客户端认证 - 需要构建和维护高可用 Redis 集群 - 需要协调 Sidekiq 进程的生命周期管理 2. 设计目标 A. 功能目标 - 使用关系数据库替代 Redis 实现任务队列功能 - 支持任务调度、并发控制、重试机制 - 提供监控和管理界面 B. 非功能目标 - 降低运维复杂性 - 减少基础设施组件数量 - 保持足够的性能水平 二、Redis 运维成本分析1. 直接成本 A. 服务器部署 - Redis 服务器软件安装与配置 - 版本升级与补丁管理 - 服务器资源监控 B. 持久化配置 - RDB 快照：内存快照持久化 - AOF 日志：追加文件日志 - 混合策略：结合两者优势 2. 间接成本 A. 网络与安全 - 防火墙规则配置 - Redis 客户端认证管理 - 高可用集群部署 B. 进程管理 - Sidekiq 进程编排 - 跨部署的生命周期管理 - 进程崩溃恢复 3. 调试复杂性 当任务出现问题时，需要同时调试 Redis 和 RDBMS 两个具有不同语义的数据存储，在不同的查询语言和工具之间切换上下文。还需要维护两套独立的备份策略。 三、SolidQueue 工作原理1. 核心技术：SKIP LOCKED PostgreSQL 9.5 增强了 SQL 的 `FOR UPDATE` 子句，添加了 `SKIP LOCKED` 选项。`FOR UPDATE` 创建排他行锁，`SKIP LOCKED` 进一步跳过当前被锁定的行。 这使得基于数据库的任务队列成为可能，即使在规模化场景下也能正常工作。 2. 任务获取流程 工作进程获取任务的查询： ```sql SELECT * FROM solid_queue_ready_executions WHERE queue_name = 'default' ORDER BY priority DESC, job_id ASC LIMIT 1 FOR UPDATE SKIP LOCKED ``` 自由的工作进程始终获取下一个可用任务。 这个数据库优化解决了早期数据库队列实现面临的根本问题：**锁竞争**。工作进程从不等待另一个进程，也从不阻塞。多个工作进程可以同时查询，PostgreSQL 保证每个进程获得唯一的任务。 3. 数据库表结构 SolidQueue 架构围绕三个核心表： ```mermaid graph TD subgraph SolidQueue 数据库表结构 A[solid_queue_jobs 任务元数据表] B[solid_queue_scheduled_executions 定时任务表] C[solid_queue_ready_executions 就绪任务表] end D[新任务] -->|已调度| B D -->|立即执行| C B -->|到达执行时间| C C -->|工作进程获取| E[执行中] E -->|完成| F[删除执行记录] E -->|失败| G[失败记录表] ``` A. solid_queue_jobs 存储所有任务元数据，包括任务名称、Ruby 类、开始和结束时间戳。默认情况下，每个排队请求都会记录在此表中，并在任务完成后永久保留。 B. solid_queue_scheduled_executions 定时任务等待直到其预定时间到达。 C. solid_queue_ready_executions 准备立即运行的任务排队在此，工作进程从中获取任务。 PostgreSQL 的 MVCC 设计通过内置的 autovacuum 进程很好地处理了任务表的快速和稳定 churn（大量插入和删除）。无需特殊调优。 4. 进程架构 ```mermaid graph LR subgraph SolidQueue 进程组件 A[Supervisor 监督进程] B[Workers 工作进程] C[Dispatchers 调度进程] D[Schedul…

rabbitmq 遇到的一些问题
type: item
date: 2025-02-24T03:24:19+00:00
description: （1）内存类型 MQ 节点将队列等运行状态数据不写硬盘，不影响业务数据持久化内存节点（RAM 节点）的特点运行时状态：内存节点仅将运行时状态（如交换器、队列、绑定、虚拟主机、用户和策略的定义）存储在内存中，不会将其写入磁盘。如果内存节点崩溃或重启，这些运行时状态会丢失，需要从磁盘节点或其他节点恢复。业务数据（消息）：消息的存储方式（是否持久化）由消息的 delivery-mode 属性决定，而不是节点类型。如果消息的 delivery-mode = 2（持久化），即使是在内存节点上，消息也会被写入磁盘。如果消息的 delivery-mode = 1（非持久化），消息仅存储在内存中，节点类型不会影响这一点。磁盘节点（Disk 节点）的特点运行时状态：磁盘节点将运行时状态存储在内存和磁盘中，确保即使节点重启，这些状态也不会丢失。业务数据（消息）：同样，消息的存储方式由 delivery-mode 属性决定，与节点类型无关。总结内存节点和磁盘节点的区别仅在于运行时状态的存储方式，不会直接影响业务数据（消息）的存储。消息的持久化由 delivery-mode 属性控制，无论是内存节点还是磁盘节点，持久化消息都会被写入磁盘。如果使用内存节点，需要注意运行时状态的丢失风险，尤其是在集群环境中，建议至少有一个磁盘节点来保存集群的运行时状态。（2）关于 DURABLE，只是影响队列是否存在，与其业务数据持久化无关是的，你的理解是正确的。在 RabbitMQ 中，durable 属性仅影响队列本身的定义是否在 RabbitMQ 服务器重启后仍然存在，而与队列内部的数据（消息）是否持久化无关。durable 属性的作用队列的持久化：当 durable=True 时，队列的定义会被持久化到磁盘。即使 RabbitMQ 服务器重启，队列仍然会存在。当 durable=False 时，队列的定义仅存储在内存中。如果 RabbitMQ 服务器重启，队列会被删除。与消息持久化的区别：durable 属性仅影响队列的定义，不涉及队列中消息的存储方式。消息是否持久化由消息的 delivery-mode 属性决定：delivery-mode=1：消息非持久化，仅存储在内存中。delivery-mode=2：消息持久化，会被写入磁盘。使用场景durable=True：适用于需要长期存在的队列，例如任务队列或消息队列，确保队列定义在 RabbitMQ 重启后仍然可用。即使队列是持久的，队列中的消息仍然需要单独设置为持久化（delivery-mode=2）才能确保消息不丢失。durable=False：适用于临时队列，例如 RPC 风格的应用程序，队列的生命周期与消费者绑定，消费者断开后队列可以自动删除。注意事项如果希望消息在 RabbitMQ 重启后仍然存在，必须同时满足以下两个条件：队列是持久的（durable=True）。消息是持久的（delivery-mode=2）。如果只设置了 durable=True 而没有设置 delivery-mode=2，队列定义会保留，但消息可能会丢失。总结durable 属性仅控制队列定义的持久化，与队列内部消息的存储方式无关。为了确保消息在 RabbitMQ 重启后不丢失，需要同时设置队列为持久化（durable=True）和消息为持久化（delivery-mode=2）。（3）关于如何不落盘业务数据，需要消息中指定 delivery-mode 为 2delivery-mode 是 AMQP 协议中定义的一个消息属性，用于指示 RabbitMQ 如何处理消息的存储和持久化。它有两个可能的值：delivery-mode = 1：这是默认值，表示消息是非持久化的。RabbitMQ 会将消息保留在内存中，不会将其写入磁盘。如果 RabbitMQ 重启，这些非持久化的消息将会丢失。delivery-mode = 2：表示消息是持久化的。RabbitMQ 会将消息写入磁盘，确保即使 RabbitMQ 重启，消息仍然会保留在队列中。这种模式提供了更高的可靠性，但可能会影响性能，因为磁盘 I/O 比内存 I/O 慢。使用场景delivery-mode = 1：适用于对消息丢失不敏感的场景，例如实时日志或临时数据，可以最大限度地减少延迟。delivery-mode = 2：适用于需要确保消息不丢失的场景，例如金融交易或关键业务数据。性能影响使用 delivery-mode = 2 时，由于需要将消息写入磁盘，可能会增加发布消息的延迟，尤其是在高并发或 I/O 负载较高的情况下。如果需要更高的性能，可以结合其他优化技术，例如事务或批量确认。总结delivery-mode 是一个重要的消息属性，开发者需要根据业务需求选择合适的模式，以在消息的可靠…

使用ja-netfilter激活datagrip访问mongodb2.6.11
type: item
date: 2024-08-14T06:09:00+00:00
description: 安装datagrip，可以使用链接http://vip.123pan.cn/1815238395/download/datagrip/2024.1.5/datagrip-2024.1.5.exe使用链接https://ipfs.io/ipfs/bafybeih65no5dklpqfe346wyeiak6wzemv5d7z2ya7nssdgwdz4xrmdu6i/下载jetbra.zip文件。或者直接从这里http://vip.123pan.cn/1815238395/download/datagrip/%E6%BF%80%E6%B4%BB/jetbra-8f6785eac5e6e7e8b20e6174dd28bb19d8da7550.zip解压到datagrip的bin目录下。进入bin/jetbra/，查看readme.txtOperation guide: 1. add -javaagent:/path/to/ja-netfilter.jar=jetbrains to your vmoptions (manual or auto) 2. log out of the jb account in the 'Licenses' window 3. use key on page https://jetbra.in/5d84466e31722979266057664941a71893322460 4. plugin 'mymap' has been deprecated since version 2022.1 5. don't care about the activation time, it is a fallback license and will not expire Enjoy it~ JBR17: add these 2 lines to your vmoptions file: (for manual, without any whitespace chars) --add-opens=java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED --add-opens=java.base/jdk.internal.org.objectweb.asm.tree=ALL-UNNAMED NEW: Auto configure vmoptions: macOS or Linux: execute "scripts/install.sh" Windows: double click to execute "scripts\install-current-user.vbs" (For current user) "scripts\install-all-users.vbs" (For all users) 找到安装datagrip目录的datagrip64.vmoptions，根据上述readme.txt内容加入进去。然后启动datagrip，不要使用账号密码登录，选择激活码54H0PAD972IO7OS-[binary]-[binary]-[binary]

sql_mode导致程序无法获取数据了
type: item
date: 2024-08-13T02:12:28+00:00
description: 研发发来了一个报错，这个报错是sql_mode=only_full_group_by兼容性导致。直接修改sql_mode就可以了。com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: In aggregated query without GROUP BY, expression #2 of SELECT list contains nonaggregated column 'xxx.bm.gid'; this is incompatible with sql_mode=only_full_group_by at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.8.0_152] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[na:1.8.0_152] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.8.0_152] at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[na:1.8.0_152]临时修改## 查看 -- 开启-- 查看数据库版本和 Session级信息 SELECT VERSION(),@@sql_mode; -- 查看数据库版本和 GLOBAL级信息 SELECT VERSION(),@@GLOBAL.sql_mode; ## 关闭 -- 关闭 session级 SET SESSION sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY','')); -- 关闭 GLOBAL级 SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY','')); 查看线上配置修改配置文件 mysql: image: harbor.op123.ren:44301/library/mysql:5.7.35 command: --sql-mode="STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION" restart: "no" container_name: mysql environment: - MYSQL_ROOT_PASSWORD=xxx - TZ=Asia/Shanghai - SET_CONTAINER_TIMEZONE=true - CONTAINER_TIMEZONE=Asia/Shanghai # 添加性能相关的环境变量 - MYSQL_INNODB_BUFFER_POOL_SIZE=4G - MYSQL_INNODB_LOG_FILE_SIZE=256M - MYSQL_INNODB_LOG_BUFFER_SIZE=64M - MYSQL_INNODB_FLUSH_LOG_AT_TRX_COMMIT=2 - MYSQL_INNODB_FLUSH_METHOD=O_DIRECT - MYSQL_MAX_CONNECTIONS=1000 # 添加日志相关的环境变量 - MYSQL_LOG_CONSOLE=true - MYSQL_LOG_ERROR=/var/log/mysql/custom-error.log - MYSQL_LOG_QUERIES_ENABLED=true - MYSQL_LOG_QUERIES_FILE=/var/log/mysql/queries.log networks: yewu-network: ipv4_address: 192.168.177.55 cap_add: - SYS_NICE # CAP_SYS_NICE ports: - 3306:3306 volumes: - ./data/mysql/conf:/etc/mysql/conf.d - ./data/mysql/data:/var/lib/mysql - ./data/mysql/logs:/var/log/mysql - /etc/localtime:/etc/loc…