ZooKeeper 实战与源码剖析
么敬国
新东方集团首席架构师
18975 人已学习
新⼈⾸单¥59
课程目录
已完结/共 47 讲
ZooKeeper 实战与源码剖析
登录|注册
留言
3
收藏
沉浸
阅读
分享
手机端
回顶部
当前播放: 25 | Raft协议解析
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.75x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
01 | 课程介绍
02 | 内容综述
03 | 什么是ZooKeeper?
04 | ZooKeeper提供什么服务?
05 | 开始使用ZooKeeper
06 | 使用ZooKeeper实现Master-Worker协同
07 | ZooKeeper架构解析
08 | ZooKeeper API简介
09 | ZooKeeper API:Watch示例
10 | 使用ZooKeeper实现分布式队列
11 | 使用ZooKeeper实现分布式锁
12 | 使用ZooKeeper实现选举
13 | 使用Apache Curator简化ZooKeeper开发
14 | 如何安装配置一个ZooKeeper生产环境?
15 | 如何进行ZooKeeper的监控?
16 | 通过ZooKeeper Observer实现跨区域部署
17 | 通过动态配置实现不中断服务的集群成员变更
18 | ZooKeeper节点是如何存储数据的?
19 | 使用ZooKeeper实现服务发现(1)
20 | 使用ZooKeeper实现服务发现(2)
21 | 使用ZooKeeper实现服务发现(3)
22 | Kafka是如何使用ZooKeeper的?
23 | 什么是Paxos协议?
24 | 对比Chubby和ZooKeeper
25 | Raft协议解析
26 | 什么是etcd?
27 | etcd API: KV部分
28 | etcd API:Watch和Lease部分
29 | 使用etcd实现分布式队列
30 | 使用etcd实现分布式锁
31 | 如何搭建一个etcd生产环境?
32 | 存储数据结构之B+tree
33 | 存储数据结构之LSM
34 | 本地存储技术总结
35 | ZooKeeper本地存储源码解析
36 | 网络编程基础
37 | 事件驱动的网络编程
38 | Java的事件驱动网络编程
39 | ZooKeeper的客户端网络通信源码解读
40 | ZooKeeper的服务器网络通信源码解读
41 | ZooKeeper的Request Processor源码解读
42 | Standalone的ZooKeeper是如何处理客户端请求的?
43 | Quorum模式下ZooKeeper节点的Request Processor Pipeline
44 | ZooKeeper的Leader Election
45 | ZooKeeper的Zab协议
46 | 客户端和服务器端交互:Watch和Session
47 | 结课测试&结束语
本节摘要

课前预习

为了有更好的学习效果,建议大家在看视频前把下面的资料看一下:

课件和 Demo 地址

https://gitee.com/geektime-geekbang/geekbang-zk-course

登录 后留言

全部留言(3)

  • 最新
  • 精选
13761642169
使用raft协议的系统,只有leader可以接受写请求,follower接受读请求?

作者回复: Etcd支持以下两种read: 1. Linearizable read(默认): 需要由Leader发起,Leader发送一个请求给所有节点,在收到多数节点的响应之后,才把结果返回给客户端。如果一个follower收到linearizable read的请求,需要转发给leader来处理。 2. Serializable read(使用Get API的话要加WithSerializable选项): Leader和follower都可以在本地处理,时延低。 只有Etcd的leader才能处理write。Follower在接到write请求后,要转发给leader来处理。 参见https://github.com/etcd-io/etcd/blob/master/Documentation/faq.md#do-clients-have-to-send-requests-to-the-etcd-leader: > Raft is leader-based; the leader handles all client requests which need cluster consensus. However, the client does not need to know which node is the leader. Any request that requires consensus sent to a follower is automatically forwarded to the leader. Requests that do not require consensus (e.g., serialized reads) can be processed by any cluster member.

2019-09-29
2
Goober
这里存在一个问题就是 是协议微调的:s5 下线后,s1 上线 这时候已经是(4,3),那么s5 不会再成为leader 所以不存在(3,2)覆盖 (2,2)
2020-02-10
2
H-NL2724
PPT上图的内容有错误好像;raft算法选举部分
2022-12-14
收起评论