Go 并发编程实战课
晁岳攀(鸟窝)
前微博技术专家,知名微服务框架 rpcx 作者
5434 人已学习
立即订阅
登录后,你可以任选4讲全文学习
推荐试读
换一换
01 | Mutex:如何解决资源并发访问问题?
02 | Mutex:庖丁解牛看实现
05| RWMutex:读写锁的实现原理及避坑指南
课程目录
已完结/共 22 讲
开篇词 (1讲)
开篇词 | 想吃透Go并发编程,你得这样学!
基本并发原语 (11讲)
01 | Mutex:如何解决资源并发访问问题?
02 | Mutex:庖丁解牛看实现
03|Mutex:4种易错场景大盘点
04| Mutex:骇客编程,如何拓展额外功能?
05| RWMutex:读写锁的实现原理及避坑指南
06 | WaitGroup:协同等待,任务编排利器
07 | Cond:条件变量的实现机制及避坑指南
08 | Once:一个简约而不简单的并发原语
09 | map:如何实现线程安全的map类型?
10 | Pool:性能提升大杀器
11 | Context:信息穿透上下文
原子操作 (1讲)
12 | atomic:要保证原子操作,一定要使用这几种方法
Channel (3讲)
13 | Channel:另辟蹊径,解决并发问题
14 | Channel:透过代码看典型的应用模式
15 | 内存模型:Go如何保证并发读写的顺序?
扩展并发原语 (3讲)
16 | Semaphore:一篇文章搞懂信号量
17 | SingleFlight 和 CyclicBarrier:请求合并和循环栅栏该怎么用?
18 | 分组操作:处理一组子任务,该用什么并发原语?
分布式并发原语 (2讲)
19 | 在分布式环境中,Leader选举、互斥锁和读写锁该如何实现?
20 | 在分布式环境中,队列、栅栏和STM该如何实现?
结束语 (1讲)
结束语 | 再聊Go并发编程的价值和精进之路
Go 并发编程实战课
15
15
1.0x
00:00/00:00
登录|注册

19 | 在分布式环境中,Leader选举、互斥锁和读写锁该如何实现?

你好,我是鸟窝。
在前面的课程里,我们学习的并发原语都是在进程内使用的,也就是我们常见的一个运行程序为了控制共享资源、实现任务编排和进行消息传递而提供的控制类型。在接下来的这两节课里,我要讲的是几个分布式的并发原语,它们控制的资源或编排的任务分布在不同进程、不同机器上。
分布式的并发原语实现更加复杂,因为在分布式环境中,网络状况、服务状态都是不可控的。不过还好有相应的软件系统去做这些事情。这些软件系统会专门去处理这些节点之间的协调和异常情况,并且保证数据的一致性。我们要做的就是在它们的基础上实现我们的业务。
常用来做协调工作的软件系统是 Zookeeper、etcd、Consul 之类的软件,Zookeeper 为 Java 生态群提供了丰富的分布式并发原语(通过 Curator 库),但是缺少 Go 相关的并发原语库。Consul 在提供分布式并发原语这件事儿上不是很积极,而 etcd 就提供了非常好的分布式并发原语,比如分布式互斥锁、分布式读写锁、Leader 选举,等等。所以,今天,我就以 etcd 为基础,给你介绍几种分布式并发原语。
既然我们依赖 etcd,那么,在生产环境中要有一个 etcd 集群,而且应该保证这个 etcd 集群是 7*24 工作的。在学习过程中,你可以使用一个 etcd 节点进行测试。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
01 | Mutex:如何解决资源并发访问问题?
02 | Mutex:庖丁解牛看实现
05| RWMutex:读写锁的实现原理及避坑指南
13 | Channel:另辟蹊径,解决并发问题
14 | Channel:透过代码看典型的应用模式
结束语 | 再聊Go并发编程的价值和精进之路
该试读文章来自付费专栏《Go 并发编程实战课》,如需阅读全部文章,
请购买文章所属专栏
立即购买
登录 后留言

精选留言(7)

  • 鸟窝
    置顶
    这一讲和下一讲的代码在 https://github.com/smallnest/distributed
    2020-11-25
    1
    7
  • Kepler
    类似zookeeper 的分布式锁原理,节点宕机对应session 销毁,持有的锁会被释放
    2020-12-10
    7
  • K菌无惨
    老师, Locker是超时解锁是通过NewSession时添加WithTTL这个SessionOption来设置的吗

    作者回复: 对

    2021-01-23
    1
  • 那时刻
    关于思考题,
    如果持有互斥锁或者读写锁的节点意外宕机了,从调用接口来看,与当前节点启动的session有关系,节点宕机之后,感觉应该有与该session相关的处理,比如超时机制,所以它持有的锁会被释放。
    etcd 提供的读写锁,按照rwmutex的实现写锁应该比读锁优先级高,但是在分布式环境下,如此实现的话,我想会增加复杂度和出问题的几率。

    2020-11-23
    1
  • tianfeiyu
    老师,问一下您这边有用过 redis 相关的分布式的并发原语库吗

    作者回复: redis最常用的就是分布式锁

    2021-08-04
  • types
    关于leader选举,几个问题:
    1. 如何获取从节点的信息??
    2. leader选举成功后, resign是只有主节点可以发起吗,还是从节点也可以发起resign

    作者回复: 我认为你这里的说的主节点和从节点,leader指的都是应用程序的,而不是etcd的。
    1.没办法获取,分布式锁不负责这个职责。你可以通过etcd的节点实现,这也是服务发现实现的逻辑
    2.主节点

    2021-07-02
  • myrfy
    还没来得及去看etcd库的代码,盲猜一下。
    第一个问题,我觉得要看场景,如果被锁住的资源可以被重新分配,我相信etcd能检测到持有锁的节点断开,concurrent包里应该有相关的实现把锁释放。但是,如果被锁住的资源非常重要,影响到整个系统的状态,必须要人工介入才能把破损的数据修复,那这个时候自动释放锁反而可能完成更大规模的损失。
    第二个问题,还是得去看代码再说
    2020-11-23
收起评论
7
返回
顶部