feat(basic): add BASE

系统设计基础/分布式/README.md

@@ -2,7 +2,7 @@
  * @Author: shgopher shgopher@gmail.com
  * @Date: 2024-09-14 13:02:10
  * @LastEditors: shgopher shgopher@gmail.com
- * @LastEditTime: 2024-10-28 10:22:54
+ * @LastEditTime: 2024-10-28 12:42:12
  * @FilePath: /luban/系统设计基础/分布式/README.md
  * @Description: 
  * 
@@ -12,8 +12,8 @@
 ## 分布式理论
 - [拜占庭将军问题](./分布式理论/拜占庭将军问题/README.md)
 - [CAP](./分布式理论/CAP/README.md)
-- [BASE](./分布式理论/BASE/README.md)
 - [ACID](./分布式理论/ACID/README.md)
+- [BASE](./分布式理论/BASE/README.md)
 ## 分布式算法
 - [paxos](./分布式算法/paxos/README.md)
 - [raft](./分布式算法/raft/README.md)

系统设计基础/分布式/分布式理论/BASE/README.md

@@ -2,12 +2,44 @@
  * @Author: shgopher shgopher@gmail.com
  * @Date: 2024-10-27 23:44:39
  * @LastEditors: shgopher shgopher@gmail.com
- * @LastEditTime: 2024-10-27 23:47:48
- * @FilePath: /luban/系统设计基础/分布式/分布式理论/BASE/README
+ * @LastEditTime: 2024-10-28 13:04:08
+ * @FilePath: /luban/系统设计基础/分布式/分布式理论/BASE/README.md
  * @Description: 
  * 
  * Copyright (c) 2024 by shgopher, All Rights Reserved. 
 -->
 # BASE
 
 BASE：basically available eventually consistent，基本可用，最终一致主要追求的是 AP 即：高可用性
+
+在正常的系统中，**AP 模型永远是主流**，因为 CP 模型的不可用占比过大是不可接受的行为，比如每个节点的可用性为 99.9%，那么众多集群的可用性因为是乘机就会下降的非常厉害，比如变成了 99.7%，那么一个月就要有 100 多分钟的不可用时间，这对于系统来说非常的灾难
+
+**1 基本可用，2 最终一致性是 BASE 的核心思想**
+
+## 基本可用
+- 服务降级，允许损失部分功能的可用性保障核心功能的可用性，服务降级来保证核心体验，比如新闻 App 不能观看视频和照片了，但是能看新闻的文字，文字乃是新闻的核心功能，或者高清图片替换为缩略图，等等方案。
+- 流量削峰，错峰请求，来满足整体可用
+- 延迟响应，先把需求放到消息队列中，后台慢慢处理
+- 过载保护流量限流，如果数据量过大就要开始限流，直接拒绝服务
+## 最终一致
+最常见的一个体验，微信更新头像，你的朋友并不会立刻看到，他们甚至需要刻意点开你的头像才能看到你更新了头像
+
+最终一致性的核心问题是**以什么数据为准？**
+
+- 以最新的写入数据为准，哪个节点最新用哪个
+- 以第一次的写入数据为准
+
+那么我们该如何实现最终一致性呢？
+
+- 读时修复，在读取数据时，如果数据不一致，进行修复，也就是如果系统在读取的时候检测到数据并不一致，开始自动修复数据
+- 写时修复，在写入数据时，检测到数据不一致，进行修复
+- **异步修复**，这个最常见，经常在后台进行测试数据，通过定时对账来检测数据的一致性，并且修复数据
+
+写时修复不需要做数据一致性的对比，性能消耗是最低的，因为写的数据哪个最新就用哪个就行了
+
+在实现最终一致性的时候，同时实现自定义写一致性级别
+(All、Quorum、One、Any)，让用户可以自主选择相应的一致性级别，比如可以通过
+设置一致性级别为 All，来实现强一致性
+## BASE 的实践
+
+