Zookeeper：投票机制实现机制
Kafka：特点存储机制应用场景
设计模式：三大原则工厂抽象工厂单例

Zookeeper

投票机制

1：持久节点（persistent）和临时节点（ephemeral）
持久节点只能通过delete删除。临时节点在创建该节点的客户端崩溃或关闭时，自动被删除。
而leader明显为临时节点
2：仲裁模式：法定人数必须大于一半，即满足多数原则，即可用服务器超过一半才代表系统可用
选取leader的两种情况：
1：开机
在集群正常工作之前，myid小的服务器给myid大的服务器投票
有 5 台服务器,编号分别是 1,2,3,4,5,按编号依次启动:

服务器 1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器 1 的状态一直属于 Looking。
服务器 2 启动，给自己投票，同时与之前启动的服务器 1 交换结果，由于服务器 2 的编号大所以服务器 2 胜出，但此时投票数没有大于半数(3票)，所以两个服务器的状态依然是 LOOKING。
服务器 3 启动，给自己投票，同时与之前启动的服务器 1,2 交换信息，由于服务器 3 的编号最大所以服务器 3 胜出，此时投票数正好大于半数，所以服务器 3 成为领导者，服务器 1,2 成为小弟。
服务器 4 启动，给自己投票，同时与之前启动的服务器 1,2,3 交换信息，尽管服务器 4 的编号大，但之前服务器 3 已经胜出，所以服务器 4 只能成为小弟。
服务器 5 启动，后面的逻辑同服务器 4 成为小弟。
2：leader宕机
首先每一个server都会进入looking状态，并且会将自己设为推荐leader，数据结构为（推荐leader，zxid）
每一个server彼此交换投票意向，当收到所有server回复后，计算zxid最大的作为本server的推荐leader，更新数据结构（新leader，最大的zxid）
统计所有选票，超过半数的为胜利者

Zookeeper的工作

目录为树形结构
四个节点分别是：
/master，存储了当前主节点的信息
/workers，下面的每个子znode代表一个从节点，子znode上存储的数据，如“foo.com:2181”，代表从节点的信息。
/tasks，下面的每个子znode代表一个任务，子znode上存储的信息如“run cmd”，代表该内务内容
/assign，下面每个子znode代表一个从节点的任务集合。如/assign/worker-1，代表worker-1这个从节点的任务集合。/assign/worker-1下的每个子znode代表分配给worker-1的一个任务。
在这里插入图片描述
如何实现工作：
客户端向zookeeper请求，在特定的znode结点master设置观察点（watch）即订阅。
当该znode发生变化时，zookeeper通知客户端，客户端收到通知后进行业务处理。
观察点触发后立即失效。所以一旦观察点触发，需要再次设置新的观察点
我们使用Zookeeper不能期望能够监控到节点每次的变化。思考如下场景：
1、客户端C1设置观察点在/tasks
2、观察点触发，C1处理自己的逻辑
3、C1设置新的观察点前，C2更新了/tasks
4、C1处理完逻辑，再次设置了观察点。
此时C1不会得到第三步的通知，因此错过了C2更新/tasks这次操作。要想不错过这次更新，C1需要在设置监视点前读取/tasks的数据，进行对比，发现更新。
再如下面的场景：
1、客户端C1设置观察点在/tasks
2、/tasks上发生了连续两次更新
3、C1在得到第一次更新的通知后就读取了/tasks的数据
4、此时第二次更新也已经发生，C1用第一次的通知，读取到两次更新后的数据，此时C1虽然错过了第二次通知，但是C1最终还是读取到了最新的数据。因此Zookeeper只能保证最终的一致性，而无法保证强一致性。

Kafka

点对点模式：是一个生产者对应一个消费者，且消息只能被消费一次
发布-订阅：是一个生产者对应多个消费者，通过topic。生产者将消息发送到topic，相关的几个消费者都订阅这个topic

特点：
吞吐量大：
1：数据磁盘持久化：消息不在内存中cache，直接写入到磁盘，充分利用磁盘的顺序读写性能
2：zero-copy：减少IO操作步骤
3：合并发送：Producer 多条消息一次发送。减少 broker 存储消息的 IO 操作次数。但影响消息的实时性
4：Producer 端可以通过 GZIP 或 Snappy 格式对消息集合进行压缩。Producer 端进行压缩之后，在 Consumer 端需进行解压。瓶颈往往体现在网络上而不是 CPU(压缩和解压会耗掉部分 CPU 资源)

