|
单个技术岗？当然不。
前端、后端、客户端、音视频技术……
我们想办法，搞来了整个淘系这一年，所有程序员的技术分享。
对这些资料进行整理后，我们得以窥见淘系过去一年的核心技术进展。
一起来看看。（文末附传送门）
过去一年，淘系的技术进展
这些技术进展，既有各个技术岗单独的研究成果，又有整个大型项目的迭代升级 （如天猫双11）。
其中技术岗，又主要包括前端、后端、算法、客户端、测试、音视频与图像、端智能与MNN……
以关注度最高的2020天猫双11项目为例。
-
每个Server会发出一个投票，第一次都是投自己，其中投票信息 = (myid，ZXID)
-
收集来自各个服务器的投票
-
处理投票并重新投票，处理逻辑：优先比较ZXID，然后比较myid。
-
统计投票，只要超过半数的机器接收到同样的投票信息，就可以确定leader，注意epoch的增加跟同步。
-
改变服务器状态Looking变为Following或Leading。
-
当 Follower 链接上 Leader 之后，Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对，比对结果要么回滚，要么和 Leader 同步，保证集群中各个节点的事务一致。
-
集群恢复到广播模式，开始接受客户端的写请求。
3.3 脑裂
脑裂问题是集群部署必须考虑的一点，比如在Hadoop跟Spark集群中。而ZAB为解决脑裂问题，要求集群内的节点数量为2N+1。当网络分裂后，始终有一个集群的节点数量过半数，而另一个节点数量小于N+1, 因为选举Leader需要过半数的节点同意，所以我们可以得出如下结论：
有了过半机制，对于一个Zookeeper集群，要么没有Leader，要没只有1个Leader，这样就避免了脑裂问题
4 一致性协议之 ZAB
建议先看下 浅谈大数据中的2PC、3PC、Paxos、Raft、ZAB ，不然可能看的吃力。
4.1 ZAB 协议介绍
ZAB (Zookeeper Atomic Broadcast 原子广播协议) 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的一致性协议。基于该协议，ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。
分布式系统中leader负责外部客户端的写请求。follower服务器负责读跟同步。这时需要解决俩问题。
Leader 服务器是如何把数据更新到所有的Follower的。
Leader 服务器突然间失效了，集群咋办?
因此ZAB协议为了解决上面两个问题而设计了两种工作模式，整个 Zookeeper 就是在这两个模式之间切换：
-
原子广播模式：把数据更新到所有的follower。
-
崩溃恢复模式：Leader发生崩溃时，如何恢复。
4.2 原子广播模式
你可以认为消息广播机制是简化版的 2PC协议，就是通过如下的机制保证事务的顺序一致性的。
（编辑：长春站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
