什么是数据一致性? 只有当服务端的ZK存在多台时,才会出现数据一致性的问题, 服务端存在多台服务器,他们被划分成了不同的角色,只有一台Leader,多台Follower和多台Observer, 他们中的任意一台都能响应客户端的读请求,任意一台也都能接收写请求, 不同的是,Follower和Observer接收到客户端的写请求后不能直接处理这个请求而是将这个请求转发给Leader,由Leader发起原子广播完成数据一致性 理论上ZK集群中的每一个节点的作用都是相同的,他们应该和单机时一样,各个节点…

前言 ZooKeeper对Zab协议的实现有自己的主备模型,即Leader和learner(Observer + Follower),有如下几种情况需要进行领导者的选举工作 情形1: 集群在启动的过程中,需要选举Leader 情形2: 集群正常启动后,leader因故障挂掉了,需要选举Leader 情形3: 集群中的Follower数量不足以通过半数检验,Leader会挂掉自己,选举新leader 本篇博文,从这三个方面进行源码的追踪阅读 程序入口 QuorumPeer.java相当于集群中的每…

一般拿Timer和Quartz相比较的,简直就是对Quartz的侮辱,两者的功能根本就不在一个层级上,如本篇介绍的Quartz强大的序列化机制,可以序列到 sqlserver,mysql,当然还可以在第三方插件的基础上实现quartz序列化到热炒的mongodb,redis,震撼力可想而知,接下来本篇就和大家聊一聊怎么搭 建基于sqlserver的quartz集群,实现这么一种双机热备的强大功能. 一:下载sqlserver版的建表脚本   首先大家可以通过github上搜索quartz的源代码…

目录 1. Jedis 单点连接 2. Jedis 基于sentinel连接 基本使用 源码分析 本次源码分析基于: jedis-3.0.1 1. Jedis 单点连接   当是单点服务时,Java 连接Redis的客户端: Jedis jedis = null; try { jedis = new Jedis("192.168.237.130", 6379); jedis.hset("hashzz", "k1", "v1")…

整个Flink集群的角色分为Jobmanager和TaskManager 以Standalone为例来看一下脚本里面是怎样启动集群的 找到源码的dist这里面包含了启动的脚本文件 standalone模式下我们通过start-cluster.sh这个脚本启动 来看下里面具体做了什么 在最后调用了jobmanager.sh start 这个脚本和config.sh  中的TMSlaves 这个方法,分别启动了jobmanager和taskmanager 先看一下Jobmanager 在jobman…

入口 书接上篇博客中的ZK集群启动后完成数据的统一性恢复后,来到启动ZkServer的逻辑,接下来的重点工作就是启动不同角色的对应的不同的处理器Processor 如上图查看ZooKeeperServer的继承图,三种不同的角色有不同的ZooKeeperServer的实现逻辑类 三者启动时,都将会来到ZooKeeperServer.java中的startUp()方法中,源码如下,但是,不同的角色针对setupRequestProcessors();进行了不同的重写,所以本篇博客的重点即使看一下他…

Redis源码阅读(六)集群-故障迁移(下) 最近私人的事情比较多,没有抽出时间来整理博客.书接上文,上一篇里总结了Redis故障迁移的几个关键点,以及Redis中故障检测的实现.本篇主要介绍集群检测到某主节点下线后,是如何选举新的主节点的.注意到Redis集群是无中心的,那么使用分布式一致性的算法来使集群中各节点能对在新主节点的选举上达成共识就是一个比较可行的方案. 在工程上,Raft一致性算法是比较易于实现和理解的分布式一致性算法:Redis也是使用了Raft来做主节点选举的.所以这里先简单…

Redis源码阅读(五)集群-故障迁移(上) 故障迁移是集群非常重要的功能:直白的说就是在集群中部分节点失效时,能将失效节点负责的键值对迁移到其他节点上,从而保证整个集群系统在部分节点失效后没有丢失数据,仍能正常提供服务.这里先抛开Redis实际的做法,我们可以自己想下对于Redis集群应该怎么做故障迁移,哪些关键点是必须要实现的.然后再去看Redis源码中具体的实现,是否覆盖了我们想到的关键点,有哪些设计是我们没有想到的,这样看代码的效果会比较好. 我在思考故障迁移这个功能时,首先想到的是节点…

Redis源码阅读(四)集群-请求分配 集群搭建好之后,用户发送的命令请求可以被分配到不同的节点去处理.那Redis对命令请求分配的依据是什么?如果节点数量有变动,命令又是如何重新分配的,重分配的过程是否会阻塞对外提供的服务?接下来会从这两个问题入手,分析Redis3.0的源码实现. 1. 分配依据——槽 Redis将每个客户端的请求命令通过哈希的方式映射到槽上,映射方法就是对该客户端请求中的键值求CRC16校验值,求得的值再和16383(0x3FFF)进行与操作,得到的结果即为槽值:Redis…

Redis源码阅读(三)集群-连接建立 对于并发请求很高的生产环境,单个Redis满足不了性能要求,通常都会配置Redis集群来提高服务性能.3.0之后的Redis支持了集群模式. Redis官方提供的集群功能是无中心的,命令请求可以发送到任意一个Redis节点,如果该请求的key不是由该节点负责处理,则会返回给客户端MOVED错误,提示客户端需要转向到该key对应的处理节点上.支持集群模式的redis客户端会自动进行转向,普通模式客户端则只返回MOVED错误. 先看下常见的Redis集群结构:…