虹科干货 | 什么是数据库一致性?

数据库一致性是确保数据在所有节点间保持规则的一致状态,避免不一致数据导致的问题。文章通过驾照数据库和银行转账的例子解释了不一致性的影响,并介绍了强一致性与弱一致性。RedisEnterprise的Active-Active地理分布提供了强一致性保障,通过复制和持久化策略保证数据的一致性和高可用性。文章还提到了ACID属性中的隔离级别,用于控制并发事务中的数据访问。
摘要由CSDN通过智能技术生成

数据库一致性(database consistency)由一组值定义,数据库系统中的所有数据点都必须与这些值保持一致,才能正确读取和接受数据。如果任何不符合先决条件值的数据进入数据库,将导致数据集出现一致性错误。数据库一致性通过建立规则来实现。任何写入数据库的数据事务都只能按照数据库开发人员制定的规则,包括特定约束、触发器、变量、级联等来更改受影响的数据。

例如,假设您某地区的交通安全研究所工作。您的任务是创建一个新驾照数据库。在过去的十年中,该地区的人口激增,因此需要为所有首次申领驾照的人提供新的字母和数字格式。在您的数据库中,该地区驾照的新设定值如下:1个字母+ 7个数字,现在每个条目都必须遵循这一规则。如果输入"C08846024",则返回错误。为什么?因为输入的值是1个字母+8个数字,这实质上是一种不一致的数据形式。

一致性还意味着,一个表中任何一个特定对象的任何数据更改都需要在该对象所在的所有其他表中进行更改。继续以驾照为例,如果新驾驶员的家庭地址发生变化,则必须在所有存在该地址的表中体现该更新。如果一个表中的地址是旧的,而其他所有表中的地址都是新的,这也是数据不一致的典型例子。

注意:数据库一致性并不保证在任何给定事务中引入的数据是正确的,它只保证在系统中写入和读取的数据符合所有有资格进入数据库的数据的先决条件。更简单地说,在上面的示例中,您可以输入符合1个字母+ 7个数字规则的数据事务,但这并不能保证数据与实际的驾照相对应。数据库一致性并不考虑数据所代表的内容,只考虑其格式。

为什么数据库一致性很重要?

一致的数据使数据库能够像运转良好的机器一样运行。已建立的规则/值可将不一致的数据排除在主数据库和副本之外,从而保持其操作顺利:

  • 准确性
  • 增加数据库空间
  • 更快、更高效的数据检索

数据库一致性对所有输入数据进行管理。因此,尽管数据库在接受新数据时会发生变化,但它至少会根据一开始制定的验证规则一致地发生变化。如今,全球每天都有数十亿美元的决策是根据数据库的一致性做出的。当实时信息成为现代数字业务的基础时,制定验证规则以确保数据集没有错误信息就显得至关重要。因为数据错误增加延迟,损害实时体验。

数据库一致性示例

现实世界中有哪些数据库一致性操作的例子?我们已经在上文的驾照数据库场景中探讨了一个例子。现在我们转向银行业看看。

假设您正在将资金从一个账户转入另一个账户。您刚刚将12000元转入一个已有3000元的账户中。假设正确刷新后,账户余额会显示为15000元。但是,新余额现在显示为0元,说明最新的操作并没有反映在您的余额中。这种技术上的疏忽是数据库弱一致性的一个典型例子。诸如此类的问题可能会损害银行声誉并造成巨大损失。对于任何行业的数据库开发人员和消费者来说,数据库系统的强一致性正变得越来越不可或缺。

强一致性 vs 弱一致性

强一致性主节点、副本及其所有相应节点中的所有数据都符合验证规则,并且在任何给定时间内都是相同的。有了强数据库一致性,无论从哪个客户端访问数据—客户将始终看到遵循数据库既定规则的更新版本数据。

弱一致性无法保证主节点、副本节点或节点中的数据在任何时刻都是相同的。某个客户可以访问数据,并看到通过验证规则的信息,但可能不是最近更新的数据,从而导致一致性错误。

Redis Enterprise(Redis企业版数据库)的Active-Active地理分布允许多个主数据库,使您能够灵活地处理越来越大的工作负载。所谓 “Active-Active”,是指数据库的每个实例都可以接受对任何键的读写操作。每个数据库实例,无论距离多远,都是网络上的一个对等节点。这意味着,当对任何实例进行写操作时,该节点会自动向网络上的所有其他实例发送消息,说明缓存中的哪些内容发生了更改,并确保所有实例保留一致的缓存数据集。

Redis Enterprise独特的Active-Active地理分布采用了复杂的算法,旨在处理可能导致缓存不一致的潜在写入冲突。这些算法基于无冲突复制数据类型(CRDT),确保来自多个副本的写入数据能够以有效保持一致性的方式进行合并。

