各种集群解析

redis kafka zk es eureka mysql
集群最好都是基奇数，半数以上活着代表正常工作

redis集群主要通过hash solt分支，连接任何一个机器都保存了其他的信息,会转发到具体的机器
redis.conf cluster-enabled yes cluster-config-file 一定要加上-c，不然节点之间是无法自动跳转的
5.0创建集群redis-cli --cluster create 127.0.0.1:1001 127.0.0.1:1002 --cluster-replicas 1 -a ww
主从 slaveof master 6379
Gossip协议工作原理就是节点彼此不断通信交换信息 ping/pong日常通信 .meet消息：用于通知新节点加入 .fail消息：当节点判定集群内另一个节点下线时，会向集群内广播一个fail消息

Config config = new Config();
config.useClusterServers()
.setScanInterval(2000) // 集群状态扫描间隔时间，单位是毫秒
//可以用"rediss://"来启用SSL连接
.addNodeAddress(“redis://127.0.0.1:7000”, “redis://127.0.0.1:7001”)
RedissonClient redisson = Redisson.create(config);

zk集群 一个领导者(Leader)，多个跟随者(Follower） Observer组成的集群 扩容！！逐台进行服务器的重启
全局数据一致:每个server保存一份相同的数据副本，client无论连接到哪个Server，数据都是一致的
选举机制:
初始化：总共5台，第一台启动投自己，第二台启动就是2票，1为looking状态，0票。第三台启动3票，超过了半数 后续4，5就是floweer
leader挂掉:epoch是leade任期时id（选举一次增加1），zxid是事务id，sid就是其myid，当某时刻leader宕机后，首先考察存活节点的epoch id，epoch最大的选举为leader，如果epoch都相同，则看其事务id zxid ，选举zxid最大的为leader，如果zxid都相同，则看其sid，就是节点的myid，myid大的为leader
Zookeeper3.4.6不存在脑裂的问题。 选举算法是FastLeaderElection，该算法的规则是投票超过半数的服务器才能当选为Leader。
zkServer.sh start
zoo.cfg 追加
server.1=192.168.80.50:3188:3288
server.2=192.168.80.60:3188:3288
ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 原子广播 的协议
原子广播：1.客户端写请求 —> 2.leader发事务提案zxid —> 3.follower各自通过FIFO队列接收后，以事务日志写入本地磁盘，并反馈ack响应 —> 4.leader收到超半数follower的ack后，自己提交事务，广播commit让所有follow也完成提交 两阶段提交(2PC) 消息队列，用来解耦他们之间的耦合，解除同步阻塞
崩溃恢复：Leader选举+数据恢复max(epoch) -> max(zxid) -> max(serverid)

private String connectString = “hadoop102:2181,hadoop103:2181,hadoop104:2181”;
zooKeeper = new ZooKeeper(connectString, sessionTimeout, new Watcher() {//Watcher就是监听节点

但Kafka本身是没有延迟队列功能的，RabbitMQ、RocketMQ有延迟队列的功能
第1步：发送延迟消息时不直接发送到目标topic，而是发送到一个用于处理延迟消息的topic，例如delay-minutes-1 delay-minutes-5不同休息时间
第2步：写一段代码拉取delay-minutes-1中的消息，将满足条件的消息发送到真正的目标主题里。！！
KafkaConsumer 提供了暂停和恢复的API函数，调用消费者的暂停方法后就无法再拉取到新的消息，同时长时间不消费kafka也不会认为这个消费者已经挂掉了。
不能用sleep 可能会挂掉！！
Timer timer = new Timer();
timer.schedule(new TimerTask() {
@Override
public void run() {
synchronized (lock) {
consumer.resume(consumer.paused());//恢复所有被暂停拉取的分区
lock.notify();
}
}
}, 0, 1000);
kafka的rebalance机制 可能重复消费 集群不稳定 消费速度
分区个数的增加 对Topic的订阅发生变化 消费组成员的加入或离开
Coordinator会从中选择一个Consumer担任Leader的角色，并把组成员信息以及订阅信息发给Leader 具体哪个Consumer负责消费哪些Topic的哪些Partition
max.poll.interval.ms 每隔多长时间去拉取消息 max.poll.records 一次从拉取出来的数据条数
从kafka-0.9版本及以后，kafka的消费者组和offset信息就不存zookeeper了 offset放在kafka内置的一个topic中，该topic是__consumer_offsets
在kafka集群中有2个种leader，一种是broker的leader即controller leader，还有一种就是partition的leader
当broker启动的时候，但是集群中只能有一个leader对外提供服务，在指定的zookeeper路径下创建临时节点，只有第一个成功创建为leader，其余的都是follower
从Zookeeper中读取当前分区的所有ISR(in-sync replicas)集合 调用配置的分区选择算法选择分区的leader
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, “192.168.3.36:9092,192.168.3.36:9093,192.168.3.36:9094”);
Producer<String, String> producer = new KafkaProducer<String, String>(props); KafkaConsumer