深入浅出cassandra 4 数据一致性问题概述

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:
/**
*author:ahuaxuan(张荣华)
*date: 2010-2-28
*/

在上一篇文章,ahuaxuan和大家简单的熟悉了cassandra的集群环境的部署,接下来要做的就是搞清除这种部署模型的的理论依据.

理论依据一,数据一致性和W R N

首先简单解释一下数据一致性(这个问题是老生常谈的问题,任何一本应用开发的书上都有它的描述)
所谓的一致性其实就是事物ACID中的C:

事务在完成时,必须使所有的数据都保持一致状态。在相关数据库中,所有规则都必须应用于事务的修改,以保持所有数据的完整性。事务结束时,所有的内部数据结构(如 B 树索引或双向链表)都必须是正确的。

(但是一致性并非只存在于事务环境中,这也就是说我们会有一些系统不能实现A, 或者I,但是能够实现C和D,这里面有一个哲学问题,是不是我们所有的应用都需要事务,如果所有的应用都需要事务,那么几年前mysql的
isam索引为什么会这么流行?所以说事务有事务的用处,非事务由非事务的用途。cassandra0.5中目前还没有实现完整的事务功能,但是已经有不少公司在使用。)

那么举两个非一致性的场景,比如说某个数据存放着两份备份,某一份数据被修改之后,必须保证这份修改被用户看到之前,另一份数据修改也已经完成。
或者说有相互依赖的两条数据,等用户能看到前条数据的时候,他一定能看到第二条数据。否则在修改的过程中,用户拿到了第一条刚修改完的数据,但是在拿第二条数据的时候却拿到了老的数据,
这两种场景都有可能在mysql的master-slaver模型中出现
在master中插入数据,然后去slaver中查找该数据,你有可能查找不到,具体的原因后面会讲到。


但是在这之前我们还得再来看看标题中的3个字母:

N: cassandra网络中复制数据的节点数
R: cassandra网络中读节点数
W:cassandra网络中阻塞写节点数(为什么是阻塞写?后面的文章中会讲到)

为什么要提出这三个概念呢,其实这三个概念和cassandra中的数据一致性和读写性能息息相关.

我们先来看第一个问题,数据一致性.

在一般的数据库集群(或者m-s之流的策略)中,读写操作的一致性问题向来会困扰一部分人,举个例子,在mysql的master和slaver模式中,
写操作总是由master负责,读操作有slaver负责,当然必要时master也可以负责读操作,但是我相信用过mysql的m-s模式的人一般都会碰到一个问题,
就是数据延迟的问题,一条写语句发往master,然后master会把数据复制到slaver上,但是这里有一个问题,复制和插入过程是没有全局锁来保证顺序的,也就是master写往自己,其实客户端就可以
从Master上读取这条数据,但是如果客户端操作的是slaver,那它就要碰运气了,因为复制的时间可长可短,而且和网络环境相关,有的时候数据延迟会高达12分钟.ahuaxuan曾经就碰到复制过程2分钟的场景.

但是如果这里有全局锁来控制复制过程,比如在cluster模型下,那么写操作必须等待所有的机器都写完,那么写操作才能返回,虽然这样容错性得到了保证,但是写操作的性能大大下降,而且集群环境中的节点越多写操作越忙.

在ahuaxuan看来,mysql的cluster模式和m-s模式其实也是W/R/N之间关系的一种表现.
举例来说,在cluster模式中(假设一共3台机器),由于要考虑到读操作和写操作的容错,所以写操作需要有全居锁的保证,而且所有的集群都要响应写操作,而读操作只需要操作一台机器,为啥了,因为所有的数据在用户能读之前都会在所有的mysql机器上.
所以我们可以把这种行为看成: N=mysql的集群数量(3), W=mysql的集群数量(3), R=1

而在m-s模式中,由于写只需要涉及m,所以这里W=1,而读操作也只是涉及到一台机器,所以R=1,而N还是为3,但是正如ahuaxuan论述的那样,m-s是不能保证一致性的,而且不能保证写操作的容错性.

我们再仔细看以下这两个例子的关系
cluster模型中, N=3, W=3(全局锁同步控制), R=1, 可以容错,可以保证一致性. W+R=4 > N=3
M-S模型中, N=3, W=1(slaver是异步复制写,注意,这里不是同步读写,同步的话,这里的W就应该是3), R=1, 读操作可以容错,不能保证数据一致性, W+R=2 < N=3

而amazon论文中对W/R/N的论述大意如下:
如果W+R>N, 那么写读写操作都会有多份,这种模式下可以保证数据的强一致性. 在实现了同步(注意,这里不是异步)数据复制类m-s的场景中,N=2, W=2, R=1,这种模型可以保证数据一致性. 但是如果是异步数据复制的类m-s场景,那么如同ahuaxuan之前举的Mysql例子一样,是不能保证数据一致性的.

那么我们在想远一点,举一个比较极端的例子,如果N=3, W=3, R=1,这种是数据库集群常用的模型,所以在这种场景下读性能会远高于写性能.而如果N=3, R=3, W=1,这种场景下,写一次,但是读取的时候需要读多次,然后比较版本
所以在这种场景下写性能远高于读性能,如果要写性能很高的场景我们一般也不会采取这种模型.

