FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

auto commit · suckthegithub/Interview-Notebook@98a0089 · GitHub

Repository navigation

Commit 98a0089

Browse files
committed
auto commit
1 parent ea6ec0d commit 98a0089

1 file changed

Lines changed: 12 additions & 12 deletions

File tree

‎notes/分布式问题分析.md‎

Lines changed: 12 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@
2929

3030
分布式存储中可以将数据分片到多个节点上,不仅可以提高性能(可扩展性),同时也可以使用多个节点对同一份数据进行备份(高可用性)。
3131

32-
至于分布式计算,就是将一个大的计算任务分解成小任务分配到多台节点上去执行,再汇总每个小任务的执行结果得到最终结果。MapReduce 是分布式计算的最好例子。
32+
至于分布式计算,就是将一个大的计算任务分解成小任务分配到多个节点上去执行,再汇总每个小任务的执行结果得到最终结果。MapReduce 是分布式计算最好的例子。
3333

3434
# 二、分布式事务
3535

@@ -42,42 +42,42 @@
4242

4343
## 应用场景
4444

45-
- 下单:减少库存、更新订单状态。库存和订单不在同一个数据库,因此涉及分布式事务。
46-
- 支付:买家账户扣款、卖家账户入账。买家和卖家账户信息不在同一个数据库,因此涉及分布式事务。
45+
- 下单:减少库存、更新订单状态。库存和订单如果不在同一个数据库,就涉及分布式事务。
46+
- 支付:买家账户扣款、卖家账户入账。买家和卖家账户信息如果不在同一个数据库,就涉及分布式事务。
4747

4848
## 解决方案
4949

5050
### 1. 两阶段提交协议
5151

52-
[两阶段提交](https://github.com/CyC2018/Interview-Notebook/blob/master/notes/%E4%B8%80%E8%87%B4%E6%80%A7%E5%8D%8F%E8%AE%AE.md#%E4%B8%A4%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4%E5%8D%8F%E8%AE%AE)
52+
> [两阶段提交](https://github.com/CyC2018/Interview-Notebook/blob/master/notes/%E4%B8%80%E8%87%B4%E6%80%A7%E5%8D%8F%E8%AE%AE.md#%E4%B8%A4%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4%E5%8D%8F%E8%AE%AE)
5353
54-
两阶段提交协议可以很好得解决分布式事务问题,它可以使用 XA 来实现,XA 它包含两个部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如 Oracle、DB2 这些商业数据库都实现了 XA 接口;而事务管理器作为全局的协调者,负责各个本地资源的提交和回滚。
54+
两阶段提交协议可以很好地解决分布式事务问题。它可以使用 XA 来实现,XA 包含两个部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如 Oracle、DB2 这些商业数据库都实现了 XA 接口;而事务管理器作为全局的协调者,负责各个本地资源的提交和回滚。
5555

5656
### 2. 消息中间件
5757

5858
消息中间件也可称作消息系统 (MQ),它本质上是一个暂存转发消息的一个中间件。在分布式应用当中,我们可以把一个业务操作转换成一个消息,比如支付宝的余额转入余额宝操作,支付宝系统执行减少余额操作之后向消息系统发送一个消息,余额宝系统订阅这条消息然后进行增加余额宝操作。
5959

6060
#### 2.1 消息处理模型
6161

62-
**(一)点对点**
62+
(一)点对点
6363

6464
<div align="center"> <img src="../pics//96b63e13-e2d8-4ddb-9aa1-a38959ca96e5.jpg" width="600"/> </div><br>
6565

66-
**(二)发布/订阅**
66+
(二)发布/订阅
6767

6868
<div align="center"> <img src="../pics//654acfed-a6a5-4fc7-8f40-3fdcae57bae8.jpg" width="700"/> </div><br>
6969

7070
#### 2.2 消息的可靠性
7171

72-
消息的发送端的可靠性:发送端完成操作后一定能将消息成功发送到消息系统。
72+
(一)发送端的可靠性
7373

74-
消息的接收端的可靠性:接收端仅且能够从消息中间件成功消费一次消息。
75-
76-
**(一)发送端的可靠性**
74+
发送端完成操作后一定能将消息成功发送到消息系统。
7775

7876
在本地数据建一张消息表,将消息数据与业务数据保存在同一数据库实例里,这样就可以利用本地数据库的事务机制。事务提交成功后,将消息表中的消息转移到消息中间件,若转移消息成功则删除消息表中的数据,否则继续重传。
7977

80-
**(二)接收端的可靠性**
78+
(二)接收端的可靠性
79+
80+
接收端仅且能够从消息中间件成功消费一次消息。
8181

8282
保证接收端处理消息的业务逻辑具有幂等性:只要具有幂等性,那么消费多少次消息,最后处理的结果都是一样的。
8383

0 commit comments

Comments
 (0)

Back | FazBrowse Home | New Git URL