modify distributed mds

h2pl · h2pl · commit 33753f61770d · 2023-04-09T17:15:21.000+08:00
diff --git a/ReadMe.md b/ReadMe.md
@@ -334,7 +334,7 @@ todo
 [//]: # (* [搞懂分布式技术：Nginx负载均衡原理与实践 ]&#;docs/distributed/practice/搞懂分布式技术：Nginx负载均衡原理与实践.md&#;)
 * [搞懂分布式技术：LVS实现负载均衡的原理与实践 ](docs/distributed/practice/搞懂分布式技术：LVS实现负载均衡的原理与实践.md )
 * [搞懂分布式技术：分布式session解决方案与一致性hash](docs/distributed/practice/搞懂分布式技术：分布式session解决方案与一致性hash.md)
-* [搞懂分布式技术：分布式ID生成方案 ](docs/distributed/practice/搞懂分布式技术：分布式ID生成方案.md )
+* [搞懂分布式技术：分布式ID生成方案 ](docs/distributed/搞懂分布式技术：分布式ID生成方案.md )
 * [搞懂分布式技术：缓存的那些事](docs/distributed/practice/搞懂分布式技术：缓存的那些事.md)
 * [搞懂分布式技术：SpringBoot使用注解集成Redis缓存](docs/distributed/practice/搞懂分布式技术：SpringBoot使用注解集成Redis缓存.md)
 * [搞懂分布式技术：缓存更新的套路 ](docs/distributed/practice/搞懂分布式技术：缓存更新的套路.md )
diff --git a/docs/distributed/practice/分布式理论总结.md b/docs/distributed/practice/分布式理论总结.md
@@ -1,3 +1,12 @@
+# Table of Contents
+
+  * [六、Raft](#六、raft)
+    * [单个 Candidate 的竞选](#单个-candidate-的竞选)
+    * [多个 Candidate 竞选](#多个-candidate-竞选)
+    * [数据同步](#数据同步)
+  * [参考](#参考)
+
+
 ## 六、Raft
 
 Raft 也是分布式一致性协议，主要是用来竞选主节点。
@@ -63,4 +72,4 @@ Raft 也是分布式一致性协议，主要是用来竞选主节点。
 - [深入理解分布式事务](https://juejin.im/entry/577c6f220a2b5800573492be)
 - [What is CAP theorem in distributed database system?](http://www.colooshiki.com/index.php/2017/04/20/what-is-cap-theorem-in-distributed-database-system/)
 - [NEAT ALGORITHMS - PAXOS](http://harry.me/blog/2014/12/27/neat-algorithms-paxos/)
-- [Paxos By Example](https://angus.nyc/2012/paxos-by-example/)
+- [Paxos By Example](https://angus.nyc/2012/paxos-by-example/)
diff --git a/docs/distributed/practice/搞懂分布式技术：LVS实现负载均衡的原理与实践.md b/docs/distributed/practice/搞懂分布式技术：LVS实现负载均衡的原理与实践.md
@@ -1,3 +1,4 @@
+
 # 目录
 
 * [负载均衡的原理](#负载均衡的原理)
@@ -555,4 +556,4 @@ public class TestIpHash {
  }
  }
 
-````
+````
diff --git a/docs/distributed/practice/搞懂分布式技术：SpringBoot使用注解集成Redis缓存.md b/docs/distributed/practice/搞懂分布式技术：SpringBoot使用注解集成Redis缓存.md
@@ -1,3 +1,5 @@
+
+
 # 目录
 
 * [Redis配置](#redis配置)
diff --git a/docs/distributed/practice/搞懂分布式技术：ZAB协议概述与选主流程详解.md b/docs/distributed/practice/搞懂分布式技术：ZAB协议概述与选主流程详解.md
@@ -1,3 +1,31 @@
+# Table of Contents
+
+  * [ZAB协议](#zab协议)
+  * [消息广播模式](#消息广播模式)
+  * [崩溃恢复](#崩溃恢复)
+    * [数据同步](#数据同步)
+  * [ZAB协议原理](#zab协议原理)
+  * [Zookeeper设计目标](#zookeeper设计目标)
+* [ZAB与FastLeaderElection选主算法流程详解](#zab与fastleaderelection选主算法流程详解)
+  * [选择机制中的概念](#选择机制中的概念)
+    * [服务器ID](#服务器id)
+    * [数据ID](#数据id)
+    * [逻辑时钟](#逻辑时钟)
+    * [选举状态](#选举状态)
+  * [选举消息内容](#选举消息内容)
+  * [选举流程图](#选举流程图)
+    * [判断是否已经胜出](#判断是否已经胜出)
+  * [选举流程简述](#选举流程简述)
+  * [几种领导选举场景](#几种领导选举场景)
+    * [集群启动领导选举](#集群启动领导选举)
+    * [Follower重启](#follower重启)
+    * [Leader重启](#leader重启)
+* [一致性保证](#一致性保证)
+  * [Commit过的数据不丢失](#commit过的数据不丢失)
+  * [未Commit过的消息对客户端不可见")未Commit过的消息对客户端不可见](#未commit过的消息对客户端不可见未commit过的消息对客户端不可见)
+* [总结](#总结)
+
+
 本文内容参考网络，侵删
 
 本系列文章将整理到我在GitHub上的《Java面试指南》仓库，更多精彩内容请到我的仓库里查看
@@ -348,4 +376,4 @@ ZAB协议保证了在Leader选举的过程中，已经被Commit的数据不会
 *   由于使用主从复制模式，所有的写操作都要由Leader主导完成，而读操作可通过任意节点完成，因此Zookeeper读性能远好于写性能，更适合读多写少的场景
 *   虽然使用主从复制模式，同一时间只有一个Leader，但是Failover机制保证了集群不存在单点失败（SPOF）的问题
 *   ZAB协议保证了Failover过程中的数据一致性
-*   服务器收到数据后先写本地文件再进行处理，保证了数据的持久性
+*   服务器收到数据后先写本地文件再进行处理，保证了数据的持久性
diff --git a/docs/distributed/practice/搞懂分布式技术：Zookeeper典型应用场景及实践.md b/docs/distributed/practice/搞懂分布式技术：Zookeeper典型应用场景及实践.md
@@ -1,3 +1,4 @@
+
 # 目录
 
 * [一.ZooKeeper典型应用场景实践](#一zookeeper典型应用场景实践)
@@ -479,4 +480,4 @@ Master选举
 
 第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。
 
-同步队列。一个job由多个task组成，只有所有任务完成后，job才运行完成。可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时znode，一旦临时节点数目达到task总数，则job运行完成。
+同步队列。一个job由多个task组成，只有所有任务完成后，job才运行完成。可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时znode，一旦临时节点数目达到task总数，则job运行完成。
diff --git a/docs/distributed/practice/搞懂分布式技术：Zookeeper的配置与集群管理实战.md b/docs/distributed/practice/搞懂分布式技术：Zookeeper的配置与集群管理实战.md
@@ -1,3 +1,5 @@
+
+
 # 目录
 
 * [4.1 配置文件](#41-配置文件)
@@ -347,4 +349,4 @@ server.3=127.0.0.1:2890:3890
 
 ![](https://java-tutorial.oss-cn-shanghai.aliyuncs.com/20230407212836.png))
 
-可见，关闭zk3以后，由于集群中的可用Server只剩下一台（达不到集群总数的半数以上），**集群将处于不可用的状态。**
+可见，关闭zk3以后，由于集群中的可用Server只剩下一台（达不到集群总数的半数以上），**集群将处于不可用的状态。**
diff --git a/docs/distributed/practice/搞懂分布式技术：使用RocketMQ事务消息解决分布式事务.md b/docs/distributed/practice/搞懂分布式技术：使用RocketMQ事务消息解决分布式事务.md
@@ -1,3 +1,4 @@
+
 # 目录
 
 * [初步认识RocketMQ的核心模块](#初步认识rocketmq的核心模块)
diff --git a/docs/distributed/practice/搞懂分布式技术：分布式session解决方案与一致性hash.md b/docs/distributed/practice/搞懂分布式技术：分布式session解决方案与一致性hash.md
@@ -1,3 +1,21 @@
+# Table of Contents
+
+* [一、问题的提出](#一、问题的提出)
+  * [1. 什么是Session？](#1-什么是session？)
+  * [2. 什么是Session一致性问题？](#2-什么是session一致性问题？)
+* [二、Session一致性解决方案](#二、session一致性解决方案)
+  * [1. Session Stiky](#1-session-stiky)
+  * [2. Session Replication](#2-session-replication)
+  * [3. Session数据集中存储](#3-session数据集中存储)
+  * [4. Cookie Based](#4-cookie-based)
+* [三、总结](#三、总结)
+  * [一致性Hash概述](#一致性hash概述)
+  * [一致性hash的特性](#一致性hash的特性)
+  * [虚拟节点](#虚拟节点)
+  * [均匀一致性hash](#均匀一致性hash)
+  * [总结](#总结)
+
+
 
 本文内容参考网络，侵删
 
@@ -182,4 +200,4 @@ hash环上顺时针从整数0开始，一直到最大正整数，我们根据四
 
 ## 总结
 
-在分布式系统中一致性hash起着不可忽略的地位，无论是分布式缓存，还是分布式Rpc框架的负载均衡策略都有所使用。
+在分布式系统中一致性hash起着不可忽略的地位，无论是分布式缓存，还是分布式Rpc框架的负载均衡策略都有所使用。
diff --git a/docs/distributed/practice/搞懂分布式技术：分布式一致性协议与Paxos，Raft算法.md b/docs/distributed/practice/搞懂分布式技术：分布式一致性协议与Paxos，Raft算法.md
@@ -1,3 +1,5 @@
+
+
 # 目录
 
 * [2PC](#2pc)
@@ -481,4 +483,4 @@ Leader 会等待大多数的 Follower 也进行了修改，然后才将修改提
     What is CAP theorem in distributed database system?
     NEAT ALGORITHMS - PAXOS
     Raft: Understandable Distributed Consensus
-    Paxos By Example
+    Paxos By Example
diff --git a/docs/distributed/practice/搞懂分布式技术：分布式事务常用解决方案.md b/docs/distributed/practice/搞懂分布式技术：分布式事务常用解决方案.md
@@ -1,3 +1,16 @@
+# Table of Contents
+
+* [一、概述](#一、概述)
+* [二、理论](#二、理论)
+  * [2.1、二阶段提交](#21、二阶段提交)
+  * [2.2、三阶段提交](#22、三阶段提交)
+  * [2.3、TCC柔性事务](#23、tcc柔性事务)
+  * [2.4、Seata](#24、seata)
+* [三、应用场景](#三、应用场景)
+* [四、总结](#四、总结)
+* [五、参考源码](#五、参考源码)
+
+
 
 > 数据不会无缘无故丢失，也不会莫名其妙增加
 
@@ -155,4 +168,4 @@ CREATE TABLE `tb_notice_message` (  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT
 编程文档：https://gitee.com/cicadasmile/butte-java-note应用仓库：https://gitee.com/cicadasmile/butte-flyer-parent
 ```
 
-本文转载自 https://mp.weixin.qq.com/s/xa9Giv9xdSM3AahwN3WckQ
+本文转载自 https://mp.weixin.qq.com/s/xa9Giv9xdSM3AahwN3WckQ
diff --git a/docs/distributed/practice/搞懂分布式技术：分布式系统的一些基本概念.md b/docs/distributed/practice/搞懂分布式技术：分布式系统的一些基本概念.md
@@ -1,3 +1,4 @@
+
 # 目录
   * [1、分布式](#1、分布式)
   * [2、集群（Cluster）](#2、集群（cluster）)
diff --git a/docs/distributed/practice/搞懂分布式技术：初探分布式协调服务zookeeper.md b/docs/distributed/practice/搞懂分布式技术：初探分布式协调服务zookeeper.md
@@ -1,3 +1,12 @@
+# Table of Contents
+
+* [目录](#目录)
+  * [小梁的邮件](#小梁的邮件)
+  * [小王的Master选举](#小王的master选举)
+  * [小蔡的分布式锁](#小蔡的分布式锁)
+  * [Zookeeper](#zookeeper)
+
+
 # 目录
 
 本文转自：微信公众号【码农翻身】
@@ -152,4 +161,4 @@ Zookeeper 所使用的树形结构和自己想象的非常类似，更重要的
 
 _后记：本文从使用者的角度描述了Zookeeper有什么用处，至于它内部是如何工作，那是另外一个Big topic了，我们以后再讲。___
 
-（完）
+（完）
diff --git a/docs/distributed/practice/搞懂分布式技术：浅析分布式事务.md b/docs/distributed/practice/搞懂分布式技术：浅析分布式事务.md
@@ -1,3 +1,19 @@
+# Table of Contents
+
+* [目录](#目录)
+  * [什么是事务？](#什么是事务？)
+  * [事务的四大特性 ACID](#事务的四大特性-acid)
+  * [事务的隔离级别](#事务的隔离级别)
+  * [事务并发执行会出现的问题](#事务并发执行会出现的问题)
+  * [数据库的四种隔离级别](#数据库的四种隔离级别)
+  * [什么是分布式事务？](#什么是分布式事务？)
+  * [CAP理论](#cap理论)
+  * [BASE理论](#base理论)
+  * [分布式事务协议](#分布式事务协议)
+    * [2PC](#2pc)
+    * [3PC](#3pc)
+
+
 # 目录
 
 本文转载自 linkedkeeper.com
diff --git a/docs/distributed/practice/搞懂分布式技术：浅谈分布式消息技术Kafka.md b/docs/distributed/practice/搞懂分布式技术：浅谈分布式消息技术Kafka.md
@@ -1,3 +1,18 @@
+# Table of Contents
+
+* [目录](#目录)
+  * [**Kafka的基本介绍**](#kafka的基本介绍)
+  * [**Kafka的设计原理分析**](#kafka的设计原理分析)
+  * [**Kafka数据传输的事务特点**](#kafka数据传输的事务特点)
+  * [**Kafka消息存储格式**](#kafka消息存储格式)
+  * [**副本（replication）策略**](#副本（replication）策略)
+  * [**Kafka消息分组，消息消费原理**](#kafka消息分组，消息消费原理)
+  * [**Push vs. Pull**](#push-vs-pull)
+  * [**Kafak顺序写入与数据读取**](#kafak顺序写入与数据读取)
+  * [**消费者（读取数据）**](#消费者（读取数据）)
+  * [**Reference**](#reference)
+
+
 # 目录
 
 本文转载自 linkedkeeper.com  
@@ -281,4 +296,4 @@ https://my.oschina.net/silence88/blog/856195
 
 https://toutiao.io/posts/508935/app_preview
 
-转载请并标注: “本文转载自 linkedkeeper.com ”
+转载请并标注: “本文转载自 linkedkeeper.com ”
diff --git a/docs/distributed/practice/搞懂分布式技术：浅谈分布式锁的几种方案.md b/docs/distributed/practice/搞懂分布式技术：浅谈分布式锁的几种方案.md
@@ -1,3 +1,15 @@
+# Table of Contents
+
+* [目录](#目录)
+  * [前言](#前言)
+  * [分布式一致性问题](#分布式一致性问题)
+  * [分布式锁需要具备哪些条件](#分布式锁需要具备哪些条件)
+  * [分布式锁实现方式](#分布式锁实现方式)
+  * [解决上述问题有两种方案](#解决上述问题有两种方案)
+  * [zookeeper分布式锁](#zookeeper分布式锁)
+  * [小结](#小结)
+
+
 # 目录
 
 本文内容参考网络，侵删
diff --git a/docs/distributed/practice/搞懂分布式技术：消息队列因何而生.md b/docs/distributed/practice/搞懂分布式技术：消息队列因何而生.md
@@ -1,5 +1,5 @@
-#目录
 
+# 目录
 * [何时需要消息队列](#何时需要消息队列)
     * [解耦](#解耦)
     * [最终一致性](#最终一致性)
@@ -404,4 +404,4 @@ Future<Result> future = request(server);//server立刻返回future return future
 
 # 总结
 
-本文从为何使用消息队列开始讲起，然后主要介绍了如何从零开始设计一个消息队列，包括RPC、事务、最终一致性、广播、消息确认等关键问题。并对消息队列的push、pull模型做了简要分析，最后从批量和异步角度，分析了消息队列性能优化的思路。下篇会着重介绍一些高级话题，如存储系统的设计、流控和错峰的设计、公平调度等。希望通过这些，让大家对消息队列有个提纲挈领的整体认识，并给自主开发消息队列提供思路。另外，本文主要是源自自己在开发消息队列中的思考和读源码时的体会，比较不"官方"，也难免会存在一些漏洞，欢迎大家多多交流。
+本文从为何使用消息队列开始讲起，然后主要介绍了如何从零开始设计一个消息队列，包括RPC、事务、最终一致性、广播、消息确认等关键问题。并对消息队列的push、pull模型做了简要分析，最后从批量和异步角度，分析了消息队列性能优化的思路。下篇会着重介绍一些高级话题，如存储系统的设计、流控和错峰的设计、公平调度等。希望通过这些，让大家对消息队列有个提纲挈领的整体认识，并给自主开发消息队列提供思路。另外，本文主要是源自自己在开发消息队列中的思考和读源码时的体会，比较不"官方"，也难免会存在一些漏洞，欢迎大家多多交流。
diff --git a/docs/distributed/practice/搞懂分布式技术：缓存更新的套路.md b/docs/distributed/practice/搞懂分布式技术：缓存更新的套路.md
@@ -1,3 +1,4 @@
+
 # 目录
 
 * [缓存更新的套路](#缓存更新的套路)  
@@ -106,4 +107,4 @@ Write Back套路，一句说就是，在更新数据的时候，只更新缓存
 
 4）上面，我们没有考虑缓存（Cache）和持久层（Repository）的整体事务的问题。比如，更新Cache成功，更新数据库失败了怎么吗？或是反过来。关于这个事，如果你需要强一致性，你需要使用“两阶段提交协议”——prepare, commit/rollback，比如Java 7 的[XAResource](http://docs.oracle.com/javaee/7/api/javax/transaction/xa/XAResource.html)，还有MySQL 5.7的 [XA Transaction](http://dev.mysql.com/doc/refman/5.7/en/xa.html)，有些cache也支持XA，比如[EhCache](http://www.ehcache.org/documentation/3.0/xa.html)。当然，XA这样的强一致性的玩法会导致性能下降，关于分布式的事务的相关话题，你可以看看《[分布式系统的事务处理](https://coolshell.cn/articles/10910.html)》一文。
 
-（全文完）
+（全文完）
diff --git a/docs/distributed/搞懂分布式技术：分布式ID生成方案.md b/docs/distributed/搞懂分布式技术：分布式ID生成方案.md
@@ -1,6 +1,12 @@
-# 目录
+# Table of Contents
+
+  * [**一、需求缘起**](#一、需求缘起)
+  * [**二、常见方法、不足与优化**](#二、常见方法、不足与优化)
+  * [**方法二：单点批量ID生成服务**](#方法二：单点批量id生成服务)
+  * [**方法三：uuid/guid**](#方法三：uuidguid)
+  * [**方法四：取当前毫秒数**](#方法四：取当前毫秒数)
+
 
-* [分布式ID生成器 | 架构师之路](#分布式id生成器--架构师之路)
 
 本文内容参考网络，侵删
 
@@ -19,11 +25,10 @@
 如果对本系列文章有什么建议，或者是有什么疑问的话，也可以关注公众号【Java技术江湖】联系作者，欢迎你参与本系列博文的创作和修订。
 
 <!-- more -->  
-## 分布式ID生成器 | 架构师之路
 
 转自：58沈剑架构师之路2017-06-25
 
-**一、需求缘起**
+## **一、需求缘起**
 
 几乎所有的业务系统，都有生成一个唯一记录标识的需求，例如：
 
@@ -65,7 +70,7 @@ select message-id/ (order by message-id)/limit 100
 
 这也是本文要讨论的核心问题：**如何高效生成趋势有序的全局唯一ID。**
 
-**二、常见方法、不足与优化**
+## **二、常见方法、不足与优化**
 
 **方法一：使用数据库的auto_increment来生成全局唯一递增ID**
 
@@ -103,7 +108,7 @@ select message-id/ (order by message-id)/limit 100
 
 为了解决上述两个问题，引出了第二个常见的方案。
 
-**方法二：单点批量ID生成服务**
+## **方法二：单点批量ID生成服务**
 
 分布式系统之所以难，很重要的原因之一是“没有一个全局时钟，难以保证绝对的时序”，要想保证绝对的时序，还是只能使用单点服务，用本地时钟保证“绝对时序”。
 
@@ -143,7 +148,7 @@ ID生成服务假设每次批量拉取6个ID，服务访问数据库，将当前
 
 另外，ID-gen-service也可以实施水平扩展，以解决上述缺点（3），但会引发一致性问题，具体解决方案详见《》。
 
-**方法三：uuid/guid**
+## **方法三：uuid/guid**
 
 不管是通过数据库，还是通过服务来生成ID，业务方Application都需要进行一次远程调用，比较耗时。
 
@@ -165,7 +170,7 @@ string ID =GenUUID();
 
 *   uuid过长，往往用字符串表示，作为主键建立索引查询效率低，常见优化方案为“转化为两个uint64整数存储”或者“折半存储”（折半后不能保证唯一性）
 
-**方法四：取当前毫秒数**
+## **方法四：取当前毫秒数**
 
 uuid是一个本地算法，生成性能高，但无法保证趋势递增，且作为字符串ID检索效率低，有没有一种能保证递增的本地算法呢？
 
@@ -237,4 +242,4 @@ snowflake是twitter开源的分布式ID生成算法，其**核心思想为，**
 
 **缺点**：
 
-*   由于“没有一个全局时钟”，每台服务器分配的ID是绝对递增的，但从全局看，生成的ID只是趋势递增的（有些服务器的时间早，有些服务器的时间晚）
+*   由于“没有一个全局时钟”，每台服务器分配的ID是绝对递增的，但从全局看，生成的ID只是趋势递增的（有些服务器的时间早，有些服务器的时间晚）
diff --git a/src/main/java/md/mdToc.java b/src/main/java/md/mdToc.java
@@ -4,7 +4,7 @@
 
 public class mdToc {
     public static void main(String[] args) {
-        String path = "D:\\idea_project\\JavaTutorial\\docs\\distributed\\basic";
+        String path = "D:\\idea_project\\JavaTutorial\\docs\\distributed\\practice\\temp";
         AtxMarkdownToc.newInstance().genTocDir(path);
     }
 }

Original file line number	Diff line number	Diff line change
`@@ -1,3 +1,4 @@`
	`1`	`+`
`1`	`2`	`# 目录`
`2`	`3`
`3`	`4`	`* [负载均衡的原理](#负载均衡的原理)`
`@@ -555,4 +556,4 @@ public class TestIpHash {`
`555`	`556`	`}`
`556`	`557`	`}`
`557`	`558`
`558`		-````
	`559`	+````
Original file line number	Diff line number	Diff line change
`@@ -1,3 +1,5 @@`
	`1`	`+`
	`2`	`+`
`1`	`3`	`# 目录`
`2`	`4`
`3`	`5`	`* [Redis配置](#redis配置)`
Original file line number	Diff line number	Diff line change
`@@ -1,3 +1,4 @@`
	`1`	`+`
`1`	`2`	`# 目录`
`2`	`3`
`3`	`4`	`* [初步认识RocketMQ的核心模块](#初步认识rocketmq的核心模块)`