首页 文章 精选 留言 我的

精选列表

搜索[稳定]，共10000篇文章
优秀的个人博客,低调大师

微软再推稳定性补丁 为即将到来功能更新做准备

部分运行 Windows 10 May 2021 功能更新及此前版本的用户，近日获得了一个新的可靠性补丁，主要为即将到来的累积更新或者功能更新做好准备。该更新编号为 KB4023057，它在 2018 年首次推出，现在微软再次推出了该补丁。 Windows 可靠性补丁主要是为了改善 Windows Update 过程，并将可靠性改进应用于负责你设备上更新的各种服务。它还将尝试在你的电脑上腾出空间，以方便即将到来的每月/功能更新。 可靠性更新通常是在一个大的累积或功能更新即将到来时，以及对一个主要的Windows 10版本的支持即将结束时发布。通过在你的设备上安装KB4023057可靠性更新，微软希望能使未来的更新过程更加无缝。 还值得注意的是，可靠性更新将在你的设备上安装或更新“Microsoft Update Health Tools”。微软更新健康工具到应该可以解决 Windows 文件的损坏，通过缩小各种图片的缩略图和清理临时文件来释放磁盘空间。在支持公告中，微软解释说，该补丁甚至可以分析你的网络设置。 在公告中写道，Windows 10 May 2020 功能更新(Version 2004)在 2021 年 5 月停止支持，因此，微软很可能想利用可靠性补丁，比以往更积极地将最新的功能更新推送给PC。同时，该补丁有可能为即将到来的功能更新，如 2021 年晚些时候发布的 Sun Valley 更新，对那些不兼容的设备进行改善。 【责任编辑：未丽燕 TEL：（010）68476606】
2021-06-15
优秀的个人博客,低调大师

Chrome 84 稳定版正式发布，带来许多面向开发者的更新

Chrome 84 正式发布了，这个版本直接面向用户的功能更新较少，主要是一些开发者工具和 Web API 更新。以下是内容快速一览： 用户可以使用“应用程序图标快捷方式”（App Icon Shortcuts）在应用程序中启动任务。 Web Animations API添加了对许多以前不支持的功能的支持。 唤醒锁定（Wake lock）可以防止屏幕变暗或锁定。 内容索引 API（Content Indexing API）帮助显示脱机可用的内容。 新的实验功能：idle detection和Web Assembly SIMD。 Same Site Cookie policy再次开始更新。 以及更多。 App icon shortcuts（APP 图标快捷方式） 应用程序图标快捷方式使用户可以轻松快速启动应用程序中的常见任务。 Chrome 和 Edge 的桌面版及移动版本均支持这项功能。通过在 Windows 和 macOS 上右键单击应用程序图标，或在 Android 上长按应用程序图标，便可以调用这些快捷方式。 Web animations API（网络动画 API） Chrome 84 向 Web Animations API 添加了许多以前不受支持的功能。 animation.ready和animation.finished已实现 浏览器现在可以清理和删除旧动画，从而节省内存并提高性能 现在可以使用复合模式组合动画——带有add和accumulate选项 Content indexing API（内容索引 API） 使用内容索引 API，可以为可脱机使用的内容添加 URL 和元数据，然后通过元数据可将内容呈现给用户，使用户在无网络连接的情况下也能看见内容。 Wake lock API（唤醒锁定API） 使用该 API，网站可以启用唤醒锁定，防止屏幕变暗或锁屏。 Origin trials 还有两项实验功能，包括： Idle detection（空闲检测） 当用户处于空闲状态时，Idle Detection API（空闲检测 API）会进行通知，表明他们可能已经远离计算机。这非常适合聊天应用程序或社交网站之类的东西，让用户知道其联系人是否可用。 Web Assembly SIMD 它引入了映射到硬件中常用 SIMD 指令的操作。SIMD 操作用于提高性能，尤其是在多媒体应用程序中。 其他 逐步恢复SameSite cookie changes 滥用权限请求或滥用通知的网站将自动被隐藏通知（详情可见之前的报道） QuicTransport新的实验功能 更新说明：https://developers.google.com/web/updates/2020/07/nic84
2020-07-15
优秀的个人博客,低调大师

Python 编程语言实行尽可能成熟、稳定的新管理模式

在创始人和首席执行官 Guido van Rossum 辞去 BDFL 后，Python 软件基金会已经确定了 Python 的新管理模式。 新管理模型将依赖于一个由五人组成的指导委员会来建立标准实践，以便为 Python 引入新功能。该提案被设计为“无趣”、全面、灵活和轻量。 『我们不是管理专家，我们认为 Python 并不是一个好的实验对象，去实践新的或者没有经过证实的管理模式』，Nathaniel Smith 和 Donald Stufft 在 Python文档中解释道。『所以这个模式是尽可能地成熟的、众所周知的，且经过测试。大多数成功的 F/OSS 项目中最常见的是，一个大多数不干涉的理事会，而且低级的细节直接来自 Django 的管理模型』。 指导委员会将作为 Python 的“最终上诉法院”，并将对决策过程拥有广泛的权力，包括接受或拒绝 PEP 的能力（Python 功能增强建议），执行和更新项目的行为准则，创建子委员会和管理项目资产。但 Nathaniel Smith 和 Donald Stufft 说，理事会的预期目标是采取更多不干涉和偶尔干涉的方式来发挥其权力。 『理事会应该尽可能少地寻找使用这些权力的方法。』Nathaniel Smith 和 Donald Stufft。『最好定义 PEP 决策的标准流程（例如，接受其他 801x 系列 PEP 之一），而不是对单个 PEP 进行裁决。建立行为准则委员会比制定个案更好。等等。为了利用其权力，理事会投票。每个理事会成员都必须投票或明确弃权。在特定投票中有利益冲突的成员必须弃权。通过需要大多数非弃权理事会成员的支持。』 指导委员会的任务是提供一种可访问的，可维护的，形式化的引入变更的方法，基于『一般的理念，即将大的变化分成一系列可以独立审查的小变化：而不是试图在一个 PEP 中做所有事情，我们专注于为进一步的治理决策提供最小但坚实的基础。』
2018-12-22
优秀的个人博客,低调大师

