redis通讯与高可用集群原理
上一篇文章介绍了 单机版的redis的持久化与过期键删除原理
现在将粗略介绍一下集群的redis的通讯与集群的原理
，好！废话不多说，让我们开始吧。。。
redis通讯
redis是一个小系统，那么为了让这个系统可以稳定地工作，通讯便是不可缺少的功能，redis的通讯通过事件机制来实现，它的事件有两种，文件事件和时间事件
文件事件
文件事件主要用于执行命令，如写入写出等。。文件事件通过套接字来进行通讯，套接字里面说明了这个事件具体是什么，见下图
由图我们可以知道，redis的文件事件处理器由以下部分组成
1、套接字：用于按照一定的规则封装事件的任务。
2、I/O多路复用程序：文件事件处理器使用I/O多路复用程序来监听多个套接字，并根据套接字所执行的任务为套接字 关联不同的事件处理器
3、文件事件分派器：文件事件分派器将将所有的文件事件放在一个队列里面，然后逐个取出交给事件处理器处理，所以说redis是单线程的
4、事件处理器：处理事件
时间事件
时间事件分为定时事件和周期性事件
1、定时事件：让程序在指定时间执行的定时任务
2、周期性事件：周期性执行的事件，如过期键删除中的定期删除
3、时间事件的实现
服务器将所有的时间事件放在一个无序的链表（不按照when来进行排序），每当时间事件执行器运行，就遍历这个队列查找已经到时间的事件然后调用相应的处理器进行处理
事件调度
在文件事件和时间事件同时存在的时候，如何进行调度？
1、首先文件事件是只要有文件事件到达就马上执行
2、对于时间事件它的执行方式则是
- 2-1 获取最快要开始执行的时间事件的时间
- 2-2 阻塞等待最近的需要执行的时间事件的到来
- 2-3 时间到来，执行时间事件
3、事件调度（文件事件与时间事件共存）–》aeProcessEvent 函数
函数的原理如图（不贴代码了）见它的原理图
意思就是不断处理文件事件，当时间事件到来则开始处理时间事件，没有事件则进入阻塞状态，不断循环。但是需要注意的是，这些事件都不是抢占式的，而是一个接着一个执行，当然，如果一个事件执行的时间超越某个临界值的时候，这个事件会自动break，然后保存状态等待下次执行
4、实例
上面解释那么多肯定都不如一个实例来得清楚，那么让我们来个实例
开始时间 结束时间 动作
0 10 创建一个在100毫秒执行的事件事件
11 30 等待文件事件
31 50 文件事件到达，处理文件事件
51 85 等待文件事件
85 130 文件事件到达，执行文件事件
130 150 处理时间事件（0毫秒创建的时间事件）
从上面的例子可以看出文件事件到来，且处理器空闲的话就立马执行，时间事件在时间到来的时候，如果处理器空闲，则执行，处理器不空闲，需要等到当前文件事件执行完了之后才进行处理，而不进行抢占式调度。
Redis集群的原理
主从复制
在redis中，可以通过复制配置文件然后启动一个新的redis（redis集群搭建，下个文章讲解），新的redis可用通过slaveof命令让一个服务器成为另个服务器的从服务器，现在先让我们从单个主机和单个从机的简单的情况探讨redis集群中的集群与数据一致性（基于redis2.8以上的版本）
redis主从复制分为两部分同步与命令传播
为了简单说明，我将从一条时间线进行说明
初次进行主从复制–>redis运行中命令同步–>redis宕机重启后数据同步
1、初次主从复制
当从机刚刚启动，则它需要从主机同步数据，也就是将主机的数据同步一份给从机，首先主机收到salveof命令后，
- 主机以当前状态为节点运行BGSAVE命令，生成一个RDB文件然后发给从机
- 主机生成一个缓冲区记录从当前开始所执行的命令
- 从机先拿到主机发来的RDB文件进行同步
- 从机拿到缓冲区里面的命令，然后执行，至此，同步完成，这种方式也叫做“同步”
2、redis运行中命令同步
对于运行中同步，redis采用偏移量机制和复制积压缓冲区机制
2-1偏移量机制
主从同步完成后，主从均记录一个变量offset，每执行一条命令，offest加1，从机也是如此，故而只要比较主机和从机的offest的大小，主机offest减去从机offest就知道他们两差几条数据
2-2复制积压缓冲区机制
redis中有一个复制积压缓冲区，他的大小默认为1m，采用先进先出的方式记录最近执行的命令，当命令还未到1m则往里面不断放入最近执行的命令，大于1m后抛弃最老的命令，放入最新的命令
2-3同步
- 计算偏移量：主机offest减从机offest中得到主从相差几条数据；
- 主机通过偏移量从复制积压缓冲区里面取从机缺少的那几条数据发给从机；
- 从机执行后便完成同步，这便是命令传播
3、宕机后同步
主机宕机，则从机上位，成为新的主机，然后老的主机启动成为从机，从机宕机则启动还是从机，这两种情况均会导致主从不一致，那么这种情况下:同步方案如下
- 通过offest得到主从之间差了多少条命令，
- 如果偏移量差不大于复制积压缓冲区大小，也就是宕机丢失的命令在复制积压缓冲区里面还能找到，则拿出里面的命令执行一遍就可以恢复，
- 如果已经超出了复制积压缓冲区大小，则需要进行RDB来进行同步，也就是和初次同步时那样。
redis集群
这是一篇理论性的文章，那么集群搭建的过程我将在下一篇文章里面进行介绍，假设我们已经有一个集群，三主三从，分别为7001、7002、7003、7004、7005、7006
1、内存地址管理
在进行集群后，redis默认将整个内存非为16384块（也可以自己分），也就是0-16383，在进行搭建的时候，我们可以指定每组主机管理的地址，最终会形成一个表，如下
它记录了每个主机所处理的地址
如
7001处理0-5000
7002处理5001-10000
7002处理10001-16383
2命令处理
我们知道redis集群里面任何一个主机都可以处理所有命令，那么他们是如何做到的呢
看图
命令到来，先通过CRC16算法算出这条命令具体要对那个槽做操作，如果就是这个主节点管理的曹，则处理，如果不是，则先执行move命令，跳转到正确的主节点，然后执行命令
3、宕机与选举
当主机宕机后，从机如何变成主机，就需要进行选举，选举是一个很有趣的过程，首先需要明白一点，就是主机才有投票的权力
例子
就以上面三主三从为例，假设7001宕机，选举如下
- 从机7004将通过广播向集群发送一条消息，意思就是为自己拉票，
- 如果此时主机还没有套票给其他从机则这个主机会将票投给第一个向他拉票的从机，
- 如果有一个从机得到半数主机以上的票则当选为新的主机（假设除去已经宕机的主机还有N个主机，则从机需要得到N/2+1的票才能当选为主机）
- 至此新主机上位，原来的主机会重启变为从机
合理性
这种选举看起来有点随便呀，真是这样？仔细一想，其实这种选举方式恰好选举出了网络状态最好的从机，是很不错的选举
一些需要避免的问题----》选举失败，从机无法变为主机
例子
看上图，假设03主机宕机，那么就可能出现主机选举失败的可能
06 和 07 均广播拉票，如果主机01将票给了06，主机02将票给了07，那么两个从机均得到一票，均不满足N/2+1的票,两个都不能当选，故而选举失败，这种错误是可以人为避免的。
4、可用性分析
4-1 稳定性
就以刚才的三主三从为例，他的生存能力已经非常的强，任何一台机子宕机都不会导致整个集群不可用，当然有种情况就是某个集群的某一组主机和从机全部宕机，那么就会导致集群不可用，如01和04同时宕机，那么这组主从管理的0-5000这5001个槽将不能被管理，导致集群不可用
4-2 可用性
在设置集群之后，主机主要负责写，而从机负责读，实现读写分离，大大加强了redis性能。
总结
前面的连篇文章都只是介绍了redis的一些原理，下一篇文章我将从实践的角度开始介绍集群的搭建和使用，喜欢的话可以关注一下呦，您的关注是我前进的动力