6 周总结

本周主要有的内容主要有两个主题：zk和Doris（nosql存储）



一、zk

zk在分布式的各种框架、中间件里面算是常客了。比如分布式任务elastic-job，RPC框架dubbo、motan等。



现在我们看看zk主要能完成哪些事情：



主要场景一、分布式锁 （临时顺序节点）

我们的应用需要一个任务去完成某件事情A，这个事情的代价就是要花费10W RMB，如果机器1执行了，机器2也执行了那么就会导致10W的损失。这个时候我们需要一种方式在任何时候都只有在服务器集群中找到一台机器来完成这个事情。zk解决这个问题的基本思路是：每台服务器都在zk的指定目录下面创建一个临时顺序节点并且前一个节点的变化，创建的临时节点内容可以是机器的id或者机器的IP，服务端在触发任务的时候判定最小的值和自己机器是否匹配，匹配则拿到锁。另外一旦有某台机器下线，则移除目录下面对应的临时节点即可。



主要场景二、节点订阅、发布（watcher）

常用的RPC框架Dubbo就用zk作为服务发现的中间件。服务放把自己的相关信息放到一个节点下，客户端订阅这个节点。服务放的上下线会产生事件通知到客户端，客户端更新本地的映射地址达到服务治理的目的。



主要场景三、配置中心

节点内存储少量的配置信息，客户端watcher节点，客户端发布更新内容会自动同步到客户端。



二、集群

单机的zk在一定规模的业务下是不足以支撑业务的，我们同样需要保证zk的高可用，高可用要怎么办呢，是的，用集群! 基本的思路就是一个leader，N个follower。为了保证能选出正确的leader，zk实现了zab协议。为了保证数据的一致性，实现了分布式一致性算法paxos。



三、缺陷

• 如果机器A 拿到了zk集群的锁然后运行任务， 但是运行过程中和zk断开了链接，这个时候zk的客户端会按照你指定的重试策略重新链接zk，zk集群也会相应的等待一段时间。但是超过一段时间之后，zk的集群就会重新选主，这个时候可能机器B拿到了锁，然后这个时候A可能还没执行完，这就出问题了。这个时候可能有什么说用Redis，redis也有自己的问题，如果一台机器拿到了redis的锁，然后执行的过程中服务器down了，这个锁就一直不能释放。你可能觉得给这个锁设置一个超时时间，可是你不确定你的任务执行时间的情况了，你是不能确定多久合适，设置久了浪费资源，设置短了就又回到了原来的问题。所以一般来说这类任务为了稳妥，还得起一个线程来监控当前持有锁的程序是否正常，正常就为这个锁延长时间。

• ZK设计之初就不是为了存储大量高并发的数据，所以在这块上的性能比redis差很多。所以在服务订阅，集群管理这些低并发场景是非常适合的。



四、关于basic paxos的解释

我们把场景定位mysql的主从同步，1个master，3个slave。然后我们采用实现了paxos思想保证slave之间的数据一致。那么这个时候的具体过程是什么样子的呢？



首先我们这里假定网络是不会出现错误，比如我传入一个a=2,网络给我改成a=1. 网络允许波动和延迟。



简单描述下数据master和slave同步的过程(异步模式)：往master写数据的时候会先写入到binlog中，然后写入到master的存储中。slave在连接上master之后会开启一个线程B用于接收从master发送过来数据塞入relay log（中继日志），master会有开启一个线程A读取binlog然后和B对应。具体的实现细节中有非常多要考虑的地方，现在我们就考虑一个，怎么确保3个slave读到的都是相同的数据，总不能让第一台slave读到binlog的第5条记录 ，第二台slave读到binlog的第6条记录吧。



paxos过程描述：（Proposer,acceptor,leaner）

1. 线程A读取到一条数据，发送给三个slave Proposer，格式大概就是(sqlId,V1). V1是version1的简写。

2. 三台slave检查本地存储饿sqlid，如果发现没有这个id，那就返回给A (null,V1)，那么线程A就发送确认消息（sql,V1）,相当于给sqlId复制为sql，然后三个slave把这sql写入到本地的relay log中，并返回给master写入成功的消息，同时这个消息要同步给leaner，leaner需要知道写入的返回结果是什么。



是的，这个就是最简单的逻辑，二阶段提交。



问题在于发生异常了咋办！



1. 发送(sqlId,V1)的时候，如果一个返回都是（null,V1），那就直接写入（sql,v1）。