禅道自动化测试框架 ZTF 3.5 发布，Bug 修复及增强稳定性

大家好，禅道自动化测试框架ZTF 3.5发布 Bug修复及新版本禅道的支持。 ZTF是禅道团队自研的开源自动化测试框架，与禅道无缝集成，可将禅道用例和测试脚本进行同步，将执行结果自动提交到禅道并生成测试报告，执行失败的用例可通过命令在禅道中创建Bug。ZTF命令行工具可以配合Jenkins、GitLab CI等持续集成工具使用。在流水线中，可以调用ZTF执行测试脚本，执行结束后，ZTF负责把单元或自动化测试的结果回传给禅道。二者合作打通了持续测试的一个闭环。 欢迎大家下载使用，并提出宝贵建议。配合禅道22.0及以后版本使用。 一、更新记录 1. 体验优化 优化客户端右上角设置按钮点击区域 优化客户端添加服务器时地址端口 2.问题修复 41870 修复单元测试预期中特殊符号‘-’在运行后会识别成‘//’的问题 41697 修复单元测试最后一个e中的最后一个数据为~~时，ztf执行识别不了为空的问题 55043 修复ztf3.4连接禅道开源版21.7.2失败 56015 修复ztf客户端无法同步脚本，并且服务器不可用的问题 61583 修复ztf windows11下安装报错 62691 修复ztf导出用例，用例步骤的层级不对的问题 62643 修复javascript脚本同步不一致的问题 70109 修复ztf gui 用例执行结果不会自动更新的问题 70379 修复ztf 同步执行结果到禅道报错的问题 70380 修复ZTF用例结果回传后，禅道里面的测试执行列表永远都是用例的第一个版本的问题 70624 修复客户端启动报错的问题 70651 修复获取禅道用例详情时返回值兼容性问题 其他请参考完整版本ChangeLog 二、客户端下载地址 ztf-win64-3.5.zip ztf-linux-arm64-3.5.zip ztf-linux-amd-3.5.zip ztf-darwin-3.5.zip 开源项目代码 使用过程中有任何问题欢迎到github issue反馈，附上具体报错或者通过禅道官方社区论坛反馈，附上具体复现流程和系统信息 四、帮助文档 Jenkins持续集成文档 自动化测试文档 单元测试文档 五、ZTF使用文档 ZTF使用Go语言开发，真正做到了平台无依赖、部署无依赖，只需要一个可执行文件就可以运行，可以解决用例信息管理、测试脚本执行、测试结果比对、缺陷Bug提交等问题。 ZTF自动化测试框架对您现有的测试脚本资产没有侵入，可很好地驱动9种脚本语言、10种单元测试框架、7种自动化测试工具来编写和执行脚本，并把最终结果回传给禅道，进行统一的报告展示，打通项目管理和持续集成工具之间的沟壑。 相关代码可参考demo目录和这里。
2026-03-27
优秀的个人博客,低调大师

Cursor Rules优化实战：构建高效稳定的AI代码生成规范体系｜得物技术

