docs: format document with prettier

全面整理项目内容,可读性更佳

docs/high-concurrency/redis-caching-avalanche-and-caching-penetration.md

@@ -1,4 +1,5 @@
 ## 面试题
+
 了解什么是 Redis 的雪崩、穿透和击穿？Redis 崩溃之后会怎么样？系统该如何应对这种情况？如何处理 Redis 的穿透？
 
 ## 面试官心理分析
@@ -8,6 +9,7 @@
 ## 面试题剖析
 
 ### 缓存雪崩
+
 对于系统 A，假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机。缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据库必然扛不住，它会报一下警，然后就挂了。此时，如果没有采用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。
 
 这就是缓存雪崩。
@@ -18,9 +20,9 @@
 
 缓存雪崩的事前事中事后的解决方案如下：
 
-* 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
-* 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。
-* 事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
+- 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
+- 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。
+- 事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
 
 ![redis-caching-avalanche-solution](./images/redis-caching-avalanche-solution.png)
 
@@ -30,13 +32,13 @@
 
 好处：
 
-* 数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
-* 只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
-* 只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来了。
+- 数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
+- 只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
+- 只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来了。
 
 ### 缓存穿透
 
-对于系统A，假设一秒 5000 个请求，结果其中 4000 个请求是黑客发出的恶意攻击。
+对于系统 A，假设一秒 5000 个请求，结果其中 4000 个请求是黑客发出的恶意攻击。
 
 黑客发出的那 4000 个攻击，缓存中查不到，每次你去数据库里查，也查不到。
 
@@ -52,6 +54,6 @@
 
 不同场景下的解决方式可如下：
 
-* 若缓存的数据是基本不会发生更新的，则可尝试将该热点数据设置为永不过期。
-* 若缓存的数据更新不频繁，且缓存刷新的整个流程耗时较少的情况下，则可以采用基于 Redis、zookeeper 等分布式中间件的分布式互斥锁，或者本地互斥锁以保证仅少量的请求能请求数据库并重新构建缓存，其余线程则在锁释放后能访问到新缓存。
-* 若缓存的数据更新频繁或者在缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存过期前主动地重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。
+- 若缓存的数据是基本不会发生更新的，则可尝试将该热点数据设置为永不过期。
+- 若缓存的数据更新不频繁，且缓存刷新的整个流程耗时较少的情况下，则可以采用基于 Redis、zookeeper 等分布式中间件的分布式互斥锁，或者本地互斥锁以保证仅少量的请求能请求数据库并重新构建缓存，其余线程则在锁释放后能访问到新缓存。
+- 若缓存的数据更新频繁或者在缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存过期前主动地重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。