Zookpeer和Kafka

Eureka和ZooKeeper中的CAP理论
C：数据一致性。A：服务可用性。P：分区容错性（当前网络延迟故障会导致丢包等问题
Eureka（保证AP），Zookeeper（保证CP）
Zookeeper数据最终一致 选举leader过程中集群不可用 对数据一致性要求较高
Eureka 服务高可用 服务节点间的数据可能不一致 对注册中心服务可用性要求较高

Zookeeper主从集群数据存储在内存中，客户端随意连接任何节点并读写,如果连接的是follower节点会自动转到leader进行，redis的主从集群写操作只能连接主节点 集群最少需要3台或者保证奇数台为了选举算法 集群中个服务器之间通过TCP通信并维持心跳
Leader事务请求的唯一调度者和处理者(除查询请求
Follower处理非事务请求 和Lea保持心跳，参与Leader选举投票
Observer处理非事务请求，不参与选举投票 为提高读性能
zxid事务id是长度64位的数字其中低32位是按照事务请求次数递增,高32位是leader版本的epoch编号选举新lea加一

ZAB原子广播
zk节点之间的数据一致性是通过ZAB zookeeper atomic broadcast（原子广播）协议来保证的最终一致性:Leader将写请求发给所有Follower统计F写成功数量超过半数通知所有的F提交写操作 sync指令获取最终值 节点ZNode能存 1MB 数据
ZAB另一种模式是崩溃恢复模式leader挂了zk集群处于不可用状态 其余follower根据zxid(事务id数据同步进度 越大越完整)以及myid/SID(服务器ID创建zk集群的顺序号)投票选举将自己的zxid和myid发送给其他节点比zxid 首次启动集群启动个数过半,可以提供服务时最后启动的为leader(集群投票给自己比较票数;zxid;myid

Zookeeper的四种类型节点：
persistent：持久化节点
persistent_sequential： 持久化顺序节点
ephemeral：临时节点
ephemeral_sequential：临时顺序节点
持久化节点只能主动调用detele方法删除
临时节点在创建者超时或失去连接后节点就会被删除，临时节点下面没有子节点
顺序节点在创建后会自动在后面添加序列号

zk中的一些常用方法和分布式锁
create:创建节点 delete:删除节点 exists:存在节点 get:取节点的值 set:节点赋值 getChildren:取节点下子节点信息 sync:获取到同步数据
分布式锁zk节点的递增有序性确保锁的公平 节点编号是上一个次序编号加一。线程抢占锁之前创建自己的临时ZNode 如果不是最小节点就监听前一个Znode删除事件就轮到自己占有锁。能避免羊群效应 时序锁有时限
leader重启变成foller去同步新leader的数据,如果是假死复活后还会认为自己是leader 给foller发送命令时f会拒绝epoch小于现任leader的任何请求
ZK的持久化和redis一样SnapShot快照记录内存中的全量数据,TxnLog记录事务日志
详见 Zookeeper 持久化——FileTxnLog(一)

消息队列
RabbitMQ:万级吞吐量 时效性最快微秒级 动态扩展麻烦，代码开源社区活跃bug好解决
RocketMQ:10万级吞吐 时效性毫秒级 java代码开发方便定制 数据0丢失 阿里出品可能被抛弃
Kafka:10万级吞吐 毫秒级 功能简单 数据0丢失 将消息持久化到磁盘

Kafka中的角色
broker消息中间件所在的服务器 就是一个kafka节点 多个broker构成一个kafka集群
producer消息生产者发布消息到broker 获取broker提供的metadata信息 包含集群中存活的servers列表和Partition leader等
consumer消息消费者读取broker消息的客户端 可以消费多个topic中的数据
consumergroup消息订阅者集群 一个分区的消息可被多个消费者群组消费 但只有一个可以消费消息
topic相同主题的数据分类库 发布到kafka的每个消息分类都有一个对应的topic分类
Partition分区 : 单独的 log文件在磁盘上面每个Topic的分区Partition,保证消息的消费顺序时将partition数设为1
offset偏移量 存在分区的log文件末唯一且递增的64字节的序号,是kafka确定消息是否被消费过的标识 递增的数字(（高水位HW，标识了一个特定的offset消费者只能拉取到这之前的消息) 保存在消费者本地和broker中 数据不一致同步+异步提交
Leader:每partition有多个副本，其中只有一个是leader并负责读写 新数据会广播给所有f并保持通信 如果f响应很慢会被leader删掉重新建一个
Broker节点内分区和副本关系

follower Partition分区的副本不会被读写消费 只用于防止数据丢失 leader挂了ISR参与选举 (与leader保持默认10秒同步的统称ISR不同步的为OSR)所有ISR确认消息已经写入磁盘时kafka才认为消息被提交了b

zookeeper维护和协调broker
增broker或故障时,zk通知生产者和消费者,生产者和消费者依zk的broker状态信息发布和订阅任务
Topic主题可以存在多个broker节点上,内有多个Partition分区(log文件)中有一个leader和多个follower,每个分区有(复本因子leader + follower)Replica副本 所有副本统称AR,每个副本都有对应的log日志,每个日志内有多个日志分段内有.log日志文件.index偏移量稀疏索引文件和.timeindex时间戳索引文件。带key的消息Kafka根据key的hash值映射到固定分区 没key的消息随机存储到分区
消息确认机制ACK=0[NONE]不保证Broker接收到消息 低延迟高吞吐 消息会丢失ACK=1 [LEADER]leader把记录写到日志并回应ACK= -1 [ALL]所有副本follower都收到消息并回应
Rebalance分区再均衡
consumer增减或Topic或分区发生变更触发kafka重新分配分区归属权 此时消费者无法消费,添加再均衡监听器在分配分区权之前消费
分区分配策略默认为Range:平均轮询分配topic的分区余数分到第一个消费者,topic多的情况第一个消费者能分到更多分区RoundRobin:打乱所有topic的分区依据hash值分给消费者 会造成消费混乱Sticky:粘性分配尽可能均匀;尽可能的与上次分配保持相同
消息由producer直接通过socket发送到broker，中间不会经过任何"路由层"。事实上，消息被路由到哪个partition上由producer客户端决定，比如可以采用"random"“key-hash”"轮询"等。
kafkaConsumer.assign(new TopicPartition(“test-topic”,0))订阅指定的分区 默认kafka分配订阅的主题内分区的消息