shahainloong · shahainloong · Nov 30, 2020 · Nov 21, 2020 · Nov 21, 2020 · Nov 22, 2020
diff --git a/README.md b/README.md
@@ -66,24 +66,25 @@
     - [Spring/SpringBoot](#springspringboot)
     - [MyBatis](#mybatis)
     - [Netty (必看 :+1:)](#netty-必看-1)
+    - [ZooKeeper](#zookeeper)
   - [认证授权](#认证授权)
     - [JWT](#jwt)
     - [SSO(单点登录)](#sso单点登录)
   - [分布式](#分布式)
+    - [CAP 理论](#cap-理论)
+    - [BASE 理论](#base-理论)
+    - [Paxos 算法和 Raft 算法](#paxos-算法和-raft-算法)
     - [搜索引擎](#搜索引擎)
     - [RPC](#rpc)
     - [API 网关](#api-网关)
     - [分布式 id](#分布式-id)
-    - [ZooKeeper](#zookeeper)
   - [微服务](#微服务)
   - [高并发](#高并发)
     - [消息队列](#消息队列)
     - [读写分离](#读写分离)
     - [分库分表](#分库分表)
     - [负载均衡](#负载均衡)
   - [高可用](#高可用)
-    - [CAP 理论](#cap-理论)
-    - [BASE 理论](#base-理论)
     - [限流](#限流)
     - [降级](#降级)
     - [熔断](#熔断)
@@ -211,7 +212,6 @@
 
 ### Redis
 
-1. [关于缓存的一些重要概念(Redis 前置菜)](docs/database/Redis/some-concepts-of-caching.md)
 2. [Redis 常见问题总结](docs/database/Redis/redis-all.md)
 
 ## 系统设计
@@ -248,6 +248,14 @@
 1. [剖析面试最常见问题之 Netty（上）](https://xiaozhuanlan.com/topic/4028536971)
 2. [剖析面试最常见问题之 Netty（下）](https://xiaozhuanlan.com/topic/3985146207)
 
+#### ZooKeeper
+
+> 前两篇文章可能有内容重合部分，推荐都看一遍。
+
+1. [【入门】ZooKeeper 相关概念总结](docs/system-design/distributed-system/zookeeper/zookeeper-intro.md)
+2. [【进阶】ZooKeeper 相关概念总结](docs/system-design/distributed-system/zookeeper/zookeeper-plus.md)
+3. [【实战】ZooKeeper 实战](docs/system-design/distributed-system/zookeeper/zookeeper-in-action.md)
+
 ### 认证授权
 
 **[《认证授权基础》](docs/system-design/authority-certification/basis-of-authority-certification.md)** 这篇文章中我会介绍认证授权常见概念： **Authentication**,**Authorization** 以及 **Cookie**、**Session**、Token、**OAuth 2**、**SSO** 。如果你不清楚这些概念的话，建议好好阅读一下这篇文章。
@@ -263,7 +271,21 @@
 
 ### 分布式
 
-[分布式相关概念入门](docs/system-design/distributed-system/分布式.md)
+#### CAP 理论
+
+CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。
+
+关于 CAP 的详细解读请看：[《CAP理论解读》](docs/system-design/distributed-system/CAP理论.md)。
+
+#### BASE 理论
+
+**BASE** 是 **Basically Available（基本可用）** 、**Soft-state（软状态）** 和 **Eventually Consistent（最终一致性）** 三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。
+
+关于 CAP 的详细解读请看：[《BASE理论解读》](docs/system-design/distributed-system/BASE理论.md)。
+
+#### Paxos 算法和 Raft 算法
+
+**Paxos 算法**诞生于 1900 年，这是一种解决分布式系统一致性的经典算法 。但是，由于 Paxos 算法非常难以理解和实现，不断有人尝试简化这一算法。到了2013 年才诞生了一个比 Paxos 算法更易理解和实现的分布式一致性算法—**Raft 算法**。
 
 #### 搜索引擎
 
@@ -275,6 +297,7 @@ RPC 让调用远程服务调用像调用本地方法那样简单。
 
 1. [Dubbo 总结：关于 Dubbo 的重要知识点](docs/system-design/distributed-system/rpc/关于Dubbo的重要知识点.md)
 2. [服务之间的调用为啥不直接用 HTTP 而用 RPC？](docs/system-design/distributed-system/rpc/服务之间的调用为啥不直接用HTTP而用RPC.md)
+3. [一款基于 Netty+Kyro+Zookeeper 实现的自定义 RPC 框架](https://github.com/Snailclimb/guide-rpc-framework)
 
 #### API 网关
 
@@ -287,13 +310,11 @@ RPC 让调用远程服务调用像调用本地方法那样简单。
 
 在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。比如数据量太大之后，往往需要对进行对数据进行分库分表，分库分表后需要有一个唯一 ID 来标识一条数据或消息，数据库的自增 ID 显然不能满足需求。相关阅读：[为什么要分布式 id ？分布式 id 生成方案有哪些？](docs/system-design/micro-service/分布式id生成方案总结.md)
 
-#### ZooKeeper
+#### 分布式事务
 
-> 前两篇文章可能有内容重合部分，推荐都看一遍。
+**分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。**
 
-1. [【入门】ZooKeeper 相关概念总结](docs/system-design/distributed-system/zookeeper/zookeeper-intro.md)
-2. [【进阶】ZooKeeper 相关概念总结](docs/system-design/distributed-system/zookeeper/zookeeper-plus.md)
-3. [【实战】ZooKeeper 实战](docs/system-design/distributed-system/zookeeper/zookeeper-in-action.md)
+简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
 
 ### 微服务
 
@@ -338,18 +359,6 @@ RPC 让调用远程服务调用像调用本地方法那样简单。
 
 相关阅读： **《[如何设计一个高可用系统？要考虑哪些地方？](docs/system-design/high-availability/如何设计一个高可用系统要考虑哪些地方.md)》** 。
 
-#### CAP 理论
-
-CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。
-
-关于 CAP 的详细解读请看：[《CAP理论解读》](docs/system-design/high-availability/CAP理论.md)。
-
-#### BASE 理论
-
-**BASE** 是 **Basically Available（基本可用）** 、**Soft-state（软状态）** 和 **Eventually Consistent（最终一致性）** 三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。
-
-关于 CAP 的详细解读请看：[《BASE理论解读》](docs/system-design/high-availability/BASE理论.md)。
-
 #### 限流
 
 限流是从用户访问压力的角度来考虑如何应对系统故障。

diff --git a/docs/database/Redis/images/缓存读写策略/cache-aside-read.drawio b/docs/database/Redis/images/缓存读写策略/cache-aside-read.drawio
diff --git a/docs/database/Redis/images/缓存读写策略/cache-aside-read.png b/docs/database/Redis/images/缓存读写策略/cache-aside-read.png
diff --git a/docs/database/Redis/images/缓存读写策略/cache-aside-write.drawio b/docs/database/Redis/images/缓存读写策略/cache-aside-write.drawio
diff --git a/docs/database/Redis/images/缓存读写策略/cache-aside-write.png b/docs/database/Redis/images/缓存读写策略/cache-aside-write.png
diff --git a/docs/database/Redis/images/缓存读写策略/read-through.drawio b/docs/database/Redis/images/缓存读写策略/read-through.drawio
diff --git a/docs/database/Redis/images/缓存读写策略/read-through.png b/docs/database/Redis/images/缓存读写策略/read-through.png
diff --git a/docs/database/Redis/images/缓存读写策略/write-through.drawio b/docs/database/Redis/images/缓存读写策略/write-through.drawio
diff --git a/docs/database/Redis/images/缓存读写策略/write-through.png b/docs/database/Redis/images/缓存读写策略/write-through.png
diff --git a/docs/database/Redis/some-concepts-of-caching.md b/docs/database/Redis/some-concepts-of-caching.md
diff --git a/docs/essential-content-for-interview/PreparingForInterview/美团面试常见问题总结.md b/docs/essential-content-for-interview/PreparingForInterview/美团面试常见问题总结.md
@@ -106,7 +106,7 @@
 request.getRequestDispatcher("login_success.jsp").forward(request, response);
 ```
 
-**重定向（Redirect）** 是利用服务器返回的状态码来实现的。客户端浏览器请求服务器的时候，服务器会返回一个状态码。服务器通过 HttpServletRequestResponse 的 setStatus(int status)方法设置状态码。如果服务器返回 301 或者 302，则浏览器会到新的网址重新请求该资源。
+**重定向（Redirect）** 是利用服务器返回的状态码来实现的。客户端浏览器请求服务器的时候，服务器会返回一个状态码。服务器通过 HttpServletResponse 的 setStatus(int status)方法设置状态码。如果服务器返回 301 或者 302，则浏览器会到新的网址重新请求该资源。
 
 1. **从地址栏显示来说**：forward 是服务器请求资源，服务器直接访问目标地址的 URL，把那个 URL 的响应内容读取过来，然后把这些内容再发给浏览器。浏览器根本不知道服务器发送的内容从哪里来的，所以它的地址栏还是原来的地址。redirect 是服务端根据逻辑，发送一个状态码，告诉浏览器重新去请求那个地址。所以地址栏显示的是新的 URL。
 2. **从数据共享来说**：forward：转发页面和转发到的页面可以共享 request 里面的数据。redirect：不能共享数据。

diff --git a/docs/java/basis/BIO,NIO,AIO总结.md b/docs/java/basis/BIO,NIO,AIO总结.md
@@ -11,10 +11,10 @@
   - [2. NIO \(New I/O\)](#2-nio-new-io)
     - [2.1 NIO 简介](#21-nio-简介)
     - [2.2 NIO的特性/NIO与IO区别](#22-nio的特性nio与io区别)
-      - [1)Non-blocking IO（非阻塞IO）](#1non-blocking-io（非阻塞io）)
+      - [1)Non-blocking IO（非阻塞IO）](#1non-blocking-io非阻塞io)
       - [2)Buffer\(缓冲区\)](#2buffer缓冲区)
       - [3)Channel \(通道\)](#3channel-通道)
-      - [4)Selectors\(选择器\)](#4selectors选择器)
+      - [4)Selectors\(选择器\)](#4selector-选择器)
     - [2.3  NIO 读数据和写数据方式](#23-nio-读数据和写数据方式)
     - [2.4 NIO核心组件简单介绍](#24-nio核心组件简单介绍)
     - [2.5 代码示例](#25-代码示例)
@@ -37,7 +37,7 @@
 > 当你同步执行某项任务时，你需要等待其完成才能继续执行其他任务。当你异步执行某些操作时，你可以在完成另一个任务之前继续进行。
 
 - **同步** ：两个同步任务相互依赖，并且一个任务必须以依赖于另一任务的某种方式执行。 比如在`A->B`事件模型中，你需要先完成 A 才能执行B。 再换句话说，同步调用中被调用者未处理完请求之前，调用不返回，调用者会一直等待结果的返回。
-- **异步**： 两个异步的任务完全独立的，一方的执行不需要等待另外一方的执行。再换句话说，异步调用种一调用就返回结果不需要等待结果返回，当结果返回的时候通过回调函数或者其他方式拿着结果再做相关事情，
+- **异步**： 两个异步的任务是完全独立的，一方的执行不需要等待另外一方的执行。再换句话说，异步调用中一调用就返回结果不需要等待结果返回，当结果返回的时候通过回调函数或者其他方式拿着结果再做相关事情，
 
 **阻塞和非阻塞**