共 84 篇相关文章
这篇讲的是 Redis RDB 持久化的底层实现。作者从 RDB 与 AOF 的基本概念切入，随后迅速深入核心，剖析了负责持久化 IO 操作的关键数据结构 `struct rio`。 文章的亮点在于对 `rio` 结构的拆解。它巧妙地通过函数指针（如 `read`、`write`）抽象了读写行为，并用一个 `union` 联合体统一了对内存缓冲区和文件的处理，使得一套代码能同时服务于内存缓存和磁盘文件两种场景，设计上颇具巧思。 接着，作者以 `rdbSave()` 函数为主线，通过代码注释的方式，清晰地勾勒出整个 RDB 写文件的流程：从创建临时文件、初始化 `rio` 结构，到遍历每个数据库、写入操作码和数据项。这个过程不仅解释了数据是如何被序列化到磁盘的，也揭示了 BGSAVE 等后台操作的基础——主进程 `fork` 出子进程来执行这个主逻辑，从而避免阻塞服务。 对于想了解 Redis 如何将内存数据“快照”到硬盘的开发者而言，这篇文章提供了一个从数据结构到执行流程的清晰视角。
还在为数据库和文件备份的手动操作感到繁琐吗？作者用 Python 开发了 yunbk 这个简洁的备份插件，让数据备份变得像写几行代码一样简单。它的核心思路是通过一个统一的 `with` 上下文管理器，在临时目录中完成所有备份文件的写入，调用 `backup()` 后便自动上传至配置的后端存储，最后彻底清理现场，不留痕迹。 这个插件最大的优点是灵活性和易用性。通过提供本地、FTP、阿里 OSS 等多种后端适配器，开发者可以轻松地将 MySQL、Redis 等数据库，或是任意媒体目录备份到不同位置。文章中给出了几个清晰的代码示例，比如仅需几行就能完成 MySQL 全库的本地备份。作者还推荐结合 APScheduler 实现定时自动化备份，给出了一个完整的调度脚本，让整个备份方案更加实用和落地。
这篇讲的是 Redis 中为了极致节省内存而设计的压缩链表 ziplist 的实现细节。作者从 Redis 的 list 结构有两种底层实现（普通双链表和 ziplist）切入，重点剖析了后者。 ziplist 的核心巧妙之处在于，它用一段连续的内存空间模拟了双向链表的功能，从而省去了每个节点额外的前驱和后驱指针开销（每个指针8字节）。文章详细拆解了 ziplist 的整体格式以及每个 entry 的 TLV（类型-长度-值）结构，特别是通过 `prelen` 字段记录前一项的长度来实现反向遍历，通过精心设计的 `encoding` 字段对不同长度的字符串和整数进行紧凑编码。 通过分析 `ziplistFind()` 函数的源码，文章展示了 ziplist 如何进行数据查找与比较。最后，文章点明了 ziplist 在 Redis 中的实际应用场景（如 Hash 结构在数据量小时的底层存储），并解释了它的性能优势：紧凑的线性内存布局不仅节省空间，还可能更好地利用 CPU 缓存，使得在数据量较小时，其查找性能甚至可以媲美哈希表。
这篇深度技术文章从源码层面拆解了 Redis 的核心数据结构——字典（dict）。作者首先指明，Redis 的每个数据库（db）本质上由两个哈希表（dictht）构成，真正存储键值对的是这两个表。文章重点剖析了 Redis 哈希表设计最精妙的部分：为何需要两个哈希表，以及如何利用它们实现 **渐进式 rehash（重哈希）**，从而在服务不中断的前提下完成表的扩容。 具体实现上，当触发扩展时，Redis 会为第二个哈希表分配新空间，并在后续的每次增删改查操作中，分批次地将数据从旧表迁移至新表。文章结合源码（`dictRehash` 函数）展示了这一“逐步搬家”的过程，并点明了其背后的设计考量：在服务器空闲时，定时任务会推进 rehash；在高负载时，操作本身的开销也会承担部分 rehash 工作，以此平衡性能。 此外，文章还分析了这种设计带来的“副作用”：由于查找操作需同时兼顾两个表，加上写操作本身包含多次查找，导致 Redis 在执行 SET 等写命令时效率并不高，这也从底层解释了其“重读轻写”的特性。最后，文章简要介绍了在涉及持久化（如 RDB/AOF）遍历哈希表时，也需要正确处理这两个表的过渡状态。全文逻辑清晰，从结构定义到核心算法，再到其对上层行为的影响，层层递进，非常适合想深入理解 Redis 高性能背后实现细节的开发者。
这篇讲的是Redis有序集合ZSet背后的灵魂——跳表（skiplist）。作者从Redis源码出发，一层层拆解了这个经典数据结构。 文章首先点明跳表的核心价值：它用空间换时间，通过预先在有序链表上建立多级“索引”，实现了类似二分查找的高效查询。Redis正是利用它来支撑ZSet的排序和范围查询操作。 更精彩的部分在于对Redis具体实现的剖析。文章不仅给出了核心结构体`zskiplistNode`和`zskiplist`的定义，还深入到了插入和删除操作的算法细节。比如，插入时如何随机生成新节点的层数，以及如何通过`update`数组和`rank`数组来精确地调整每一层的前驱指针和`span`值。`span`这个设计很巧妙，它记录了两个节点之间跳过了多少元素，是实现按排名查询的关键。 作者没有停留在理论，而是结合代码注释，把查找、插入、删除的完整流程都梳理了一遍。从概念到实现，从宏观到微观，清晰地展现了Redis是如何用这套机制来保障其高性能的。对于想理解Redis内部原理的开发者来说，这篇源码分析对数据结构的剖析很到位。
这篇讲的是 Redis 事务的内部运作原理。作者从 MULTI、EXEC、DISCARD、WATCH 四个基础命令入手，但不止步于表面用法，而是深入到服务端源码，揭秘了事务背后的命令队列机制。 核心在于理解 Redis 的单线程模型。当客户端发送 MULTI 后，后续命令并不会立即执行，而是被服务端通过一个 `multiState` 结构体缓存在命令队列中。文章详细展示了 `multiCmd` 和 `multiState` 的结构，并结合 `processCommand` 函数的代码，清晰说明了命令是如何在“入队”和“执行”两个状态间切换的。 另一个巧妙之处是 WATCH 命令如何实现类 CAS（检查并设置）功能。文章通过对比有无 CAS 特性的表格例子，生动解释了并发修改的冲突场景。随后剖析了 `watchForKey` 等函数，展示了 Redis 如何通过监视键值对，在事务执行前检测到数据变化，从而自动取消事务，保证了操作的原子性。 整体来看，文章将事务机制拆解为命令缓存和乐观锁两个核心，并提供了关键的数据结构和源码片段，让读者能从实现层面真正理解 Redis 事务“一次性、顺序执行”的特性是如何保障的。
这篇讲的是 Redis 中整数集合 intset 的底层实现细节。当 set 中所有元素都是整数时，Redis 会优先使用 intset 这种紧凑的数据结构，只有遇到非整数时才升级为更通用的 dict。作者深入源码，拆解了 intset 如何做到高效存储与操作。 intset 本质是一个有序、不重复的整型数组。它的精巧之处在于通过 `encoding` 字段动态记录当前数组中整数的位宽（16、32或64位），从而在保证功能的前提下极致节省内存。查找操作直接利用数组的有序特性，采用经典的二分查找算法，效率很高。 文章的重点和亮点在于对插入过程的剖析。当插入的新整数超出了当前编码范围（例如向一个全是 16 位整数的集合插入一个 32 位整数），intset 不会简单拒绝，而是会触发一次“编码升级”（`intsetUpgradeAndAdd`）。升级过程非常巧妙：它会重新分配内存，将现有所有元素转换为新编码，并逆序移动元素以避免数据覆盖。由于新整数必然是最大或最小值，最终将其放置在数组头部或尾部即可。这种按需升级的设计，平衡了内存效率与灵活性。 整体来看，intset 是一个为特定场景高度优化的微型数据结构。它通过有序数组+二分查找+动态编码升级，为 Redis 提供了一个内存极其友好且高效的整数集合实现，是理解 Redis 空间优化哲学的一个绝佳范例。
作者从统一游戏后台架构的需求出发，尝试使用Celery任务队列，并分别以RabbitMQ和Redis作为消息代理，来探索这套方案能否替代以前自研的C++ server通信模式。文章详细记录了在macOS下通过Homebrew安装RabbitMQ、启用其管理插件，并配置Redis和Celery的过程。 随后，作者通过一个简单的“加法”任务，对两种消息代理的性能进行了初步对比。在相同配置下，使用RabbitMQ时任务完成耗时约0.545秒，使用Redis时则约0.604秒。结果显示，在这个简单场景中两者的性能表现相近。 这篇文章为考虑引入任务队列的团队提供了一个具体的实践起点，展示了如何快速搭建并初步评估Celery+RabbitMQ或Celery+Redis这一组合。作者也指出，这只是初步测试，后续还需要对更多复杂场景和更高并发下的性能进行深入验证。
这篇讲的是 Redis 存储键值对的核心底层数据结构，从源码层面剖析了其设计与巧妙的权衡。文章从全局视角出发，逐一介绍了 dict 哈希表、可变类型的 redisObject、高效插入删除的 zset（跳表+哈希表组合）、经典的 adlist 双链表，以及为优化 CPU 缓存和内存而生的压缩列表 ziplist 和整数集合 intset 等关键结构。 不止于理论，作者更将这些结构与具体的 Redis 命令联系起来，清晰地展现了不同场景下的选择逻辑。比如，SET 命令对应最简单的 sds 或数值类型；HSET 和 LPUSH 在特定条件下会使用紧凑的 ziplist 而非链表；SADD 会根据元素是否全为整数，在 intset 和 dict 之间动态切换；而 ZADD 有序集合则综合运用了 skiplist 和 dict，或采用 ziplist，具体取决于配置阈值。 这种从底层实现到命令行为的串联分析，揭示了 Redis 在性能与内存之间精妙平衡的设计哲学。作者提到这只是系列开篇，后续将逐一深挖每个结构，值得对 Redis 内部机制感兴趣的技术人持续关注。
这篇讲的是 Redis 在内存紧张时如何选择“淘汰谁”的策略。当数据集大小超过 maxmemory 限制时，Redis 会启动数据淘汰机制，而策略的选择直接关系到服务的稳定性和数据的访问模式。 文章梳理了 Redis 提供的六种策略。核心思路分为三类：针对设置了过期时间的键（volatile）进行 LRU（最近最少使用）、TTL（最快过期）或随机淘汰；针对所有键（allkeys）进行 LRU 或随机淘汰；以及完全禁止驱逐。作者重点剖析了 LRU 和 TTL 两种机制的实现细节。 有趣的是，Redis 的 LRU 并非一个严格的全局算法。它维护了一个每分钟更新的服务器级 lruclock，在每次淘汰时，会从数据集中随机抽取一批键（由 maxmemory_samples 控制），然后只在这批“样本”中找出 LRU 值最大的那个进行淘汰。TTL 策略的实现方式也类似，是随机采样后淘汰剩余存活时间最长的键。这是一种在性能与效果之间做出权衡的巧妙设计，牺牲了绝对的精确性，换来了极低的计算开销。 文章通过源码揭示了 freeMemoryIfNeeded() 这个核心函数的工作流程：每次执行命令后检查内存，若超标则根据配置的策略，遍历数据库，通过采样找出要驱逐的键值对并删除，同时将此操作同步到 AOF 和从库。理解这些机制，能帮助我们更好地配置 Redis，在缓存命中率、内存使用和性能之间找到最佳平衡点。
这篇讲的是中国互联网长达20年的“C2C”发展路径，即从美国复制商业模式的历程。作者深入剖析了这一现象背后的深层逻辑，指出其核心驱动力是风险投资（VC）的运作需求——通过对标一个已被验证的美国成功案例（如“中国的Facebook”），来降低投资者的风险感知并为最终的赴美上市铺平道路。 但文章并未止步于“简单抄袭”的论断。作者进一步指出，成功的C2C实践都伴随着深度的“Glocalization”（全球本土化）。从门户网站为适应中国网民习惯而开创的“海量快速”编辑模式，到百度依赖线下代理和网吧预装的地推打法，再到淘宝基于中国零售业现状对eBay模式的颠覆性改造，乃至QQ在虚拟道具盈利上的原创，这些案例无不体现了基于本土环境的微创新甚至彻底重构。 最终，随着互联网从“信息”深化到“人”，中美用户行为的差异愈发显著。作者观察到，纯粹的复制已难以为继，反而是具备强本地化能力或原生创新的模式（如微信生态、互联网金融）开始引领新阶段。这篇文章为我们理解中国互联网的商业基因提供了一个历史视角，也启发我们思考：在今天的出海或本土竞争中，单纯的模式借鉴已远远不够，对用户与市场的深刻理解才是关键。
这篇讲的是一个Redis内存突然暴增导致宕机的排查案例。作者从服务器异常消耗几十G内存、最终因SWAP宕机说起，一开始和DBA同事以为是有大键占用了空间，但用工具分析后排除了这个可能。 问题随后转向了另一个方向：即使单个键不大，但大量相同模式的键累计起来，占用的空间也可能非常可观。作者最初想用 `KEYS` 配合 `DEL` 命令批量删除可疑键，结果因为数据量太大，`KEYS` 命令直接让服务器再次崩溃——这暴露了KEYS命令在生产环境中的巨大风险。 最终，作者改用支持游标迭代的 `SCAN` 命令，通过PHP脚本分批扫描并删除目标键，同时监控内存变化，成功锁定了问题源头。整个过程也强调了一个运维要点：除了关注大键，监控Redis键总数的变化幅度同样重要，这能帮助及早发现类似批量写入导致的隐患。
这篇是面向初者的Redis全景指南，从安装启动讲起，一直深入到核心数据结构、持久化机制和生产配置。文章不止停留在“是什么”，更用大量实际命令演示了如何操作。 作者将Redis的五种数据结构——字符串、列表、集合、有序集合与哈希——拆解开来，配合代码示例讲明各自的用法与底层特性。比如，他指出lists在底层是链表，因此头部尾部操作是常数时间，但随机定位较慢，并以此引出其在消息队列等场景的应用优势。 在掌握基础后，教程进一步引导读者理解RDB与AOF两种持久化的原理与选择，主从同步的机制，乃至事务处理。最后对redis.conf配置文件的逐项解读，让初学者也能看懂并调整安全、性能与限制相关的参数。 整个系列循序渐进，覆盖了从“跑起来”到“用得好”的关键知识点，对于希望快速上手并扎实理解Redis的新手来说，是一份非常友好的实战手册。
作者翻阅了《七天七数据库》一书后，结合自身多个项目从MySQL迁移到NoSQL的实际需求，分享了一套具体的数据库选型方案。他指出，不同的业务场景需要不同的数据库来发挥最大价值。 对于社区网站中复杂的关系数据（如用户关注、图片关联），他摒弃了传统关联表，选择了原生支持图关系的Neo4j，这不仅简化了数据模型，也提升了查询性能和开发体验。而面对网站丰富且结构多变的内容模型（如用户、站点），他看中了MongoDB对复杂索引查询的良好支持，认为其能完美替代MySQL的大多数功能，并可能简化缓存层，甚至取代部分Redis的角色。 在处理高写入、弱一致性要求的微博本地缓存时，他对比后认为Cassandra在写性能和可用性上优于MongoDB。对于极高并发的API服务，他则在Cassandra和Riak之间权衡，前者在列式存储和写性能上可能更具优势。 整篇文章从具体业务痛点出发，详细对比了不同NoSQL数据库在一致性、查询能力、性能及运维复杂度上的关键差异，并给出了清晰的选型结论。这为同样面临类似技术过渡的开发者，提供了一个非常实用且可参考的架构思路。
这篇文章探讨了在单机环境下，如何通过unix socket来优化php-fpm、mysql和redis的连接性能。作者从图虫服务器的单机运行现状出发，指出即使使用127.0.0.1本地IP，连接仍需经过TCP/IP层，引入不必要的开销；对于像图虫这样单机日处理2000万+动态请求的服务，切换到unix socket能直接绕过网络栈，实现更快的本地通信。 文章通过一个简单测试展示了立竿见影的效果：200次redis请求耗时从38ms降至27ms，这10毫秒的差距在高并发场景下足以驱动优化。配置方法也被详细列出——对于mysql(PDO)，需在DS
这篇讲的是大型网站（以淘宝为例）中一种令人头疼的故障——“会话串号”，即用户意外登录到他人账号的现象。作者基于亲身的运维经历，剖析了几起真实案例。 文章首先区分了两种串号场景：一种是系统BUG导致的，用户不仅能看到别人页面，还能进行操作；另一种是缓存导致的，用户只能看到别人的页面但无法操作。重点在于前两种技术性串号：第一起源于Jboss的Tomcat在解析Request参数时存在BUG，可能读取到脏数据导致登录串号；第二起则是店铺系统在静态化改造时，缓存服务器错误地缓存了包含Set-Cookie的HTTP头，导致用户获得了一个他人的SessionID。 排查这类问题周期很长，因为难以重现且不易定位根因。为此，文章提出了一种主动防御思路：在Cookie中增加一个签名值，并在服务端会话框架中校验该签名。一旦检测到客户端与服务端的签名不一致，就清空会话并强制用户重新登录。这套机制旨在快速发现并阻断串号，将被动排查转为主动防御。
这篇讲的是Redis的HGETALL命令可能引发的性能陷阱。作者从亲身踩坑经历出发，描述了在HASH字段从十几个扩展到一百多个，并使用Pipelining批量获取时，意外导致服务器宕机的过程。 问题的根因在于Redis的单线程模型：当执行HGETALL时，Redis必须遍历每个字段来获取数据，其消耗的CPU时间与字段数量成正比。配合Pipelining一次性发起大量HGETALL请求，单个线程被长时间占用，从而阻塞了所有其他命令，导致服务不可用。 文章随后分析了三种解决思路：引入多线程的Memcached作为缓存层；部署多个Redis实例以利用多CPU核心；或采用序列化字段冗余，将多个字段合并为一个“all”字段存储，从而将多次HGETALL简化为一次HGET，大幅减少操作数。作者最终指出，技术坑就是用来踩的，重要的是从中爬出来并找到解决方法。
这篇讲的是如何为网站设计用户成长体系。作者从几个国内典型网站出发，拆解了它们各自的成长体系设计思路与背后的逻辑。 文章对比了微博、QQ、豆瓣、知乎等平台的做法。比如，微博的成长体系紧密围绕其媒体战略，通过粉丝量、V认证和勋章来塑造和展示“牛人”，核心是满足用户的自我营销需求。腾讯QQ则依靠在线时长累积成长值，并结合虚拟币（Q币）消费，驱动力更多源于用户在社交圈中的虚拟身份满足感。相比之下，豆瓣的成长体系最为“隐藏”，它通过“小豆”和内容推荐，让用户在兴趣参与中自然体现价值，而非刻意追求等级，这体现了其产品气质。 作者指出，没有普适的公式，成长体系必须服务于产品定位。淘宝的等级与积分直接绑定交易，是电商驱动交易的典型；而知乎通过邀请码的稀缺性和基于专业认可的“关注”，构建了高质量社区的门槛。这些案例共同揭示了一个核心：好的成长体系，是将平台的商业目标与用户的核心价值感巧妙融合，无论是社交荣耀、内容贡献还是实际利益。
这篇文章从实际应用出发，讨论了Redis的优势与局限，并对比了其他海量数据存储方案。作者指出，Redis的有序集合（zset）等丰富数据结构使其在表达业务逻辑时极为高效，特别适合对性能要求高、数据规模可控的场景，比如消息传递系统的收发件箱。 然而，Redis“所有数据必须存放在内存中”的核心设计，直接导致了容量瓶颈和高昂的硬件成本。作者通过计算说明，对于一个百万级用户系统，数据量轻松超过单机内存极限。由此还引发了一系列问题：持久化时fork进程占用双倍内存，Aof日志写盘可能阻塞系统，以及不成熟的主从复制可能因网络抖动产生全量同步，严重消耗带宽。单机架构也迫使开发者在业务逻辑之外，必须额外设计复杂的数据分片方案。 面对海量数据，文章对比了Cassandra、HBase和MongoDB等方案。作者认为纯键值存储（如Cassandra）对结构化数据的表达能力太弱；而像HBase这类系统，其数据模型提供了更有序的组织方式。文章最终提出的观点是：理想的存储方案应当提供基础的有序数据结构，允许开发者通过“实体”加“有序子集”的方式来自然映射业务逻辑，从而在海量数据规模下，实现高效的数据访问与传输。 因此，Redis应定位在小而美的高性能缓存或结构化存储层，而非追求海量数据的存储目标。
这篇讲的是Redis命令行操作的全面指南。作者从连接数据库、基本键操作出发，系统梳理了对String、List、Set、Zset（有序集合）、Hash这五种核心数据类型的所有常用命令。 它不只是罗列，而是结合了具体的场景。例如，SET/GET用于基础的键值存取，SADD/SMEMBERS用于集合成员的增减与遍历，ZADD/ZRANGE则用于需要按分数排序的场景。文章还涵盖了持久化（如SAVE/BGSAVE）和远程服务器控制（如INFO/MONITOR）等运维命令。 对于Redis使用者来说，这就像一份随时可查的“命令字典”，将官方文档中分散的命令按功能和数据类型组织起来，提供了清晰的参照。无论是初学者熟悉接口，还是开发者日常查阅特定命令的用法，都能从中快速找到答案。
