ELK\ZOOKEEPER\KAFKA\MONGODB
ELK是软件集合elasticsearch、logstash、kibana的简称，由这三个软件及相关的组件可以打造大规模的日志实时处理系统。
elasticsearch：是一个机遇Lucene(Java全局搜索高效引擎包)的、支持分布式全局索引的分布式存储和索引引擎，主要负责将日志索引并存储起来，方便业务方检索查询。
logstash：是一个日志收集、过滤和转发的中间件，主要负责将各条业务线的各类日志统一收集、过滤后、转发给elasticsearch进行下一步的处理
kibana：是一个可视化工具，主要负责查询elasticsearch的数据并以可视化的方式展现给业务方，比如各类饼图、直方图、区域图等。
zookeeper概念：
zookeeper是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。
zookeeper提供一个类似于Linux文件系统的树形结构(可认为是轻量级的内存文件系统，但是只适合存少量信息，完全不适合存储大量文件或者大文件)，同时提供了对于每个节点的监控和通知机制。
zookeeper集群是一个基于主从复制的高可用集群每个服务器承担如下三种角色中的一种：
1)leader
一个zookeeper集群同一时间只会有一个实际工作的leader，他会发起并维护与各个follower以及observer间的心跳。
所有的写操作必须要通过leader完成再由leader将写操作广播给其他服务器，只要有超过半数节点(不包括observer节点)写入成功，该写请求就会被提交
2)follower
一个zookeeper集群可能同时存在多个follower，它会响应leader的心跳
follower可直接处理并返回客户端的读请求，同时会将写请求转发给leader
并且负责在leader处理请求时对请求进行投票
3)observer
这个角色的功能与follower差不多，但是observer无投票权，zookeeper需要保证高可用性和强一致性，未来支持更多的客户端，需要增加更多的server；server增多，则投票阶段的延迟增大，影响性能；引入observer，observer不参与投票，直接受客户端连接，并将写请求转发给leader。加入更多的observer节点，能够提高伸缩性，同时不影响吞吐率。
ZAB协议：原子消息广播协议,协议的事物编号zxid设计中，zxid是一个64位的数字，其中低32位是一个简单的单调递增计数器，针对客户端的每一个请求，计数器加1，而高32位则代表leader周期epoch的编号，每个当选产生一个新的leader服务器，就会从这个服务器上取出其本地日志中最大事物的zxid，并从中读取epoch值，然后加1，以此作为新的epoch，并将低32位从0开始计数。
epoch：可以理解为当前集群所处的年代或者周期，每个leader都会有自己的周期值，所以leader变更后，其周期值在前一个值的基础上加1，这样就算旧的leader崩溃后恢复了，也不再是正在使用的leader了，因为它已经不再当前周期内了，当前周期有一个新的leader。
ZAB的两种模式：恢复模式和广播模式
当服务启动或者在领导者崩溃之后，ZAB就进入了恢复模式，当领导者呗选举出来且大多数server完成了和leader的状态同步后，恢复模式就结束了，状态同步保证了leader和server具有相同的系统状态。
ZAB协议的4阶段
leader election(选举阶段-选举出准leader)
leader election(选举阶段)：节点在一开始都处于选举阶段，只要一个节点得到半数以上节点的票数，它就可以当选准leader。只有到达广播阶段，准leader才会成为真正的leader，这一阶段的目的就是为了选出一个准leader，然后进入下一个阶段。
discovery(发现阶段-接受建议、生成epoch、接受epoch)
discovery：这个阶段，follower和准leader进行通信，同步follower最近接收的事物提议，这个一阶段的主要目的是发现当前大多数节点接收的最新提议，并且准leader生成新的epoch，让follower接受，更新他们的accepted epoch。
synchronization(同步阶段-同步follower副本)
synchronization：这个时候主要利用leader前一阶段获得的最新提议历史，同步集群中所有的副本，只有当大多数节点都同步完成没准leader才会成为真正的leader，follower只会接收zxid比自己的lastzxid大的提议
broadcast(广播阶段-leader消息广播)
broadcast：到了这个阶段，zookeeper集群才能正式对外提供事物服务，并且leader可以进行消息广播，同时如果有新的节点加入，还需要对新节点进行同步。
ZAB提交事物并不像2PC一样需要全部follower都ACK。只需要得到超过半数的ACK就可以了。
zookeeper工作原理
zookeeper的核心是原子广播，这个机制保证了各个server之间的同步，实现这个机制的协议叫做zab协议。
当服务启动或者leader崩溃后，启动恢复模式，当leader选举出来后，且大多数的server和leader状态同步后恢复模式结束
状态同步保证了leader和server具有相同的状态
一旦leader和follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这个时候当一个server加入zookeeper服务中，它就会在恢复模式下启动，发现leader，并和leader进行状态同步，待到同步结束，他也参与到消息广播中，zookeeper服务一直维持在broadcast状态，直到leader崩溃了或者leader失去了大部分的follower支持。
广播模式需要保证提议(proposal)被按顺序处理，因此ZK采用了递增的事物ID号来保证
当leader崩溃或者leader失去了大多数follower的时候，这时候zk进入恢复模式，直到重新选举出一个新的leader并让所有的server都恢复到新的状态。
ZK有4中形式的节点
PERSISTENT：持久化节点
EPHEMERAL：暂时节点
PERSISTENT_SEQUENTIAL：持久化顺序编号，目录节点
EPHEMERAL_SEQUENTIAL：暂时化顺序目录节点
KAFKA
kafka是一种高吞吐量、分布式、基于发布、订阅的消息系统。
broker：kafka的服务器，负责消息存储和转发
topic： 消息类别，kafka按照topic来分类消息
partition：topic上面的分区，一个topic可以包含多个partition，topic消息保存在各个partition上
offset： 消息在日志中的位置，可以理解是消息在partition上的偏移量，也是代表该消息的唯一序号
producer： 消息生产者
consumer： 消息消费者
consumer group：消费者分组，每个consumer必须属于一个group
zookeeper：保存着集群broker、topic、partition等meta数据，另外，还负责broker故障发现，partition leader负责选举，负载均衡等功能
partition中的数据文件包含了以下三个属性：offset、messageSize、data，offset可以看做是partition中的message的ID，标识message在这个partition中的偏移量，offset不是该message在partition中的实际存储位置，而是一个逻辑值。data才是具体的message内容。
partition物理上有多个segment文件组成，每个segment大小相等，顺序读写，每个segment数据文件已该段中最小的offset命名，文件扩展名为.log，这样在查找指定offset的message的时候，用二分法直接就可以定位到改message在那个segment数据文件中。
数据文件索引（分段索引、稀疏存储）
kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为.index，index中
并没有为数据文件中的每条message建立索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引，这样避免了索引文件占用过多的空间，从而将索引文件保留在内存中。
负载均衡(partition会均衡分布在不同的broker上)
由于消息topic由多个partition组成，切partition会均衡分布到不同的broker上，因此未为了有效利用broker集群的性能，提高消息的吞吐量，producer可以通过随机或者hash等方式，将消息平均发送到多个partition上，以实现负载均衡。
批量发送
为了提高消息吞吐量，producer端可以在内存中合并多条消息后，以一次请求的方式发送批量的消息给broker，从而大大减少broker的存储消息的IO操作次数。但也一定程度上影响了消息的实时性，换取更好的吞吐量。
压缩
producer端可以通过GZIP或Snappy格式对消息集合进行压缩，producer端进行压缩之后，在consumer端进行解压，通过压缩数据能够减少传输的数据量，减轻对网络传输的压力，在大数据处理上，瓶颈往往体现在网络上，而不是CPU。
消费者队列(consumer group)
同一个消费者队列中有多个消费者实例，不同时地消费同一个partition，等效于队列模式，partition内消息是有序的，consumer通过pull方式消费消息，kafka不删除已消费的消息，对于partition，顺序读取磁盘信息。
MONGODB
MongoDB是有C++编写的，是一个基于分布式文件存储开源数据库，在高负载情况下，添加更多的节点，保证服务器性能，MongoDB旨在为WEB应用提供可扩张的高性能数据存储解决方案
MongoDB将数据存储为一个文档，数据结构有键值对组成，起文档类似于json对象，字段值可以包含其他文档，数组和文档数组
