auto commit
This commit is contained in:
commit
0c01c75e28
|
@ -5,8 +5,8 @@
|
|||
* [Redis 的 RedLock 算法](#redis-的-redlock-算法)
|
||||
* [Zookeeper 的有序节点](#zookeeper-的有序节点)
|
||||
* [二、分布式事务](#二分布式事务)
|
||||
* [本地消息表](#本地消息表)
|
||||
* [2PC](#2pc)
|
||||
* [本地消息表](#本地消息表)
|
||||
* [三、CAP](#三cap)
|
||||
* [一致性](#一致性)
|
||||
* [可用性](#可用性)
|
||||
|
@ -60,7 +60,7 @@ EXPIRE 指令可以为一个键值对设置一个过期时间,从而避免了
|
|||
|
||||
使用了多个 Redis 实例来实现分布式锁,这是为了保证在发生单点故障时仍然可用。
|
||||
|
||||
- 尝试从 N 个相互独立 Redis 实例获取锁;
|
||||
- 尝试从 N 个互相独立 Redis 实例获取锁;
|
||||
- 计算获取锁消耗的时间,只有当这个时间小于锁的过期时间,并且从大多数(N / 2 + 1)实例上获取了锁,那么就认为锁获取成功了;
|
||||
- 如果锁获取失败,就到每个实例上释放锁。
|
||||
|
||||
|
@ -68,7 +68,7 @@ EXPIRE 指令可以为一个键值对设置一个过期时间,从而避免了
|
|||
|
||||
### 1. Zookeeper 抽象模型
|
||||
|
||||
Zookeeper 提供了一种树形结构级的命名空间,/app1/p_1 节点的父节点为 /app1。
|
||||
Zookeeper 提供了一种树形结构的命名空间,/app1/p_1 节点的父节点为 /app1。
|
||||
|
||||
<div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/aefa8042-15fa-4e8b-9f50-20b282a2c624.png" width="320px"> </div><br>
|
||||
|
||||
|
@ -103,16 +103,6 @@ Zookeeper 提供了一种树形结构级的命名空间,/app1/p_1 节点的父
|
|||
|
||||
例如在下单场景下,库存和订单如果不在同一个节点上,就涉及分布式事务。
|
||||
|
||||
## 本地消息表
|
||||
|
||||
本地消息表与业务数据表处于同一个数据库中,这样就能利用本地事务来保证在对这两个表的操作满足事务特性,并且使用了消息队列来保证最终一致性。
|
||||
|
||||
1. 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息,本地事务能保证这个消息一定会被写入本地消息表中。
|
||||
2. 之后将本地消息表中的消息转发到 Kafka 等消息队列中,如果转发成功则将消息从本地消息表中删除,否则继续重新转发。
|
||||
3. 在分布式事务操作的另一方从消息队列中读取一个消息,并执行消息中的操作。
|
||||
|
||||
<div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/476329d4-e2ef-4f7b-8ac9-a52a6f784600.png" width="740px"> </div><br>
|
||||
|
||||
## 2PC
|
||||
|
||||
两阶段提交(Two-phase Commit,2PC),通过引入协调者(Coordinator)来协调参与者的行为,并最终决定这些参与者是否要真正执行事务。
|
||||
|
@ -151,6 +141,17 @@ Zookeeper 提供了一种树形结构级的命名空间,/app1/p_1 节点的父
|
|||
|
||||
任意一个节点失败就会导致整个事务失败,没有完善的容错机制。
|
||||
|
||||
## 本地消息表
|
||||
|
||||
本地消息表与业务数据表处于同一个数据库中,这样就能利用本地事务来保证在对这两个表的操作满足事务特性,并且使用了消息队列来保证最终一致性。
|
||||
|
||||
1. 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息,本地事务能保证这个消息一定会被写入本地消息表中。
|
||||
2. 之后将本地消息表中的消息转发到消息队列中,如果转发成功则将消息从本地消息表中删除,否则继续重新转发。
|
||||
3. 在分布式事务操作的另一方从消息队列中读取一个消息,并执行消息中的操作。
|
||||
|
||||
<div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/476329d4-e2ef-4f7b-8ac9-a52a6f784600.png" width="740px"> </div><br>
|
||||
|
||||
|
||||
# 三、CAP
|
||||
|
||||
分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)和分区容忍性(P:Partition Tolerance),最多只能同时满足其中两项。
|
||||
|
@ -184,8 +185,6 @@ Zookeeper 提供了一种树形结构级的命名空间,/app1/p_1 节点的父
|
|||
- 为了保证一致性(CP),不能访问未同步完成的节点,也就失去了部分可用性;
|
||||
- 为了保证可用性(AP),允许读取所有节点的数据,但是数据可能不一致。
|
||||
|
||||
<div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/0b587744-c0a8-46f2-8d72-e8f070d67b4b.jpg"/> </div><br>
|
||||
|
||||
# 四、BASE
|
||||
|
||||
BASE 是基本可用(Basically Available)、软状态(Soft State)和最终一致性(Eventually Consistent)三个短语的缩写。
|
||||
|
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
指某个请求从发出到接收到响应消耗的时间。
|
||||
|
||||
在对响应时间进行测试时,通常采用重复请求方式,然后计算平均响应时间。
|
||||
在对响应时间进行测试时,通常采用重复请求的方式,然后计算平均响应时间。
|
||||
|
||||
### 2. 吞吐量
|
||||
|
||||
|
@ -94,7 +94,7 @@
|
|||
|
||||
## 监控
|
||||
|
||||
对 CPU、内存、磁盘、网络等系统负载信息进行监控,当某个数据达到一定阈值时通知运维人员,从而在系统发生故障之前及时发现问题。
|
||||
对 CPU、内存、磁盘、网络等系统负载信息进行监控,当某个信息达到一定阈值时通知运维人员,从而在系统发生故障之前及时发现问题。
|
||||
|
||||
## 服务降级
|
||||
|
||||
|
|
29
notes/分布式.md
29
notes/分布式.md
|
@ -5,8 +5,8 @@
|
|||
* [Redis 的 RedLock 算法](#redis-的-redlock-算法)
|
||||
* [Zookeeper 的有序节点](#zookeeper-的有序节点)
|
||||
* [二、分布式事务](#二分布式事务)
|
||||
* [本地消息表](#本地消息表)
|
||||
* [2PC](#2pc)
|
||||
* [本地消息表](#本地消息表)
|
||||
* [三、CAP](#三cap)
|
||||
* [一致性](#一致性)
|
||||
* [可用性](#可用性)
|
||||
|
@ -60,7 +60,7 @@ EXPIRE 指令可以为一个键值对设置一个过期时间,从而避免了
|
|||
|
||||
使用了多个 Redis 实例来实现分布式锁,这是为了保证在发生单点故障时仍然可用。
|
||||
|
||||
- 尝试从 N 个相互独立 Redis 实例获取锁;
|
||||
- 尝试从 N 个互相独立 Redis 实例获取锁;
|
||||
- 计算获取锁消耗的时间,只有当这个时间小于锁的过期时间,并且从大多数(N / 2 + 1)实例上获取了锁,那么就认为锁获取成功了;
|
||||
- 如果锁获取失败,就到每个实例上释放锁。
|
||||
|
||||
|
@ -68,7 +68,7 @@ EXPIRE 指令可以为一个键值对设置一个过期时间,从而避免了
|
|||
|
||||
### 1. Zookeeper 抽象模型
|
||||
|
||||
Zookeeper 提供了一种树形结构级的命名空间,/app1/p_1 节点的父节点为 /app1。
|
||||
Zookeeper 提供了一种树形结构的命名空间,/app1/p_1 节点的父节点为 /app1。
|
||||
|
||||
<div align="center"> <img src="pics/aefa8042-15fa-4e8b-9f50-20b282a2c624.png" width="320px"> </div><br>
|
||||
|
||||
|
@ -103,16 +103,6 @@ Zookeeper 提供了一种树形结构级的命名空间,/app1/p_1 节点的父
|
|||
|
||||
例如在下单场景下,库存和订单如果不在同一个节点上,就涉及分布式事务。
|
||||
|
||||
## 本地消息表
|
||||
|
||||
本地消息表与业务数据表处于同一个数据库中,这样就能利用本地事务来保证在对这两个表的操作满足事务特性,并且使用了消息队列来保证最终一致性。
|
||||
|
||||
1. 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息,本地事务能保证这个消息一定会被写入本地消息表中。
|
||||
2. 之后将本地消息表中的消息转发到 Kafka 等消息队列中,如果转发成功则将消息从本地消息表中删除,否则继续重新转发。
|
||||
3. 在分布式事务操作的另一方从消息队列中读取一个消息,并执行消息中的操作。
|
||||
|
||||
<div align="center"> <img src="pics/476329d4-e2ef-4f7b-8ac9-a52a6f784600.png" width="740px"> </div><br>
|
||||
|
||||
## 2PC
|
||||
|
||||
两阶段提交(Two-phase Commit,2PC),通过引入协调者(Coordinator)来协调参与者的行为,并最终决定这些参与者是否要真正执行事务。
|
||||
|
@ -151,6 +141,17 @@ Zookeeper 提供了一种树形结构级的命名空间,/app1/p_1 节点的父
|
|||
|
||||
任意一个节点失败就会导致整个事务失败,没有完善的容错机制。
|
||||
|
||||
## 本地消息表
|
||||
|
||||
本地消息表与业务数据表处于同一个数据库中,这样就能利用本地事务来保证在对这两个表的操作满足事务特性,并且使用了消息队列来保证最终一致性。
|
||||
|
||||
1. 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息,本地事务能保证这个消息一定会被写入本地消息表中。
|
||||
2. 之后将本地消息表中的消息转发到消息队列中,如果转发成功则将消息从本地消息表中删除,否则继续重新转发。
|
||||
3. 在分布式事务操作的另一方从消息队列中读取一个消息,并执行消息中的操作。
|
||||
|
||||
<div align="center"> <img src="pics/476329d4-e2ef-4f7b-8ac9-a52a6f784600.png" width="740px"> </div><br>
|
||||
|
||||
|
||||
# 三、CAP
|
||||
|
||||
分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)和分区容忍性(P:Partition Tolerance),最多只能同时满足其中两项。
|
||||
|
@ -184,8 +185,6 @@ Zookeeper 提供了一种树形结构级的命名空间,/app1/p_1 节点的父
|
|||
- 为了保证一致性(CP),不能访问未同步完成的节点,也就失去了部分可用性;
|
||||
- 为了保证可用性(AP),允许读取所有节点的数据,但是数据可能不一致。
|
||||
|
||||
<div align="center"> <img src="pics/0b587744-c0a8-46f2-8d72-e8f070d67b4b.jpg"/> </div><br>
|
||||
|
||||
# 四、BASE
|
||||
|
||||
BASE 是基本可用(Basically Available)、软状态(Soft State)和最终一致性(Eventually Consistent)三个短语的缩写。
|
||||
|
|
|
@ -16,6 +16,10 @@
|
|||
|
||||
|
||||
|
||||
<<<<<<< HEAD
|
||||
|
||||
</br><div align="center">💡 </br></br> 更多精彩内容将发布在公众号 **CyC2018**,公众号提供了该项目的离线阅读版本,后台回复"下载" 即可领取。也提供了一份技术面试复习思维导图,不仅系统整理了面试知识点,而且标注了各个知识点的重要程度,从而帮你理清多而杂的面试知识点,后台回复"资料" 即可领取。我基本是按照这个思维导图来进行复习的,对我拿到了 BAT 头条等 Offer 起到很大的帮助。你们完全可以和我一样根据思维导图上列的知识点来进行复习,就不用看很多不重要的内容,也可以知道哪些内容很重要从而多安排一些复习时间。</div></br>
|
||||
=======
|
||||
</br><div align="center"> 💡 <br> 更多精彩内容将发布在公众号 **CyC2018**,公众号提供了该项目的离线阅读版本,后台回复"下载" 即可领取。也提供了一份技术面试复习思维导图,不仅系统整理了面试知识点,而且标注了各个知识点的重要程度,从而帮你理清多而杂的面试知识点,后台回复"资料" 即可领取。我基本是按照这个思维导图来进行复习的,对我拿到了 BAT 头条等 Offer 起到很大的帮助。你们完全可以和我一样根据思维导图上列的知识点来进行复习,就不用看很多不重要的内容,也可以知道哪些内容很重要从而多安排一些复习时间。</div></br>
|
||||
>>>>>>> c060922114ab186252f34af0eed3b6412e147693
|
||||
<div align="center"><img width="180px" src="https://cyc-1256109796.cos.ap-guangzhou.myqcloud.com/%E5%85%AC%E4%BC%97%E5%8F%B7.jpg"></img></div>
|
||||
|
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
指某个请求从发出到接收到响应消耗的时间。
|
||||
|
||||
在对响应时间进行测试时,通常采用重复请求方式,然后计算平均响应时间。
|
||||
在对响应时间进行测试时,通常采用重复请求的方式,然后计算平均响应时间。
|
||||
|
||||
### 2. 吞吐量
|
||||
|
||||
|
@ -94,7 +94,7 @@
|
|||
|
||||
## 监控
|
||||
|
||||
对 CPU、内存、磁盘、网络等系统负载信息进行监控,当某个数据达到一定阈值时通知运维人员,从而在系统发生故障之前及时发现问题。
|
||||
对 CPU、内存、磁盘、网络等系统负载信息进行监控,当某个信息达到一定阈值时通知运维人员,从而在系统发生故障之前及时发现问题。
|
||||
|
||||
## 服务降级
|
||||
|
||||
|
|
Loading…
Reference in New Issue
Block a user