2019-10-26学完3-7节我自己总结了一下个人的理解：
分布式协调与同步的场景中需要解决一些通用问题
1.分布式系统中，多个节点都需要访问一个临界资源，但是同一时刻只能有一个节点可以访问，为了解决这个问题就是要通过分布式互斥来实现，老师说的有你没我，有我没你；分布式锁就是实现分布式互斥的一种实现方式
2.分布式系统中，多个节点需要同时写一份相同的数据，怎么保证数据写的是一致的呢？需要一个节点来协调，这个协调节点叫做leader，它是怎么产生的呢？是通过选举产生的，这就是分布式选举；
3.分布式系统中，多个节点达成某一项共识可以通过选举（投票）的方式实现，选举不简单是少数服从多数，还有一些拓展：投票的时候考虑优先级，考虑权重，考虑代理等
4.分布式系统中除了互斥，达成共识还有协同作战：分布式事务，多个节点同时做一件事，要么全成功，要么全失败；本来单机事务是通过数据库（Mysql）的多版本MVCC实现的，现在在分布式环境中，每个节点都有数据库，不能实现分布式事务了，现在需要通过程序来模拟实现单机事务的特性ACID。考虑实际情况，XA协议下的2阶段和3阶段提交都不能很好的满足需求，衍生出了新的理论(BASE)来实现展开作者回复: 总结得很到位，加油！
10
2019-10-07分布式锁是实现互斥的一种手段。 1 10
2019-10-311 .redis 不用通过超时来释放锁，DEL操作可以直接释放不用等到超时
2. redis 官方已经明确说明不推荐 setnx 来实现分布式锁了(https://redis.io/commands/setnx) 官方给出了 the Redlock algorithm 各语言的实现版本是来实现分布式锁的机制，比如JAVA的实现版本(https://github.com/redisson/redisson) 所以从可靠性来讲并不比zk的方案差 2 8
2019-10-09分布式互斥是在分布式系统中存在多个节点共享某个资源或临界区，任何时刻只允许一个进程访问资源或执行临界区，而分布式锁正好是解决分布式互斥的一种方法。作者回复: 总结得很到位，加油！
5
2019-10-07老师，想问一个问题，通过zoomkeeper来实现分布式锁，等发生网络中断的对应的临时节点会消失来实现分布式锁的异常情况，我们知道进程挂掉会触发相应的文件引用计数减一，一般情况下会把连接关闭，但是如果是正常的网络中断引起的临时节点消失，从而其他进程获取锁，但是可能发生网络中断的进程业务并没有处理完成，这个该怎么办？ 1 4
2019-12-14给库存数加锁这个例子写的不好。文中说到，
我们能想到的最简单方案就是，给吹风机的库存数加一个锁。当有一个用户提交订单后，后台服务器给库存数加一个锁，根据该用户的订单修改库存。而其他用户必须等到锁释放以后，才能重新获取库存数，继续购买。
既然说了其他用户必须等到锁释放后才能重新获取库存，那为什么后面又说A和B同时获得库存数呢？这不矛盾了吗？还有这个库存数是存在哪里的？如果存在公共服务器上，类似于redis那个例子，那多个用户抢同一把锁也没问题啊，反正只有一个能抢到，等一个用户释放锁，下一个用户再获得锁。展开 3
2019-10-26这课程买的太赚了 3
2019-10-18老师关于redis的分布式锁还有几个问题
1、setnx加过期时间的原子性问题（目前应该已经解决）
2、锁的续期问题
3、如果redis集群或者主从模式下只写入一个节点时挂掉导致锁失效
期望老师答疑时详细说一下展开 3
2019-10-14最后一段有些问题 应改为若本进程为写请求，则向比自己序号小的最后一个请求节点注册监听事件，因为写和写之间也是互斥的。编辑回复: 这个问题已经修正，非常感谢你的反馈~
3
2019-10-13请老师确认一下redis是否会为一个KEY建立等待队列。我以为，Redis的分布式锁根本没有队列，收到setnx返回为0的进程会不断的重试，直到某一次的重试成为DEL命令后第一个到达的setnx从而获得锁，至于此进程在等待获得锁的众多进程中是不是第一个发出setnx的，redis并不关心。 3 2- 2019-10-07分布式锁与分布式互斥的关系是什么呢？
我觉得分布式互斥是前提条件或者说实现目的，而分布式锁是手段或者说是实现方法。
还有文章中有2个地方不理解。一个是那个zookeeper实现分布式锁的，写请求为什么说是要等待比自己小的读请求结束，如果是比自己小的写请求就不用等待了吗？我理解是，自己为读请求就等待比自己小的写请求结束，写请求就等待所有比自己小的所有请求结束。另一个不理解也是类似问题，就是下面那个写watch应该是等等比自己小的那个事件就结束添加watch事件吧？ 2 
2019-11-07分布式锁实现了分布式互斥的集中式算法？ 1
2019-10-12redis的分布式锁如何实现排队？ 1 1
2020-02-03老师您好，在读你这篇专栏时，对基于Zookeeper实现的分布式锁有几个疑问？
1.从应用程序角度，对Zookeeper的请求应该只有一个，获取分布式锁请求。这个请求到达Zookeeper后如何被拆分成“读请求”和“写请求”的？
2.文中“Zookeeper实现分布式锁”的第4个步骤，和“解决羊群效应”的第3个步骤中，提到的“节点编号”和“序号”是同一个含义吗？
3.“解决羊群效应”的第3个步骤，没太想明白，可能是存在第1个问题的困扰导致的。能否请老师补充一张时序图。
谢谢。
2020-01-13老师，数据库分布式锁的时候，如果我查询库存直接在库存表上加for update，岂不是不用独立一张表去做分布式了，也不存在您说的问题。
2020-01-09问下 吹风机那个例子,AB下单时候,不管谁先下单,都会把库存锁住了, 另外一方不能再去操作库存了呀 等对方获取到库存锁时候,判断下是否还有,不会卖出去三个呀? 1
2020-01-03老师你好，我对这段话理解不了，请问一下要怎么理解？
想象一下，用户 A 想买 1 个吹风机，用户 B 想买 2 个吹风机。在理想状态下，用户 A 网速好先买走了 1 个，库存还剩下 1 个，此时应该提示用户 B 库存不足，用户 B 购买失败。但实际情况是，用户 A 和用户 B 同时获取到商品库存还剩 2 个，用户 A 买走 1 个，在用户 A 更新库存之前，用户 B 又买走了 2 个，此时用户 B 更新库存，商品还剩 0 个。这时，电商就头大了，总共 2 个吹风机，却卖出去了 3 个。
你说“实际情况是，在A更新库存之前，用户B又买走了两个，此时B更新库存，商品还剩0个。”可是这段话是在描述加了锁以后的情况吧，这种情况下B怎么嫩俄国更新库存呢？还是说这段话的前提是没有加锁的时候呢？谢谢展开
2019-12-30老师好，解决羊群效应方法的第三步：watch 监听比自己序号小的最后一个请求的释放，这个释放如果是进程崩溃导致的怎么办，比如被监听的那个节点并没有获取到锁，但因为连接断了导致临时节点删除，那是不是同一时刻有多个进程获取到锁，不知道我描述清楚了没，我尽力了
2019-12-24分布式技术原理与算法#Day5
就像前面说的，无论是集中式分布式还是令牌环，都具有资源访问的排他性，就是厕所无法两个人共用，因此厕所上都有一把锁。
而这个锁不一定是门上的锁，它可以是一种标记，比如厕所门上面的led显示使用中，所有人都能看到，那么这个标记就是锁。它的存在意义就是为了保证它锁保护的资源同一时刻只有一个线程能访问。
分布式环境下就要稍微麻烦一些，比如有多个办公室都用这一个厕所，那么还使用单机锁就是每个办公室都能看到显示厕所的使用状态的大屏。而且情况可能比这个要复杂一点，假设当前有五个人要上厕所，但只有两个坑位，该谁先上呢？而且假设有的人宽一些，需要占用两个坑位(甚至多个坑位)。那你说先来的先占吧，先来的不管占用几个坑位都先锁上这几个坑位的门，然后在大屏上显示剩余坑位。感觉不错，不过假设五个人在不同的屋子，胖子和瘦子看屏幕都满足自己的坑位于是同时走到厕所，无论谁先锁定这个坑位，另一个都无法通畅，因为两个坑位被申请出三个。于是分布式锁就出现了……
第一种是基于数据库实现的，就是有一张锁表，锁住就加一条记录，释放就删除一条记录，上述同时打申请的状况由数据库保证不发生，这个能满足并发量不大的场景，而且数据库存在单点故障，以及如果某个人一直占坑会导致死锁。
第二种是基于缓存实现，其实就是把数据库换成了分布式缓存，首先它写内存，比第一种快，然后他有队列保证先后顺序，最后他有超时机制不会造成死锁，最最后他跨集群部署不存在单点问题。第二种可以看作第一种的优化方案。
第三种是基于zookeeper。它的优势在哪里呢？原来访问相同资源的进程是互相不知道的，比如胖子并不知道瘦子在占用资源。ZK为共享资源单独划出一个目录。来申请该共享资源的进程会按时间顺序领到一个编号和一个资源使用滚动屏，记录了其他进程的编号和资源使用类型。编号小的获得锁，编号第二小的会看前一个在干啥，如果自己想读但是前面那个在写，那么就等待。如果自己想写更得等待。其实为了避免羊群效应，如果自己是读请求，就监控之前的最后一个写请求，而如果自己是写请求，就监控自己前一个请求即可。
Zk较为成熟，且案例也比较多，其实实现分布式锁实现复杂度最小的，且天然高可用。但性能肯定不如缓存。展开
2019-11-26分布式锁的锁就是分布式互斥的，各个线程通过随机算法获得这个锁。