docs: update articles

Author: yanglbme

.prettierrc

@@ -0,0 +1,10 @@
+{
+    "tabWidth": 4,
+    "useTabs": false,
+    "semi": true,
+    "singleQuote": true,
+    "trailingComma": "all",
+    "bracketSpacing": true,
+    "jsxBracketSameLine": false,
+    "arrowParens": "avoid"
+}

README.md

@@ -1,15 +1,15 @@
 # 海量数据处理
 
-- [如何从大量的 URL 中找出相同的 URL？](/docs/big-data/find-common-urls.md)
-- [如何从大量数据中找出高频词？](/docs/big-data/find-top-100-words.md)
-- [如何找出某一天访问百度网站最多的 IP？](/docs/big-data/find-top-1-ip.md)
-- [如何在大量的数据中找出不重复的整数？](/docs/big-data/find-no-repeat-number.md)
-- [如何在大量的数据中判断一个数是否存在？](/docs/big-data/find-a-number-if-exists.md)
-- [如何查询最热门的查询串？](/docs/big-data/find-hotest-query-string.md)
-- [如何统计不同电话号码的个数？](/docs/big-data/count-different-phone-numbers.md)
-- [如何从 5 亿个数中找出中位数？](/docs/big-data/find-mid-value-in-500-millions.md)
-- [如何按照 query 的频度排序？](/docs/big-data/sort-the-query-strings-by-counts.md)
-- [如何找出排名前 500 的数？](/docs/big-data/find-rank-top-500-numbers.md)
+-   [如何从大量的 URL 中找出相同的 URL？](/docs/big-data/find-common-urls.md)
+-   [如何从大量数据中找出高频词？](/docs/big-data/find-top-100-words.md)
+-   [如何找出某一天访问百度网站最多的 IP？](/docs/big-data/find-top-1-ip.md)
+-   [如何在大量的数据中找出不重复的整数？](/docs/big-data/find-no-repeat-number.md)
+-   [如何在大量的数据中判断一个数是否存在？](/docs/big-data/find-a-number-if-exists.md)
+-   [如何查询最热门的查询串？](/docs/big-data/find-hotest-query-string.md)
+-   [如何统计不同电话号码的个数？](/docs/big-data/count-different-phone-numbers.md)
+-   [如何从 5 亿个数中找出中位数？](/docs/big-data/find-mid-value-in-500-millions.md)
+-   [如何按照 query 的频度排序？](/docs/big-data/sort-the-query-strings-by-counts.md)
+-   [如何找出排名前 500 的数？](/docs/big-data/find-rank-top-500-numbers.md)
 
 ---
 

docs/big-data/README.md

@@ -48,9 +48,9 @@ for i in range(8):
 
 **那么对于这道题**，我们用 2 个 bit 来表示各个数字的状态：
 
-- 00 表示这个数字没出现过；
-- 01 表示这个数字出现过一次（即为题目所找的不重复整数）；
-- 10 表示这个数字出现了多次。
+-   00 表示这个数字没出现过；
+-   01 表示这个数字出现过一次（即为题目所找的不重复整数）；
+-   10 表示这个数字出现了多次。
 
 那么这 2<sup>32</sup> 个整数，总共所需内存为 2<sup>32</sup>\*2b=1GB。因此，当可用内存超过 1GB 时，可以采用位图法。假设内存满足位图法需求，进行下面的操作：
 

docs/big-data/find-no-repeat-number.md

@@ -20,5 +20,5 @@
 
 ### 方法总结
 
-- 内存若够，直接读入进行排序；
-- 内存不够，先划分为小文件，小文件排好序后，整理使用外排序进行归并。
+-   内存若够，直接读入进行排序；
+-   内存不够，先划分为小文件，小文件排好序后，整理使用外排序进行归并。

docs/big-data/sort-the-query-strings-by-counts.md

@@ -4,32 +4,32 @@
 
 ## 系统拆分
 