一、背景 随着AI辅助编程工具的普及，Cursor IDE已经成为越来越多开发者的选择。然而，在实际使用过程中，我们发现了一个关键问题：如何让AI真正理解项目需求并生成高质量、一致性的代码？ 答案在于构建一套系统化的AI协作规范。与传统的代码规范不同，AI协作规范需要考虑更多维度： 如何让AI准确理解业务逻辑和技术要求 如何确保生成代码的架构一致性和质量标准 如何在团队中推广和维护统一的开发模式 如何避免规范冲突和维护成本过高的问题 本文将分享我们在Cursor Rules优化过程中的实践经验，展示如何从混乱的规范体系演进到清晰、高效的AI协作规范架构。 二、旧版Rules痛点 在优化之前，团队已有的规范体系存在三个核心问题，这些问题影响了AI代码生成的质量和效率。 问题一：规则冗余与表述模糊 旧规范存在大量无效描述，包括模糊要求（如"确保高性能"）、重复定义和基础能力提示。这些冗余信息不仅增加token消耗，更分散AI注意力，显著降低代码生成效率。 问题二：提示词冲突 规范中角色定义混乱，不同文档将AI指定为架构师、开发者等矛盾角色。同时缺乏规则优先级机制，导致多规则同时生效时产生行为矛盾，无法形成明确执行路径。 问题三：维护困境 文档职责边界不清，新增规则时难以定位归属文件。修改单一功能需跨多文件调整，且规则间依赖关系不透明，造成维护成本指数级增长。 三、新版Rules设计理念 基于已有问题的深入分析，提出了一套新的设计理念，核心是：分层架构 + 职责分离 + 按需调用。 三层结构设计 新版本采用清晰的三层架构，每层都有明确的职责和边界： 标准化规则格式 为了确保规范的一致性和可维护性，我们定义了统一的规则格式： # 规则名称 ## 基础规范- 明确的技术要求和实现标准 ## 强制行为- 必须执行的具体操作和约束 ## 禁止行为 - 严格禁止的操作和做法，需要避免的常见错误 ## 示例代码- 具体的代码示例和最佳实践- 也通过 [文件名](mdc:路径) 引用外部示例 ※ 该格式优势 结构清晰：每个部分的职责明确，便于AI理解。 可执行性：强制/禁止行为都有明确的操作指导。 示例驱动：用实际代码代替抽象描述。 AI协作执行协议 为了确保AI能够正确理解和执行规范，我们设计了一个明确的AI协作协议提示词： # AI协作执行规则 ## 规则分类- basic/下的通用规则: 必须调用，通用基础规范- modules/下的模块规则: 按需调用，架构分层规范 - workflow/下的流程规则: 按需调用，业务场景规范 ## 执行流程1. 识别场景 → 调用相关规则2. 读取示例代码 → 作为生成参考3. 执行强制/禁止行为 → 确保代码质量4. 应用设计原则 → 组件化、单一职责、分层设计 ## 质量保障- 所有规则必须100%执行，重点关注强制行为和禁止行为 四、三层结构深度剖析 接下来我们详细分析新版本架构的设计特点和技术实现。 基础层的精细化设计 基础层是整个规范体系的根基，我们将原来混乱的MDC文件，精确拆分为7个职责单一的规范文件： 文件名 职责 核心内容 basic.mdc 项目基础规范 目录结构、技术栈、开发流程 code-quality.mdc 代码质量控制 复杂度限制、安全性要求 ts.mdc TypeScript规范 类型定义、严格模式配置 comment.mdc 注释规范 JSDoc格式、文件头注释 code-names.mdc 命名规范 变量、函数、组件命名约定 style.mdc 样式规范 CSS/Less编写标准 lint.mdc 代码检查 ESLint、Prettier配置 ※ 此拆分好处 职责明确：每个文件只关注一个特定领域。 维护便利：修改某个规范不会影响其他领域。 学习友好：新人可以逐个理解每个规范的要求。 示例：code-quality.mdc定义了代码质量分规范： # 代码质量分规范（通用规则） ## 强制行为 - 所有请求必须采用 HTTPS 协议- 确保第三方库安全可靠 ## 禁止行为 - 代码复杂度限制 - 单个文件不得超过 500 行 - 条件复杂度不得超过 10 - 单个函数不得超过 199 行 - 超过限制时，应优先按功能模块拆分为多个函数或文件- 禁止使用非得物域名的外部 CDN 资源- 禁止在代码中包含明文密码或硬编码 token- 禁止出现敏感词- 避免重复代码块- 不允许单词拼写错误或不符合命名规范- 避免在前端直接进行金额计算(导致精度丢失)- 禁止使用魔数(如 a === '3')，应使用常量(如 a === statusMap.login) 模块层的分层设计 模块层的设计遵循前端分层架构思想，将复杂的应用拆分为职责明确的模块： 表现层：components.mdc（组件规范）、pages.mdc（页面规范） 业务逻辑层：hooks.mdc（状态管理）、utils.mdc（工具函数） 数据服务层：service.mdc（API接口）、constants.mdc（配置管理） 路由层：route.mdc（路由配置和导航） 示例：服务层规范（service.mdc）规范定义了API接口的标准化开发流程： # API接口生成规范（模块规则） ## 存放位置规范（按优先级）- [p0] 页面级API：src/pages/{pageName}/services/{modules}.ts- [p1] 全局API：src/services/{modules}.ts- 类型文件：对应的 .interface.ts 文件 ## 标准代码模板```import { request } from '@/utils/request';import { UniversalResp } from '@/utils/request-operation';import { IUserListReq, IUserListDataRes } from './interface'; /** * 获取用户列表 * @param data 请求参数 */export const fetchUserListApi = async (data: IUserListReq) => { return request.post<UniversalResp<IUserListDataRes>>( '/api/user/list', data );};```## 强制行为- 使用MCP Server的mooncake_get_api_details工具获取接口详情- 响应数据必须使用UniversalResp<T>泛型包装- 接口命名采用fetch{ApiFileName}Api格式- 类型定义必须完整，包含完整字段注释 流程层的场景化设计 流程层是当前架构的创新点，针对具体业务场景定制化规范，将复杂的业务场景标准化。 流程文件 业务场景 核心功能 curd-page.mdc curd页面开发 curd页面完整使用流程 log.mdc 错误监控 APM监控和错误日志处理流程 sendBuried.mdc 数据埋点 用户行为埋点的标准流程 ...... 示例： curd-page.mdc 定义了完整的表格页面开发流程： ※ 该流程确保 开发效率：标准化流程减少决策时间。 质量一致性：所有表格页面都遵循相同的标准。 维护性：统一的结构便于后期维护。 # pro-table生成新页面（流程规则）深入研究代码并理解[insert feature]是如何工作的。一旦你明白了，让我知道，我将提供我的任务给你。 ## 工作流程按以下流程进行任务执行，如果评估存在非必须流程，可跳过。- MCP读取接口信息- 从用户输入中提取以下信息： - 列表名称 - 筛选项（需标记hideInTable） - 展示项（需标记hideInSearch） - 操作项 - 工具栏按钮- 评估完整的需求内容复杂度，考虑未来的扩展性，合理设计分层目录结构 - 各个模块保持单一职责，考虑合理的业务组件拆分，避免大量代码都在页面主入口文件 - 使用命令行批量创建目录文件（包含各类文件ts、tsx、less等） - 文件暂不生成代码- 配置页面的路由信息- 生成类型文件，确保所有类型定义清晰- 生成constants文件，定义所需常量- 生成services文件，实现数据服务- 生成所需的 hooks 文件- 生成页面（必需）和components（如需）文件 完成UI层 ## 强制行为- 使用pro-table进行开发，包括筛选表单，符合最佳实践- 筛选项和列表项配置创建useColumns.tsx声明，筛选项（需标记hideInTable）、展示项（需标记hideInSearch）- 左侧字段按需固定，操作项右侧固定，最多显示两个，超出折叠显示- 文本左对齐，数字右对齐，状态枚举居中显示- 分页设置支持10、20、50、100- ..... # 禁止行为..... 五、最佳实践 快速开始 第一步：创建基础架构 .cursor/rules/├── ai.mdc # AI协作总纲├── basic/ # 基础规范目录│ ├── basic.mdc│ ├── code-quality.mdc│ ├── ts.mdc│ ├── style.mdc│ ├── comment.mdc│ ├── code-names.mdc│ └── lint.mdc├── modules/ # 模块规范目录│ ├── components.mdc│ ├── pages.mdc│ ├── hooks.mdc│ ├── service.mdc│ ├── constants.mdc│ ├── utils.mdc│ └── route.mdc└── workflow/ # 流程规范目录 ├── curd-page.mdc ├── log.mdc └── send-buried.mdc └── ...... 第二步：配置AI协作协议 在 ai.mdc 中定义核心协作规则： # AI协作执行规则 ## 规则分类- basic/下的通用规则: 必须调用，通用基础规范- modules/下的模块规则: 按需调用，架构分层规范 - workflow/下的流程规则: 按需调用，业务场景规范 ## 执行流程1. 识别场景 → 调用相关规则2. 读取示例代码 → 作为生成参考3. 执行强制/禁止行为 → 确保代码质量4. 应用设计原则 → 组件化、单一职责、分层设计 ## 质量保障所有规则必须100%执行，重点关注强制行为和禁止行为 分阶段实施计划 阶段 目标 关键活动 试点阶段 验证规范有效性 选择1-2个项目试点，收集反馈 优化阶段 完善规范内容 根据试点反馈优化规范，开发工具 标准化阶段 形成团队标准 制定团队级标准，持续改进机制 六、总结 基于以下设计思路，并通过构建三层架构的AI协作规范体系： 单一职责：每个规范文件只负责一个功能领域，规则维护简单，冲突减少。 分层架构：基础→模块→流程的清晰层级，规则依赖明确，扩展容易。 按需调用：根据开发场景智能调用相关规范，使得上下文信息精准，效率提升。 示例驱动：用代码示例代替抽象描述，AI理解准确，执行到位。 持续进化：支持规范的迭代优化和扩展，研发适应变化，持续改进。 我们成功缓解了AI辅助编程中的核心问题，这套方法论不仅适用于Cursor Rules，更可以推广到其他AI协作工具的规范设计中。在AI辅助编程快速发展的今天，构建一套清晰、系统化的协作规范，将是每个开发团队的核心竞争力。 往期回顾 1.一致性框架：供应链分布式事务问题解决方案｜得物技术 2.Redis 是单线程模型？｜得物技术 3.得物社区活动：组件化的演进与实践 4.得物研发自测 & 前端自动化测试体系建设 5.从CPU冒烟到丝滑体验：算法SRE性能优化实战全揭秘｜得物技术 文 / 阳凯 关注得物技术，每周更新技术干货 要是觉得文章对你有帮助的话，欢迎评论转发点赞～ 未经得物技术许可严禁转载，否则依法追究法律责任。
2025-06-26
优秀的个人博客,低调大师

