基于Redis构建系统的经验和教训
这篇文章从实际应用出发，讨论了Redis的优势与局限，并对比了其他海量数据存储方案。作者指出，Redis的有序集合（zset）等丰富数据结构使其在表达业务逻辑时极为高效，特别适合对性能要求高、数据规模可控的场景，比如消息传递系统的收发件箱。 然而，Redis“所有数据必须存放在内存中”的核心设计，直接导致了容量瓶颈和高昂的硬件成本。作者通过计算说明，对于一个百万级用户系统，数据量轻松超过单机内存极限。由此还引发了一系列问题：持久化时fork进程占用双倍内存，Aof日志写盘可能阻塞系统，以及不成熟的主从复制可能因网络抖动产生全量同步，严重消耗带宽。单机架构也迫使开发者在业务逻辑之外，必须额外设计复杂的数据分片方案。 面对海量数据，文章对比了Cassandra、HBase和MongoDB等方案。作者认为纯键值存储（如Cassandra）对结构化数据的表达能力太弱；而像HBase这类系统，其数据模型提供了更有序的组织方式。文章最终提出的观点是：理想的存储方案应当提供基础的有序数据结构，允许开发者通过“实体”加“有序子集”的方式来自然映射业务逻辑，从而在海量数据规模下，实现高效的数据访问与传输。 因此，Redis应定位在小而美的高性能缓存或结构化存储层，而非追求海量数据的存储目标。