zookeeper集群+消息队列kafka

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。为分布式框架提供协调服务的Apache项目。
ZooKeeper数据模型的结构与Linux文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。 

zookeeper=注册中心+通知机制+文件系统

zookeeper的特点

1）Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群。
（2）Zookeepe集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。所以                           Zookeeper适合安装奇数台服务器。
（3）全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据            都是一致的。
（4）更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行，即先进先出。
（5）数据更新原子性，一次数据更新要么成功，要么失败。
（6）实时性，在一定时间范围内，Client能读到最新数据

Zookeeper 选举机制

123根据myid选举出leader之后再加入服务器此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；

非第一次启动选举机制

集群中确实不存在Leader。
假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、7，并且此时SID为3的服务器是Leader。某一时刻，3和5服务器出现故障，因此开始进行Leader选举。
选举Leader规则：
1.EPOCH大的直接胜出
2.EPOCH相同，事务id大的胜出
3.事务id相同，服务器id大的胜出

/为什么需要消息队列（MQ）
主要原因是由于在高并发环境下，同步请求来不及处理，请求往往会发生阻塞。比如大量的请求并发访问数据库，导致行锁表锁，最后请求线程会堆积过多，从而触发 too many connection 错误，引发雪崩效应。
我们使用消息队列，通过异步处理请求，从而缓解系统的压力。消息队列常应用于异步处理，流量削峰，应用解耦，消息通讯等场景。
消息队列的两种模式

1、点对点模式2、发布/订阅模式

/Kafka 系统架构
（1）Broker
一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

（2）Topic
可以理解为一个队列，生产者和消费者面向的都是一个 topic。
类似于数据库的表名或者 ES 的 index
物理上不同 topic 的消息分开存储

（3）Partition
为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分割为一个或多个 partition，每个 partition 是一个有序的队列。Kafka 只保证 partition
内的记录是有序的，而不保证 topic 中不同 partition 的顺序。