diff --git a/README.md b/README.md
index e98496e..ef9b81c 100644
--- a/README.md
+++ b/README.md
@@ -4,9 +4,7 @@
 [![original](https://img.shields.io/badge/original-%E4%B8%AD%E5%8D%8E%E7%9F%B3%E6%9D%89-blue.svg)](https://github.com/doocs/advanced-java)
 [![PRs Welcome](https://img.shields.io/badge/PRs-Welcome-brightgreen.svg)](http://makeapullrequest.com)
 
-本系列知识出自中华石杉，石杉老师拥有 10 余年 BAT 一线大厂架构经验，简直神级人物。我对这部分知识做了一个系统的整理，方便学习查阅。
-
-> 微信公众号：石杉的架构笔记(shishan100)
+本系列知识出自中华石杉，我对这部分知识做了一个系统的整理，方便学习查阅。
 
 ## 分布式系统
 
@@ -69,7 +67,7 @@
 - [如何保证 Redis 高并发、高可用？Redis 的主从复制原理能介绍一下么？Redis 的哨兵原理能介绍一下么？](/docs/high-concurrency/how-to-ensure-high-concurrency-and-high-availability-of-redis.md)
 - [Redis 的持久化有哪几种方式？不同的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？](/docs/high-concurrency/redis-persistence.md)
 - [Redis 集群模式的工作原理能说一下么？在集群模式下，Redis 的 key 是如何寻址的？分布式寻址都有哪些算法？了解一致性 hash 算法吗？如何动态增加和删除一个节点？](/docs/high-concurrency/redis-cluster.md)
-- [了解什么是 Redis 的雪崩和穿透？Redis 崩溃之后会怎么样？系统该如何应对这种情况？如何处理 Redis 的穿透？](/)
+- [了解什么是 Redis 的雪崩和穿透？Redis 崩溃之后会怎么样？系统该如何应对这种情况？如何处理 Redis 的穿透？](/docs/high-concurrency/redis-caching-avalanche-and-caching-penetration.md)
 - 如何保证缓存与数据库的双写一致性？
 - Redis 的并发竞争问题是什么？如何解决这个问题？了解 Redis 事务的 CAS 方案吗？
 - 生产环境中的 Redis 是怎么部署的？
diff --git a/docs/high-concurrency/redis-caching-avalanche-and-caching-penetration.md b/docs/high-concurrency/redis-caching-avalanche-and-caching-penetration.md
new file mode 100644
index 0000000..1e487ff
--- /dev/null
+++ b/docs/high-concurrency/redis-caching-avalanche-and-caching-penetration.md
@@ -0,0 +1,42 @@
+## 面试题
+了解什么是 redis 的雪崩和穿透？redis 崩溃之后会怎么样？系统该如何应对这种情况？如何处理 redis 的穿透？
+
+## 面试官心理分析
+其实这是问到缓存必问的，因为缓存雪崩和穿透，是缓存最大的两个问题，要么不出现，一旦出现就是致命性的问题。所以面试官一定会问你。
+
+## 面试题剖析
+### 缓存雪崩
+对于系统 A，假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机。缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据库必然扛不住，它会报一下警，然后就挂了。此时，如果没用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。
+
+这就是缓存雪崩。
+
+![redis-caching-avalanche](/img/redis-caching-avalanche.png)
+
+大约在 3 年前，国内比较知名的一个互联网公司，曾因为缓存事故，导致雪崩，后台系统全部崩溃，事故从当天下午持续到晚上凌晨 3~4 点，公司损失了几千万。
+
+缓存雪崩的事前事中事后的解决方案如下。
+- 事前：redis高可用，主从+哨兵，redis cluster，避免全盘崩溃。
+- 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。
+- 事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
+
+![redis-caching-avalanche-solution](/img/redis-caching-avalanche-solution.png)
+
+用户发送一个请求，系统 A 收到请求后，先查本地 ehcache 缓存，如果没查到再查 redis。如果 ehcache 和 redis 都没有，再查数据库，将数据库中的结果，写入 ehcache 和 redis 中。
+
+限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？**走降级**！可以返回一些默认的值，或者友情提示，或者空白的值。
+
+好处：
+- 数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
+- 只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
+- 只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，就是可能点击几次刷不出来页面，但是可能多点几次，就可以刷出来一次。
+
+### 缓存穿透
+对于系统A，假设一秒 5000 个请求，结果其中 4000 个请求是黑客发出的恶意攻击。
+
+黑客发出的那 4000 个攻击，缓存中查不到，每次你去数据库里查，也查不到。
+
+举个栗子。数据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数。这样的话，缓存中不会有，请求每次都“视缓存于无物”，直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。
+
+![redis-caching-penetration](/img/redis-caching-penetration.png)
+
+解决方式很简单，每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 `set -999 UNKNOWN`。这样的话，下次便能走缓存了。
\ No newline at end of file
diff --git a/img/redis-caching-avalanche-solution.png b/img/redis-caching-avalanche-solution.png
new file mode 100644
index 0000000..992d33a
Binary files /dev/null and b/img/redis-caching-avalanche-solution.png differ
diff --git a/img/redis-caching-avalanche.png b/img/redis-caching-avalanche.png
new file mode 100644
index 0000000..54016aa
Binary files /dev/null and b/img/redis-caching-avalanche.png differ
diff --git a/img/redis-caching-penetration.png b/img/redis-caching-penetration.png
new file mode 100644
index 0000000..ecd509b
Binary files /dev/null and b/img/redis-caching-penetration.png differ