Kafka团队的"找数据难"风波：为啥查个余额要翻遍整个账本？
2016年某天，Kafka团队的程序员们集体掉头发——因为用户总在问："我就想查张三现在账户余额，为啥非得把银行十年流水账全翻一遍？" 这就像你去ATM取钱，机器非要你从开卡第一笔交易开始回忆，简直离谱！
问题出在哪？
Kafka本来是个"流水账大师"，专门擅长：
- 按顺序记录交易（比如张三存100，李四转50）
- 超高效率记新账（每秒能写百万条记录）
但它有个致命缺陷：查单个数据像大海捞针。因为没有"目录索引"，要查张三余额就得扫描整个数据库，可能得读几个G的数据！就像图书馆没图书检索系统，找本书得从第一本翻到最后一本。
️ 三选一的难题
团队面临三个方案：
1. 加索引（但会拖慢记账速度，自废武功）
2. 让用户自己导数据到数据库（太麻烦，被骂风险+10086）
3. 偷偷塞个"小账本"进去（最终选择）
他们选了方案三，在Kafka内部藏了个叫RocksDB的"智能电子账本"。这个账本特点是：
- 能秒查任何人余额（比如输入"张三"直接显示结果）
- 但只存在一台电脑里，电脑坏了账本就没了
于是又搞了个"账本备份系统"（changelog主题），每次更新都要：
1. 记到主账本 → 2. 抄到备份账本 → 3. 还要复制到其他服务器
结果一条交易数据要被反复抄十几次！
其他公司的同款烦恼
亚马逊的DynamoDB也遇到类似问题。用户总想："帮我找出所有未发货订单"，但系统只会按订单号查。他们的解决方案是搞"影子账本"（GSI），本质是：
- 自动创建副账本（比如按订单状态分类）
- 主账本更新后，异步更新副账本（可能有延迟）
- 每个副账本都要单独算钱！
核心矛盾
所有分布式系统都面临"鱼和熊掌"难题：
- 要查询快？得建索引
- 要写入快？就别建索引
就像你不能要求博尔特：
1. 保持百米冲刺速度
2. 同时能随时停下来回答记者问题
血的教训
某公司给DynamoDB加了5个索引后发现：
- 原本1秒能写1000条数据
- 现在实际只能写200条（因为要同步更新所有索引）
- 还经常出现"刚改完密码却查不到"的灵异事件
✅ 正确姿势
加索引前先灵魂三问：
1. 是不是真的每天都要用这个查询？
2. 能不能接受查到的数据是5分钟前的？
3. 准备好为这个功能多付3倍服务器钱了吗？
记住：在分布式系统里，没有"简单加个索引"这种事，只有"再维护一个数据库"的觉悟！就像给汽车加飞行功能——不是装对翅膀就能解决的。
极客辣评：
“明细”与 “汇总”的本质冲突。