2026
07月
定时任务多实例打架：用一条 INSERT 语句做租约锁
本文介绍了一种利用数据库表实现分布式定时任务锁的轻量级方案。该方案通过10行锁表结构和单条upsert语句，在不引入中间件的情况下解决了多实例任务重复执行问题。关键设计包括：基于MySQL行锁的原子抢断机制、5分钟租约实现自动释放、ownerId校验防止误删、完整运行流水记录等。特别强调了锁与核心服务同故障域的原则，以及通过显式SKIPPED状态区分正常抢占与异常情况。该方案已在生产环境稳定运行，同时保持对单实例部署的兼容性，体现了简单可靠的分布式系统设计哲学。
组织架构树怎么存：物化路径的取舍与级联
本文提出了一种结合邻接表和物化路径的组织架构存储方案，使用`parent_id`维护逻辑关系，通过`tree_path`字段（格式如`/1/5/12/`）预存完整路径信息。该设计将递归查询转为字符串前缀匹配，显著提升子树检索（如`LIKE '/1/5/%'`）、层级判断等高频操作的效率，适用于读多写少场景。 关键实现包括：部门移动时通过前缀替换+深度差值批量更新子树路径，严格保证事务原子性避免中间态问题；删除操作限制为空节点以防止关联数据丢失。相比递归CTE和闭包表方案，该方案在中等规模树状数据中实现了存储成本与查询性能的最佳平衡。核心经验在于：写入时付出计算路径的代价，换取读取性能的确定提升，并通过事务和保守删除策略确保数据一致性。
06月
谁干的？干了什么？：把审计日志当产品做
审计日志需结构化设计以满足质询需求，区别于应用日志的开发者视角，审计日志需面向管理员和合规需求，记录操作者、对象、动作、结果等核心信息，并长期存储于可检索的数据库而非易失的日志文件。设计关键包括：通用表结构通过字段预演质询场景（如操作者、目标对象、动作类型等），区分高频检索字段与低频JSON细节；针对AI任务单独设计表结构以标记风险；写入时实施截断与脱敏治理。审计日志需通过管理端查询页和任务自我审计机制提升可见性，确保在事故发生时能快速定位问题。核心原则是：分表设计服务于不同的查询模式，写入端治理保障数据卫生，审计的核心价值在于事故时的可靠回溯能力。
主键为什么不用自增：简化版雪花 ID 的取舍
本文探讨IM系统放弃自增主键、改用简化版雪花ID的设计思路。自增ID存在业务量泄露、数据库依赖性强及数据合并风险三大缺陷。作者设计的30行雪花ID方案通过时间戳位移与自增序列结合，在单机环境下实现全局单调递增，巧妙规避时钟回拨问题，通过CAS保证并发安全。该方案明确放弃多实例支持，保留未来扩展性。文中同时指出前端需特殊处理64位长整型精度问题，并将ID的排序性提升为重要基础设施特性，支持游标分页等核心功能。最后总结三点：应用层掌握发号权能简化业务流程；技术简化需明确约束条件；跨语言精度问题须早期防范。这种有针对性的取舍设计，体现了工程决策中的克制与清醒。
删了又没完全删：两段式软删除的设计
文章探讨了业务系统中“删除”功能的复杂性与设计思路。作者起初采用简单的软删除（`is_deleted`字段），后升级为两段式删除：先进入可逆的回收站阶段（`deleted_at`标记，30天有效期），再进入不可逆的彻底删除（`is_deleted=1`）。关键设计包括：通过字段分工明确状态转换（如`WHERE`条件保证状态机逻辑），恢复时严格校验时间窗口，查询中必须逐表过滤软删除标记。此外，作者强调软删除应仅用于用户主动删除的场景（如文件），业务状态变更（如员工离职）需用状态机，技术数据（如临时记录）则直接硬删除。最后，物理清理通过异步流水线实现最终一致性。全文核心观点包括：删除需设计为多阶段状态机、恢复逻辑应独立于后台任务、查询过滤是持续维护成本，以及合理区分删除类型的重要性。
消息一多接口就慢：把 offset 分页换成游标分页
这篇文章总结了IM系统中分页接口从offset分页切换到游标分页的经验。传统offset分页存在性能线性劣化和数据一致性问题，而游标分页通过记录具体数据位置（如消息序号或时间戳+ID组合）解决了这两个问题。作者详细介绍了两种场景的实现：消息列表使用单调递增的seq_no作为单字段游标，会话列表则需要包含pin_flag、时间戳和ID的三元组复合游标。文章强调了游标必须完全对应排序字段、需要主键作为决胜字段等关键细节，并指出接口层应强制校验复合游标的完整性。最终改造使分页性能稳定在毫秒级，不再受数据量增长影响。
接口报错别让用户猜：统一响应、错误码与 requestId
项目早期技术债中最容易被低估的是接口的报错方式不一致问题。解决方案通过统一响应包、标准化错误码、简化业务异常和建立统一的异常出口，最终实现了全系统的一致性。具体措施包括：定义通用响应结构（R类），采用0为业务成功的标识；错误码设计以HTTP状态码为参照，便于直观理解；业务异常仅携带必要信息，确保简洁性；通过全局异常处理器统一处理各类异常，避免敏感信息泄露。这套方案大幅降低了前后端协作成本，提升了系统的可维护性和安全性。核心价值在于一致性，而非技术复杂度，200行代码实现了全局规范化。
模块还在各扫门前雪：用领域事件把业务串起来
模块化单体架构中，领域事件通过解耦发布方与消费方实现业务逻辑隔离。本文以员工入职场景为例，提出组织模块仅需发布`EmployeeHiredEvent`事件，而插件系统、消息模块等消费方自主响应。事件设计需遵循三原则：① 字段使用原始类型快照而非实体引用；② 采用`file.uploaded`等稳定命名跨进程路由；③ 强制包含`occurredAt`和`operatorId`审计字段。核心实现依托事务提交后触发的`publishAfterCommit`机制，避免监听方读取未提交数据。消费方通过`@EventListener`独立处理事件，需捕获非致命异常确保主流程不受影响。该方案的代价包括调用链可追溯性降低和最终一致性风险，适用于通知类等可延迟处理场景。实践表明，领域事件能有效减轻核心模块的调度负担，11类事件在四个模块中仅用百行代码实现解耦。
05月
群聊怎么做：从成员管理到已读回执的完整实现
本文重点解析了Workforce Hub即时通讯系统中的群聊功能设计。核心设计包括：1）复用私聊会话表并通过conversation_type字段区分群聊；2）独立成员管理表实现角色权限、消息状态跟踪（如last_read_seq计算未读数）；3）三类群组（组织群/业务群/自定义群）的差异化控制；4）成员变动事件的全员推送机制；5）发言权限的实时检查策略（ALL/ADMIN_ONLY/MUTED）。关键技术方案包括：消息推送时仅覆盖在线成员、已读序号通过GREATEST函数防回退、历史消息可见范围（FULL/AFTER_JOIN）配置等。相比私聊，群聊在数据关系、状态同步和权限控制上存在更复杂的业务逻辑。文章还提及未来针对大群推送性能的优化方向。
IM消息怎么存？从建表到幂等的完整方案
该文章详细探讨了IM系统消息存储的关键设计要点与实战方案。1. 表结构设计采用会话级严格递增`seq_no`替代自增ID保证消息顺序，JSON字段`content_json`支持多类型消息扩展；2. 采用游标分页（基于`seq_no`的条件查询）解决传统offset分页的性能与一致性问题；3. 通过客户端幂等键(`client_message_id`)四元组唯一约束实现消息去重，结合应用层校验与数据库约束双重保障；4. 独立状态字段管理消息编辑/撤回流程，用户行为通过`im_message_user_action`表实现软删除，不影响其他用户查看。文章还对比了JDBC与ORM框架在高压写入场景的选型考量，最终形成包含消息顺序、分页策略、幂等控制等六方面核心机制的技术方案。
