Hash 表的性能通常取决于两件事：冲突发生后如何找下一个候选位置，以及这些候选位置离缓存有多远。传统链式哈希把冲突元素串成链表，逻辑简单，但一次查询可能要跳过多个指针；普通开放寻址没有指针跳跃，却常常只能逐个 slot 检查。
Swiss Table 的核心贡献是在开放寻址表前面加了一层非常小的元数据，让 CPU 能按 group 批量排除大量不可能匹配的 slot。它不改变 hash 表的基本语义，而是改变查找、插入、删除时的观察方式：先用极小的哈希指纹过滤，再对少数候选 key 做精确比较。
这个设计来自 Google 的工程实践，后来成为 Abseil flat_hash_map 的底层实现，也被 Rust 标准库 HashMap 采用。Go 1.24 之后，内置 map 的默认运行时实现也切换到了 Swiss Table 风格。
百分位数是描述数据分布最常用的指标之一:P95、P99 告诉你接口长尾延迟,中位数告诉你"典型"水平。SQL 标准为精确计算提供了 PERCENTILE_CONT 和 PERCENTILE_DISC,大数据引擎则普遍内置了以 sketch 为核心的近似算法。本文从原理出发介绍这些函数与算法,给出每种算法的伪代码,并配上可以手算验证的例子。
假设你正在运营一个分布式限流系统，全公司上百个服务都要经过你分配的"带宽配额"。预算就这么多，但每个服务的真实需求你事先不清楚——有的服务平时风平浪静，促销时流量能翻 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 的设计本质，最后落到分布式限流的三大关键问题与生产选型建议。如果你正在设计或优化一套限流方案，这篇文章会是一张清晰的路线图。
