add gc remembered set

aixiangbing · Mar 19, 2020 · 75ce806 · 75ce806
1 parent ad2b4b0
commit 75ce806
Show file tree

Hide file tree

Showing 7 changed files with 90 additions and 265 deletions.
diff --git a/content/docs/architecture/distributed/lock/index.md b/content/docs/architecture/distributed/lock/index.md
@@ -27,6 +27,20 @@ else
 end
 ```
 
+#### 缺陷
+
+由于超时时间导致锁被多 Client 同时获取：
+
+1. C1 获取锁 A 成功，但由于 GC 等原因线程挂起，锁 A 过期
+2. C2 获取锁 A 成功
+3. C1 & C2 同时认为自己加锁成功
+
+异步的主从复制 & Master 宕机，导致锁丢失：
+
+1. C1 获取锁 A 成功，Master 宕机，Slave 未同步到锁 A
+2. C2 获取锁 A 成功
+3. C1 & C2 同时认为自己加锁成功
+
 ### RedLock
 
 为了解决 Redis 单点的问题。 Redis 的作者提出了 RedLock 的解决方案。方案非常的巧妙和简洁。 RedLock 的核心思想就是，**同时使用多个 Redis Master 来冗余，且这些节点都是完全的独立的，也不需要对这些节点之间的数据进行同步**。
@@ -98,13 +112,14 @@ if (i > 0) {
 1. 使用 ZK 的临时节点和有序节点，每个线程获取锁就是在 ZK 创建一个临时有序的节点，比如在 `/lock/` 目录下。
 2. 创建节点成功后，获取 `/lock` 目录下的所有临时节点，再判断当前线程创建的节点是否是所有的节点的序号最小的节点。
 3. 如果当前线程创建的节点是所有节点序号最小的节点，则认为获取锁成功。
-4. 如果当前线程创建的节点不是所有节点序号最小的节点，则对节点序号的前一个节点添加一个事件监听。
+4. 如果当前线程创建的节点不是所有节点序号最小的节点，则对节点序号的 **前一个节点** 添加一个事件监听。
 
 
 ### 缺陷
 
-1. ZK 集群的读写吞吐量不高
-2. 网络抖动可能导致 Session 离线，锁被释放
+1. **羊群效应**：当一个节点变化时，会触发大量的 `watches` 事件，导致集群响应变慢。每个节点尽量少的 `watches`，这里就只注册 **前一个节点** 的监听
+2. ZK 集群的读写吞吐量不高
+3. 网络抖动可能导致 Session 离线，锁被释放
 
 ## 参考链接
 

diff --git a/content/docs/architecture/distributed/zk/index.md b/content/docs/architecture/distributed/zk/index.md
@@ -239,7 +239,7 @@ Zookeeper 的另一个作用就是担任分布式事务中的协调者角色，
 
 ZooKeeper 并不保证在每个实例中，两个不同的客户端将具有相同的 ZooKeeper 数据的视图。由于诸如网络延迟的因素，一个客户端可以在另一客户端被通知该改变之前执行更新，考虑两个客户端A和B的场景。如果客户端A将 `/a` 的值从 `0` 设置为 `1` ，客户端B读取 `/a` ，客户端 B 可以读取旧值 0，这取决于它连接到的服务器。如果客户端A 和客户端B 读取相同的值很重要，则客户端B应该在执行读取之前从 ZooKeeper API 方法调用 `sync()` 方法。
 
-对于 Zookeeper 来说，它实现了A可用性、P分区容错性、C中的写入强一致性，丧失的是C中的读取一致性。
+对于 Zookeeper 来说，它实现了A可用性（**非高可用**）、P分区容错性、C中的写入强一致性，丧失的是C中的读取一致性。
 
 ### 我们能做什么
 

diff --git a/content/docs/basic/database/redis/index.md b/content/docs/basic/database/redis/index.md
@@ -439,12 +439,6 @@ Redis 提供以下 BitMap 操作接口：`setBit`、`getBit`、`bitCount`、`bit
 
 在缓存失效的时候（判断拿出来的值为空），不是立即去 `load db` ，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的 `SETNX`）去 `set` 一个 `mutex key` ，当操作返回成功时，再进行 `load db` 的操作并回设缓存；否则，就重试整个 `get` 缓存的方法。
 
-
-## Redis分布式锁
-
-  - 加锁：`Redis.set(String key, String value, String nxxx, String expx, int time)`
-  - 解锁：通过 Lua 脚本执行 `if Redis.call('get', KEYS[1]) == ARGV[1] then return Redis.call('del', KEYS[1]) else return 0 end`
-
 ## 数据淘汰机制
 
 ### 对象过期

diff --git a/content/docs/fromwork/spring/ioc/index.md b/content/docs/fromwork/spring/ioc/index.md
@@ -9,12 +9,12 @@ categories: spring
 
 `Ioc—Inversion of Control`，即“控制反转”，不是什么技术，而是一种设计思想。在Java 开发中，**Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制**。如何理解好Ioc呢？理解好Ioc的关键是要明确“谁控制谁，控制什么，为何是反转（有反转就应该有正转了），哪些方面反转了”，那我们来深入分析一下：
 
-　　- 谁控制谁，控制什么：传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对 象的创建；谁控制谁？当然是IoC 容器控制了对象；控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。
-　　- 为何是反转，哪些方面反转了：有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。
+- **谁控制谁，控制什么**：传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对象的创建；谁控制谁？当然是IoC 容器控制了对象；控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。
+- **为何是反转，哪些方面反转了**：有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。
 
 ## IoC能做什么
 
-　　**IoC 不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序**。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；有了IoC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是 松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。
+**IoC 不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序**。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；有了IoC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是 松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。
 
 ## IoC和DI