feat: chapter 10

Author: honkinglin

docs/grokking/chapter-10.md

@@ -91,4 +91,19 @@
      - 当 `Count >= 3` 时：  
        - 拒绝该请求
 
-![图10-3](/grokking/f10-3.png)
+![图10-3](/grokking/f10-3.png)
+
+**我们这套算法存在哪些问题？**  
+
+1. **固定窗口的局限性**  
+   这是一个固定窗口算法，因为我们在每分钟结束后重置了“StartTime”。这种做法可能导致每分钟允许的请求数翻倍。想象一下，如果 Kristie 在某一分钟的最后一秒内发送了 3 个请求，那么她可以在下一分钟的第一秒再次发送 3 个请求，从而在两秒内总共发出 6 个请求。对此问题的解决方案是使用滑动窗口算法，我们会在后面进行讨论。  
+
+2. **原子性问题**  
+   在分布式环境中，“先读后写”的操作模式会引发竞态条件。举例来说，如果 Kristie 当前的 `Count` 为 2，而她又同时发起两个新请求，如果这两个请求分别被两个并发进程处理，并且都在任一进程更新 `Count` 之前读取到了 `Count=2`，那么每个进程都会错误地认为 Kristie 还可以再发送一次请求，导致没有正确执行限流。  
+
+![图10-4](/grokking/f10-4.png)
+
+如果我们使用 Redis 来存储键值数据，一种解决原子性问题的方法是在读写操作期间使用 Redis 锁。然而，这会让同一用户的并发请求被顺序化处理，降低吞吐量并增加系统复杂度。我们也可以使用 Memcached，但也同样会面临类似的复杂性。  
+
+如果我们使用简单的哈希表，可以为每条记录实现自定义的加锁机制，以解决上述的原子性问题。
+