zk的学习
1、zk框架是分布式的开源式的应用程序协调服务是Hadoop和HBase的一个组件，zk主要包括配置维护、域名服务、分布式同步、组服务等。zk主要和dubbo一起用用于分布式框架中，Dubbo框架主要用于开发的提供者和服务消费者，其中Dubbo服务提供者和消费者都会在zk注册自己的URL，但是服务消费者还要能通过订阅拿到注册者的URL，以便于在后面的程序中去调用服务提供者，当服务提供者发生变化时候，也会通过订阅进行通知。
2、Paxos算法和zk协议
Paxos算法叫做分布式选举算法，zk使用的是ZAB协议，原子广播的方式，二者具有相同的地方，都有一个Leader，用来协调N个Follower的运行，Leader要超过等待半数的Follower做出正确反馈之后才能进行提案。同时二者都有一个参数来代表Leader的周期。不同之处是二者的使用系统是不一样的，
Paxos用来构建分布式一致性状态机系统，而ZAB用来构建高可用的分布式数据主备系统
3、zk的节点类型
持久、持久顺序、临时、临时顺序四种
持久：创建之后一直存在，除非删除，创建节点的客户端失效也不会影响该节点
持久顺序：跟持久一样，但是他是在父节点创建下一个子节点的时候记录下每一个子节点创建的先后顺序，会给每一个子节点加上一个数字后缀
临时：创建客户端会话失效，而不是链接中断，节点就没有了，不能创建子节点
临时顺序：和临时类型一样，不过父节点在创建子节点的时候会和持久顺序一样记录下子节点的创建顺序。
4、zk的节点watch监控通知是永久的么？
不是，因为如果watch事件是一个一次性的触发器，如果当设置watch的节点发生变化时候（变更或者删除），此时会进行通知，但是没有设置watch事件的客户端不通知。
为什么不是永久的，因为如果服务端频繁的变动和修改这会很大程度消耗性能，实际的应用中，我们只需要知道最新的变更即可，不需要每次都进行通知。
5、zk的部署方式：单机，集群
zk的集群中的机器角色：Leader、follower
集群中最少要几台机器：集群中最低3台机器（2N+1）
为啥集群中机器数目是奇数台：主要为了选举算法（过半即可存活）
6、集群中支持动态添加机器么？
所谓的动态添加机器，也就是我们常说的水平扩容，zk在这方面的支持不是很好。
实现主要有两种实现方式：全部重启：关闭所有的zk服务，修改配置之后统一重启，不会影响客户端的会话
逐个重启：每关闭一个zk服务然后再重启，在实际使用中常用的一种方式
7、zk是如何保证事务的一致性的？
zk采用的递增的事务ID来保证，所有的proposal都在被提出的时候加上了zxid，zxid实际上市一个64位的数字，高32位是epoch用来标识leader是否发生了改变，如果有新的leader产生出来，epocjh会自增，低32位采用递增计数，当新产生proposal的时候，会依据数据库的两阶段，首先向其他的server发送事务执行请求，超过半数的机器能够执行并且成功吗，那么就会开始执行
8、zk是如何选取主Leader的？
当Leader崩溃或者Leader失去大多数的F欧欧、follower时候，zk进入恢复模式
zk的znode类型有四种，持久化目录结构、持久化顺序目录结构、临时目录结构、临时顺序目录结构
zk的通知机制：client 端会建立一个watcher时间，当该znode发生变化视乎，client会收到zk的tognzhi ,然后water通知给各个客户端从而改变配置
9、zk的配置管理
程序分布式的部署在不同的机器上，将程序的配置信心放到zk的znode下，当配置发生变化时候，znode繁盛变化，通过改变zk中的某个目录节点的内容，利用water】通知各个客户端，从而更改配置
10、zk的命名服务：
通过指定的名字来获取资源或者服务的地址，zk创建一个全局的路径，该路径就是指向集群中的集群，提供的服务的地址或者远程的对象
11、分布式通知和协调
对于系统调度来说，操作人员发送通知实际上是通过控制台改变某个节点的状态，然后zk将这些bia发送给注册了这个几点的warcher的所有客户端
对于执行情况：每一个工作进程都在某一个目录下创建一个临时及诶点，兵携带工作的进度数据，这样汇总的数据就可以监控目录子节点的变化获得工作进度的全局情况
12、机器中为啥会有master？
在分布式环境中，有些业务逻辑只需要在一台机器上执行，其他的机器可以共享这一结果，从而能够大大减少工作和重复计算，所有需要master选举
13、zk的集群中服务器之间是如何进行通信的？Leader服务器会和每一个Follower/Observer服务器建立TCP连接，同时为每一个F/O都建立一个LearnHander的实体，LearnHander主要负责Leader和F/O之间的网络通讯，包括数据的同步，请求转发和Proposal提议的投票等，Leader服务器保存了所有的F/O的LearnHandler
14、zk是否会自动进行日志清理？如何进行清理的？
zk自己不会进行日志清理，需要运维人员进行清理
15、zk的选举过程
当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法使用ZAB协议：
① 选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；
② 选举线程首先向所有Server发起一次询问(包括自己)；
③ 选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；
④ 收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；
⑤ 线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数， 设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。
通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数最好是奇数2n+1，且存活的Server的数目不得少于n+1
16、master/slaver之间如何进行通信：Storm定期扫描
PtBalancer：节点监听
17、节点变多时，PtBalancer速度会很慢：原因：1、zk有1MB的传输限制，实践中znode必须相当小，而队列成千上万的信息，非常大。2、节点比较多的时候，启动自然就变慢，使用Queue会导致很多的znode，此时需要显著增加initlimit和syncLimit（初试·限制和同步限制）3、znode很大的时候很难清理。需要创建额外的程序专门进行清理 4、当包含很大量的znode时候，zk的性能会显著下降 5、zk的数据库完全放在内存中，大量的znode’会占用大量的内存空间和资源
18、客户端对ServerList的轮询机制是什么？
采用随机的轮询机制，客户端在初始化的时候会将所有的Server保存在一个List中，然后随机打散，形成一个环，之后从0号位开始一个个的使用。如果客户端在切换Server过程中耗时较长那收到SessinExpired的风险
19、客户端是如何正确的出来CONNECTIONLOSS（链接断开）和SESSIONEXPIRED（session过期）的两类链接异常
在zk中使用tcp进行链接，客户端和服务器使用是长连接，在SESSION_TIMEOUT时间内，服务器会确定客户端是否链接正常（客户端会定时向服务端定时发送heart_beat），服务器重启下次的SESSION_TIMEOUT相同，在正常情况，session一直是有效的，zk集群中所有机器都保存session信息，出现问题后，也就是客户端和服务器的链接中断了（客户端链接服务端的那边机器zk挂了），这时候客户端会主动从地址列表（初始化时候传入构造方法的参数ConnectString）中选择新的地址进行连接。
20、我每次都能收到每次节点的变化通知：答案是否定的，原因在于：当一次数据修改，通知客户端，客户端再次注册watch，在这个过程中，可能数据已经发生了许多次数据修改，因此，千万不要做这样的测试：”数据被修改了n次，一定会收到n次通知”来测试server是否正常工作。（我曾经就做过这样的傻事，发现Server一直工作不正常？其实不是）。即使你使用了GitHub上这个客户端也一样。不能为临时节点创建子节点
21、可以直接拒绝单个IP对zk的访问和操作吗？
本身不提供这样的功能，只提供了对单个IP链接数的限制，可以通过更该iptables来实现对单个ipde限制
22、在getChildren(String path, boolean watch)是注册了对节点子节点的变化，那么子节点的子节点变化能通知吗
不能
- 创建的临时节点什么时候会被删除，是连接一断就删除吗？延时是多少？
连接断了之后，ZK不会马上移除临时数据，只有当SESSIONEXPIRED之后，才会把这个会话建立的临时数据移除。因此，用户需要谨慎设置Session_TimeOut
24.Zookeeper做了什么？
1.命名服务 2.配置管理 3.集群管理 4.分布式锁 5.队列管理
25.Zookeeper同步流程
选完Leader以后，zk就进入状态同步过程。
- Leader等待server连接；
2 .Follower连接leader，将最大的zxid发送给leader；
3 .Leader根据follower的zxid确定同步点；
4 .完成同步后通知follower 已经成为uptodate状态；
5 .Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。
<ignore_js_op>
20.Zookeeper工作流程-Leader
1 .恢复数据；
2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；
3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。
PING 消息是指Learner的心跳信息；
REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；
ACK消息是 Follower的对提议的回复，超过半数的Follower通过，则commit该提议；
REVALIDATE消息是用来延长SESSION有效时间。
<ignore_js_op>
21.Zookeeper工作流程-Follower
Follower主要有四个功能：
1.向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
2.接收Leader消息并进行处理；
3.接收Client的请求，如果为写请求，发送给Leader进行投票；
4.返回Client结果。
Follower的消息循环处理如下几种来自Leader的消息：
1 .PING消息： 心跳消息；
2 .PROPOSAL消息：Leader发起的提案，要求Follower投票；
3 .COMMIT消息：服务器端最新一次提案的信息；
4 .UPTODATE消息：表明同步完成；
5 .REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；
6 .SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。
dubbo框架学习
dubbo框架是什么？
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务台有调用方案，以及SOA服务治理方案，提供了分布式服务的远程服务调用，实质就是服务调用（同于以前的Web Service模式调用）
优点：远程通讯，提供了多种基于长连接的NIO的框架抽象封装，包括多线程、序列化、请求响应的信息交换方式
集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持、软负载均衡、失败容错、地址路由、动态配置等集群支持
自动发现：基于注册中心目录服务，使消费者能够找到服务提供者。从而实现地址透明，使服务提供方能平滑增加
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）
dubbo的架构
角色说明–provider：暴露服务的服务提供方
consumer：调用远程服务的服务消费方
registery：服务注册与发现的注册中心
monitor：统计服务的调用次数和调用时间的监控中心
container：服务运行时的容器
dubbo调用的过程：
1、首先服务容器负责启动，加载运行服务提供者
2、然后zai 服务提供者启动时候，向注册中心注册自己的提供的服务
3、接着服务提供者在启动时候，向注册中心订阅自己的所需要的服务
4、最后注册中心将服务提供者的地址返回给消费者，如果有变更，注册中心会基于长连接进行推送变更数据给消费者
5、服务消费者，从提供者的地址列表中，基于软负载均衡算法，选一台调用者进行调用，如果调用失败，再重新选一台
6、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
负载均衡算法的分类：
轮询法（顺序轮流）、随机法（系统随机算法）、源地址哈希法（客户端IP通过哈希函数地址对应）、加权轮询法（配置高、负载低的机器配置更高权重，反之也可）、加权随机法（同于加权轮询，但是使用的是按权重随机请求）、最小链接数法（选取积压链接数最小的一台服务器处理当前请求）（六大算法）
nginx的五种均衡算法：
轮询法（默认）、weight（指定轮询几率，weight和访问比例成正比）、ip_hash（解决session的问题）、fair（第三方，按照后端的访问时间来分配）、url_hash(按照url的hash结果来分配)第三方
什么是web的负载均衡？
web 负载均衡的作用就是把请求均匀的分配给各个节点，它是一种动态均衡，通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把请求理分配出去。对于不同的应用环境(如电子商务网站,它的计算负荷大;再如网络数据库应用，读写频繁，服务器的存储子系统系统面临很大压力;再如视频服务应用，数据传输量大，网络接口负担重压。)，使用的均衡策略 (算法)是不同的。 所以均衡策略(算法)也就有了多种多样的形式，广义上的负载均衡既可以设置专门的网关、负载均衡器，也可以通过一些专用软件与协议来实现。 在OSI七层协议模型中的第二(数据链路层)、第三(网络层)、第四(传输层)、第七层(应用层)都有相应的负载均衡策略(算法)，在数据链路层上实现负载均衡的原理是根据数据包的目的MAC地址选择不同的路径;在网络层上可利用基于IP地址的分配方式将数据流疏通到多个节点;而传输层和应用层的交换(Switch)，本身便是一种基于访问流量的控制方式，能够实现负载均衡。
DNS轮询：早期的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。
反向代理服务器：使用代理服务器，可以将请求转发给内部的服务器，使用这种加速模式显然可以提升静态网页的访问速度。然而，也可以考虑这样一种技术，使用代理服务器将请求均匀转发给多台服务器，从而达到负载均衡的目的。
地址转换网关：支持负载均衡的地址转换网关，可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。
OSI七层网络模型
物理层
数据链路层
网络层
传输层
会话层
表示层
应用层