写代码的狮子

别再把数据导入当“小功能”了（二）：如何把导入约束成一种系统能力 一、先明确一个现实问题：导入不是“写一次”的功能 在上一篇文章里，我分享了一套 基于缓存的日常数据导入方案，解决了： 同步导入性能问题

为什么我最终 更青睐基于缓存（Redis）的导入方案，以及它背后的工程思考。 一、先纠正一个常见误区：导入 ≠ 大数据处理 提到数据导入，很多人第一反应是： 大数据量 批处理 性能优化 但在大多数业务

一、很多文章里的“订单系统”，一开始就不真实 在不少技术文章中，订单系统的起点往往是这样的： 一个订单表 下单 → 同步调用 ERP 成功 or 失败 但在真实的企业级业务中，订单系统几乎从来不是这样

这篇文章，我只回答一个问题： 一、先给结论：RocketMQ 的线程不是“按 Topic”算的，但很容易“看起来像是” 很多线上事故的根因不是： 而是： 而 实例 ≠ Topic， 但在 Spring

这篇文章不讨论“该不该用 MQ”， 而是结合一次真实业务实践，聊聊： MQ 同步本地缓存到底会在哪些地方失效 为什么这些问题不是 bug，而是设计必然 又该如何在工程上把不可避免的问题关进笼子里 一、

在上一篇文章中，我介绍了在电商核心链路中引入 RoaringBitmap， 解决活动命中计算的性能与内存问题。 但当这部分性能瓶颈被解决之后，一个新的问题很快浮现出来： 这篇文章想聊的，不是 Roar

一、背景 在电商系统中，营销板块有一类非常典型、但性能要求极高的场景： 商品打活动标 到手价计算 这些请求都会涉及： 根据多个规则维度，计算命中了哪些活动。 活动规模并不算夸张： 活动总量：万级 商品