虹科是Redis企业版数据库中国区战略合作伙伴。Redis企业版软件(Redis Enterprise)是企业级的数据库软件,也是一款实时数据平台,为全球超过8500家知名企业提供实时数据服务。具有线性可扩展性、高可用性、持久性、备份和恢复、地理分布、分层内存访问、多租户、安全性等8大核心功能、拥有RediSearch、RedisJSON等7大【Redis企业版特有模块】,可以任何规模在云、本地和混合部署中运行现代应用程序,提供无服务器、多模型的数据库解决方案。Redis企业版的核心优势是采用Redis on flash分层存储技术即【内存+闪存+磁盘】的存储方式,其Active-Active地理分布式架构允许跨地理位置同时进行数据读写操作、拥有亚毫秒延迟和极高吞吐量。

一致性级别

一致性级别是另一组先决条件值,它决定了有多少个副本或节点必须响应新的允许数据,然后才被确认为有效事务。这种操作可以根据每笔事务进行更改。例如,程序员可以规定,在确认数据一致性之前,只有两个节点需要读取新输入的数据。一旦数据跨过了这个界限,它就会被认为是一致的数据。

隔离级别

隔离级别是数据库ACID(原子性、一致性、隔离性、持久性)属性的一部分。ACID是SQL数据库一致性的基本概念,也是某些数据库为优化数据库一致性而遵循的基本概念。隔离(Isolation)是ACID属性之一,它将某些数据块与特定数据库网络中的所有信息隔离开来,使其不会被其他用户事务修改。隔离被用来减少并发事务中产生的无关数据的读写。

有四种类型的隔离级别
(1)未提交读取:最低级别。如果前一个事务对该行进行了未提交更新,则停止该行的更新。
(2)已提交读取:不允许"脏读"。如果事务已经更新,但尚未提交,则会阻止任何读取或写入。
(3)可重复读取:该级别使正在读取的数据行不会被访问和更新。
(4)可序列化:最高隔离级别,可序列化通常锁定整个表,而不是特定的数据行。

复制过程中的一致性

Redis企业版软件能够将数据复制到另一个数据库实例,以获得高可用性,并将内存中的数据永久持久化到磁盘上,以获得持久性。使用WAIT命令,可以控制复制和持久化数据库的一致性和持久性保证。

向数据库发布的任何更新通常按以下流程执行:
(1)应用程序发出写操作
(2)代理与系统中包含给定键的正确主(也称为“master”)"分片"通信
(3)分片写入数据并向代理发送回执
(4)代理将回执发送给应用程序
(5)主分片向副本发送写入信息
(6)副本将写入确认发回给主服务器
(7)写入副本的内容被持久化到磁盘上
(8)副本内部确认写入

使用WAIT命令,应用程序可以要求仅在复制或持久性在副本上确认后等待确认。

使用WAIT命令的写操作流程如下所示:
(1)应用程序发出写操作
(2)代理与系统中包含给定key的正确主 "分片"通信
(3)复制将更新传递给副本分片
(4)复制将更新持久化到磁盘(假设选择了每次写入都自动更新)
(5-8)通过步骤5至8,确认从副本一直发回代理。

通过此流程,应用程序只有在复制到副本和持久化存储实现耐久性后,才能从写入中获得确认。

使用WAIT命令,应用程序可以保证即使在节点故障或节点重新启动的情况下,也会记录已确认的写入。

数据库一致性常见问题解答(QA)

Q:数据一致性意味着什么?
A:如果数据在同一时间出现在所有相应的节点中,无论用户在哪里访问数据,数据都是一致的。

Q:数据一致性与数据库一致性是一回事吗?
A:数据一致性是指数据在整个网络中以及在使用该数据的众多应用程序之间尽可能保持一致的过程。数据库一致性要求对进入网络的数据制定验证规则,以使其在公式上与表中的所有其他数据保持一致。

Q:什么是最终一致性?
A:通过最终一致性,经过更新的数据最终将反映在存储该数据的所有节点中。最终,通过最终一致性,无论任何客户端在网络中访问数据,所有节点都将生成相同的数据。

Q:关系数据库中的单个表包括?
A:关系数据库中的所有数据都存储在表中,表由行和列组成。数据点被组织在这些行和列中。行通常被称为 “记录”,代表数据类别,而列或 "字段 "则代表 “实例”。在数据库中可以找到表格,其基于主题的设计有助于防止数据冗余。

Q:关系数据库由哪些部分组成?
A:关系数据库由表组成

Q:ACID模型与BASE模型相比有何不同?
A:ACID和BASE(基本可用、软状态、最终一致)模型之间的主要区别在于,ACID致力于优化数据库一致性,而BASE则加强高可用性。ACID可保持事务一致性,因此如果您采用BASE模型,请确保一致性仍是重中之重,并得到彻底解决。

Q:Redis数据库是否一致?
A:当Redis用作缓存时,一致性问题可能发生在Redis实例(主/副本)之间,以及Redis缓存和作为主数据库的Redis之间。在这种情况下,如果两者之间的数据不匹配,数据就会不一致。对于开源Redis来说,一致性较弱,但Redis Enterprise的Active-Active Geo-Distribution提供了较强的最终一致性。

推荐阅读:
《虹科Redis企业版数据库简介》
《虹科干货 | 什么是数据库一致性?》

虹科是Redis企业版数据库的中国区战略合作伙伴,了解更多【企业级数据库解决方案】及【企业缓存购买】,欢迎前往虹科云科技官网!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值