稳定且高性价比的大模型存储：携程 10PB 级 JuiceFS 工程实践

在过去两年多的时间里，随着 AI 大模型的快速发展，JuiceFS 在携程内部得到了越来越多 AI 用户的关注。目前，携程通过 JuiceFS 管理着 10PB 数据规模，为 AI 训练等多个场景提供存储服务。 本文将介绍携程如何使用 JuiceFS，以及基于 JuiceFS 实现的关键管理能力，包括多租户权限管理、计费功能、故障排查和监控等方面。同时，还将分享 3 个生产环境中的排障案例。最后，我们对比了 JuiceFS 与极速 NAS 的性能与成本，JuiceFS 在大多数业务场景中能提供与极速 NAS 接近的性能，同时成本仅为极速 NAS 的十分之一。 01 JuiceFS 在携程的应用：从冷存到 AI 场景 携程早在 2022 年就已经开始接入 JuiceFS，当时的主要目的是替代 GlusterFS，以提高其列表性能，服务 DBA，处理偏冷的数据。此外，这种解决方案能够与 OSS 的生命周期和运行策略相搭配，有效地降低 DBA 处理冷数据的成本。点击此处查看早期案例。 随着 AI 应用的需求变化，尤其是在 AI 模型训练过程中，存储需求开始转向大带宽读写和频繁的写入操作，如模型的 checkpoint 保存、数据分发及存储等。 AI 这个场景最大的痛点在于，携程的训练和推理系统被分开管理，导致存储架构非常割裂。训练过程中产生的模型需要通过复杂的上传和下载流程来分发到其他平台，这个过程显得非常低效且繁琐。 目前的做法是，训练平台和推理平台通过 JuiceFS CSI 挂载相同的卷，但对权限进行区分：训练平台具备读写权限（ReadWriteMany），而推理平台则仅具备只读权限（ReadOnlyMany）。对于只读负载，预读功能可通过 JuiceFS 中的相关参数进行调优，以提高性能。 此外，AI 应用面临的另一个问题是存储性能的瓶颈，尤其是在读性能方面。AI 推理任务需要较高的带宽，而许多存储产品的带宽表现有限。与 OSS 配合使用时，存储带宽可以根据数据量的增加而自动扩展。例如，OSS 为用户提供的带宽与数据流量成正比，数据使用量越大，分配的带宽也越大，这种设计使得 AI 用户在大规模数据读取时能够获得所需的带宽。 02 JuiceFS 部署架构 & 关键能力 我们搭建的部署架构与社区大部分的推荐方案一致，采用了 TiKV + OSS 的组合。具体来说，架构由以下几个核心组成部分构成： TiKV & PD 作为元数据引擎：TiKV 支持分布式架构和事务处理，具备出色的性能。通过跨 IDC 部署，确保系统的高可用性。 Ali OSS 作为存储底座：结合专线网络提供大带宽传输能力。同时，OSS 的自动转冷功能使得系统在成本控制上具有优势，性价比高。 JuiceFS 客户端的定制化：对 JuiceFS 客户端 进行了针对性修改，特别是在内部管理功能上，例如自助服务、计费系统、控制限速等。我们还进行了优化，以便用户在 Kubernetes (k8s) 环境中能够方便地使用。 关键能力 1：多租户权限管理与计费 我们要为多个用户群体提供服务，包括 AI、DBA 等不同领域的用户。为了保证资源的合理使用，我们为每个申请用户提供了独立的 token，用户需使用 token 进行挂载，以此实现资源的隔离。 为了控制成本，我们对用户的使用进行严格监控和计费。我们在每个卷（Volume）级别进行实时监控，并按小时生成账单，确保每个用户的使用情况得到清晰记录和计费。 在 Kubernetes 环境中，很多用户选择使用动态存储类来实现存储的自动化调度。但为了实现自助申请并便于计费，我们采用了静态 PVC。这种方式可以方便地关联卷，并与自动化流程相结合，确保每个卷的费用被精确记录。在 JuiceFS 中，每个卷都记录了一个全局变量（totalUsedSpace），该变量用于追踪与计费相关的使用情况。 虽然社区也支持对子目录的计费，但对于我们初期开发而言，按卷级别计费相对简单和高效。 计费原理 携程内部使用的工具 FinOps 可以定期拉取阿里云费用中心的数据，以获取每个云产品的费用信息。通过这个工具，我们能够实现对各项云服务费用的实时监控。 在使用这个工具时，当申请 JuiceFS 卷时，需要进行关联，卷的创建会与相应的用户关联。为了有效管理，我们每小时都会进行一次打点监控，记录空间使用情况、文件引用数量等指标，并将这些数据发送到 FinOps 系统。然后，FinOps 会对每个卷进行费用分摊，将 OSS 的费用按比例分摊到每个卷的所有者。 费用异常：存储泄露 在日常运营中，主要关注的是费用的上升情况和费用占用的趋势。这些费用数据能够反映出是否存在异常问题。在一次费用分析中，我们遇到了一个典型问题：通过 JuiceFS 统计的使用量没有明显变化，但整个 OSS 的成本却有所上升。经过进一步分析，确认阿里云的收费政策和 OSS 单价并未变化。然而，分摊出去的单价却上升了，导致了整体费用的增加。 在检查 JuiceFS 的计费统计和阿里云 OSS 上的文件量统计时，我们发现两者之间存在显著的差异。OSS 提供了一个存储空间清单功能，可以查看当前整个 bucket 下所有文件的使用量。我们通过使用 OSS 清单对数据进行聚合，发现 JuiceFS 统计的用量远低于 OSS 统计的用量。这导致了用户在 JuiceFS 中的存储空间使用量被低估，从而使得 OSS 存储空间的费用被错误地分摊给其他用户，进而导致其他用户的单价上升。 这一差异的根本原因在于 JuiceFS 删除文件的实现方式。对于大量删除的文件，JuiceFS 使用软删除策略标记文件为已删除，但后台会逐步删除这些数据。由于在使用过程中禁用了所有后台任务，导致用户的删除操作产生了许多待处理（pending）和失败的删除请求。 进一步分析后，我们发现 JuiceFS 存在两种数据泄露情况：一是待处理删除（pending delete），二是回收站（trash）中的数据。为了应对这一问题，我们设置了一个额外的监控服务，每隔 6 小时扫描一次潜在的数据泄露。如果发现泄露数据，我们会启用一个专门的客户端，取消禁用后台任务，并清理这些泄露的数据。 功能禁用 禁用回收站：回收站功能在很多用户场景下并不需要开启。回收站是后台任务，需要额外的资源进行清理，尤其是在使用 TiKV（如 RocksDB 数据库）的情况下，回收站会对数据库性能造成一定压力，尤其在出现突发的大规模删除时。因此，我们选择不启用回收站功能。 禁用备份元数据（BackupMeta）功能：JuiceFS 提供了元数据备份功能，但在数据量较大时，逻辑备份速度较慢，无法满足我们的需求。为了提高备份效率，我们更倾向于使用 TiKV 提供的官方备份工具来进行数据库备份，这样可以更好地支持大规模数据的备份需求。 关键能力 2：日志收集与管理，提高排障效率 我们使用内部工具将 TiKV 和 PD 中的日志收集到 ClickHouse，通过 Kafka 传输并最终存储到 ClickHouse 。 通过这样的日志收集，我们能够及时捕捉集群中的错误信息。许多情况下，集群可能会产生大量的错误，但用户并未察觉，且从客户端来看，性能似乎并未受到显著影响。然而，经过多次事故的处理，我们发现很多问题都是通过分析 TiKV 的日志来发现的，从而能在早期阶段及时解决潜在问题。 关键能力 3：监控 在监控方面，我们挑选了 TiKV 官方提供的一些关键指标来构建自有的监控系统。TiKV 和 TiDB 的整体监控体系相对复杂，官方提供的监控看板包含了大量信息，显得过于繁杂。刚接手时，这一部分确实没有很清晰的理解。 在实践过程中，我们最终选取了几个核心的指标，以便更有效地监控 TiKV 的性能： 性能相关指标：包括 CPU、内存使用情况以及热点读写。 PD（相关指标：重点监控 Region leader 分布与调度情况。 GC（垃圾回收）相关指标：包括 GC 时间和 MVCC 删除等信息。 在 JuiceFS 客户端的监控中，我们通过 Prometheus 接口获取 CSI 的指标。然而，对于普通挂载情况，特别是在用户自行部署 JuiceFS 的机器上，我们无法直接控制或访问这些数据。因此，我们使用 JuiceFS 提供的 state 文件来采集简化的监控指标。大部分场景中，state 文件已经能够覆盖我们需要的指标。为了高效采集数据，我们在每台机器上部署了一个 DaemonSet，通过该工具定期读取 state 文件并进行监控。 客户端监控看板包括以下内容：CPU 和内存使用情况、启动时间和启动参数、Golang 性能指标（如堆内存中的活跃对象）、以及读写性能（包括缓冲区和块缓存的使用情况）。除了关注客户端的读写性能外，更多时候我们更侧重于整体带宽情况。 关键能力 4：元数据备份 在 TiKV 生态中，存在两个不同的 br 备份工具。TiKV 文档中提到的 br 工具只能备份通过 rawKV API 写入的数据，无法备份通过 txnKV API 写入的数据。 与此不同，TiDB 仓库中的 br 工具更侧重于备份 TiDB 数据。这个工具提供了 backup txn 子命令，专门用于备份通过 txnKV API 写入的数据。最终，我们采用了 TiDB 的全量快照备份方案，每日进行定时备份。 在使用 TiKV 集群版本 v5.2 并直接应用 TiDB br 工具的 master 分支代码 时，遇到了一些问题： 虽然可以成功备份数据，但在恢复时出现了错误。 在备份过程中，TiKV 持续尝试执行备份操作，且无法停止。 针对这些问题，我们将其反馈给了 TiKV 社区，并在社区的帮助下成功解决了相关 bug。解决问题后，我们对备份过程进行了优化，通过设置备份限速为 50MB/s，使得备份过程能够在大约 15 分钟 内完成。 TiKV 备份通过 trip-tikv-manager 服务进行管理，该服务负责调度和执行备份任务。备份数据被存储在独立的对象存储 中，目前使用的是 Ceph 存储系统。 目前，在我们的最大集群扩展后的生产环境中，能够在 20 分钟内完成全量备份。备份任务基本上会在每天定时执行，并通过监控实时查看备份状态。由于 JuiceFS 服务全天没有明显低谷，我们选择在白天对 TiKV 进行备份。 鉴于我们的系统部署为三中心结构，并已对 Region 实施了 Zone 级别的隔离，即便单一中心发生宕机，也不会影响到 TiKV 的可用性。因此，我们将 TiKV 的备份视作一种额外的安全措施，仅执行快照级别的备份与恢复操作。 03 生产环境排障案例 案例 1：TiKV MVCC (Multi-Version Concurrency Control) 堆积 这个问题是在去年 9 月被发现的。当时我们发现，尽管 TiKV 数据库和 JuiceFS 的整体使用量并没有显著增长，但数据库的磁盘空间和引擎大小却急剧下降。奇怪的是，TiKV 的 CPU 使用率和 QPS 并未发生明显变化。进一步分析日志后，发现大量与 region 相关的报错，这些错误是由于 MVCC（多版本并发控制） 堆积引起的。MVCC 堆积后，region 内的旧版本数据不断累积，导致 region 无法正常分割，从而阻碍了硬盘空间的及时回收。 通过深入排查并使用 tikv-ctl 工具解码报错的 region 中的 key 后，我们发现这些 key 均来自同一个 JuiceFS 卷。由于用户频繁更新文件，JuiceFS 中的 chunk Key 数量不断增加，每次更新都会在 TiKV 中生成新的版本，从而迅速消耗内存和磁盘资源。 进一步分析我们发现，TiKV MVCC 堆积问题与 JuiceFS 的元数据定义和存储方式密切相关。TiKV 作为支持 MVCC 的数据库，能够保证事务的隔离性。每当数据被更新时，TiKV 会为每个写入操作分配一个时间戳（TSO），从而创建一个新的版本，而不是直接修改原有数据。这种机制确保了事务的隔离性，并保证了读操作可以读取到一致的数据。 在实际应用中，JuiceFS 会将文件切分为多个 chunk，每个 chunk 包含若干 slice。当一个 chunk 被频繁更新时，TiKV 会为该 chunk 创建新的版本，导致相同 chunk key 在 TiKV 中产生多个版本。 频繁更新同一 chunk 会使 TiKV 无法及时回收过期的版本，从而迅速消耗存储资源，最终导致 MVCC 堆积。随着这些未回收的旧版本不断积累，TiKV 的存储压力逐渐增加，可能会导致性能下降，甚至引发磁盘空间不足等问题。 具体来说，高频更新文件导致以下两方面的性能问题： JuiceFS ：由于 chunk 记录的 slice 数量不断增多，JuiceFS 需要更多时间来恢复完整的文件视图。当 slice 数量过多时，JuiceFS 会暂停写入，并强制执行数据压缩（compaction）操作。 TiKV：频繁写入版本会增加 RocksDB 中存储的数据量，导致 LSM 树的读性能下降，从而影响 TiKV 的整体性能。 针对上述问题，我们采取了一种更加激进的垃圾回收（GC）策略。具体做法是设置一个独立服务，每隔 5 分钟通知 TiKV 的 PD 节点，告知它在接下来的 25 分钟内的数据可以被 GC 回收。这样，TiKV 在 GC 时能够通过 compaction 过程高效回收无用数据，减少了 GC 对 CPU 的占用。同时，通过加速 TiKV 的 compaction 过程，能够有效降低 MVCC 堆积的风险，防止版本过度堆积而导致的性能瓶颈。 案例 2：大量容器同时扫盘打爆 TiKV 在进行大量容器同时扫描磁盘时，TiKV 负载超过 70%，甚至出现崩溃的情况。经过排查发现，所有卷都是通过 CSI 形式挂载的。在使用 CSI 挂载 JuiceFS 时，会启动一个单独的 Pod 并在其中挂载 JuiceFS 客户端。由于 JuiceFS 客户端与应用 Pod 完全隔离，无法感知应用中的挂载点操作，导致 TiKV 的 PD（Placement Driver）管理节点的利用率不断上升。 进一步调查后，发现大量 GET 请求，主要是文件查找操作。虽然 OSS 监控数据显示一切正常，但 TiKV 却持续受到来自历史失败请求的压力，导致性能下降。卷中存在大量小文件和超大目录，导致 TiKV 不断处理类似"扫盘"行为的请求。最初我们认为问题出在宿主机上的某些应用，但进一步排查后发现，JuiceFS 应用的 Pod 中有一个定时任务，该任务会定期扫描目录。多个 Pod 同时对一个超大目录进行扫描，造成 TiKV 负载极大。 针对这一问题，采取了以下对策： 消除 updatedb 的影响：通过使用 ConfigMap 将 /etc/updatedb.conf 挂载到用户 Pod 中，覆盖镜像自带的配置，并在配置中禁止扫描 JuiceFS 挂载点。 限流元数据操作：为了防止用户不经意间的行为影响 TiKV 集群的性能，我们修改了 JuiceFS 和 TiKV 相关代码，在元数据部分添加了限流机制，避免 TiKV 因过多文件查找请求而过载。 进一步限流代码：尽管之前对 OSS 带宽进行了限流，但问题仍未完全解决。因此，我们进一步添加了针对元数据操作的限流代码，特别是针对 TiKV 的元数据操作，从而缓解了 TiKV 集群服务质量下降的问题。 案例 3：JuiceFS client OOM 在使用 JuiceFS 的过程中，AI 用户，存在不规范的使用方式。这些用户会在 JuiceFS 中存储训练数据集，这些数据集可能是图片或文档，都是小文件，而且通常都是讲大量小文件集中存储在一个目录中。某些目录中的文件数量甚至达到数百万，甚至数千万个。当多个应用同时发起目录读取请求时，可能会导致内存溢出（OOM）问题，尤其是在目录中包含大量小文件时。 为了解决这一问题，我们对线上 JuiceFS 客户端进行了 pprof dump 分析，确认问题出在 JuiceFS 的目录读取实现。具体而言，在 JuiceFS 中，目录读取是一个阻塞式操作。每次读取目录时，系统会拉取该目录下所有文件的名称和属性。如果目录中包含大量文件，这一过程会消耗大量内存。例如，对于一个包含 500 万个文件的目录，单次目录读取请求会导致内存占用达到 3.7GB，并且这部分内存会被长时间持有。 为了解决这一问题，团队将全量读取目录的实现修改为流式缓冲读取方式，从而有效减少了内存占用，并防止了 OOM 问题的发生。在与社区沟通并反馈该问题后，社区积极参与修复，最终成功解决了这一问题。 meta: support dir stream #5162 04 JuiceFS 的成本优势：十分之一极速 NAS 我们对 JuiceFS 与阿里极速 NAS 的进行了性能对比，结果显示，在大部分读写场景下都不落于极速 NAS，甚至性能更加优秀。 JuiceFS 具有客户端缓存和预取功能，并且采用了 OSS 大带宽、以及数据和元数据分离的设计，这使得它在大部分应用场景中表现出色，尤其是在大模型推理应用中。大模型推理应用通常需要高带宽的顺序读取场景。 通过将 JuiceFS 与 OSS 结合使用，我们实现了一个分布式文件系统方案，能够在大多数业务场景中提供与极速 NAS 相同的功能和接近的性能，而成本仅为极速 NAS 的十分之一。 这一成本优势是 JuiceFS 方案的最大魅力之一，它能够显著降低我们的运营成本。 Q&A Q：大模型对于存储的主要需求是什么，还是只关注性价比？ A：在大模型场景中，我们最关心的是顺序读写带宽。训练过程涉及训练数据和模型的加载，以及检查点（checkpoint）的写入。推理过程则主要涉及模型的加载。尽管整个流程中涉及一些写操作，但读操作占主导，因此，我们特别重视提升读带宽的性能。 Q：从对象存储拉取数据慢，有什么建议? A：JuiceFS 非常适合 AI 负载场景，能够提供非常高的顺序读写带宽。对于顺序读写，JuiceFS 可以启用预读功能，提前从 OSS 拉取数据，这能有效提升性能。然而，由于 OSS 的延迟一般高于 50ms，这可能会影响随机读写的性能。如果对低延迟有较高要求，NFS-Ex 和 CPFS 都能提供 1ms 以内的 4K 随机读写延迟。此外，JuiceFS 官方也提供了分布式缓存方案来降低延迟。总体来说，这之间是性能与成本之间的权衡。 Q：TiKV元数据规模大概能支撑到多大的量？数据量大的场景，元数据是不是成为瓶颈？ A：提供一组携程的数据供参考，我们的一台生产集群，TiKV节点数量为 6 个，每个节点配置为 64 核 256 G 内存，承载着接近 40 亿个文件的负载。在这种配置下，TiKV 的 get p99 延迟仍然保持在 1.5ms 以下。实际生产中，元数据的延迟与 OSS 的延迟不在同一量级，因此 TiKV 并未成为瓶颈。
2025-03-10
优秀的个人博客,低调大师

