更新内容

.vuepress/config.js

@@ -58,7 +58,7 @@ export default defineUserConfig({
             }
         ],
         sidebar: [
-            //'/intro.md',
+            '/intro.md',
             '/noun.md',
             {
                 text: '第一章：云原生技术概论',

consensus/The-Byzantine-General-Problem.md

@@ -2,6 +2,8 @@
 
 Lamport 认为“故事让问题变得欢迎”，因此他在提出观点和问题时常用故事背景吸引眼球。所以，拜占庭将军问题不是研究历史，而是 Lamport 在研究分布式系统容错性时编的一个故事。
 
+笔者用几千字描述这个问题，似乎有着啰嗦，但你会真正理解为什么所有的容错系统必须  (n-1)/2 个节点正常才能运行。
+
 :::tip 拜占庭将军问题描述
 
 拜占庭帝国派出多支军队去围攻一个强大的敌人，每支军队有一个将军，但由于彼此距离较远，他们之间只能通过信使传递消息。敌方很强大，必须有超过半数的拜占庭军队一同参与进攻才可能击败敌人。在此期间，将军们彼此之间需要通过信使传递消息并协商一致后，在同一时间点发动进攻。

consensus/summary.md

@@ -2,10 +2,11 @@
 
 笔者一直认为分布式容错系统是软件工程里面最难啃的领域，想想在充斥着无序、冲突和不可靠的网络环境中实现数据一致就感到头疼。虽然这些复杂是道门槛，但对于程序员构建自己的知识体系而言，只要理解这些复杂产生的原因，那么也就懂了构建大规模分布式系统的要素是什么。
 
-如图 6-1 所示，在本章，我们知难而上，从解决问题的角度去分析分布式容错系统，从共识问题认识 Paxos，以工程实践为目的去了解 Raft 的设计思路。理解了问题，以及这些共识算法的解题思路，自然也能体会到 etcd、consul 以及各类分布式容错系统的设计原理。
+如图 6-1 所示，在本章，我们知难而上，从解决问题的角度去分析分布式容错系统，从共识问题认识 Paxos，以工程实践为目的去了解 Raft 的设计思路。理解了问题以及这些共识算法的解题思路，自然也能体会到 etcd、consul 以及各类分布式容错系统的设计原理，也能更好地把这些理解实践到现实[^1]。
 
 <div  align="center">
 	<img src="../assets/consensus.png" width = "450"  align=center />
 	<p>图 6-1 本章内容导图</p>
 </div>
 
+[^1]: 7.9.1 篇节

http/bbr.md

@@ -64,9 +64,9 @@ Google 在 ACM 杂志上发布过一篇文章 《BBR: Congestion-Based Congestio
 	<p>图2-21 早期拥塞控制</p>
 </div>
 
-这些机制完美适应了 1980 年代的网络特征：低带宽、浅缓存队列，美好持续到了 2000 年代。随后互联网大爆发，多媒体应用特别是图片，音视频类的应用促使带宽必须猛增，而摩尔定律促使存储设施趋于廉价而路由器队列缓存猛增，这便是 BBR 诞生的背景。换句话说，1980 年代的拥塞控已经不适用了，2010 年代需要另外的一次见招拆招。
+这些机制完美适应了 1980 年代的网络特征：低带宽、浅缓存队列。美好持续到了 2000 年代，随后互联网大爆发，多媒体应用特别是图片、音视频类促使带宽猛增，而摩尔定律促使存储设施趋于廉价、网关路由设备队列缓存猛增。链路变长变宽、设备性能提升，初代的拥塞控已经不适用，新的时代需要另外的一次见招拆招 -- 这便是 BBR 诞生的背景。
 
-如果说上一次 1980 年代的拥塞控制旨在收敛，那么这一次 BBR 则旨在效能最大化。
+如果说上一次 1980 年代的拥塞控制旨在收敛，那么这一次 BBR 则旨在网络效能最大化。
 
 ### 1. 网络效能最大化
 

intro.md

@@ -31,4 +31,6 @@
 
 ## 致谢
 
-首先感谢我的家人，
+首先感谢我的家人，
+
+写作不是无中生有，