diff --git a/docs/high-concurrency/redis-cas.md b/docs/high-concurrency/redis-cas.md
index 4a4cae1..add1469 100644
--- a/docs/high-concurrency/redis-cas.md
+++ b/docs/high-concurrency/redis-cas.md
@@ -1,7 +1,16 @@
 ## 面试题
-
+redis 的并发竞争问题是什么？如何解决这个问题？了解 redis 事务的 CAS 方案吗？
 
 ## 面试官心理分析
+这个也是线上非常常见的一个问题，就是**多客户端同时并发写**一个 key，可能本来应该先到的数据后到了，导致数据版本错了。或者是多客户端同时获取一个 key，修改值之后再写回去，只要顺序错了，数据就错了。
 
+而且 redis 自己就有天然解决这个问题的 CAS 类的乐观锁方案。
 
 ## 面试题剖析
+某个时刻，多个系统实例都去更新某个 key。可以基于 zookeeper 实现分布式锁。每个系统通过 zookeeper 获取分布式锁，确保同一时间，只能有一个系统实例在操作某个 key，别人都不允许读和写。
+
+![zookeeper-distributed-lock](/img/zookeeper-distributed-lock.png)
+
+你要写入缓存的数据，都是从 mysql 里查出来的，都得写入 mysql 中，写入 mysql 中的时候必须保存一个时间戳，从 mysql 查出来的时候，时间戳也查出来。
+
+每次要**写之前，先判断**一下当前这个 value 的时间戳是否比缓存里的 value 的时间戳要新。如果是的话，那么可以写，否则，就不能用旧的数据覆盖新的数据。
\ No newline at end of file
diff --git a/img/zookeeper-distributed-lock.png b/img/zookeeper-distributed-lock.png
new file mode 100644
index 0000000..807e193
Binary files /dev/null and b/img/zookeeper-distributed-lock.png differ