Redis怎么搞互联网之间的数据同步，两个Redis互相同步的那些事儿

关于Redis怎么搞互联网之间的数据同步,也就是两个Redis互相同步的那些事儿，这事儿说白了就是让两个不在同一个地方的Redis数据库里的数据保持一致，一个变了，另一个也跟着变，这在互联网应用里非常常见，比如你有两个机房，一个在北京，一个在上海，你肯定希望两个机房的Redis数据是一样的，这样无论用户访问哪个机房，看到的数据都是最新的。

Redis自己提供了几种主要的机制来做这个事,但各有各的适用场景和特点，根据Redis官方文档和一些技术社区的普遍认知，比如像Redis Labs（现在叫Redis Ltd.）的博客、Stack Overflow上的高赞回答以及《Redis实战》这类书籍中的描述，主要的方法有以下几种：

第一种，也是最基本、最常用的，叫主从复制。

这个最好理解,就是指定一个Redis当“老大”（主节点，Master），另外一个或者几个Redis当“小弟”（从节点，Slave），规矩很简单：小弟只能听老大的。

• 怎么工作？ 一开始，小弟会连上老大，说：“大哥，把你这儿现在所有的数据都给我一份。”这个过程叫全量同步，老大就会把自己内存里某个时间点的所有数据做个快照（这个快照就是RDB文件），发给小弟，小弟清空自己的数据，然后加载这份快照，从这以后，老大只要一有新的写命令（比如SET, DEL这些），就会立刻把这些命令自己也发一份给所有连着的小弟，小弟收到命令后，就在自己这边执行一遍，这样，只要网络不中断，小弟的数据最终总是和老大保持一致。
• 用在哪儿？ 这种模式最常见了，主要用来做读写分离，也就是说，所有的写操作都只能去主节点做，而读操作可以分散到各个从节点上去做，这样就能大大减轻主节点的压力，提升整个系统的读性能，它也提供了数据的备份，万一主节点宕机了，从节点上还有一份完整的数据。
• 要注意啥？ 这种同步是异步的，意思是，老大执行完写命令、回复客户端成功后，才会去把命令发给小弟，这中间有个极短的时间差，所以有可能出现客户端在主节点写成功了，但立刻去从节点读，读到的还是旧数据，这在一些对一致性要求极高的场景下需要注意，如果网络断了一会儿又恢复了，Redis从2.8版本开始支持部分重同步，也就是只同步断线期间丢失的那部分命令，而不需要全量同步，这比以前高效多了。

第二种，更高级一点的，叫哨兵模式。

主从复制挺好,但有个大问题：万一老大（主节点）宕机了，整个系统就不能写了，因为小弟们不能接收写命令，这时候就需要有人能自动发现老大挂了，然后从剩下的小弟里面选一个新的老大出来，让其他小弟都去听新老大的，这个“监工”和“选举官”的角色，就是Redis哨兵。

• 怎么工作？ 哨兵本身也是一个或多个独立的Redis进程（不存储数据），它们的主要任务就是不停地监控所有的主节点和从节点是否正常运行，如果某个哨兵发现主节点失联了，它不会立刻行动，而是会告诉其他哨兵：“哎，我感觉老大好像不行了。”其他哨兵也会去确认，当足够多的哨兵（这个数量可以配置）都认为主节点确实挂了，它们就会协商投票，从剩下的从节点中选出一个最合适的（比如数据最新的那个）来晋升为新的主节点，哨兵会通知其他的从节点和客户端，让从节点去连接新的主节点，让写请求也发到新的主节点上。
• 用在哪儿？ 任何需要高可用性的主从复制场景，简单说，就是给你的主从架构加了一个自动故障转移的能力，让系统在主节点故障时能自动恢复，不需要人工干预，大大提高了系统的可靠性。
• 要注意啥？ 配置会稍微复杂一点，因为要部署多个哨兵实例来避免哨兵自己成为单点故障，选举新主节点的过程中，系统会有短暂的不可用。

第三种，用于大规模和更复杂需求的，叫Redis集群。

当你的数据量非常大,一台机器的内存都装不下了，或者你需要的写并发非常高，一个主节点扛不住了，这时候主从复制和哨兵模式就有点力不从心了，你需要把数据分散到多台机器上去，这就是Redis集群要解决的问题。

• 怎么工作？ Redis集群把所有的数据分成了16384个槽位，你可以想象成一个大表格有16384个格子，集群里有多个主节点，每个主节点负责管理一部分槽位（比如节点A负责0-5000号槽，节点B负责5001-10000号槽），当你存一个数据时，Redis会用一个算法根据key算出它属于哪个槽，然后把这个数据存到管理那个槽的节点上，每个主节点还会配备一个或多个从节点，负责复制主节点的数据，并在主节点故障时顶上去，Redis集群可以看作是数据分片和主从复制+高可用的结合体。
• 用在哪儿？ 超大数据量、超高并发的场景，它通过分片实现了横向扩展，理论上可以无限扩容，它自身就具备了故障转移的能力，不需要额外部署哨兵。
• 要注意啥？ 使用起来有一些限制，比如涉及多个key的操作（像集合求交集并集）如果这些key不在同一个节点上，就无法直接执行，客户端也需要支持集群协议，能够知道哪个key应该发到哪个节点上去。

• 就想做个简单的备份或者读写分离 -> 用主从复制。
• 想要主从复制，还要求主节点挂了能自动切换 -> 用主从复制+哨兵模式。
• 数据量单机根本存不下，或者写请求多到单机扛不住 -> 用Redis集群。

除了Redis自带的这些机制,还有一些外部的工具也能做数据同步，比如阿里云开源的RedisShake，它可以实现两个独立Redis实例之间的数据迁移、备份和同步，特别适合在不同网络环境（比如自有机房和云上）的Redis之间同步数据，或者不同版本的Redis之间同步数据，因为它不依赖于Redis自身的复制协议。

搞互联网之间的Redis数据同步,核心就是根据你的业务需求——是要求性能，还是要求高可用，还是要求海量数据——来选择上面这些“兵器”，没有最好的，只有最合适的。