redis中主从节点的爱恨情仇

故事发生在数据库的家族，由于redis经常被MySql同学diss无法高可用，于是愤青redis开始自己进化了

这时候小黑，小白，小红这哥仨开始商量着怎么桃园结义，开始打天下

小白说：咱们是亲哥仨，咱们是一个团队，咱们应该用主从模式，主节点主要负责写数据，从节点主要负责读数据，只要做好数据的同步，读写分离提高性能，另外主大哥崩了，其他的兄弟自动补上，这样不就干掉MySql咱们也可以实现高可用了吗

小黑：我觉得大哥说得对

小红：I think so

于是这哥仨开始哼哧哼哧干活了，小白大哥是主节点，小红和小黑是从节点，于是大哥得到的数据都会写成一个ROB文件传递给两个兄弟。

于是大哥发送了ROB文件后收到的修改命令也会及时的发送给小红，小黑这样数据就做到了一致

但是好景不长

小红：两位大哥，我这里网络刚刚抽风掉线了，你好意思

小白：没事，你等下我把最新的数据写成ROB文件给你发过去，重新同步一下

小红：先别急，我这只是网络掉线了一小会，没必要被全部数据都同步一下吧，太浪费时间了

小白：那不然怎么办，我哪知道你那边的数据和我这里查了哪里

小黑：我有个建议，小白你内部准备一个缓冲区，你后面传输命令的时候，除了同步给我们，你自己也网缓冲区写一份，这样把最近的命令保存起来，我们下次不管谁掉线了，你只需要把最新的给我们同步了就好了

小红：完美（手动兰花指）

小白：让我想想啊，我怎么知道我缓存的和你们缺失的能不能对的上呢？又怎么知道该发哪些缓存给你们呢？

小黑：要不怎么整个游标把，叫做复制偏移量，最开始都从0开始，随着数据复制和同步大家一起更新，后面只需要比较各自的这个偏移量，就能知道缺失哪些数据了

小白：可行

小白：但是还有一个问题，咱么这个Team要是壮大了，有新人来了，他里面也保存了偏移量，但是和我们的不一样，我把数据给他发过去岂不是不合适

小红：我有办法了（小红突然乍起）

小红：怎么每次运行都生成一个运行ID，随机的，每次都不一样。第一次同步的时候，主节点把自己的运行ID告诉从节点，后面从节点断线重连都要告诉主节点他之前保存的运行ID，主节点拿到之后和自己的比较一下就知道这个从节点之前是不是从自己这里复制数据的，是的话就只同步缺失的部分，不是的话就说明是新来的，就得把全部数据都同步给他

小黑：好办法

小红：咱们虽然有主从复制，但是主节点挂了，还是需要程序员们手动来选择从节点升级为主节点来提供写入服务，感觉好low啊

小黑：确实

小白：要不这样，咱们选出来一个当管理员，不用负责读写数据，专门来统筹协调，谁要是掉线了，就在从节点选一个出来顶上

小黑：我看行，这个管理员就叫哨兵

小红：好主意，不过一个管理员怕是不够，万一管理员挂了，那不就完了，得多找几个

 

这样小红小黑小白的大家庭有加入三个兄弟，一起解决了高并发的问题，过上了其乐融融的生活。