假设你正在运营一个分布式限流系统，全公司上百个服务都要经过你分配的"带宽配额"。预算就这么多，但每个服务的真实需求你事先不清楚——有的服务平时风平浪静，促销时流量能翻 10 倍；有的服务每月稳定增长 30%。
你会怎么分配这些带宽？
30 多年前，Van Jacobson 在设计 TCP 拥塞控制时面对的是同一个问题：网络（链路）的带宽是共享资源，发送方不知道链路的当前容量，也不知道有多少其他发送方在抢资源。他必须设计一个让所有发送方在不知道对方存在的情况下，依然能公平、高效地共享链路的算法。
如果你写过监控告警、自适应限流或者负载均衡，大概率遇到过这个问题：怎么用一个数值，实时地描述"当前系统有多慢"？EWMA（Exponentially Weighted Moving Average，指数加权移动平均）几乎是工程实践里的标准答案——它只需要一个 float 的内存，一行加法就能更新，却能给出比简单平均更贴近"当下"的估计。
先看一段栈，再决定要不要继续读——
# 这两份 stack dump 间隔 14 分钟抓的，"jdbc:mysql://10.14.127.31:19030/xxx"
# 的 connection adder 线程，tid 完全一致，栈帧一帧没动。
# 业务侧呢？告警群里全是 SQLTransientConnectionException。说真的，这种栈谁都不想看到——10 个 HikariCP 连接池、每个池的 adder 都卡在 socketRead0，不是忙，是死等。更扎心的是，业务方第一时间甩锅 HikariCP “卡死了”，但 HikariCP 的 MAIN 池好好的；另一边 DBA 看到 MySQL 进程没崩、SHOW PROCESSLIST 也查不出明显异常。两边都没事，问题到底出在哪？
在 Presto/Trino 中，0.5 默认不是 DOUBLE，而是 DECIMAL。这个容易被忽略的字面量类型，会让 bigint * 0.5 这类表达式整体走上 Decimal 算术规则，最终把结果 scale 锁死在 1 位小数。
本文从一个线上"精度丢失"问题切入，逐步拆解 Presto 的类型推导链与 Decimal 四则运算规则，再对比 MySQL 在加减乘除上的差异，最后给出可复用的排查建议。如果你曾在跨引擎或跨团队迁移时被精度问题困扰，这篇文章应该能帮到你。
限流是高并发系统里最朴素的自我保护手段：当流量超过系统承载上限时，主动拒绝或排队部分请求，换取整体稳定。
这篇文章从固定窗口、滑动窗口、漏桶、令牌桶、GCRA 五类经典算法讲起，用 Redis Lua 脚本还原实现细节，再分析 Redisson RateLimiter 的设计本质，最后落到分布式限流的三大关键问题与生产选型建议。如果你正在设计或优化一套限流方案，这篇文章会是一张清晰的路线图。
凌晨 3 点，oncall 电话响了。“服务慢了，用户在刷不出页面。” 你 SSH 进一台从没见过的 Linux 服务器，没有 Prometheus dashboard，没有 APM 火焰图，只有黑漆漆的命令行。
第一分钟该敲什么？
Netflix 性能工程团队 2015 年给出的答案是：10 个命令，60 秒。本文把这套方法整理成一份可以照抄的清单，并补上一张"心智地图"，让你不只是机械记忆命令，而是理解为什么要敲它们、应该看哪几列、看完之后该往哪走。
你有没有遇到过这种场景：线上服务偶发延迟，top 看 CPU 正常、iostat 看磁盘不忙、strace 抓不到关键调用，但应用就是慢。想看某个系统调用真实的耗时分布？想找"一闪而过"的短进程？传统工具集体失灵。
问题的根源在于：Linux 内核对你"关着门"。你想观测的所有关键路径——系统调用、网络收发、调度、文件 I/O——都在内核里，而你已经很多年没编译过内核了。
eBPF（extended Berkeley Packet Filter）就是 Linux 给开发者开的一扇窗。它让你不重启内核、不写内核模块，就能在内核的关键路径上跑一段自定义逻辑。本文用三件事讲清它：eBPF 是什么、怎么工作、怎么先用起来。