那么我们再回头来看看使用数据库系统的时候我们需要些什么,我们要综合考虑我们的数据特征,然后来判断是水平切分,垂直切分等等,然后还要考虑各种部署模型,m-s, cluster等等.
当然这些技术目前都是比较成熟的,在一些大型的互联网系统,水平和垂直切分已经成了标准做法,而且往往他们和m-s或者cluster模型结合起来使用。
比如说在统计系统中,通常会通过日期来进行水平切分统计数据。在其他和id相关的系统中,可能将id进行hash做水平切分,等等类似的方案有很多。当然也有可能根据常用和非常用来对数据进行垂直切分。
与此同时对数据库进行m-s或者cluster部署(根据业务特征决定),但是由于m-s和cluster的扩展有限,所以通常还会将app和一组数据库(m-s或者cluster部署)绑定,进行整体failover.


但是
即使这样做在容错和水平扩展上还是会有局限性,随着数据量的增大,原来可行的方法会渐渐变得不可行,于是我们不得不寻找新的理论,新的方案,cassandra背后的理论也是在这种需求的促发下产生的.

回到正题,
通过ahuaxuan举了例子,我想同学们应该都基本上对W/R/N之间的关系有了一个比较直观的理解.既然这个话题放在这里说明,那么证明我们的cassandra中也存在这样的问题,
在后面的文章我们会讲到cassandra在网络上其实是dynamo理论的一个实现,这意味着存在如下事实.

每条数据并不是保存在cassandra中所有的节点上,部分数据会保存在部分节点上(而如何确定什么数据保存在什么节点上这是通过一致性hash算法来决定的.)
比如说我们一共有n个节点在网络中,那么如果根据key算出对应的value应该保存在n-m号节点上,那么我们可以认为这个value对象还会有备份在n-m-1,和n-m-2的节点上(假设N=3)
而在读取的时候,我们也可以通过consistency_level来控制R的值,这样对应的在cassandra中, N, W, R的关系也成为我们必须要了解的内容。


在后续的文章中,我们将通过代码来详细的分析cassandra中的数据备份策略,以及读策略, 但是在那之前,我们还需要知道cassandra中的网络模型,
以及W, R, N在cassandra模型中究竟处于什么样的位置。to be continued

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
5月前
|
存储 SQL Prometheus
【TiDB原理与实战详解】1、原理与基础优化~学不会? 不存在的!
TiDB 是一款开源的分布式关系型数据库,具备水平扩展、高可用性和强一致性等特点,适用于高并发、低延迟的大规模数据处理场景。其架构设计灵感源自 Google 的 Spanner 和 F1,并兼容 MySQL。TiDB 集群由 TiDB Server(无状态 SQL 层)、PD(元数据管理模块)和 TiKV Server(分布式存储层)组成,还包含 TiFlash(列存储引擎)以加速分析型查询。TiDB 支持分布式事务和多种事务模式,适用于 OLTP 和 HTAP 场景,如电商平台和金融系统。此外,TiDB 的部署要求包括高性能硬件配置和特定网络设置,以确保系统的稳定性和高效运行。
|
8月前
|
NoSQL MongoDB 数据库
|
8月前
|
存储 大数据 对象存储
ClickHouse 如何实现数据一致性
本文探讨了在 ClickHouse 中实现数据一致性的方法,主要关注 `ReplacingMergeTree` 引擎。该引擎允许更新已有数据,通过定期合并操作删除重复并保持最终一致性。然而,由于合并时间不可预测,单纯依赖此引擎无法确保实时一致性。为解决此问题,文章提出了四种策略:1)手动触发合并,但不建议频繁使用;2)使用 `FINAL` 查询,但在查询时合并数据,效率较低;3)通过标记和 `GroupBy` 查询实现一致性;4)在允许一定偏差的情况下,直接使用 `ReplacingMergeTree` 保持最终一致性。在实践中,推荐结合标记列和 `GroupBy` 以保证数据一致性。
311 0
|
8月前
|
SQL 弹性计算 关系型数据库
TiDB的主要特点:深入了解其技术特性
【2月更文挑战第25天】TiDB作为一款高性能、分布式的关系型数据库,其独特的技术特性使其在数据处理领域脱颖而出。本文将深入探讨TiDB的主要特点,包括其分布式架构、MySQL协议兼容性、弹性伸缩能力、强一致性保证以及丰富的SQL功能等,帮助读者更全面地了解这一优秀的数据库产品
|
存储 消息中间件 缓存
【Cassandra从入门到放弃系列 一】概述及基本架构
【Cassandra从入门到放弃系列 一】概述及基本架构
2650 0
|
存储 SQL NoSQL
大数据存储组件TiDB原理+实战篇1
大数据存储组件TiDB原理+实战篇
|
存储 SQL 分布式计算
大数据存储组件TiDB原理+实战篇2
大数据存储组件TiDB原理+实战篇
|
存储 算法 前端开发
开源分布式数据库PolarDB-X源码解读——PolarDB-X源码解读(番外):如何实现一个Paxos
开源分布式数据库PolarDB-X源码解读——PolarDB-X源码解读(番外):如何实现一个Paxos
339 0
|
缓存 NoSQL
TiDB的分布式事务原理探究
TiDB分布式事务原理探究,步骤分为 事务开启,事务写,事务回滚,或者事务提交。事务提交中由包括操作映射,Prewrite 和 Commit
672 0
|
SQL 存储 安全
数据库系统原理概述
数据库系统原理概述

热门文章

最新文章

下一篇
开通oss服务