共 3 篇相关文章
这篇讲的是Redis的HGETALL命令可能引发的性能陷阱。作者从亲身踩坑经历出发，描述了在HASH字段从十几个扩展到一百多个，并使用Pipelining批量获取时，意外导致服务器宕机的过程。 问题的根因在于Redis的单线程模型：当执行HGETALL时，Redis必须遍历每个字段来获取数据，其消耗的CPU时间与字段数量成正比。配合Pipelining一次性发起大量HGETALL请求，单个线程被长时间占用，从而阻塞了所有其他命令，导致服务不可用。 文章随后分析了三种解决思路：引入多线程的Memcached作为缓存层；部署多个Redis实例以利用多CPU核心；或采用序列化字段冗余，将多个字段合并为一个“all”字段存储，从而将多次HGETALL简化为一次HGET，大幅减少操作数。作者最终指出，技术坑就是用来踩的，重要的是从中爬出来并找到解决方法。
这篇讲的是大型互联网平台实验系统中，一个关键但容易被忽略的技术点：如何让多个AB实验在同一用户身上互不干扰地并行运行。 作者从实验平台的实际挑战出发：当公司内同时进行数十个甚至上百个实验时，不同实验层之间的流量如何划分才能保证数据的纯净与正交？文章没有停留在简单的“按比例随机”这种初级方案上，而是详细拆解了基于hash计算的多层切分实现。核心思路是对用户ID等唯一标识进行多次hash运算，生成不同的伪随机值，分别用于决定该用户是否进入某个实验层、具体落在哪个流量桶。这样，理论上任何两个不同实验层的流量分配都是相互独立的。 文章不仅给出了算法原理，还结合具体业务场景（比如不同实验层可能有着不等比例的流量需求）进行了说明。这种设计确保了实验结果的可对比性和统计显著性，是构建可靠、可扩展实验平台的基础设施。对于需要处理复杂实验矩阵的工程师来说，其中关于hash函数选择与流量正交性的讨论，提供了直接的工程参考。
这篇梳理了Key-Value数据库的“前世今生”。从Unix早期的dbm说起，带读者回顾了gdbm、ndbm、sdbm、cdb等一脉相承的经典实现，也提及了功能强大的Berkeley DB与近年备受关注的qdbm。 作者没有止步于罗列，而是指出了一个关键洞察：这类数据库本质上并非传统意义上的“数据库”，其核心价值在于提供一种极其简单、高效的数据存储与读取功能。这种对技术本质的界定，能帮助开发者在项目初期更清晰地判断技术选型的方向。文章虽短，但脉络清晰，点明了这类轻量级存储引擎的定位。