-- [为什么要进行系统拆分？如何进行系统拆分？拆分后不用 Dubbo 可以吗？](/docs/distributed-system/why-dubbo.md)
+-   [为什么要进行系统拆分？如何进行系统拆分？拆分后不用 Dubbo 可以吗？](/docs/distributed-system/why-dubbo.md)
 
 ## 分布式服务框架
 
-- [说一下 Dubbo 的工作原理？注册中心挂了可以继续通信吗？](/docs/distributed-system/dubbo-operating-principle.md)
-- [Dubbo 支持哪些序列化协议？说一下 Hessian 的数据结构？PB 知道吗？为什么 PB 的效率是最高的？](/docs/distributed-system/dubbo-serialization-protocol.md)
-- [Dubbo 负载均衡策略和集群容错策略都有哪些？动态代理策略呢？](/docs/distributed-system/dubbo-load-balancing.md)
-- [Dubbo 的 SPI 思想是什么？](/docs/distributed-system/dubbo-spi.md)
-- [如何基于 Dubbo 进行服务治理、服务降级、失败重试以及超时重试？](/docs/distributed-system/dubbo-service-management.md)
-- [分布式服务接口的幂等性如何设计（比如不能重复扣款）？](/docs/distributed-system/distributed-system-idempotency.md)
-- [分布式服务接口请求的顺序性如何保证？](/docs/distributed-system/distributed-system-request-sequence.md)
-- [如何自己设计一个类似 Dubbo 的 RPC 框架？](/docs/distributed-system/dubbo-rpc-design.md)
-- [CAP 定理的 P 是什么](/docs/distributed-system/distributed-system-cap.md)
+-   [说一下 Dubbo 的工作原理？注册中心挂了可以继续通信吗？](/docs/distributed-system/dubbo-operating-principle.md)
+-   [Dubbo 支持哪些序列化协议？说一下 Hessian 的数据结构？PB 知道吗？为什么 PB 的效率是最高的？](/docs/distributed-system/dubbo-serialization-protocol.md)
+-   [Dubbo 负载均衡策略和集群容错策略都有哪些？动态代理策略呢？](/docs/distributed-system/dubbo-load-balancing.md)
+-   [Dubbo 的 SPI 思想是什么？](/docs/distributed-system/dubbo-spi.md)
+-   [如何基于 Dubbo 进行服务治理、服务降级、失败重试以及超时重试？](/docs/distributed-system/dubbo-service-management.md)
+-   [分布式服务接口的幂等性如何设计（比如不能重复扣款）？](/docs/distributed-system/distributed-system-idempotency.md)
+-   [分布式服务接口请求的顺序性如何保证？](/docs/distributed-system/distributed-system-request-sequence.md)
+-   [如何自己设计一个类似 Dubbo 的 RPC 框架？](/docs/distributed-system/dubbo-rpc-design.md)
+-   [CAP 定理的 P 是什么](/docs/distributed-system/distributed-system-cap.md)
 
 ## 分布式锁
 
-- [Zookeeper 都有哪些应用场景？](/docs/distributed-system/zookeeper-application-scenarios.md)
-- [使用 Redis 如何设计分布式锁？使用 Zookeeper 来设计分布式锁可以吗？以上两种分布式锁的实现方式哪种效率比较高？](/docs/distributed-system/distributed-lock-redis-vs-zookeeper.md)
+-   [Zookeeper 都有哪些应用场景？](/docs/distributed-system/zookeeper-application-scenarios.md)
+-   [使用 Redis 如何设计分布式锁？使用 Zookeeper 来设计分布式锁可以吗？以上两种分布式锁的实现方式哪种效率比较高？](/docs/distributed-system/distributed-lock-redis-vs-zookeeper.md)
 
 ## 分布式事务
 
-- [分布式事务了解吗？你们如何解决分布式事务问题的？TCC 如果出现网络连不通怎么办？XA 的一致性如何保证？](/docs/distributed-system/distributed-transaction.md)
+-   [分布式事务了解吗？你们如何解决分布式事务问题的？TCC 如果出现网络连不通怎么办？XA 的一致性如何保证？](/docs/distributed-system/distributed-transaction.md)
 
 ## 分布式会话
 