Simple Admin - Go 语言分布式后台管理系统 v1.5.0 稳定版发布

Simple Admin - Go 语言分布式后台管理系统 v1.5.0 更新 项目介绍 Simple Admin 是一个开箱即用的分布式微服务后端管理系统，基于 go-zero 开发，为开发小型到大型项目后台提供了丰富的功能，易于扩展，支持三端代码生成。 官方自带多种扩展，助力中小企业快速上云，快速迭代。项目全部采用中英双语支持，方便应用出海，深度支持国际化。适合用于微服务学习和商用，开源免费。 Simple Admin Core / Job / MCMS / FMS / Common v1.5.0 更新 介绍 核心模块 Core, 定时任务模块 Job, 消息中心模块 MCMS, 以及文件管理模块 FMS 均已升级 核心模块用于基础的后台运行，其余模块可根据需求选用。 特性 最新技术栈：使用 ent, casbin, kafka 等前沿技术开发 完全支持 go-swagger: 直接在 api 文件内编写注释即可直接生成 swagger 文档 统一的错误处理: 整个系统拥有国际化的统一错误处理 国际化：内置完善的国际化方案 服务注册发现: 完善的服务注册发现机制，原生支持 K8s 权限: 内置完善的动态路由权限生成方案, 集成 RBAC 权限控制 代码生成: 内置三端 Web, API, RPC 代码生成 多种扩展: 提供多种扩展，同时具有非常简单的接入功能 其他: 流量控制， ES 服务 ORM: 强大的 Ent 框架支持 本次更新 新增(Common): Tenant 数据权限 redis key 优化(Common): 移除 redis key 多余的字符 新增(Core/Menu): 新增 permission 字段用于控制页面权限 更新: all in one 和 changelog 更新: 更新依赖 Simple Admin Backend UI v1.5.0 更新 介绍 Simple Admin UI 是基于 vue-vben-admin 二次开发的为 Simple Admin 专门开发的后台管理界面，基于 Vue3 和 TypeScript 开发， 提供后台错误统一处理，国际化等功能，本项目完全免费，可用于学习和商用. 特性 最新技术栈：基于 Vue3/vite5 等最新技术开发 TypeScript: 采用 Typescript 的语言 主题：可配置的主题 国际化：内置完善的国际化方案 Mock 数据 内置 Mock 数据测试方案 权限 支持动态路由权限 组件 二次封装了多个常用的组件 Remeda: 使用 remeda 作为数据处理工具 本次更新 修复(MenuItem): 修复 menu item 在 top layout 下显示错误名称 新增(Menu Permission): 菜单新增页面元素权限标识 新增(hasElementPermission): 新增 hasElementPermission 方法用于控制前端元素显示 优化(Role drawer): 优化权限控制抽屉宽度 优化(checkbox): 全局优化 checkbox 宽度默认为 20 更新(vxe-table): 升级 vxe-table 组件至最新版本 优化: 优化部分注释 更新： 更新依赖 Goctls v1.7.14 更新 介绍 Goctls 是一个基于 Go Zero 官方生成工具 Goctl 开发的针对 Simple Admin 适配优化的生成工具。提供强大的代码生成功能，同时集成了许多定制工具，实现快速开发微服务接入后台和前台 ​。三端代码生成可以大大提升开发效率，欢迎体验 ​。 特性 go-swagger : 基于 go-swagger 生成 API 文档，只需一行注释即可生成文档 i18n: 所有生成模板均实现多国语言支持 错误处理: 优化错误信息处理, 支持多语言错误 Validator: 简单易用的校验器, 只需添加 tag 即可校验 三端代码生成: 支持三端代码生成，生成 API, RPC 和 web 端的 CRUD 代码 RPC 接口分组： rpc logic group 分组 proto 文件拆分: 支持 proto 文件拆分，方便管理 Ent 支持: 全面支持 Ent 代码生成，包括数据库导入，schema 生成，模板管理，自动升级等功能 额外工具: 额外工具如本地日志查看，环境变量查看 本次更新 优化(vben): 优化 checkbox 默认宽度为 20 更新： 更新依赖 文档地址:点击访问
2024-07-15
优秀的个人博客,低调大师

