第四章:OceanBase集群技术架构(分布式事务、MVCC、事务隔离级别)

简介: 第四章:OceanBase集群技术架构(分布式事务、MVCC、事务隔离级别)

分布式事务跨机执行时,OceanBase通过多种机制保证ACI

A 原子性Atomicity

原子性是指事务是一个不可分割的工作单位,事务中的操作要么都发生,要么都不发生。

依赖两阶段提交协议保证分布式事务的原子性

C 一致性Consistency

事务前后数据的完整性必须保持一致

保证主键唯一等一致性约束。全局快照-单租户GTS服务,1秒钟内能够响应获取全局时间戳的调用次数超过200万次。

I 隔离性Isolation

多个用户并发访问数据库时,数据库为每个用户开启的事务,不能被其他事务的操作所干扰。

采用MVCC进行并发控制,实现read-committed的隔离级别

所有修改的行加互斥锁,实现写-写互斥

读操作读取特定快照版本的数据,读写互不阻塞

D 持久性Durability

一个事务一旦被提交,它对数据库中数据的改变就是永久性的,接下来即使数据库发生故障也不应该对其有任何影响。

Redo-Log使用Paxos协议做多副本同步

因服务器时钟差异,分布式数据库ACID挑战更大

和传统的数据库的单点全共享架构不同,OceanBase是一个原生的分布式架构,采用了多点无共享的架构,在实现全局一致的快照隔离和多版本并发控制时,会面临分布式架构所带来的技术挑战。

OceanBase全局一致性快照技术

OceanBase数据库利用一个集中式服务来提供全局一致的版本号。事务在修改数据或者查询数据的时候,无论请求源自哪台物理 机器,都会从这个集中式的服务处获取版本号,保证所有的版本号单调向前并且和真实世界的时间顺序保持一致。

创新的两阶段提交,任何故障均可以保障事务的原子性

技术难点:依赖两阶段提交协议保证事务原子性

两阶段提交:状态多、复杂、状态机容易卡住

OceanBase两阶段提交协议特点

事务协调者和所有参与者都是高可用的。

单机多分区事务,所有参与者都prepare成功即认为事务进入提交状态,立即返回客户端commit

全自动处理异常情况

多版本并发控制(MVCC),解决读写互斥问题

事务隔离级别

事务并发问题:

脏读:读取了未提交的数据

不可重复读:指的是在同一事务内,不同的时刻读到的同一批数据可能是不一样的(期间被别的事务更新数据)

幻读:指的是在同一事务内,在操作过程中进行两次查询,第二次查询的结果包含了第一次查询中 未出现的数据或者缺少了第一次查询中出现的数据(期间被别的事务插入或者删除了数据)


OceanBase支持多种事务隔离级别

基于全局一致的数据版本号管理,以不同的版本号策略实现不同的隔离级别

Oracle模式支持以下两种隔离级别,应用系统可以根据需求权衡使用任何一种隔离级别:

Read-Committed:避免脏读,存在不可重复读和幻读(默认)

Serializable:避免脏读、不可重复读、幻读

MySQL模式支持读已提交、可重复读两种隔离级别

不支持脏读(Dirty-Read),只能获取已提交数据


相关文章
|
4天前
|
设计模式 存储 算法
分布式系统架构5:限流设计模式
本文是小卷关于分布式系统架构学习的第5篇,重点介绍限流器及4种常见的限流设计模式:流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击,确保资源合理分配。流量计数器简单但存在边界问题;滑动窗口更精细地控制流量;漏桶平滑流量但配置复杂;令牌桶允许突发流量。此外,还简要介绍了分布式限流的概念及实现方式,强调了限流的代价与收益权衡。
34 11
|
6天前
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
29 11
|
7天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
42 11
|
21天前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
|
17天前
|
存储 算法 安全
分布式系统架构1:共识算法Paxos
本文介绍了分布式系统中实现数据一致性的重要算法——Paxos及其改进版Multi Paxos。Paxos算法由Leslie Lamport提出,旨在解决分布式环境下的共识问题,通过提案节点、决策节点和记录节点的协作,确保数据在多台机器间的一致性和可用性。Multi Paxos通过引入主节点选举机制,优化了基本Paxos的效率,减少了网络通信次数,提高了系统的性能和可靠性。文中还简要讨论了数据复制的安全性和一致性保障措施。
33 1
|
1月前
|
人工智能 运维 算法
引领企业未来数字基础架构浪潮,中国铁塔探索超大规模分布式算力
引领企业未来数字基础架构浪潮,中国铁塔探索超大规模分布式算力
|
25天前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
55 8
|
6天前
|
存储 负载均衡 监控
揭秘 Elasticsearch 集群架构,解锁大数据处理神器
Elasticsearch 是一个强大的分布式搜索和分析引擎,广泛应用于大数据处理、实时搜索和分析。本文深入探讨了 Elasticsearch 集群的架构和特性,包括高可用性和负载均衡,以及主节点、数据节点、协调节点和 Ingest 节点的角色和功能。
21 0
|
2月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
22天前
|
存储 NoSQL Java
使用lock4j-redis-template-spring-boot-starter实现redis分布式锁
通过使用 `lock4j-redis-template-spring-boot-starter`,我们可以轻松实现 Redis 分布式锁,从而解决分布式系统中多个实例并发访问共享资源的问题。合理配置和使用分布式锁,可以有效提高系统的稳定性和数据的一致性。希望本文对你在实际项目中使用 Redis 分布式锁有所帮助。
65 5