一、分片场景下的分布式事务，真的是"地狱级"难题 还记得第一次在分片数据库上实现分布式事务时，我天真地以为用个简单的两阶段提交就搞定了。结果上线后，事务要么提交失败，要么回滚不完整、 今天我们就来聊聊，在分片场景下，TCC和Seata到底该怎么选？分布式事务又该怎么实现？这些坑，我踩过，你也别踩了！ 二、分片场景下的分布式事务，为什么这么难？ 1. 分片场景的特殊性 在分片数
分片键选错了，你的数据库分片就是"灾难现场"！ 一、开场白：分片键，数据库分片的"命门" 还记得第一次做数据库分片时，我天真地以为随便选个字段当分片键就行了。结果上线后，数据分布严重不均，有的分片撑爆了，有的分片闲得发慌。 今天我们就来聊聊，分片键到底该怎么选？路由规则又该怎么设计？这些坑，我踩过，你也别踩了！ 二、分片键选择，真的不是随便选选 1. 什么
一、传统数据库分布式化 业务应用系统可以按照交易类型分为 OLTP 场景和 OLAP 场景两大类。OLTP 是面向交易的处理过程，单笔交易的数据量小，但是要在很短的时间内给出结果，典型场景包括购物、转账等；而 OLAP 场景通常是基于大数据集的运算，典型场景包括生成各种报表等。 OLTP 与 OLAP 两种场景有很大的差异，虽然传统数据库在其早期是将两者融合在一起的。但是随着它们向分布式，特别是
一、完整的一致性模型 完整的一致性模型如下图所示。 图中不同的颜色代表了可用性的程度 1、粉色代表网络分区后完全不可用。也就是 CP 类的数据库。 2、黄色代表严格可用。当客户端一直访问同一个数据库节点，那么遭遇网络分区时，在该一致性下依然是可用的。它在数据端或服务端，被认为是 AP 数据库；而从客户端的角度被认为是 CP 数据库。 3、蓝色代表完全可用。可以看到其中全都是客户端一致
本篇文章我们来聊聊如何在分布式数据库，乃至一般性的分布式系统内同步数据。 不知道大家是否发现这样一种事实：同步数据是一种代价非常高昂的操作，如果同步过程中需要所有参与的节点互相进行操作，那么其通信开销会非常巨大。 如下图所示，随着参与节点的增加，其通信成本逐步提高，最终一定会导致数据在集群内不一致。尤其在超大型和地理空间上分散的集群网络中，此现象会进一步被放大。 为了减少同步通信开销和参与节点的
分布式系统部分所重点解决的问题，即围绕失败模型来设计算法、解决各种稳定性问题。 解决问题的前提是发现问题，所以这一篇我们来说说如何发现系统内的错误，这是之后要介绍的算法们所依赖的前置条件。比如上一篇提到的共识算法，如果没有失败侦测手段，我们是无法解决拜占庭将军问题的，也就是会陷入 FLP 假说所描述的境地中，从而无法实现一个可用的共识算法。这里同时要指明，失败不仅仅是节点崩溃，而主要从其他节点看，
分布式数据库区别于传统数据库的一个重要特性就是其分布式的特点，这些特点来源于分布式理论的发展，特别是数据分布相关理论的发展。相比于无状态分布式系统，有状态的数据库在分布式领域中将会面对更多的挑战。下面我们从失败模型开始，讨论分布式模式下的数据库吧。 一、失败模型 分布式系统是由多个节点参与其中的，它们直接通过网络进行互联。每个节点会保存本地的状态，通过网络来互相同步这些状态；同时节点需要访问时间组
一、事务概述 事务管理是数据库中存储引擎的一个相当独立并且重要的组件，它可以保证对数据库的一系列操作看起来就像只有一步操作一样。这大大简化了面向数据库的应用的开发，特别是在高并发场景下，其意义更为重要。 一个典型的案例就是转账操作：从甲处转 100 元给乙。现实生活中，这个操作是原子的，因为纸币是不可复制的。但是在计算机系统内，这个操作实际上是由两个操作组成：甲账户减 100、乙账户加 100。两
索引是数据检错的关键技术，那么在分布式数据库这种体量的数据容量下，如单机数据那样进行数据表全量扫描是非常不现实的，故分布式存储引擎的关键就是要通过索引查找目标数据。 本文章，我们就一起来看看分布式数据库索引相关的内容。 一、分布式索引是什么？ 目前世界上主要的分布式数据库的数据存储形式，就是围绕着索引而设计的。由于分布式数据库的数据被分散在多个节点上，当查询请求到达服务端时，目标数据有极大的概率并
数据库的一个首要目标是可靠并高效地管理数据，以供人们使用。进而不同的应用可以使用相同的数据库来共享它们的数据。数据库的出现使人们放弃了为每个独立的应用开发数据存储的想法，同时，随着数据库广泛的使用，其处理能力飞速发展，演进出如现代的分布式数据库这般惊人的能力。 那么，为了支撑抽象的多种场景。一般的数据库都会采用多模块或多子系统的架构来构建数据库，从而方便数据库项目团队依据现实的场景来组合不同的子模
MySQL 由于其单机机能的限制，很早就发展了数据复制技术以提高性能。同时依赖该技术，MySQL 可用性也得到了长足的发展。 截止到现在，该技术经历了四代的发展。第一代为传统复制，使用 MHA（Master High Available）架构；第二代是基于 GTID 的复制，即 GTID+Binlog server 的模式；第三代为增强半同步复制，GTID+增强半同步复制；第四代为 MySQL 原
数据库最强的隔离级别是序列化，它保证从事务的角度看自己是独占了所有资源的。但序列化性能较差，因此我们引入了多种隔离界别来提高性能。在文章的最后我们再看看分布式数据库中常用的并发控制手段，它们是实现隔离级别的有效方案，其中以多版本方式实现快照隔离最为常见。 一、隔离级别 在谈隔离级别之前，我们先聊聊“序列化”（Serializability）的概念。 序列化的概念与事务调度（Schedule）密切相
数据库复制的主要目的是在几个不同的数据库节点上保留相同数据的副本，从而提供一种数据冗余。这份冗余的数据可以提高数据查询性能，而更重要的是保证数据库的可用性。本篇文章介绍两种复制模式：单主复制与多主复制。 一、单主复制 单主复制，也称主从复制。写入主节点的数据都需要复制到从节点，即存储数据库副本的节点。当客户要写入数据库时，他们必须将请求发送给主节点，而后主节点将这些数据转换为复制日志或修改数据流发
21 世纪的开发者往往要面对一种窘境：需在众多的数据库中艰难地做出选择。他们其实也想如老一辈技术人一样闭着眼睛去选择 Oracle 或者 DB2，因为它们曾经被证明是“不会出错”的选择，即无论选择哪款数据库，都不会丢工作。 而时至今日，时代变了，我们如果不了解各种数据库内部的机理，即使选择大厂的成熟产品也有可能掉进“坑”里。因此，选择合适的数据库就成了日常工作中一项必备技能。 当然数据库的分类有各
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
