bloom-filter 标签归档

共 8 篇文章 · 返回首页

【身份与访问控制工程】Session、Refresh Token 与吊销体系

JWT 的无状态签发解决了分布式认证的扩展性,但也把吊销这件事推回到了工程师面前。一个短期 access token 配长期 refresh token 的混合架构,在 Google、Auth0、Keycloak、AWS Cognito 的实现里趋同收敛,但细节差异能决定系统在被攻击时是多丢一个账号还是多丢一百万。本文把 refresh token rotation、reuse detection、family-based abort、OIDC back-channel logout、Redis 黑名单、Bloom filter 加速、批量吊销场景拆开讲清楚。

【存储工程】LSM-Tree 工程调优:三种放大的权衡

LSM-Tree 的核心设计是把随机写转换为顺序写,但这个转换不是免费的。写入经过 MemTable 刷盘、再经过多次 Compaction 合并,每一字节的用户数据在磁盘上可能被反复读写数十次。读取一个 key 时,最坏情况下需要逐层搜索,直到命中或遍历全部层级。与此同时,旧版本数据和墓碑标记占用的额外空间,在 Co…

【存储工程】索引结构:从 B+Tree 到倒排索引

数据库里存了一亿行数据,要找出 userid 42 的那一行。没有索引的做法是全表扫描(Full Table Scan)——从第一个数据页读到最后一个数据页,逐行比对。假设每个数据页 16 KB,一亿行占 20 GB,即使顺序读能跑到 500 MB/s,也需要 40 秒。加一个 B+Tree 索引,三次磁盘 I/O 就…

【从零写一个 LSM-Tree 存储引擎】LSM-Tree 全景:为什么要先写日志再排序

从零理解 LSM-Tree 存储引擎的设计哲学:B-Tree 与 LSM-Tree 的本质差异,写放大/读放大/空间放大的三角权衡,以及 WAL、MemTable、SSTable、Compaction、Bloom Filter 各组件的角色与协作关系。从零写一个 LSM-Tree 存储引擎系列第 1 篇。