Bee V2.2 分库分表 Sharding+MongoDB ORM 稳定版发布 (更新 Maven)

Hibernate/MyBatis+ plus +Sharding JDBC + Jpa+ Spring data+ GraphQL+ App ORM (Android, 鸿蒙)= Bee 小巧玲珑! 仅860K,还不到1M,但却是功能强大! V2.2(2024.1.1·LTS版) 1.Javabean实体支持继承(配置bee.osql.openEntityCanExtend=true) 2.增强批量插入与事务的关联 2.2之前,调用批量插入在每个批都会提交commit,但在2.2改为只调用一次且在事务中,在批量插入的方法内容不再提交,而由事务控制. 扣群:992650213 3.fixed bug: 1)Condition使用Op.in时,参数为null时会报异常 2)分片批量插入上下文相关的bug 3)仅分库时,解决上下文问题 4)分片时,主线程的上下文要清除 5).InheritableThreadLocal与parallelStream()不兼容的bug,当不是分片模式时,可以用parallelStream(),而分片时则不建议使用parallelStream() 一文搞懂数据库分片:分库分表,只分库不分表,只分表不分库... https://my.oschina.net/u/4111850/blog/10759889 支持各种分片模式: 1.分库分表 2.仅分库 3.仅分表 4. 使用日期的字段作为分片键 5. 不规则，通过自定义设置映射 自动生成 Spring Boot 后端微服务代码，几秒钟即可完成，秒杀 GPT. https://gitee.com/automvc/gencode 下期功能预告: Bee已经是一个功能很齐全的ORM啦,你还想添加什么功能，请到评论区告诉我们.扣群(992650213)! 项目首页: https://gitee.com/automvc/bee https://github.com/automvc/bee https://gitee.com/automvc/bee-springboot
2024-01-10

资源下载

更多资源
优质分享App

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

时间: 2025-12-03 大小: 4.36MB 下载: 23次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2025-12-21 大小: 189MB 下载: 2次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2025-12-17 大小: 5MB 下载: 1次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2025-12-03 大小: 9.84MB 下载: 39次
热门标签
Jdk25 DeepSeek Gemini3 Nacos3 OpenAi HarmonyOS6 Docker Rocky Kubernetes SpringCloud SpringBoot4 Redis Service Mesh

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册