Skip to content

Commit 33753f6

Browse files
h2plh2pl
committed
modify distributed mds
1 parent 19319b2 commit 33753f6

20 files changed

+160
-24
lines changed

‎ReadMe.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -334,7 +334,7 @@ todo
334334
[//]: # (* [搞懂分布式技术：Nginx负载均衡原理与实践 ]&#;docs/distributed/practice/搞懂分布式技术：Nginx负载均衡原理与实践.md&#;)
335335
* [搞懂分布式技术：LVS实现负载均衡的原理与实践 ](docs/distributed/practice/搞懂分布式技术：LVS实现负载均衡的原理与实践.md )
336336
* [搞懂分布式技术：分布式session解决方案与一致性hash](docs/distributed/practice/搞懂分布式技术：分布式session解决方案与一致性hash.md)
337-
* [搞懂分布式技术：分布式ID生成方案 ](docs/distributed/practice/搞懂分布式技术：分布式ID生成方案.md )
337+
* [搞懂分布式技术：分布式ID生成方案 ](docs/distributed/搞懂分布式技术：分布式ID生成方案.md )
338338
* [搞懂分布式技术：缓存的那些事](docs/distributed/practice/搞懂分布式技术：缓存的那些事.md)
339339
* [搞懂分布式技术：SpringBoot使用注解集成Redis缓存](docs/distributed/practice/搞懂分布式技术：SpringBoot使用注解集成Redis缓存.md)
340340
* [搞懂分布式技术：缓存更新的套路 ](docs/distributed/practice/搞懂分布式技术：缓存更新的套路.md )

‎docs/distributed/practice/分布式理论总结.md

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,12 @@
1+
# Table of Contents
2+
3+
* [六、Raft](#六、raft)
4+
* [单个 Candidate 的竞选](#单个-candidate-的竞选)
5+
* [多个 Candidate 竞选](#多个-candidate-竞选)
6+
* [数据同步](#数据同步)
7+
* [参考](#参考)
8+
9+
110
## 六、Raft
211

312
Raft 也是分布式一致性协议，主要是用来竞选主节点。
@@ -63,4 +72,4 @@ Raft 也是分布式一致性协议，主要是用来竞选主节点。
6372
- [深入理解分布式事务](https://juejin.im/entry/577c6f220a2b5800573492be)
6473
- [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/)
6574
- [NEAT ALGORITHMS - PAXOS](http://harry.me/blog/2014/12/27/neat-algorithms-paxos/)
66-
- [Paxos By Example](https://angus.nyc/2012/paxos-by-example/)
75+
- [Paxos By Example](https://angus.nyc/2012/paxos-by-example/)

‎docs/distributed/practice/搞懂分布式技术：LVS实现负载均衡的原理与实践.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,4 @@
1+
12
# 目录
23

34
* [负载均衡的原理](#负载均衡的原理)
@@ -555,4 +556,4 @@ public class TestIpHash {
555556
}
556557
}
557558

558-
````
559+
````

‎docs/distributed/practice/搞懂分布式技术：SpringBoot使用注解集成Redis缓存.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,5 @@
1+
2+
13
# 目录
24

35
* [Redis配置](#redis配置)

‎docs/distributed/practice/搞懂分布式技术：ZAB协议概述与选主流程详解.md

Lines changed: 29 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,31 @@
1+
# Table of Contents
2+
3+
* [ZAB协议](#zab协议)
4+
* [消息广播模式](#消息广播模式)
5+
* [崩溃恢复](#崩溃恢复)
6+
* [数据同步](#数据同步)
7+
* [ZAB协议原理](#zab协议原理)
8+
* [Zookeeper设计目标](#zookeeper设计目标)
9+
* [ZAB与FastLeaderElection选主算法流程详解](#zab与fastleaderelection选主算法流程详解)
10+
* [选择机制中的概念](#选择机制中的概念)
11+
* [服务器ID](#服务器id)
12+
* [数据ID](#数据id)
13+
* [逻辑时钟](#逻辑时钟)
14+
* [选举状态](#选举状态)
15+
* [选举消息内容](#选举消息内容)
16+
* [选举流程图](#选举流程图)
17+
* [判断是否已经胜出](#判断是否已经胜出)
18+
* [选举流程简述](#选举流程简述)
19+
* [几种领导选举场景](#几种领导选举场景)
20+
* [集群启动领导选举](#集群启动领导选举)
21+
* [Follower重启](#follower重启)
22+
* [Leader重启](#leader重启)
23+
* [一致性保证](#一致性保证)
24+
* [Commit过的数据不丢失](#commit过的数据不丢失)
25+
* [未Commit过的消息对客户端不可见")未Commit过的消息对客户端不可见](#未commit过的消息对客户端不可见未commit过的消息对客户端不可见)
26+
* [总结](#总结)
27+
28+
129
本文内容参考网络，侵删
230

331
本系列文章将整理到我在GitHub上的《Java面试指南》仓库，更多精彩内容请到我的仓库里查看
@@ -348,4 +376,4 @@ ZAB协议保证了在Leader选举的过程中，已经被Commit的数据不会
348376
* 由于使用主从复制模式，所有的写操作都要由Leader主导完成，而读操作可通过任意节点完成，因此Zookeeper读性能远好于写性能，更适合读多写少的场景
349377
* 虽然使用主从复制模式，同一时间只有一个Leader，但是Failover机制保证了集群不存在单点失败（SPOF）的问题
350378
* ZAB协议保证了Failover过程中的数据一致性
351-
* 服务器收到数据后先写本地文件再进行处理，保证了数据的持久性
379+
* 服务器收到数据后先写本地文件再进行处理，保证了数据的持久性

‎docs/distributed/practice/搞懂分布式技术：Zookeeper典型应用场景及实践.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,4 @@
1+
12
# 目录
23

34
* [一.ZooKeeper典型应用场景实践](#一zookeeper典型应用场景实践)
@@ -479,4 +480,4 @@ Master选举
479480

480481
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。
481482

482-
同步队列。一个job由多个task组成，只有所有任务完成后，job才运行完成。可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时znode，一旦临时节点数目达到task总数，则job运行完成。
483+
同步队列。一个job由多个task组成，只有所有任务完成后，job才运行完成。可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时znode，一旦临时节点数目达到task总数，则job运行完成。

‎docs/distributed/practice/搞懂分布式技术：Zookeeper的配置与集群管理实战.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,5 @@
1+
2+
13
# 目录
24

35
* [4.1 配置文件](#41-配置文件)
@@ -347,4 +349,4 @@ server.3=127.0.0.1:2890:3890
347349

348350
![](https://java-tutorial.oss-cn-shanghai.aliyuncs.com/20230407212836.png))
349351

350-
可见，关闭zk3以后，由于集群中的可用Server只剩下一台（达不到集群总数的半数以上），**集群将处于不可用的状态。**
352+
可见，关闭zk3以后，由于集群中的可用Server只剩下一台（达不到集群总数的半数以上），**集群将处于不可用的状态。**

‎docs/distributed/practice/搞懂分布式技术：使用RocketMQ事务消息解决分布式事务.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,4 @@
1+
12
# 目录
23

34
* [初步认识RocketMQ的核心模块](#初步认识rocketmq的核心模块)

‎docs/distributed/practice/搞懂分布式技术：分布式session解决方案与一致性hash.md

Lines changed: 19 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,21 @@
1+
# Table of Contents
2+
3+
* [一、问题的提出](#一、问题的提出)
4+
* [1. 什么是Session？](#1-什么是session？)
5+
* [2. 什么是Session一致性问题？](#2-什么是session一致性问题？)
6+
* [二、Session一致性解决方案](#二、session一致性解决方案)
7+
* [1. Session Stiky](#1-session-stiky)
8+
* [2. Session Replication](#2-session-replication)
9+
* [3. Session数据集中存储](#3-session数据集中存储)
10+
* [4. Cookie Based](#4-cookie-based)
11+
* [三、总结](#三、总结)
12+
* [一致性Hash概述](#一致性hash概述)
13+
* [一致性hash的特性](#一致性hash的特性)
14+
* [虚拟节点](#虚拟节点)
15+
* [均匀一致性hash](#均匀一致性hash)
16+
* [总结](#总结)
17+
18+
119

220
本文内容参考网络，侵删
321

@@ -182,4 +200,4 @@ hash环上顺时针从整数0开始，一直到最大正整数，我们根据四
182200

183201
## 总结
184202

185-
在分布式系统中一致性hash起着不可忽略的地位，无论是分布式缓存，还是分布式Rpc框架的负载均衡策略都有所使用。
203+
在分布式系统中一致性hash起着不可忽略的地位，无论是分布式缓存，还是分布式Rpc框架的负载均衡策略都有所使用。

‎docs/distributed/practice/搞懂分布式技术：分布式一致性协议与Paxos，Raft算法.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,5 @@
1+
2+
13
# 目录
24

35
* [2PC](#2pc)
@@ -481,4 +483,4 @@ Leader 会等待大多数的 Follower 也进行了修改，然后才将修改提
481483
What is CAP theorem in distributed database system?
482484
NEAT ALGORITHMS - PAXOS
483485
Raft: Understandable Distributed Consensus
484-
Paxos By Example
486+
Paxos By Example

‎docs/distributed/practice/搞懂分布式技术：分布式事务常用解决方案.md

Lines changed: 14 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,16 @@
1+
# Table of Contents
2+
3+
* [一、概述](#一、概述)
4+
* [二、理论](#二、理论)
5+
* [2.1、二阶段提交](#21、二阶段提交)
6+
* [2.2、三阶段提交](#22、三阶段提交)
7+
* [2.3、TCC柔性事务](#23、tcc柔性事务)
8+
* [2.4、Seata](#24、seata)
9+
* [三、应用场景](#三、应用场景)
10+
* [四、总结](#四、总结)
11+
* [五、参考源码](#五、参考源码)
12+
13+
114

215
> 数据不会无缘无故丢失，也不会莫名其妙增加
316
@@ -155,4 +168,4 @@ CREATE TABLE `tb_notice_message` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT
155168
编程文档：https://gitee.com/cicadasmile/butte-java-note应用仓库：https://gitee.com/cicadasmile/butte-flyer-parent
156169
```
157170

158-
本文转载自 https://mp.weixin.qq.com/s/xa9Giv9xdSM3AahwN3WckQ
171+
本文转载自 https://mp.weixin.qq.com/s/xa9Giv9xdSM3AahwN3WckQ

‎docs/distributed/practice/搞懂分布式技术：分布式系统的一些基本概念.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,4 @@
1+
12
# 目录
23
* [1、分布式](#1、分布式)
34
* [2、集群（Cluster）](#2、集群（cluster）)

‎docs/distributed/practice/搞懂分布式技术：初探分布式协调服务zookeeper.md

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,12 @@
1+
# Table of Contents
2+
3+
* [目录](#目录)
4+
* [小梁的邮件](#小梁的邮件)
5+
* [小王的Master选举](#小王的master选举)
6+
* [小蔡的分布式锁](#小蔡的分布式锁)
7+
* [Zookeeper](#zookeeper)
8+
9+
110
# 目录
211

312
本文转自：微信公众号【码农翻身】
@@ -152,4 +161,4 @@ Zookeeper 所使用的树形结构和自己想象的非常类似，更重要的
152161

153162
_后记：本文从使用者的角度描述了Zookeeper有什么用处，至于它内部是如何工作，那是另外一个Big topic了，我们以后再讲。___
154163

155-
（完）
164+
（完）

‎docs/distributed/practice/搞懂分布式技术：浅析分布式事务.md

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,19 @@
1+
# Table of Contents
2+
3+
* [目录](#目录)
4+
* [什么是事务？](#什么是事务？)
5+
* [事务的四大特性 ACID](#事务的四大特性-acid)
6+
* [事务的隔离级别](#事务的隔离级别)
7+
* [事务并发执行会出现的问题](#事务并发执行会出现的问题)
8+
* [数据库的四种隔离级别](#数据库的四种隔离级别)
9+
* [什么是分布式事务？](#什么是分布式事务？)
10+
* [CAP理论](#cap理论)
11+
* [BASE理论](#base理论)
12+
* [分布式事务协议](#分布式事务协议)
13+
* [2PC](#2pc)
14+
* [3PC](#3pc)
15+
16+
117
# 目录
218

319
本文转载自 linkedkeeper.com

‎docs/distributed/practice/搞懂分布式技术：浅谈分布式消息技术Kafka.md

Lines changed: 16 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,18 @@
1+
# Table of Contents
2+
3+
* [目录](#目录)
4+
* [**Kafka的基本介绍**](#kafka的基本介绍)
5+
* [**Kafka的设计原理分析**](#kafka的设计原理分析)
6+
* [**Kafka数据传输的事务特点**](#kafka数据传输的事务特点)
7+
* [**Kafka消息存储格式**](#kafka消息存储格式)
8+
* [**副本（replication）策略**](#副本（replication）策略)
9+
* [**Kafka消息分组，消息消费原理**](#kafka消息分组，消息消费原理)
10+
* [**Push vs. Pull**](#push-vs-pull)
11+
* [**Kafak顺序写入与数据读取**](#kafak顺序写入与数据读取)
12+
* [**消费者（读取数据）**](#消费者（读取数据）)
13+
* [**Reference**](#reference)
14+
15+
116
# 目录
217

318
本文转载自 linkedkeeper.com
@@ -281,4 +296,4 @@ https://my.oschina.net/silence88/blog/856195
281296

282297
https://toutiao.io/posts/508935/app_preview
283298

284-
转载请并标注: “本文转载自 linkedkeeper.com ”
299+
转载请并标注: “本文转载自 linkedkeeper.com ”

‎docs/distributed/practice/搞懂分布式技术：浅谈分布式锁的几种方案.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,15 @@
1+
# Table of Contents
2+
3+
* [目录](#目录)
4+
* [前言](#前言)
5+
* [分布式一致性问题](#分布式一致性问题)
6+
* [分布式锁需要具备哪些条件](#分布式锁需要具备哪些条件)
7+
* [分布式锁实现方式](#分布式锁实现方式)
8+
* [解决上述问题有两种方案](#解决上述问题有两种方案)
9+
* [zookeeper分布式锁](#zookeeper分布式锁)
10+
* [小结](#小结)
11+
12+
113
# 目录
214

315
本文内容参考网络，侵删

‎docs/distributed/practice/搞懂分布式技术：消息队列因何而生.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
1-
#目录
21

2+
# 目录
33
* [何时需要消息队列](#何时需要消息队列)
44
* [解耦](#解耦)
55
* [最终一致性](#最终一致性)
@@ -404,4 +404,4 @@ Future<Result> future = request(server);//server立刻返回future return future
404404

405405
# 总结
406406

407-
本文从为何使用消息队列开始讲起，然后主要介绍了如何从零开始设计一个消息队列，包括RPC、事务、最终一致性、广播、消息确认等关键问题。并对消息队列的push、pull模型做了简要分析，最后从批量和异步角度，分析了消息队列性能优化的思路。下篇会着重介绍一些高级话题，如存储系统的设计、流控和错峰的设计、公平调度等。希望通过这些，让大家对消息队列有个提纲挈领的整体认识，并给自主开发消息队列提供思路。另外，本文主要是源自自己在开发消息队列中的思考和读源码时的体会，比较不"官方"，也难免会存在一些漏洞，欢迎大家多多交流。
407+
本文从为何使用消息队列开始讲起，然后主要介绍了如何从零开始设计一个消息队列，包括RPC、事务、最终一致性、广播、消息确认等关键问题。并对消息队列的push、pull模型做了简要分析，最后从批量和异步角度，分析了消息队列性能优化的思路。下篇会着重介绍一些高级话题，如存储系统的设计、流控和错峰的设计、公平调度等。希望通过这些，让大家对消息队列有个提纲挈领的整体认识，并给自主开发消息队列提供思路。另外，本文主要是源自自己在开发消息队列中的思考和读源码时的体会，比较不"官方"，也难免会存在一些漏洞，欢迎大家多多交流。

‎docs/distributed/practice/搞懂分布式技术：缓存更新的套路.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,4 @@
1+
12
# 目录
23

34
* [缓存更新的套路](#缓存更新的套路)
@@ -106,4 +107,4 @@ Write Back套路，一句说就是，在更新数据的时候，只更新缓存
106107

107108
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)》一文。
108109

109-
（全文完）
110+
（全文完）

‎docs/distributed/practice/搞懂分布式技术：分布式ID生成方案.md renamed to ‎docs/distributed/搞懂分布式技术：分布式ID生成方案.md

Lines changed: 14 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,12 @@
1-
# 目录
1+
# Table of Contents
2+
3+
* [**一、需求缘起**](#一、需求缘起)
4+
* [**二、常见方法、不足与优化**](#二、常见方法、不足与优化)
5+
* [**方法二：单点批量ID生成服务**](#方法二：单点批量id生成服务)
6+
* [**方法三：uuid/guid**](#方法三：uuidguid)
7+
* [**方法四：取当前毫秒数**](#方法四：取当前毫秒数)
8+
29

3-
* [分布式ID生成器 | 架构师之路](#分布式id生成器--架构师之路)
410

511
本文内容参考网络，侵删
612

@@ -19,11 +25,10 @@
1925
如果对本系列文章有什么建议，或者是有什么疑问的话，也可以关注公众号【Java技术江湖】联系作者，欢迎你参与本系列博文的创作和修订。
2026

2127
<!-- more -->
22-
## 分布式ID生成器 | 架构师之路
2328

2429
转自：58沈剑架构师之路2017-06-25
2530

26-
**一、需求缘起**
31+
## **一、需求缘起**
2732

2833
几乎所有的业务系统，都有生成一个唯一记录标识的需求，例如：
2934

@@ -65,7 +70,7 @@ select message-id/ (order by message-id)/limit 100
6570

6671
这也是本文要讨论的核心问题：**如何高效生成趋势有序的全局唯一ID。**
6772

68-
**二、常见方法、不足与优化**
73+
## **二、常见方法、不足与优化**
6974

7075
**方法一：使用数据库的auto_increment来生成全局唯一递增ID**
7176

@@ -103,7 +108,7 @@ select message-id/ (order by message-id)/limit 100
103108

104109
为了解决上述两个问题，引出了第二个常见的方案。
105110

106-
**方法二：单点批量ID生成服务**
111+
## **方法二：单点批量ID生成服务**
107112

108113
分布式系统之所以难，很重要的原因之一是“没有一个全局时钟，难以保证绝对的时序”，要想保证绝对的时序，还是只能使用单点服务，用本地时钟保证“绝对时序”。
109114

@@ -143,7 +148,7 @@ ID生成服务假设每次批量拉取6个ID，服务访问数据库，将当前
143148

144149
另外，ID-gen-service也可以实施水平扩展，以解决上述缺点（3），但会引发一致性问题，具体解决方案详见《》。
145150

146-
**方法三：uuid/guid**
151+
## **方法三：uuid/guid**
147152

148153
不管是通过数据库，还是通过服务来生成ID，业务方Application都需要进行一次远程调用，比较耗时。
149154

@@ -165,7 +170,7 @@ string ID =GenUUID();
165170

166171
* uuid过长，往往用字符串表示，作为主键建立索引查询效率低，常见优化方案为“转化为两个uint64整数存储”或者“折半存储”（折半后不能保证唯一性）
167172

168-
**方法四：取当前毫秒数**
173+
## **方法四：取当前毫秒数**
169174

170175
uuid是一个本地算法，生成性能高，但无法保证趋势递增，且作为字符串ID检索效率低，有没有一种能保证递增的本地算法呢？
171176

@@ -237,4 +242,4 @@ snowflake是twitter开源的分布式ID生成算法，其**核心思想为，**
237242

238243
**缺点**：
239244

240-
* 由于“没有一个全局时钟”，每台服务器分配的ID是绝对递增的，但从全局看，生成的ID只是趋势递增的（有些服务器的时间早，有些服务器的时间晚）
245+
* 由于“没有一个全局时钟”，每台服务器分配的ID是绝对递增的，但从全局看，生成的ID只是趋势递增的（有些服务器的时间早，有些服务器的时间晚）

‎src/main/java/md/mdToc.java

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44

55
public class mdToc {
66
public static void main(String[] args) {
7-
String path = "D:\\idea_project\\JavaTutorial\\docs\\distributed\\basic";
7+
String path = "D:\\idea_project\\JavaTutorial\\docs\\distributed\\practice\\temp";
88
AtxMarkdownToc.newInstance().genTocDir(path);
99
}
1010
}

0 commit comments

Comments
 (0)