fix: update why-cache.md

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

@@ -23,12 +23,12 @@
 
 用户发送一个请求，系统 A 收到请求后，先查本地 ehcache 缓存，如果没查到再查 redis。如果 ehcache 和 redis 都没有，再查数据库，将数据库中的结果，写入 ehcache 和 redis 中。
 
-限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？**走降级**！可以返回一些默认的值，或者友情提示，或者空白的值。
+限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？**走降级**！可以返回一些默认的值，或者友情提示，或者空值。
 
 好处：
 - 数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
 - 只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
-- 只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来一次。
+- 只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来了。
 
 ### 缓存穿透
 对于系统A，假设一秒 5000 个请求，结果其中 4000 个请求是黑客发出的恶意攻击。
@@ -45,6 +45,7 @@
 缓存击穿，就是说某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。
 
 不同场景下的解决方式可如下：
+
 - 若缓存的数据是基本不会发生更新的，则可尝试将该热点数据设置为永不过期。
 - 若缓存的数据更新不频繁，且缓存刷新的整个流程耗时较少的情况下，则可以采用基于 redis、zookeeper 等分布式中间件的分布式互斥锁，或者本地互斥锁以保证仅少量的请求能请求数据库并重新构建缓存，其余线程则在锁释放后能访问到新缓存。
-- 若缓存的数据更新频繁或者缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存过期前主动的重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。
+- 若缓存的数据更新频繁或者在缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存过期前主动地重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。

docs/high-concurrency/why-cache.md

@@ -32,8 +32,9 @@ mysql 这么重的数据库，压根儿设计不是让你玩儿高并发的，
 
 ### 用了缓存之后会有什么不良后果？
 常见的缓存问题有以下几个：
+
 - [缓存与数据库双写不一致](/docs/high-concurrency/redis-consistence.md)
 - [缓存雪崩、缓存穿透、缓存击穿](/docs/high-concurrency/redis-caching-avalanche-and-caching-penetration.md)
 - [缓存并发竞争](/docs/high-concurrency/redis-cas.md)
 
-后面再详细说明。
+点击超链接，可直接查看缓存相关问题及解决方案。