| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -29,7 +29,7 @@ | |||
| 29 | 29 | ||
| 30 | 30 | 分布式存储中可以将数据分片到多个节点上,不仅可以提高性能(可扩展性),同时也可以使用多个节点对同一份数据进行备份(高可用性)。 | |
| 31 | 31 | ||
| 32 | - 至于分布式计算,就是将一个大的计算任务分解成小任务分配到多台节点上去执行,再汇总每个小任务的执行结果得到最终结果。MapReduce 是分布式计算的最好例子。 | ||
| 32 | + 至于分布式计算,就是将一个大的计算任务分解成小任务分配到多个节点上去执行,再汇总每个小任务的执行结果得到最终结果。MapReduce 是分布式计算最好的例子。 | ||
| 33 | 33 | ||
| 34 | 34 | # 二、分布式事务 | |
| 35 | 35 | ||
@@ -42,42 +42,42 @@ | |||
| 42 | 42 | ||
| 43 | 43 | ## 应用场景 | |
| 44 | 44 | ||
| 45 | - - 下单:减少库存、更新订单状态。库存和订单不在同一个数据库,因此涉及分布式事务。 | ||
| 46 | - - 支付:买家账户扣款、卖家账户入账。买家和卖家账户信息不在同一个数据库,因此涉及分布式事务。 | ||
| 45 | + - 下单:减少库存、更新订单状态。库存和订单如果不在同一个数据库,就涉及分布式事务。 | ||
| 46 | + - 支付:买家账户扣款、卖家账户入账。买家和卖家账户信息如果不在同一个数据库,就涉及分布式事务。 | ||
| 47 | 47 | ||
| 48 | 48 | ## 解决方案 | |
| 49 | 49 | ||
| 50 | 50 | ### 1. 两阶段提交协议 | |
| 51 | 51 | ||
| 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) | ||
| 53 | 53 | ||
| 54 | - 两阶段提交协议可以很好得解决分布式事务问题,它可以使用 XA 来实现,XA 它包含两个部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如 Oracle、DB2 这些商业数据库都实现了 XA 接口;而事务管理器作为全局的协调者,负责各个本地资源的提交和回滚。 | ||
| 54 | + 两阶段提交协议可以很好地解决分布式事务问题。它可以使用 XA 来实现,XA 包含两个部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如 Oracle、DB2 这些商业数据库都实现了 XA 接口;而事务管理器作为全局的协调者,负责各个本地资源的提交和回滚。 | ||
| 55 | 55 | ||
| 56 | 56 | ### 2. 消息中间件 | |
| 57 | 57 | ||
| 58 | 58 | 消息中间件也可称作消息系统 (MQ),它本质上是一个暂存转发消息的一个中间件。在分布式应用当中,我们可以把一个业务操作转换成一个消息,比如支付宝的余额转入余额宝操作,支付宝系统执行减少余额操作之后向消息系统发送一个消息,余额宝系统订阅这条消息然后进行增加余额宝操作。 | |
| 59 | 59 | ||
| 60 | 60 | #### 2.1 消息处理模型 | |
| 61 | 61 | ||
| 62 | - **(一)点对点** | ||
| 62 | + (一)点对点 | ||
| 63 | 63 | ||
| 64 | 64 | <div align="center"> <img src="../pics//96b63e13-e2d8-4ddb-9aa1-a38959ca96e5.jpg" width="600"/> </div><br> | |
| 65 | 65 | ||
| 66 | - **(二)发布/订阅** | ||
| 66 | + (二)发布/订阅 | ||
| 67 | 67 | ||
| 68 | 68 | <div align="center"> <img src="../pics//654acfed-a6a5-4fc7-8f40-3fdcae57bae8.jpg" width="700"/> </div><br> | |
| 69 | 69 | ||
| 70 | 70 | #### 2.2 消息的可靠性 | |
| 71 | 71 | ||
| 72 | - 消息的发送端的可靠性:发送端完成操作后一定能将消息成功发送到消息系统。 | ||
| 72 | + (一)发送端的可靠性 | ||
| 73 | 73 | ||
| 74 | - 消息的接收端的可靠性:接收端仅且能够从消息中间件成功消费一次消息。 | ||
| 75 | - | ||
| 76 | - **(一)发送端的可靠性** | ||
| 74 | + 发送端完成操作后一定能将消息成功发送到消息系统。 | ||
| 77 | 75 | ||
| 78 | 76 | 在本地数据建一张消息表,将消息数据与业务数据保存在同一数据库实例里,这样就可以利用本地数据库的事务机制。事务提交成功后,将消息表中的消息转移到消息中间件,若转移消息成功则删除消息表中的数据,否则继续重传。 | |
| 79 | 77 | ||
| 80 | - **(二)接收端的可靠性** | ||
| 78 | + (二)接收端的可靠性 | ||
| 79 | + | ||
| 80 | + 接收端仅且能够从消息中间件成功消费一次消息。 | ||
| 81 | 81 | ||
| 82 | 82 | 保证接收端处理消息的业务逻辑具有幂等性:只要具有幂等性,那么消费多少次消息,最后处理的结果都是一样的。 | |
| 83 | 83 | ||
| Back | FazBrowse Home | New Git URL |
0 commit comments