分布式概述笔记

本文探讨了分布式事务的ACID特性及GTS与微服务的集成方式,并介绍了分布式数据库的常见解决方案,如垂直和水平拆分等。此外,还讨论了分布式缓存中的Redis哨兵模式的工作原理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一.分布式事务

事务 ACID特性

原子性(A):就是说在事务执行的过程中要么全部执行,要么全部执行,不存在中间状态。一旦事务执行过程中发生错误,即回滚操作,像什么都没有发生一样。

一致性(C):一致性就是要保证事务执行过程中系统要保持一致不便,比如A用户转账给B用户,在事务执行完成后要保证A和B两个用户的账户金额总值保持不变。

隔离性(I ):指事务执行过程中相互之间不干扰,数据不会共享

永久性(D):事务的执行是不可逆的过程,一旦事务执行完成执行结果将会被保存在数据库中,即使发生断电断网等影响事务执行结果也不会改变。

GTS与微服务的集成

   当客户端的一个请求传到应用业务服务器可能会触发多个微服务的调用,相应的可能会涉及到多个业务数据库的读写操作。GTS包括客户端(GTS Client)、资源管理器(GTS RM)和事务协调器(GTS Server)三个部分。GTS Client主要用来界定事务边界,完成事务的发起与结束。GTS RM完成事务分支的创建、提交、回滚等操作。GTS Server主要负责分布式事务的整体推进,事务生命周期的管理。GTS和微服务集成的结构图如下所示,GTS Client需要和业务应用集成部署,RM与微服务集成部署。

二.分布式数据库

分布式数据库主要是针对应用业务量巨大,当前数据库无法保证系统性能时使用。常见的分布式数据库解决方案有数据库的垂直拆分、数据库的水平拆分,在此基础上还对应有单一数据的分库、分表、数据库的读写分离等。

三.分布式缓存

     此处以redis为例,redis哨兵模式主要存在三个主要角色,即主redis(master)、从redis(slave)、哨兵redis(sentinel)。

      在同一个哨兵模式中,一个master可以有多个slave以及多个sentinel,但是slave和sentinel同一时刻只能有一个master。当sentinel节点监听到master节点宕机时会在其从节点中进行选举产生一个新的master,这个被选举的slave会作为新的master继续提供服务。如下图所示:

     

 

 

参考链接

   分布式事务

   分布式数据库

   redis哨兵模式

   分布式缓存

   深入浅出Redis-redis哨兵集群

   分布式服务框架设计和实现

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值