Zookeeper同步机制!!!

优点：解决方案、处理问题能力、架构优化/拓展能力

零、Zookeeper事务

事务id(主从同步Id-每次ack递增+1,64位存储（32位纪元号-leader号，32位自增号）)
每一个操作都将使节点接收到一个Zxid格式的时间戳
ZooKeeper的每个节点维护者两个Zxid值，为别为：cZxid、mZxid。
（1）cZxid：是节点的创建时间所对应的Zxid格式时间戳。
（2）mZxid：是节点的修改时间所对应的Zxid格式时间戳。
一个客户端发起的写请求打到follower时的整个流程。
1.follower将请求转发给leader。
2。leader发起Proposal原子广播事务提议，把消息广播给所有follower。
3.leader等待过半follower写log并返回ack后,将请求提交。
4.将这条日志广播给所有follower。
5.follower提交并给客户端返回。
假如此时发送写请求的follwer写失败了（失败的那小半数），客户端请求读的时候如果又正好请求到这个follwer，读写不一致问题出现，解决：
zookeeper 的读写一致不是在 server 做的，而是 server & client 配合的；client 会记录它见过的最大的 zxid （写成功的zkid），读取的时候，如果 server 发现 这条 zxid 比 server 端的最大 zxid 大，则此follwer抛出异常决绝请求，client 会自动重连到其他server（还在同一个 session） —— 最终会落到有新数据的 server 上，因为半数已经同意；
Zookeeper集群机器数为什么是奇数（选举出来的zkid不是最大值：1、leader死亡复活2、leader脑裂后占少数（3个节点1:2））
①、集群脑裂时（leader通信部分不可达）导致leader选举：3台机：2>2/3=1.5(脑裂A1台机，脑裂B2台机)
②、集群脑裂时（leader通信部分不可达）导致leader选举：4台机：2不大于2/4=2(脑裂A2台机，脑裂B2台机)
③、情况①允许1个节点宕机，情况②也是允许一台机子宕机（1:3时集群可用），故性价比一样且情况②出错几率更高

一、Zookeeper同步机制

一、(Eureka（AP可用性容错性）-各节点平等，
    且有自我保护机制，15分钟内85%的节点没有正常心跳：1、不再移除异常心跳服务2、仍能接收新服务注册和查询3、恢复网络后同步新注册信息到其他节点
二、Zookeeper（CP一致性容错性）-master选举整个集群不可用，选举时长30-120s)
当各个节点已经自我恢复并选举出leader后(根据事务ID和服务器ID，大值当选)，leader就开始和follows进行数据同步了，具体的逻辑可以见{org.apache.zookeeper.server.quorum.LearnerHandler}中：
leader构建NEWLEADER包，内含leader最大数据的zxid, 广播给follows，然后leader根据follower数量为每个follower创建一个LearnerHandler线程来处理同步请求（FIFO数据队列，更新数据时往队列中添加）：leader主线程阻塞，等待超过半数follower同步完数据之后成为正式leader。
follower接收到NEWLEADER包后响应FOLLOWERINFO给leader，告知本方数据最大的zxid值； leader接收到回馈后开始判断：
如果follower和leader数据一致，则直接发送DIFF告知已经同步；
判断这一阶段内有无已经北提交的决议值，如果有，那么
a) 如果follower数据比leader少，leader发送DIFF包将有差异的数据同步过去，同时将follower没有的数据逐个发送commit包给follower要求记录下来；
b) 如果follower数据zxid更大（oldLeader挂了,newLeader当选之后,oldLeader复活作为follower），此时oldLeader取出当前最新的txid，去leader上查找，没有此txid，则丢弃本地的txid，再递归查找上一个txid，不一致就一直丢弃，直到找到与newLeader上txid一致，并且数据一致；从该txid往后开始同步数据
如果这一阶段没有提交的决议，直接发送SNAP包将快照同步给follower
以上消息完毕后，LEADER发送UPTODATE包告知follower当前数据已同步，等待follower的ACK完成同步过程。
Zookeeper leader 选举　　
半数通过(服务器为奇数的原因)
– 3台机器 挂一台 2>3/2
– 4台机器 挂2台 2！>4/2

二、Redis：（1、内存操作2、单线程无上下文切换及锁冲突3、hash结构存储4、io多路复用）

Redis为什么快：
1、纯内存操作2、单线程无上下文切换及锁（但是RDB持久化时会fork一个子进程写新文件覆盖旧RDB）
3、hash数据结构简单（string、list、set、hash）4、IO多路复用（多个网络连接复用一个线程，空闲时阻塞，有一个或多个流有io事件时，系统组件回调通知，redis轮询所有的（发出事件的）流并依次顺序的处理就绪的流）
多个socket链接复用同一个线程处理;使用epoll策略，实现哪些socket有通讯，处理那些socket、 高效
只有存在大量的空闲连接和不活跃的连接的时候，使用epoll的效率才会比select/poll高
删除策略及剔除算法：一、主动删除（每秒10次检查，每次检查100个设置了过期时间的key，超过25%过期则删除后重复此动作） 二、被动删除（使用时检查） 
三、超过最大内存触发清理算法（基于设置了过期时间且内存将满条件）：
1、最少使用 2、最少使用次数 3、快过期 4、随机 5、不淘汰，写入报错
64位系统Redis的存储极限是系统中的可用内存值
Redis是个单线程模型，客户端过来的命令是按照顺序执行的，所以想要一次添加多条数据的时候可以使用管道，或者使用一次可以添加多条数据的命令
SLOWLOG [get/reset/len]
slowlog-log-slower-than  //它决定要对执行时间大于多少微秒(microsecond，1秒 = 1,000,000 微秒)的命令进行记录  
slowlog-max-len   //它决定 slowlog 最多能保存多少条日志  
当发现redis性能下降的时候可以查看下是哪些命令导致的
redis进行RDB快照的时机（在配置文件redis.conf中）
save 900 1  //表示900秒内至少一个键被更改则进行快照。  
save 300 10  //表示300秒内10条被更改则快照  
save 60 10000  //60秒内10000条  
Redis自动实现快照的过程
1、redis使用fork函数复制一份当前进程的副本(子进程)
2、父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件
3、当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。
注意：redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。
aof方式的持久化是通过日志文件的方式。默认情况下redis没有开启aof，可以通过参数appendonly参数开启。
appendonly yes  
aof文件的保存位置和rdb文件的位