- 博客(64)
- 收藏
- 关注
RSS订阅原创 IoT 终端如何「听懂」云端指令？MQTT + 消息队列上下行链路设计实战
本文以虚构产品「智享柜」为例，详解IoT设备与云端的通信链路。通过MQTT协议实现终端与云端的双向消息传递，结合Kafka消息队列解耦接入与业务系统，设计合理Topic结构与消息分发机制。重点讲解上行消息的有序处理：基于deviceCode哈希分桶，确保单设备消息顺序消费，同时支持多设备并行处理。适用于Java后端初学者理解设备接入核心架构与实践。
2026-10-28 11:17:07
390
原创 订单号「基因法」分表实战：共享充电宝的订单、支付、分润表，分片键到底怎么选？
本文分享共享充电宝项目分表改造实战，聚焦“分片键”选择与历史数据迁移难题。通过梳理订单类、支付类、分润类三类表，最终采用“基因法”——在订单号中嵌入时间信息，实现按月分表。优势在于：查询仅需订单号即可精准路由，兼顾冷热分离与归档便利，且改造成本低。结合ShardingSphere-JDBC中间件，实现无感分库分表，避免全表扫描，提升系统性能。适合对分库分表落地有困惑的开发者参考。
2026-10-12 10:22:56
1245
原创 Dubbo 默认超时重试：把下游打雪崩的隐形放大器
Dubbo默认重试机制在高峰期可能将本已变慢的请求放大三倍，引发雪崩。因retries=2导致单次调用最多发起3次请求，非幂等写操作重试将造成脏数据，而流量放大更易击穿下游。建议：非幂等写禁用重试（retries=0），读操作有限重试并严格计算超时预算，结合熔断、限流与业务幂等键，避免“重试救不了过载”。
2026-10-11 12:46:25
943
原创 从零搭建Java 项目的 AI Agent 开发工作流：从一次对话到可持续交付
本文构建Java项目AI Agent开发工作流，涵盖“入口→规则→知识→执行→验证→闭环”全链路。通过统一入口（AGENTS.md）、分层规则包与LLM Wiki协同，实现任务自动判档、最小修改与分层验证。强调双闭环：任务闭环确保交付达标，知识闭环促进经验复用。关键机制包括自动收尾脚本、版本SQL校验、索引覆盖检查及审计清单输出，所有路径需落地替换为真实仓库配置，严禁假设规则自动生效。
2026-09-14 10:19:49
3261
原创 从零搭建 AI Agent 开发工作流：从一次对话到可持续交付
为AI持续辅助开发建立稳定工作协议：用AGENTS.md、核心规则、检查脚本构成最小闭环；按任务规模分轻量、单点、完整三档调整阅读与验证；并将规则分为内核、规则包、团队与个人层。人负责提供事实与决策，Agent负责执行和交付证据。目标是让Agent主动读规则、保护既有改动、实现、验证并说明结果。
2026-09-08 14:27:58
4375
2
原创 扫码登录：短轮询、长轮询还是 SSE？
谁有资格拿到 Token—— 出码会话绑定、状态机单向、换票GETDELPC 怎么尽快看到状态变化—— 短轮询 / 长轮询 / SSE你真正要的就用实现简单、连接少、集群无脑扩短轮询窗口内立刻拿到终态长轮询终态之外还要「已扫待确认」SSE双向实时别绑在登录页上，另开 WebSocket多数网站选短轮询，是因为 TCP 和复杂度比那 1～2 秒更贵。SSE 没有推翻这个结论，它只是把「中间态也要即时」从两次长轮询里拆出来，变成一条事件流。先画状态机，再决定连不连、连多久、断了怎么办。
2026-08-24 11:37:02
4834
原创 高并发请求折叠：从 Hystrix 到埋点聚批
短时间内的多个请求，合并成一次下游调用，再把结果按原顺序还回去。【不折叠】线程1 ──▶ SELECT id=1 ──▶ DB线程2 ──▶ SELECT id=2 ──▶ DB线程3 ──▶ SELECT id=3 ──▶ DB... 共 N 次往返【折叠后】线程1 ──┐线程2 ──┼──▶ Collapser 缓冲 ──▶ SELECT id IN (...) ──▶ DB线程3 ──┘ ││ timer 到期 / 凑满 N 条▼拆回各线程结果能换来什么点说明连接与线程。
2026-08-17 14:12:53
5580
原创 RocketMQ 顺序消息优化：单 Queue 瓶颈、最终一致与 Join 三种方案
短信状态流转优化方案 核心思路：通过多队列+消费端状态机优化性能，同时保证业务正确性 改造过程： 初始方案：单队列顺序消费，严格顺序但吞吐低（仅数百TPS） 第一阶段优化：扩展到1024队列+并发消费+消费端幂等状态机，吞吐提升一个数量级 进一步优化：引入uniqueId分区+顺序消费，降低锁竞争 严格顺序场景：采用任务组Join+到达日志模式 业务状态机规则： 允许跨级更新（如直接从未记录更新到终态） 禁止状态回退 通过唯一索引+乐观锁保证并发安全 适用场景： 乐观乱序（日志类业务） 终态正确（短信状态流
2026-08-14 12:05:02
5875
原创 AI 三件套装齐了却不会用？规则、知识库、技能包一次跑通
这篇文章系统性地介绍了如何将规则文件、知识库和技能包三个工具协同使用，通过三层分工模型解决实际任务中的信息组织问题。核心要点包括： 痛点分析：分别掌握工具后仍面临使用边界模糊、内容重复冲突、缺乏判断标准等问题 解决方案：提出"三层分工+判断口诀"模型 规则文件：存储不可违反的硬性约束 知识库：记录项目事实和设计背景 技能包：封装可复用的方法论 实战演示：通过"订单超时自动取消"功能案例，展示五步协同流程 关键原则：三层信息通过引用而非复制保持一致性 文章强调这种分层方法具有工具无关性，其核心价值在于建立持久
2026-07-27 17:05:26
7057
原创 AI 好用但每次做法都不一样？给它装一套标准工作流程
摘要 工作方法论缺失导致AI执行同类任务时缺乏一致性，表现为做法不稳定、需求理解偏差、验证环节缺失等问题。解决方案是将标准工作流程封装为可复用的"技能包"，每个技能（如需求澄清、系统调试）独立管理特定环节，并能自动触发和串联成完整流程。通过开源库Superpowers可快速部署业界已验证的方法论，同时支持项目专属技能定制。使用时需注意任务复杂度与技能匹配，复杂任务推荐全套流程，简单任务可手动裁剪步骤以平衡效率与质量。该方法以结构化流程替代随机性输出，提升AI工作产出的可靠性和可预测性。
2026-07-20 11:13:16
7500
原创 AI 每次都要重新“认识“项目？给它一份会自己长大的知识库
本文提出了一种让AI自主维护项目知识库的"自洽模式"解决方案，主要解决四个痛点： AI每次会话都要重新了解项目背景 2.文档容易过时失效 3.知识来源不一致 4.文档堆积难以检索 解决方案包含五个关键实践： 将文档更新规则写入项目规范 建立索引页+模块专题页的两层结构 统一元数据模板 采用Obsidian互链规范 明确AI写入、AI检索和人工浏览的分工 该方案特点是不需要额外配置LLM Wiki或API密钥，直接在代码仓库中维护Markdown文档作为唯一真相源，AI和开发者共用同一套知识库，通过Obsid
2026-07-13 09:52:40
7533
原创 别让 AI 乱写代码：用规则文件给编码助手立规矩
文章摘要： AI编码助手虽能提升开发效率，但其输出风格和规则的不稳定性常导致团队协作问题，表现为代码风格漂移、隐性约定丢失、无视红线操作及重复经验浪费。解决方案是将团队规则固化为AI可自动加载的规范文件，核心原则包括：分层加载（全局规则与场景规则分离）、提供可执行的正反例而非抽象描述、建立闭环反馈机制（踩坑即更新规则），以及统一规则入口避免分散。通过分层文件结构（如AGENTS.md为主规则，工具专属文件为辅）和具体示例引导，确保AI在不同会话中稳定遵守团队约定，减少返工成本
2026-07-10 11:27:23
7187
原创 App 动态域名配置下发方案
移动应用动态域名配置下发方案采用SM2签名保障安全性，通过S3+CDN下发WebSocket、管理端和文件服务三类URL配置。方案核心为单一JSON文件包含SM2签名，客户端内置初始URL并验证签名后更新本地配置。签名采用确定性JSON序列化规则确保验签一致性，避免因格式差异导致失败。客户端策略包括：验签通过后持久化配置、拉取失败保留有效缓存、网络异常时触发二次拉取。存储建议使用S3+CDN组合，并保持配置拉取URL与业务服务分离。该方案可在不发版情况下实现域名切换，提升应用可用性。
2026-03-27 17:38:01
6825
原创 2025年终总结与2026年展望
时光荏苒，2025年在机遇与挑战的交织中悄然落幕。这一年，既有职业道路上的重大转折，也有知识沉淀与自我突破的坚实脚步，每一段经历都成为成长路上的珍贵印记。回望全年，有懈怠时的反思，有抉择时的坚定，更有深耕后的收获，现将这一年的经历与感悟总结如下。
2026-01-28 22:11:24
5275
1
原创 TiDB 关联子查询去关联优化实战案例与原理深度解析
本文介绍了TiDB中子查询优化中NO_DECORRELATE Hint的使用场景和效果。当外部查询结果集小(如<100行)且子查询表数据量大(如>10万行)时，默认的关联子查询优化会导致性能下降。通过添加NO_DECORRELATE Hint可以阻止优化器自动关联，保留Apply操作符执行方式，充分利用子查询表的索引。真实案例显示，该优化可使执行时间从67.1ms降至15.6ms(提升4.3倍)，扫描行数从136,851行降至25行，内存占用从11.8MB降至760Bytes。但需注意使用前提：外部查询结
2025-11-12 15:38:51
4153
原创 分页接口重复数据问题的多维度剖析与优化策略
本文分析了分页接口中数据重复问题的三大成因：SQL排序分页的不确定性、数据新增导致的分页位移以及数据删除引发的数据丢失。针对这些问题，提出了三种解决方案：使用唯一列排序、引入首次分页时间参数和基于末尾ID的对比查询。通过比较发现，基于末尾ID的对比分页方法能有效解决所有三种情况下的数据重复问题，为优化分页查询提供了可靠方案。这些方法可帮助开发人员根据不同场景选择合适的策略，确保分页数据的准确性和用户体验。
2025-08-26 20:34:19
4289
原创 ZooKeeper 一致性模型解析：线性一致性与顺序一致性的平衡
ZooKeeper采用分层一致性模型：写操作通过两阶段提交保证线性一致性，而读操作主要遵循顺序一致性。系统通过"单一视图"机制确保客户端不会连接到数据更旧的节点，补充了单调读一致性。这种设计在强一致性和性能之间取得平衡，使ZooKeeper成为分布式协调服务的理想选择。事务操作实现强一致性，读操作在顺序一致性基础上增强会话保证，满足不同场景需求。
2025-08-19 23:57:42
4912
原创 IOT集群扩容实践：问题剖析与解决策略
摘要 本文详细记录了IOT集群扩容过程中遇到的关键问题与解决方案。系统在扩容时出现了三大挑战：1）Kafka消息阻塞导致消费者节点CPU和内存告警；2）设备消息顺序错乱引发业务平台显示异常；3）传统扩容流程存在窗口期风险。针对这些问题，技术团队实施了多项优化：采用设备编号分片的多队列消费机制保障消息顺序性，调整工作线程和集群规模提升消费能力，并设计了包含权重调整的分阶段扩容流程。这些改进不仅解决了当前问题，也为未来实现动态扩缩容奠定了基础，有效提升了系统的稳定性和可扩展性。
2025-06-12 14:06:44
4809
原创 多数据源@DS和@Transactional踩坑之路
随着项目规模的不断扩大，原本的单体应用架构和单一数据库模式已逐渐无法满足日益增长的业务需求。为了更好地应对这一挑战，我们启动了核心服务及相关模块的拆分工作，以实现更高效、灵活的系统架构。然而，在拆分过程中，我们不可避免地遇到了数据源切换这一关键问题。接下来，让我为您详细阐述这一过程。通过这次经历，我们认识到在高并发场景下，合理的事务传播行为与缓存策略对系统性能至关重要。未来，我们将继续优化系统架构，加强监控与预警机制，确保系统的高效运行。
2025-03-21 16:21:50
4879
原创 2024年年终总结与2025年展望
这些宝贵的知识将为我提供坚实的基础，使我在2025年参与B端服务的重构工作中，能够提出切实可行且具有前瞻性的建议，为项目的顺利进行和成功贡献更多的力量。在新的一年里，我将继续努力，不断提升自己的技术能力、业务能力以及综合素质，为团队项目成功贡献更多的力量，为公司创造更大的价值。这些书籍不仅为我提供了深入的技术知识，还激发了我对系统设计和数据管理的新思考。在这一年中，我经历了个人成长和职业发展的双重飞跃，感受到了前所未有的充实与满足。
2025-01-04 16:06:39
3981
1
原创 MySQL千万表归档实践
随着项目数据量的急剧增长，为了优化性能提升产品体验感，我们决定对数据进行归档处理。归档策略为实时数据仅保留6个月，超过期限的数据将被归档至历史表中，在此过程中，我们遇到了数据库主从延迟的问题，下面将进行分析去解决暂停策略是一个临时解决方案，但它在一定程度上缓解了主从延迟问题，保证了归档操作的顺利进行。我们将继续监控数据库性能，并寻求更长期的解决方案，以确保数据的一致性和归档操作的效率。
2024-12-26 19:31:55
6226
原创 MySQL数据库报“You are not owner of thread”错误的解决方法
MySQL数据库报“You are not owner of thread”错误的解决方法
2024-12-12 16:08:45
4572
3
原创 Kafka异常重试方案小记
此外，我们增加了一个Web端的手动重推功能，以便于在需要时手动触发消息的重新处理，若后续异常消息多时可以考虑自动的定时调度。为了进一步增强异常处理能力，我们可以通过自行编码，在消费异常时将相关信息写入日志，或者在消费后立即写入消息，待后续消费成功后再更新其状态。为了解决重平衡期间可能出现的消息丢失问题，我们计划引入JVM钩子，在发版时对当前工作线程池中的消息进行快照，并在后续重新推送这些消息。而在kafka中原本并无死信队列的概念，所以当需要自行封装这一层概念的时候，就可以脱离既定思维的约束，
2024-10-20 17:30:28
5065
原创 MySQL五千万大表查询优化分析实战
对于一个SQL的优化我感触比较深的是：不能仅从SQL本身去进行优化，而需要结合具体的业务进行权衡从而选择一个合适的方案进行优化，目前项目也到高速上升期，出现了很多大表，未来系统将会有更多的问题，当然这即是问题也是挑战，加油！！！
2024-10-09 13:43:29
4033
2
原创 MySQL删除重复记录并且只保留最新一条
在开发过程中，因为某些问题可能会导致同一条数据在表中重复出现，此时我们需要申请权限走SQL去修复，下面介绍下具体修复流程。
2024-08-07 14:51:18
6546
原创 使用Mybatis批量插入大量数据的实践
在项目开发过程中，我们经常会有批量插入的需求，例如：定时统计任务但是受限于MySQL中参数限制，5.7版本默认值为4M，这显然不太符合我们的需求，当然我们也可以通过修改此值来适应我们业务，今天分享在不修改此值的情况下，如何在客户端优雅的处理此场景现在整个世界都变优雅了！
2024-07-05 14:24:32
7634
原创 Mybatis-Plus多种批量插入方案对比
这里先留下一张saveBatch的SQL日志截图，这里的日志是一个insert into语句，下面带了一千条数据(MP默认一千条一个批次)，使用Mybatis Log插件查看还是单条的SQL。再来看看此时控制台的SQL，与方案二的SQL有着明显的区别，这里是将批次插入的数据拼接在同一条SQL中，对于MySQL处理来说，这是真的批量新增。因很早就听闻过mybatis-plus的[伪]批量新增的问题，很快锁定问题并进行修复，下面细节描述多种批量新增方案的具体性能表现。方案一：传统for循环。
2024-06-15 22:37:22
5648
原创 MySQL树形表查询优化
这种方案挺常见，在数据量少的时候可以采用，但是量一旦大了以后呢，性能变差 且 通过Mybatis拼接完SQL以后可能会超长（而通过多线程分批后聚合编码又较为复杂）因为其他方案本质都是通过 IN 来查询数据，虽然还可以进一步对 IN 方案进行优化(例如：业务上多线程分批IN，EXISTS等)，但还是略逊一筹。但这种方式也有个弊端，那就是有的项目上还没用上MySQL8.0，那该如何处理呢？请接着看第四个通用方案。一个代理可以有很多子代理，然后子代理又有子代理，业务要求父代理能看到所有子代理的数据。
2024-05-12 23:27:37
4043
1
原创 日报表定时任务优化历程
报表是一个很常见的需求，在项目中后期往往会需要加多种维度的一些统计信息，今天就来谈谈上线近10个月后的一次报表优化优化之路（从一天报表跑需要五分钟，优化至秒级）思考：报表任务里都是一些MySQL查询 以及 内存循环对比，且门店统计那块是嵌套循环查询，订单的查询时间也有点长。以上流程跑当日耗时大约在4-5分钟，乍一看其实并不慢，但此时距离上线已有九月有余，乍一算这个任务得跑20+小时。心好累，心好累，执行超时，立马查看mysql连接 以及 德鲁伊连接池 的超时参数，果然…不管了，能跑就行，先上线再优化。
2024-05-11 21:02:25
4214
原创 德鲁伊Druid参数踩坑之路
2024/04/16日，业务反馈某个定时统计的数据未出来，大清早排查定位是其统计任务跑批失败，下面给一段伪代码。心好累，心好累，执行超时，立马查看mysql连接 以及 德鲁伊连接池 的超时参数，果然......因此业务是历史遗留的，本着解决问题的思路先将此参数修改大一下，赶紧搞定就下班回家洗洗睡了。其实在这段排查过程中，踩了好几个坑，也被好几个坑给阻碍排查的进度，下面列举下。到这真相大白，赶紧将testOnBorrow改回true，先将问题解决。修改后打补丁继续执行，又又又失败了..........
2024-04-19 14:55:21
3751
1
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人