docs: minor changes in doc description

docs/distributed-system/distributed-session.md

@@ -18,7 +18,6 @@ session 是啥？浏览器有个 cookie，在一段时间内这个 cookie 都存
 其实方法很多，但是常见常用的是以下几种：
 
 ### 完全不用 session
-
 使用 JWT Token 储存用户身份，然后再从数据库或者 cache 中获取其他的信息。这样无论请求分配到哪个服务器都无所谓。
 
 ### tomcat + redis
@@ -53,7 +52,7 @@ session 是啥？浏览器有个 cookie，在一段时间内这个 cookie 都存
 
 因为上面那种 tomcat + redis 的方式好用，但是会**严重依赖于web容器**，不好将代码移植到其他 web 容器上去，尤其是你要是换了技术栈咋整？比如换成了 spring cloud 或者是 spring boot 之类的呢？
 
-所以现在比较好的还是基于 Java 一站式解决方案，也就是 spring。人家 spring 基本上包掉了大部分我们需要使用的框架，spirng cloud 做微服务，spring boot 做脚手架，所以用 sping session 是一个很好的选择。
+所以现在比较好的还是基于 Java 一站式解决方案，也就是 spring。人家 spring 基本上承包了大部分我们需要使用的框架，spirng cloud 做微服务，spring boot 做脚手架，所以用 sping session 是一个很好的选择。
 
 在 pom.xml 中配置：
 ```xml

docs/distributed-system/dubbo-load-balancing.md

@@ -13,14 +13,14 @@ dubbo 负载均衡策略和集群容错策略都有哪些？动态代理策略
 ## 面试题剖析
 ### dubbo 负载均衡策略
 #### random loadbalance
-默认情况下，dubbo 是 random load balance **随机**调用实现负载均衡，可以对 provider 不同实例**设置不同的权重**，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。
+默认情况下，dubbo 是 random load balance ，即**随机**调用实现负载均衡，可以对 provider 不同实例**设置不同的权重**，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。
 
 #### roundrobin loadbalance
 这个的话默认就是均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。
 
 举个栗子。
 
-跟运维同学申请机器，有的时候，我们运气好，正好公司资源比较充足，刚刚有一批热气腾腾、刚刚做好的一批虚拟机新鲜出炉，配置都比较高：8 核 + 16G 机器，申请到 2 台。过了一段时间，我们感觉 2 台机器有点不太够，我就去找运维同学说，“哥儿们，你能不能再给我一台机器”，但是这时只剩下一台 4 核 + 8G 的机器。我要还是得要。
+跟运维同学申请机器，有的时候，我们运气好，正好公司资源比较充足，刚刚有一批热气腾腾、刚刚做好的虚拟机新鲜出炉，配置都比较高：8 核 + 16G 机器，申请到 2 台。过了一段时间，我们感觉 2 台机器有点不太够，我就去找运维同学说，“哥儿们，你能不能再给我一台机器”，但是这时只剩下一台 4 核 + 8G 的机器。我要还是得要。
 
 这个时候，可以给两台 8 核 16G 的机器设置权重 4，给剩余 1 台 4 核 8G 的机器设置权重 2。
 

docs/distributed-system/dubbo-service-management.md

@@ -48,7 +48,6 @@ public class HelloServiceImpl implements HelloService {
         System.out.println("hello world......");
     }
 }
-
 ```
 
 ```xml
@@ -85,13 +84,13 @@ public class HelloServiceImpl implements HelloService {
 我们调用接口失败的时候，可以通过 `mock` 统一返回 null。
 
 mock 的值也可以修改为 true，然后再跟接口同一个路径下实现一个 Mock 类，命名规则是 “接口名称+`Mock`” 后缀。然后在 Mock 类里实现自己的降级逻辑。
+
 ```java
 public class HelloServiceMock implements HelloService {
     public void sayHello() {
         // 降级逻辑
     }
 }
-
 ```
 
 ### 失败重试和超时重试

docs/high-concurrency/database-shard-dynamic-expand.md

@@ -30,13 +30,13 @@
 
 我可以告诉各位同学，这个分法，第一，基本上国内的互联网肯定都是够用了，第二，无论是并发支撑还是数据量支撑都没问题。
 
-每个库正常承载的写入并发量是 1000，那么 32 个库就可以承载32 * 1000 = 32000 的写并发，如果每个库承载 1500 的写并发，32 * 1500 = 48000 的写并发，接近 5万/s 的写入并发，前面再加一个MQ，削峰，每秒写入 MQ 8 万条数据，每秒消费 5 万条数据。
+每个库正常承载的写入并发量是 1000，那么 32 个库就可以承载32 * 1000 = 32000 的写并发，如果每个库承载 1500 的写并发，32 * 1500 = 48000 的写并发，接近 5 万每秒的写入并发，前面再加一个MQ，削峰，每秒写入 MQ 8 万条数据，每秒消费 5 万条数据。
 
 有些除非是国内排名非常靠前的这些公司，他们的最核心的系统的数据库，可能会出现几百台数据库的这么一个规模，128个库，256个库，512个库。
 
 1024 张表，假设每个表放 500 万数据，在 MySQL 里可以放 50 亿条数据。
 
-每秒的 5 万写并发，总共 50 亿条数据，对于国内大部分的互联网公司来说，其实一般来说都够了。
+每秒 5 万的写并发，总共 50 亿条数据，对于国内大部分的互联网公司来说，其实一般来说都够了。
 
 谈分库分表的扩容，**第一次分库分表，就一次性给他分个够**，32 个库，1024 张表，可能对大部分的中小型互联网公司来说，已经可以支撑好几年了。