寒蝉 Hancic
幂等性：分布式系统里"做两次"为什么不等于"做一次"
幂等性（Idempotency）= 同一操作执行一次和多次产生相同结果。分布式环境下网络超时、消息重投、自动重试逼着操作必须幂等。实现靠"记住做过没有"：request_id 去重表、唯一约束、状态机、乐观锁。幂等和并发安全是两件事——前者管重复不出错，后者管同时不出错。
分类：科技
Profiling 方法论与实战：Python + Rust 双视角
从大盘指标定位维度，到采样定位函数，再到行级追踪——从大到小看，每一步基于上一步的证据。火焰图看平顶不看宽度。Rust 瓶颈往往在算法，Python 在解释器和进程开销。改完用数字确认，P99 达标就停。
技术债务：复杂度的复利
技术债不是因为决策做错了，是条件变了之后当初合理的决策不再合理。不是所有债都该还——利息高的该还，利息低的该背，架构级的才值得专门花时间。没有专职管理员，靠写代码的人顺手还、技术负责人盯大债。
认证与鉴权选择指南：JWT、OAuth 2.0、RBAC、ABAC、Keycloak 各自该出现的地方
一个服务刚上线，没用户，没登录。调用方都是内部系统，相互信任——IP 白名单就够了。 后来用户来了。要区分谁是谁。再后来有管理员、有普通用户、有只读用户。角色一多，权限判断就散在代码里——if user.role == 'admin' 写了二十遍，改一次要改二十个文件。 这时候你才开始看认证鉴权方案
压缩算法选择指南：LZ4、Snappy、gzip、Brotli、Zstd
一个服务每天往外吐几十 G 日志。你第一反应不是「换个压缩算法」，是「太大了，压一下」。 gzip -9 access.log，跑完一看，体积缩到十分之一。满意了。 后来日志量翻倍，gzip 跑一次要二十分钟。你开始想：能不能快点。 再后来上了 Kafka，消息要实时传。压缩不是在磁盘上慢慢压——每
【量化系统从0到1】回测引擎：性能不是难点，语义才是
回测引擎的主线不是"跑得快"而是"把 A 股语义做对"：自研 142 行撮合核心、价格口径必须自洽（后复权修掉除权日假跳变）、费用用 Decimal 精确到一分钱、验证逼出三个 bug——以及 Rust 为什么最终没有写（50 票实测 0.3 秒，全市场按线性外推约 30 秒）。
【量化系统从0到1】存储架构：不选择什么，比选择什么更重要
个人量化系统的存储选型：先刻画数据特征，再推导方案——行情/因子用 parquet、财务/任务用 SQLite、元数据用 JSON。不选择什么比选择什么更重要：DuckDB、PostgreSQL 被排除的理由，以及它们的触发条件。
重试机制选择指南
调用一个外部服务失败了，第一反应是再试一次。这个直觉没错，但「再试一次」从一句代码到生产可用的重试策略，中间隔着好几层坑——每一层都是被上一层的代价逼出来的。 起点：固定次数重试 最直觉的做法：失败就重试，重试 N 次，还不行就放弃。 for i in range(3): try: return c
API 限流方案选择指南
限流是个听起来很简单的问题：请求太多，挡一挡就行。但真到实现的时候，你会发现「怎么挡」的答案一直在变——被业务规模一层层逼着升级。 起点：固定窗口计数器 最直觉的方案：在内存里记一个计数器，当前这一秒来了多少请求，超过阈值就拒。 伪代码，不是让你抄 counter = 0 windowstart =
一个简单操作是怎么在分布式环境下变复杂的
最近碰到一个问题，事后想想，很适合拿来讲分布式系统里一个很普遍的现象：一个在单节点上简单到不用过脑子的事，放到多节点环境下，复杂度会一层一层地叠上去，每加一层，就多一类你绕不开的问题。 单节点：两个 if 的事 需求是这样的：用户请求来了，需要从 S3 拉一份代码到本地，解压，然后执行。 为了避免同