-- [集群部署时的分布式 Session 如何实现？](/docs/distributed-system/distributed-session.md)
+-   [集群部署时的分布式 Session 如何实现？](/docs/distributed-system/distributed-session.md)
 
 ---
 

docs/distributed-system/README.md

@@ -14,17 +14,17 @@
 
 这个分布式锁有 3 个重要的考量点：
 
-- 互斥（只能有一个客户端获取锁）
-- 不能死锁
-- 容错（只要大部分 Redis 节点创建了这把锁就可以）
+-   互斥（只能有一个客户端获取锁）
+-   不能死锁
+-   容错（只要大部分 Redis 节点创建了这把锁就可以）
 
 #### Redis 最普通的分布式锁
 
 第一个最普通的实现方式，就是在 Redis 里使用 `SET key value [EX seconds] [PX milliseconds] NX` 创建一个 key，这样就算加锁。其中：
 
-- `NX`：表示只有 `key` 不存在的时候才会设置成功，如果此时 redis 中存在这个 `key`，那么设置失败，返回 `nil`。
-- `EX seconds`：设置 `key` 的过期时间，精确到秒级。意思是 `seconds` 秒后锁自动释放，别人创建的时候如果发现已经有了就不能加锁了。
-- `PX milliseconds`：同样是设置 `key` 的过期时间，精确到毫秒级。
+-   `NX`：表示只有 `key` 不存在的时候才会设置成功，如果此时 redis 中存在这个 `key`，那么设置失败，返回 `nil`。
+-   `EX seconds`：设置 `key` 的过期时间，精确到秒级。意思是 `seconds` 秒后锁自动释放，别人创建的时候如果发现已经有了就不能加锁了。
+-   `PX milliseconds`：同样是设置 `key` 的过期时间，精确到毫秒级。
 
 比如执行以下命令：
 
