Redis架构图那些细节没说清楚的地方，带你慢慢捋一捋Redis到底咋搭的

关于Redis架构图那些没明说的细节,咱们一步步来捋清楚，很多架构图就是几个方框加箭头，实际搭建时你会发现里头门道不少。

第一，主从复制不是画个箭头就完事了。 很多图只画了从库指向主库的箭头，但没告诉你这个连接其实挺“脆弱”的，根据《Redis设计与实现》里的描述，从库启动连上主库后，会发一个PSYNC命令，这里有个关键：如果从库中途掉线一会儿再重连，只要条件允许，它能只同步断线期间丢失的数据，不用全量同步，但这个“条件允许”取决于主库的复制积压缓冲区大小，这个缓冲区配置多大，图里可不会告诉你，小了就容易触发耗资源的全量同步。

第二，哨兵（Sentinel）高可用的“坑”在启动顺序和网络。 架构图上经常是三个哨兵实例围着主从节点，但没强调启动顺序，实际你得先启动主库，再启动从库并配置复制，最后才启动哨兵，如果反了，哨兵可能认错主库，哨兵之间要组成集群，它们相互发现靠的是主库上发布的“sentinel:hello”频道，如果网络分区，哨兵集群可能分裂，导致两个哨兵同时认为自己是老大，选出两个主库（脑裂），虽然Redis有“大多数”原则来防止，但网络问题复杂时，架构图里那条简单的线代表的可是一团乱麻。

第三，集群模式下的数据迁移和“跳转”。 Redis Cluster的架构图喜欢画成16384个槽位分给各个节点，很整齐，但当你增删节点，数据要迁移时，客户端访问可能遇到麻烦，一个键原来在节点A，现在要迁到节点B，迁移过程中，客户端如果还访问A，A发现这个键已经不在自己这儿了，它会给客户端回一个“MOVED”错误，并告诉它正确的节点B，客户端得再跳去B拿数据，这个过程如果没处理好，客户端请求就会多一次延迟，更麻烦的是“ASK”重定向，发生在迁移中途，客户端可能被连续重定向，这些流程在静态图里根本看不出来。

第四，持久化与内存的配合。 架构图常把RDB和AOF画在一边，但没说明它们怎么和主线程抢资源，RDB做快照时用子进程，理论上不影响主线程，但如果内存太大，fork子进程瞬间可能让主线程卡一下（因为复制页表），这个卡顿在追求低延迟的系统里很要命，AOF每次写盘，如果配置为“always”，确实安全，但磁盘扛不住；如果是“everysec”，那每秒刷盘，万一这秒内宕机，这一秒数据就没了，这些选择背后的权衡，不是框和线能表达的。

第五，多实例部署在同一机器上的隐形战斗。 为省成本，很多人把多个Redis实例放同一台物理机，架构图可能就画个虚线框标“物理机”，但这样实例会争抢CPU、内存带宽，特别是网络和磁盘IO，如果都做持久化，磁盘写可能成为瓶颈，更隐蔽的是，如果没绑核（CPU亲和性），这些实例可能被操作系统调度到不同CPU核心，缓存失效会导致性能下降，这些资源竞争问题，在逻辑架构图里完全看不见。

第六，客户端那点事。 架构图很少认真画客户端，客户端得有集群意识，知道槽位分布，还要能缓存这个映射表，不能每次都问集群要，连接池怎么管理？是长连接还是短连接？客户端读到“MOVED”错误后，是立即更新本地槽位映射，还是傻傻地继续报错？这些细节决定了整个系统是否真的流畅。

说到底,看架构图就像看地图，它告诉你城市之间有没有路，但没告诉你这条路是高速还是乡道，有没有收费站，会不会堵车，搭Redis，尤其是生产环境，得顺着这些线，把底下这些泥巴石头都挖出来看清楚才行。