Skip to content

Commit ff9efdd

Browse files
committed
[docs update] 内容完善
1 parent 473e87e commit ff9efdd

File tree

11 files changed

+161
-26
lines changed

11 files changed

+161
-26
lines changed

docs/.vuepress/navbar.ts

+6-2
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,11 @@ export const navbarConfig = defineNavbarConfig([
44
{ text: "面试指南", icon: "java", link: "/home.md" },
55
{ text: "优质专栏", icon: "recommend", link: "/zhuanlan/" },
66
{ text: "项目精选", icon: "github", link: "/open-source-project/" },
7-
8-
{ text: "关于作者", icon: "zuozhe", link: "/about-the-author/" },
7+
{
8+
text: "旧版链接",
9+
icon: "java",
10+
link: "https://snailclimb.gitee.io/javaguide/#/",
11+
},
912
{ text: "RSS订阅", icon: "rss", link: "https://javaguide.cn/feed.json" },
13+
{ text: "关于作者", icon: "zuozhe", link: "/about-the-author/" },
1014
]);
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,126 @@
1+
## 背景
2+
3+
在分布式系统中,不同的节点进行数据/信息共享是一个基本的需求。
4+
5+
比较简单粗暴的方法集中式发散消息,简单来说就是一个主节点同时共享最新信息给其他所有节点。但是,这种方法缺陷太多,节点多的时候不光同步消息的效率低,还太依赖与主节点,存在单点风险。
6+
7+
于是,分散式发散消息的 Gossip 协议就诞生了。
8+
9+
## Gossip 协议介绍
10+
11+
Gossip 直译过来就是闲话、流言蜚语的意思。流言蜚语有什么特点呢?容易被传播,你传我我传他,然后大家都知道了。
12+
13+
Gossip 协议也叫 Epidemic 协议(流行病协议)或者 Epidemic propagation 算法(疫情传播算法),别名很多。不过,这些名字的特点是都具有 **随机传播特性** 的特点(联想一下病毒传播、癌细胞扩散等生活中常见的情景),这也正是 Gossip 协议最主要的特点。
14+
15+
Gossip 协议最早是在 ACM 上的一篇 1987 年发表的论文 [《Epidemic Algorithms for Replicated Database Maintenance》](https://dl.acm.org/doi/10.1145/41840.41841)中被提出的。根据论文标题,我们大概就能知道 Gossip 协议当时提出的主要应用是在分布式数据库系统中各个副本节点同步数据。
16+
17+
正如其名一样,这是一种随机且带有传染性的方式将信息传播到整个网络中,并在一定时间内,使得系统内的所有节点数据一致。
18+
19+
下面我们来对 Gossip 协议的定义做一个总结: **Gossip 协议是一种允许在分布式系统中共享状态的通信协议,通过这种通信协议,我们可以将信息传播给网络或集群中的所有成员。**
20+
21+
## Gossip 协议应用
22+
23+
1、我们经常使用的分布式缓存 Redis 的官方集群解决方案(3.0 版本引入) Redis Cluster 就是基于 Gossip 协议来实现集群中各个节点数据的最终一致性。
24+
25+
![](https://img-blog.csdnimg.cn/85fbed524d8342adb054961525c6e257.png)
26+
27+
Redis Cluster 中的每个 Redis 节点都维护了一份集群的状态信息,各个节点利用 Gossip 协议传递的信息就是集群的状态信息。
28+
29+
下图就是主从架构的 Redis Cluster 的示意图,图中的虚线代表的就是各个节点之间使用 Gossip 进行通信 ,实线表示主从复制。
30+
31+
![](./images/gossip/redis-cluster-gossip.png)
32+
33+
2、NoSQL 数据库 Apache Cassandra 集群通过 Gossip 协议来进行动态管理集群节点状态(节点故障检测和恢复)。
34+
35+
3、服务网格解决方案 Consul 使用 Gossip 协议网络内可靠有效地传输新服务和事件的信息。
36+
37+
4、Bitcoin 使用 Gossip 协议来传播交易和区块信息。不过,为了提供更好的隐私保护,CMU 的研究人员提出 **蒲公英协议**
38+
39+
5、......
40+
41+
还有非常多使用 Gossip 协议的应用,学习 Gossip 协议有助于我们搞清很多技术的底层原理。
42+
43+
## Gossip 协议消息传播模式
44+
45+
Gossip 设计了两种可能的消息传播模式:**反熵(Anti-Entropy)****传谣(Rumor-Mongering)**
46+
47+
### 反熵(Anti-entropy)
48+
49+
根据维基百科:
50+
51+
> 熵的概念最早起源于[物理学](https://zh.wikipedia.org/wiki/物理学),用于度量一个热力学系统的混乱程度。熵最好理解为不确定性的量度而不是确定性的量度,因为越随机的信源的熵越大。
52+
53+
在这里,你可以把反熵中的熵了解为节点之间数据的混乱程度/差异性,反熵就是指消除不同节点中数据的差异,提升节点间数据的相似度,从而降低熵值。
54+
55+
具体是如何反熵的呢?集群中的节点,每隔段时间就随机选择某个其他节点,然后通过互相交换自己的所有数据来消除两者之间的差异,实现数据的最终一致性。
56+
57+
在实现反熵的时候,主要有推、拉和推拉三种方式:
58+
59+
- 推方式,就是将自己的所有副本数据,推给对方,修复对方副本中的熵。
60+
- 拉方式,就是拉取对方的所有副本数据,修复自己副本中的熵。
61+
- 推拉就是同时修复自己副本和对方副本中的熵。
62+
63+
伪代码如下:
64+
65+
![](https://img-blog.csdnimg.cn/20210605165106728.png)
66+
67+
在我们实际应用场景中,一般不会采用随机的节点进行反熵,而是需要可以的设计一个闭环。这样的话,我们能够在一个确定的时间范围内实现各个节点数据的最终一致性,而不是基于随机的概率。像 InfluxDB 就是这样来实现反熵的。
68+
69+
![](./images/gossip/反熵-闭环.png)
70+
71+
1. 节点 A 推送数据给节点 B,节点 B 获取到节点 A 中的最新数据。
72+
2. 节点 B 推送数据给 C,节点 C 获取到节点 A,B 中的最新数据。
73+
3. 节点 C 推送数据给 A,节点 A 获取到节点 B,C 中的最新数据。
74+
4. 节点 A 再推送数据给 B 形成闭环,这样节点 B 就获取到节点 C 中的最新数据。
75+
76+
虽然反熵很简单实用,但是,节点过多或者节点动态变化的话,反熵就不太适用了。这个时候,我们想要实现最终一致性就要靠 **谣言传播(Rumor mongering) **
77+
78+
### 谣言传播(Rumor mongering)
79+
80+
谣言传播指的是分布式系统中的一个节点一旦有了新数据之后,就会变为活跃节点,活跃节点会周期性地联系其他节点向其发送新数据,直到所有的节点都存储了该新数据。
81+
82+
如下图所示(下图来自于[INTRODUCTION TO GOSSIP](https://managementfromscratch.wordpress.com/2016/04/01/introduction-to-gossip/) 这篇文章):
83+
84+
![Gossip 传播示意图](./images/gossip/gossip-rumor- mongering.gif)
85+
86+
伪代码如下:
87+
88+
![](https://img-blog.csdnimg.cn/20210605170707933.png)
89+
90+
谣言传播比较适合节点数量比较多的情况,不过,这种模式下要尽量避免传播的信息包不能太大,避免网络消耗太大。
91+
92+
### 总结
93+
94+
- 反熵(Anti-Entropy)会传播节点的所有数据,而谣言传播(Rumor-Mongering)只会传播节点新增的数据。
95+
- 我们一般会给反熵设计一个闭环。
96+
- 谣言传播(Rumor-Mongering)比较适合节点数量比较多或者节点动态变化的场景。
97+
98+
## Gossip 协议优势和缺陷
99+
100+
**优势:**
101+
102+
1、相比于其他分布式协议/算法来说,Gossip 协议理解起来非常简单。
103+
104+
2、能够容忍网络上节点的随意地增加或者减少,宕机或者重启,因为 Gossip 协议下这些节点都是平等的,去中心化的。新增加或者重启的节点在理想情况下最终是一定会和其他节点的状态达到一致。
105+
106+
3、速度相对较快。节点数量比较多的情况下,扩散速度比一个主节点向其他节点传播信息要更快(多播)。
107+
108+
**缺陷** :
109+
110+
1、消息需要通过多个传播的轮次才能传播到整个网络中,因此,必然会出现各节点状态不一致的情况。毕竟,Gossip 协议强调的是最终一致,至于达到各个节点的状态一致需要多长时间,谁也无从得知。
111+
112+
2、由于拜占庭将军问题,不允许存在恶意节点。
113+
114+
3、可能会出现消息冗余的问题。由于消息传播的随机性,同一个节点可能会重复收到相同的消息。
115+
116+
## 总结
117+
118+
- Gossip 协议是一种允许在分布式系统中共享状态的通信协议,通过这种通信协议,我们可以将信息传播给网络或集群中的所有成员。
119+
- Gossip 协议被 Redis 、Apache Cassandra、Consul 等项目应用。
120+
- 谣言传播(Rumor-Mongering)比较适合节点数量比较多或者节点动态变化的场景。
121+
122+
## 参考
123+
124+
- 一万字详解 Redis Cluster Gossip 协议:https://segmentfault.com/a/1190000038373546
125+
- 《分布式协议与算法实战》
126+
- 《Redis 设计与实现》
Loading
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
<mxfile host="Electron" modified="2021-06-05T14:11:34.079Z" agent="5.0 (Macintosh; Intel Mac OS X 10_16_0) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/13.4.5 Chrome/83.0.4103.122 Electron/9.1.0 Safari/537.36" etag="aFl59E8uiUKHH-f9sleO" version="13.4.5" type="device"><diagram id="QYnViQyllvcs8rUYMoT7" name="Page-1">5VhNc5swEP01HONBYDAcjeOm06bTTHNoc+ooIIwaQIyQY5NfXwkkg4w/iJukziQHR/skFmnf7mPBsGfZ+orCIvlGIpQalhmtDfvSsCwATJf/E0jVIL4/aYAFxZFc1AK3+AlJ0JToEkeo1BYyQlKGCx0MSZ6jkGkYpJSs9GUxSfW7FnCBesBtCNM++hNHLGlQz5q0+GeEF4m6M3D9ZiaDarE8SZnAiKw6kD037BklhDWjbD1DqQieiktz3ac9s5uNUZSzIRcEfoFuKoCmflF8L77+dn58yS6kl0eYLuWBjblneFPD44OJ+A38qdw/q1RQuGMef24EqwQzdFvAUMyseApwLGFZyi3Ah7AsGlJivEZ8H0GM03RGUkJrR3Ycx1YYcrxklDygzkzk3ruOK2ZU2ExhPCAWJtJ5THImEwZ43O4HRJ0OUYbWHUgG6AqRDDFa8SVy1lZpJ7PVGkt71eFeQkmHdoVBmW2LjeeWED6QnDyDn/EAfmYfhx9rix/b+8/8+P3YR1w/pEkoS8iC5DCdt2hAyTKPRLTrkLVrrgkpZOj+IMYqGTu4ZERnbXBgS7KkITqwfUcqKqQLxI6noTjbQZooSiHDj7p2vnjQQb8qrJ08XMN7/jjSMz7Fi5yPQx4rxHM5EMmHud5P5USGo6ihCZX4Cd7X/gRRBcE5q4/iBIZzOYiHQznTy/rNQ0zeVHtO7KoGc2R66vlaaY4G8yB934izdZaQOC55QmwTtdnC6dw5AwQt+DiCNla5fC6CNunz0yMjj6aisxJVlMKyxOFheUJrzH4JY2RajrTvRHxHrrQu1zLctVEpI+cH+lUvdJR5151rL6utquPkBlHMAyIqvMZOl0jVdB6TSGegRHaIdXYQq7BTK1g1Mt5Eb2R8X3fRnFte1e0atxyNna0E9bcyrwlMz9FL6QWwewmpmHsPWq/K6Z+1/oKLPXBsjYsL+9zV3nsFNdmogqYJrUQcUIWOmEgNAgcV6MOphuOP/O7fVu2D3dPP1hTLHfl63zI2zQ30Vsri9pJz/I6URZXWSygLFxZPV5az7yPBji8XryMt4Iiw7BWJo8UPzqr4LXfPu/Vzy3v7I4ptv3HL0H/HsN9RYYN9LxEn9QwTxz+bnoGb7efOZnn70die/wU=</diagram></mxfile>
Loading

docs/java/jvm/jvm-intro.md

+7-5
Original file line numberDiff line numberDiff line change
@@ -385,11 +385,13 @@ System.out.println("total mem=" + Runtime.getRuntime().totalMemory() / 1024.0 /
385385
此时free memory就又缩水了,不过total memory是没有变化的。Java会尽可能将total mem的值维持在最小堆内存大小
386386

387387

388-
byte[] b = new byte[10 * 1024 * 1024];
389-
System.out.println("分配了10M空间给数组");
390-
System.out.println("Xmx=" + Runtime.getRuntime().maxMemory() / 1024.0 / 1024 + "M"); //系统的最大空间
391-
System.out.println("free mem=" + Runtime.getRuntime().freeMemory() / 1024.0 / 1024 + "M"); //系统的空闲空间
392-
System.out.println("total mem=" + Runtime.getRuntime().totalMemory() / 1024.0 / 1024 + "M"); //当前可用的总空间
388+
```java
389+
byte[] b = new byte[10 * 1024 * 1024];
390+
System.out.println("分配了10M空间给数组");
391+
System.out.println("Xmx=" + Runtime.getRuntime().maxMemory() / 1024.0 / 1024 + "M"); //系统的最大空间
392+
System.out.println("free mem=" + Runtime.getRuntime().freeMemory() / 1024.0 / 1024 + "M"); //系统的空闲空间
393+
System.out.println("total mem=" + Runtime.getRuntime().totalMemory() / 1024.0 / 1024 + "M"); //当前可用的总空间
394+
```
393395

394396
![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/0fd7550ae2144adca8ed2ede12d5fb96-new-image0c31ff20-289d-4088-8c67-a846d0c5d1e0.png)
395397

docs/open-source-project/system-design.md

+1
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,7 @@ category: 开源项目
66
## 基础框架
77

88
- **[Spring Boot ](https://github.com/spring-projects/spring-boot "spring-boot")** :Spring Boot 可以轻松创建独立的生产级基于 Spring 的应用程序,内置 web 服务器让你可以像运行普通 Java 程序一样运行项 目。另外,大部分 Spring Boot 项目只需要少量的配置即可,这有别于 Spring 的重配置。
9+
- **[Javalin](https://github.com/tipsy/javalin)** :一个轻量级的 Web 框架,同时支持 Java 和 Kotlin,被微软、红帽、Uber等公司使用。
910
- **[Quarkus](https://github.com/quarkusio/quarkus)** : 用于编写 Java 应用程序的云原生和容器优先的框架。
1011
- **[Guice](https://github.com/google/guice)** :Google 开源的一个轻量级依赖注入框架,相当于一个功能极简化的轻量级 Spring Boot。在某些情况下非常实用,就比如说我们的项目只需要使用依赖注入,不需要 AOP 等功能特性。
1112
- **[SOFABoot](https://github.com/sofastack/sofa-boot)** :SOFABoot 基于 Spring Boot ,不过在其基础上增加了 Readiness Check,类隔离,日志空间隔离等等能力。 配套提供的还有:SOFARPC(RPC 框架)、SOFABolt(基于 Netty 的远程通信框架)、SOFARegistry(注册中心)...详情请参考:[SOFAStack ](https://github.com/sofastack)

docs/open-source-project/tutorial.md

+9-5
Original file line numberDiff line numberDiff line change
@@ -9,20 +9,20 @@ category: 开源项目
99
- **[interview-guide](https://github.com/csguide-dabai/interview-guide)** :总结了后端面试八股文中的重点,希望能帮助各位准备互联网开发岗校招面试的同学。
1010
- **[toBeBetterJavaer](https://github.com/itwanger/toBeBetterJavaer)** :一份通俗易懂、风趣幽默的 Java 学习指南,内容涵盖 Java 基础、Java 集合框架、Java 并发编程、JVM、Java 企业级开发(Git、SSM、Spring Boot)等知识点。
1111
- **[advanced-java](https://github.com/doocs/advanced-java "advanced-java")** :互联网 Java 工程师进阶知识完全扫盲:涵盖高并发、分布式、高可用、微服务、海量数据处理等领域知识。
12-
- **[architect-awesome](https://github.com/xingshaocheng/architect-awesome "architect-awesome")** :后端架构师技术图谱。
1312
- **[toBeTopJavaer](https://github.com/hollischuang/toBeTopJavaer "toBeTopJavaer")** :Java 工程师成神之路 。
1413
- **[technology-talk](https://github.com/aalansehaiyang/technology-talk)** : 汇总 java 生态圈常用技术框架、开源中间件,系统架构、数据库、大公司架构案例、常用三方类库、项目管理、线上问题排查、个人成长、思考等知识
15-
- **[tutorials](https://github.com/eugenp/tutorials "tutorials")**:该项目是一系列小而专注的教程 - 每个教程都涵盖 Java 生态系统中单一且定义明确的开发领域。 当然,它们的重点是 Spring Framework - Spring,Spring Boot 和 Spring Securiyt。 除了 Spring 之外,还有以下技术:核心 Java,Jackson,HttpClient,Guava。
1614
- **[JCSprout](https://github.com/crossoverJie/JCSprout "JCSprout")** :处于萌芽阶段的 Java 核心知识库。
1715
- **[bestJavaer](https://github.com/crisxuan/bestJavaer)** : 这是一个成为更好的 Java 程序员的系列教程。
1816
- **[java-design-patterns](https://github.com/iluwatar/java-design-patterns "java-design-patterns")** : 用 Java 实现的设计模式。
1917

2018
## 计算机基础
2119

2220
- **[CS-Notes](https://github.com/CyC2018/CS-Notes "CS-Notes")** :技术面试必备基础知识、Leetcode 题解、后端面试、Java 面试、春招、秋招、操作系统、计算机网络、系统设计。
23-
- **[Waking-Up](https://github.com/wolverinn/Waking-Up)** :计算机基础(计算机网络/操作系统/数据库/Git...)面试问题全面总结,包含详细的 follow-up question 以及答案;全部采用【问题+追问+答案】的形式,即拿即用,直击互联网大厂面试 🚀;可用于模拟面试、面试前复习、短期内快速备战面试...
21+
- **[Waking-Up](https://github.com/wolverinn/Waking-Up)** :计算机基础(计算机网络/操作系统/数据库/Git...)面试问题全面总结。
2422

25-
## SpringBoot
23+
## 系统设计
24+
25+
### SpringBoot
2626

2727
- **[springboot-guide](https://github.com/Snailclimb/springboot-guide)** :SpringBoot 核心知识点总结。 基于 Spring Boot 2.19+。
2828
- **[SpringAll](https://github.com/wuyouzhuguli/SpringAll "SpringAll")** :循序渐进,学习 Spring Boot、Spring Boot & Shiro、Spring Cloud、Spring Security & Spring Security OAuth2,博客 Spring 系列源码。
@@ -33,14 +33,18 @@ category: 开源项目
3333

3434
相关文章:[Github 点赞接近 100k 的 SpringBoot 学习教程+实战推荐!牛批!](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247488298&idx=3&sn=0a8fd88ec5a050de131c2a3305482ac4&chksm=cea25ce1f9d5d5f7f53a0237d27489326bce4546353b038085c03b086d91ef396bf824d3a155&token=496868067&lang=zh_CN#rd)
3535

36-
## SpringCloud
36+
### SpringCloud
3737

3838
- **[SpringCloudLearning](https://github.com/forezp/SpringCloudLearning "SpringCloudLearning")** : 方志朋的《史上最简单的 Spring Cloud 教程源码》。
3939
- **[springcloud-learning](https://github.com/macrozheng/springcloud-learning)** : 一套涵盖大部分核心组件使用的 Spring Cloud 教程。
4040
- **[SpringCloud](https://github.com/zhoutaoo/SpringCloud "SpringCloud")** :基于 SpringCloud2.1 的微服务开发脚手架,整合了 spring-security-oauth2、nacos、feign、sentinel、springcloud-gateway 等。
4141

4242
相关文章:[Github 点赞接近 70k 的 Spring Cloud 学习教程+实战项目推荐!牛批!](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247488377&idx=1&sn=0fb33ef330159db5a9c8bc0f029cd739&chksm=cea25cb2f9d5d5a4c7bacc9dcfc90ed86e89f4262e32b40c7aa47af84c747cb6c0429f753e1d&token=496868067&lang=zh_CN#rd)
4343

44+
### Nginx
45+
46+
- **[nginx-tutorial](https://github.com/dunwu/nginx-tutorial)** :一系列 Nginx 极简教程,包含HTTP 反向代理、HTTPS 反向代理、负载均衡、静态站点、文件服务器搭建等实战内容。
47+
4448
## 大数据
4549

4650
- **[BigData-Notes](https://github.com/heibaiying/BigData-Notes "BigData-Notes")** :大数据入门指南 ⭐️。

docs/system-design/security/sso-intro.md

-3
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,6 @@ tag:
77

88
> 本文授权转载自 : https://ken.io/note/sso-design-implement 作者:ken.io
99
>
10-
> 相关推荐阅读:**[系统的讲解 - SSO单点登录](https://www.imooc.com/article/286710)**
1110
1211
## 一、前言
1312

@@ -101,8 +100,6 @@ SSO英文全称Single Sign On,单点登录。SSO是在多个应用系统中,
101100

102101
前面提到过,核心思路是客户端存储AuthToken,服务器端通过Redis存储登录信息。由于客户端是将AuthToken存储在Cookie中的。所以跨域要解决的问题,就是如何解决Cookie的跨域读写问题。
103102

104-
> **Cookie是不能跨域的** ,比如我一个
105-
106103
解决跨域的核心思路就是:
107104

108105
- 登录完成之后通过回调的方式,将AuthToken传递给主域名之外的站点,该站点自行将AuthToken保存在当前域下的Cookie中。

0 commit comments

Comments
 (0)