可扩展性：所有的 producer、broker 和 consumer都会有多个，均为分布式的。无需停机即可扩展机器
（可伸缩性：只需要改变部署的服务器数量，就可以扩大或者缩小网站的服务处理能力。
名言：当一头牛拉不动车时，不要试图找一条更强壮的牛，而是找两头牛来拉车）

负载均衡：partition会均衡分布到不同broker上，producer 可以通过随机或者 hash 等方式，将消息平均发送到多个 partition 上由zookeeper完成

拉取系统：kafka broker会持久化数据，broker没有内存压力，因此，consumer非常适合采取pull的方式消费数据
生产者push，消费者pull解耦合

Kafka就是一种发布-订阅模式
broker:Kafka 服务器，负责消息存储和转发
topic:消息类别，Kafka 按照 topic 来分类消息
partition:topic 的分区，一个 topic 可以包含多个 partition，topic 消息保存在各个partition 上
Zookeeper:保存着集群 broker、topic、partition 等 meta 数据;partition leader 选举，负载均衡

partition：由 Message组成，每个Message:offset，MessageSize，data
offset ：偏移量，是逻辑上一个值，它唯一确定了 partition 中的一条 Message，可以认为 offset 是 partition 中 Message的 id;
MessageSize ：消息内容 data 的大小;
data：Message 的具体内容
数据文件分段segment(顺序读写、分段命令、二分查找)：
partition 物理上由多个 segment 文件组成，每个 segment 大小相等，顺序读写。每个 segment 数据文件以该段中最小的 offset 命名，二分查找就可以定位到该 Message 在哪个 segment 数据文件中。

数据文件索引(分段索引、稀疏存储)
Kafka 为数据文件分段segment建立索引
采用了稀疏存储的方式，每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间在这里插入图片描述

在这里插入图片描述

应用场景

A为生产者，BCD为消费者
解耦：
传统场景：A生产到BCD
缺点在于：如果C不接收数据了，需要修改代码。如果新增加消费者，需要改代码。
kafka：A为push，BCD为pull
异步：
传统场景：A生产后再BCD本地处理后再返货。
缺点在于：时延过大，用户难以接受
削峰：当有大量数据时，传统场景无法处理。而Kafka是超载的原有的语句存入队列，之后系统再按给定吞吐量进行处理

参考资料
缺点：系统复杂性，系统一致性

设计模式

类：具有相同属性和功能的抽象的集合
面向对象的三大特性
封装：类
继承：一般来说，继承链的树叶节点才是具体类，而树枝节点都是抽象类（设计模式）
缺点：
1：父类变，子类必须变
2：破坏封装，父类的实现细节暴露给子类
多态：子类以父亲的身份出现，能够使用继承或者重新的方法，但是不能使用新的属性和方法

抽象类和接口的区别：
行为模式上区别：抽象类可以有非抽象方法，可以有成员的实现，只能继承一个类但可以有多个借口

意识：
1：类是对象的抽象，抽象类是类的抽象，接口是行为的抽象
2：抽象类是自底向上的，多来自于重构。接口是自顶向下。

普通工厂方法感觉为上转型对象的优化实现
好处在于，不要创建的引用的时候区别不同的Sender，而只需要在输入参数的时候修改即可得到不同的Sender 在这里插入图片描述

多个工厂方法：普通工厂方法容错性较低，如果传入错误的字符串则无法创建对象

在这里插入图片描述静态工厂方法：将多个工厂方法中创建对象的改为静态实例public static Sender produceMail(){
return new MailSender();
}

抽象工厂类：上述如果扩展程序，需要修改工厂类，破坏封闭性。
而抽象工厂类，扩展程序只需做一个实现类，实现Sender接口，同时做一个工厂类，实现Provider接口
在这里插入图片描述

单例模式：
1：对于一些大型的对象创建比较复杂，这是一笔很大的系统开销。
2：省去了new操作符，降低了系统内存的使用频率，减轻GC压力。
3：有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。
在这里插入图片描述