@@ -332,8 +332,8 @@ public class ZooKeeperDistributedLock implements Watcher {
 
 ### redis 分布式锁和 zk 分布式锁的对比
 
-- redis 分布式锁，其实**需要自己不断去尝试获取锁**，比较消耗性能。
-- zk 分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小。
+-   redis 分布式锁，其实**需要自己不断去尝试获取锁**，比较消耗性能。
+-   zk 分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小。
 
 另外一点就是，如果是 Redis 获取锁的那个客户端 出现 bug 挂了，那么只能等待超时时间之后才能释放锁；而 zk 的话，因为创建的是临时 znode，只要客户端挂了，znode 就没了，此时就自动释放锁。
 

docs/distributed-system/distributed-lock-redis-vs-zookeeper.md

@@ -8,17 +8,17 @@
 
 在理论计算机科学中，CAP 定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：
 
-- 一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）
-- 可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
-- 分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。）
+-   一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）
+-   可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
+-   分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。）
 
 ### 分区容错性（Partition tolerance）
 
 理解 CAP 理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了 C 性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了 A 性质。除非两个节点可以互相通信，才能既保证 C 又保证 A，这又会导致丧失 P 性质。
 
-- P 指的是分区容错性，分区现象产生后需要容错，容错是指在 A 与 C 之间选择。如果分布式系统没有分区现象（没有出现不一致不可用情况） 本身就没有分区 ，既然没有分区则就更没有分区容错性 P。
-- 无论我设计的系统是 AP 还是 CP 系统如果没有出现不一致不可用。 则该系统就处于 CA 状态
-- P 的体现前提是得有分区情况存在
+-   P 指的是分区容错性，分区现象产生后需要容错，容错是指在 A 与 C 之间选择。如果分布式系统没有分区现象（没有出现不一致不可用情况） 本身就没有分区 ，既然没有分区则就更没有分区容错性 P。
+-   无论我设计的系统是 AP 还是 CP 系统如果没有出现不一致不可用。 则该系统就处于 CA 状态
+-   P 的体现前提是得有分区情况存在
 
 > 文章来源：[维基百科 CAP 定理](https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86)
 

docs/distributed-system/distributed-system-cap.md

@@ -22,9 +22,9 @@
 
 其实保证幂等性主要是三点：
 
-- 对于每个请求必须有一个唯一的标识，举个栗子：订单支付请求，肯定得包含订单 id，一个订单 id 最多支付一次，对吧。
-- 每次处理完请求之后，必须有一个记录标识这个请求处理过了。常见的方案是在 mysql 中记录个状态啥的，比如支付之前记录一条这个订单的支付流水。
-- 每次接收请求需要进行判断，判断之前是否处理过。比如说，如果有一个订单已经支付了，就已经有了一条支付流水，那么如果重复发送这个请求，则此时先插入支付流水，orderId 已经存在了，唯一键约束生效，报错插入不进去的。然后你就不用再扣款了。
+-   对于每个请求必须有一个唯一的标识，举个栗子：订单支付请求，肯定得包含订单 id，一个订单 id 最多支付一次，对吧。
+-   每次处理完请求之后，必须有一个记录标识这个请求处理过了。常见的方案是在 mysql 中记录个状态啥的，比如支付之前记录一条这个订单的支付流水。
+-   每次接收请求需要进行判断，判断之前是否处理过。比如说，如果有一个订单已经支付了，就已经有了一条支付流水，那么如果重复发送这个请求，则此时先插入支付流水，orderId 已经存在了，唯一键约束生效，报错插入不进去的。然后你就不用再扣款了。
 
 实际运作过程中，你要结合自己的业务来，比如说利用 Redis，用 orderId 作为唯一键。只有成功插入这个支付流水，才可以执行实际的支付扣款。
 

docs/distributed-system/distributed-system-idempotency.md

@@ -12,27 +12,27 @@
 
 ### 为什么要进行系统拆分？
 
-- 为什么要进行系统拆分？如何进行系统拆分？拆分后不用 Dubbo 可以吗？Dubbo 和 thrift 有什么区别呢？
+-   为什么要进行系统拆分？如何进行系统拆分？拆分后不用 Dubbo 可以吗？Dubbo 和 thrift 有什么区别呢？
 
 ### 分布式服务框架
 
-- 说一下的 Dubbo 的工作原理？注册中心挂了可以继续通信吗？
-- Dubbo 支持哪些序列化协议？说一下 Hessian 的数据结构？PB 知道吗？为什么 PB 的效率是最高的？
-- Dubbo 负载均衡策略和高可用策略都有哪些？动态代理策略呢？
-- Dubbo 的 SPI 思想是什么？
-- 如何基于 Dubbo 进行服务治理、服务降级、失败重试以及超时重试？
-- 分布式服务接口的幂等性如何设计（比如不能重复扣款）？
-- 分布式服务接口请求的顺序性如何保证？
-- 如何自己设计一个类似 Dubbo 的 RPC 框架？
+-   说一下的 Dubbo 的工作原理？注册中心挂了可以继续通信吗？
+-   Dubbo 支持哪些序列化协议？说一下 Hessian 的数据结构？PB 知道吗？为什么 PB 的效率是最高的？
+-   Dubbo 负载均衡策略和高可用策略都有哪些？动态代理策略呢？
+-   Dubbo 的 SPI 思想是什么？
+-   如何基于 Dubbo 进行服务治理、服务降级、失败重试以及超时重试？
+-   分布式服务接口的幂等性如何设计（比如不能重复扣款）？
+-   分布式服务接口请求的顺序性如何保证？
+-   如何自己设计一个类似 Dubbo 的 RPC 框架？
 
 ### 分布式锁
 
-- 使用 Redis 如何设计分布式锁？使用 zk 来设计分布式锁可以吗？这两种分布式锁的实现方式哪种效率比较高？
+-   使用 Redis 如何设计分布式锁？使用 zk 来设计分布式锁可以吗？这两种分布式锁的实现方式哪种效率比较高？
 
 ### 分布式事务
 
-- 分布式事务了解吗？你们如何解决分布式事务问题的？TCC 如果出现网络连不通怎么办？XA 的一致性如何保证？
+-   分布式事务了解吗？你们如何解决分布式事务问题的？TCC 如果出现网络连不通怎么办？XA 的一致性如何保证？
 
 ### 分布式会话
 
-- 集群部署时的分布式 Session 如何实现？
+-   集群部署时的分布式 Session 如何实现？

docs/distributed-system/distributed-system-interview.md

@@ -12,12 +12,12 @@
 
 分布式事务的实现主要有以下 6 种方案：
 
-- XA 方案
-- TCC 方案
-- SAGA 方案
-- 本地消息表
-- 可靠消息最终一致性方案
-- 最大努力通知方案
+-   XA 方案
+-   TCC 方案
+-   SAGA 方案
+-   本地消息表
+-   可靠消息最终一致性方案
+-   最大努力通知方案
 
 ### 两阶段提交方案/XA 方案
 
@@ -37,9 +37,9 @@
 
 TCC 的全称是： `Try` 、 `Confirm` 、 `Cancel` 。
 
-- Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行**锁定或者预留**。
-- Confirm 阶段：这个阶段说的是在各个服务中**执行实际的操作**。
-- Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要**进行补偿**，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）
+-   Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行**锁定或者预留**。
+-   Confirm 阶段：这个阶段说的是在各个服务中**执行实际的操作**。
+-   Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要**进行补偿**，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）
 
 这种方案说实话几乎很少人使用，我们用的也比较少，但是也有使用的场景。因为这个**事务回滚**实际上是**严重依赖于你自己写代码来回滚和补偿**了，会造成补偿代码巨大，非常之恶心。
 
@@ -69,18 +69,18 @@ TCC 的全称是： `Try` 、 `Confirm` 、 `Cancel` 。
 
 所以 Saga 模式的适用场景是：
 
-- 业务流程长、业务流程多；
-- 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口。
+-   业务流程长、业务流程多；
+-   参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口。
 
 #### 优势
 
-- 一阶段提交本地事务，无锁，高性能；
-- 参与者可异步执行，高吞吐；
-- 补偿服务易于实现，因为一个更新操作的反向操作是比较容易理解的。
+-   一阶段提交本地事务，无锁，高性能；
+-   参与者可异步执行，高吞吐；
+-   补偿服务易于实现，因为一个更新操作的反向操作是比较容易理解的。
 
 #### 缺点
 
-- 不保证事务的隔离性。
+-   不保证事务的隔离性。
 
 ### 本地消息表
 

docs/distributed-system/distributed-transaction.md

@@ -8,10 +8,10 @@ dubbo 负载均衡策略和集群容错策略都有哪些？动态代理策略
 
 说白了，就是看你对 dubbo 熟悉不熟悉：
 
-- dubbo 工作原理：服务注册、注册中心、消费者、代理通信、负载均衡；
-- 网络通信、序列化：dubbo 协议、长连接、NIO、hessian 序列化协议；
-- 负载均衡策略、集群容错策略、动态代理策略：dubbo 跑起来的时候一些功能是如何运转的？怎么做负载均衡？怎么做集群容错？怎么生成动态代理？
-- dubbo SPI 机制：你了解不了解 dubbo 的 SPI 机制？如何基于 SPI 机制对 dubbo 进行扩展？
+-   dubbo 工作原理：服务注册、注册中心、消费者、代理通信、负载均衡；
+-   网络通信、序列化：dubbo 协议、长连接、NIO、hessian 序列化协议；
+-   负载均衡策略、集群容错策略、动态代理策略：dubbo 跑起来的时候一些功能是如何运转的？怎么做负载均衡？怎么做集群容错？怎么生成动态代理？
+-   dubbo SPI 机制：你了解不了解 dubbo 的 SPI 机制？如何基于 SPI 机制对 dubbo 进行扩展？
 
 ## 面试题剖析