简介
数据库存储选型经验总结 未读
数据库治理的云原生之道 —— Database Mesh 2.0
数据的组织
从单机到分布式数据库存储系统的演进单机数据库存储,要从内存层和持久化层两个方面来解析。
- 在内存层,仅说关系型数据库,其内存数据结构特点可以总结为:一切都是“树”。我们以最常见的 B+ 树为例,B+ 树具有以下突出的特点:
- In memory 操作效率非常高: B+ 树搜索时间复杂度是 log 级别;并且 B+ 树的叶子节点构成链表,非常有利于在内存中对数据进行 scan 操作。
- 磁盘操作效率高:B+ 树的 Fanout 足够大,树的层级较少,呈矮胖状,可以减少磁盘 IO 数;同时 B+ 树的非叶子节点只存索引数据,叶子节点存实际数据,能大大压缩树高,进一步减少磁盘 IO 数。
- 数据结构高度统一:数据 & 索引都可以直接组织成 B+ 树,因此代码的可维护性、可读性和开发效率都比较好。
- 基于单机的 FS / 块存储去做持久化,我们会遇到哪些问题呢?
- 单机容量瓶颈:在 Database 层的单机服务器上运行着 database 进程,服务器上挂载了大量本地磁盘用作数据持久化。但一台物理服务器能挂载的磁盘容量总是有限的,这就导致了单机的容量瓶颈问题。
- 扩缩容困难:当容量、CPU 或者内存等资源不够时,我们需要进行扩容。在单机时代,扩容意味着将数据从这个磁盘搬迁到另一个磁盘。但不管我们是通过网络还是有线连接手段,都需要花费一定的时间,这可能导致业务较长时间的停写(不可用),因此扩缩容是非常困难的。
- 多份独立数据,成本高:如果我们要在“复制集”之间或者主备机之间去做数据冗余或数据同步,那么每新增一分计算能力(新增一个计算节点),就要新增一分存储冗余,就会导致存储成本提高。
存储
文件
关系型数据库中往往都包含 Log 数据和 Page 数据。
假定数据库存放数据的文件称为data file,数据库的内容在内存里是有缓存的,称为db buffer。某次操作,我们取了数据库某表格中的数据,这个数据会在内存中缓存一些时间。对这个数据的修改在开始时候也只是修改在内存中的内容。当db buffer已满或者遇到其他的情况,这些数据会写入data file。(为了维护这个db buffer和db file的一致性,引入了checkpoint)
db buffer的存在不仅提高了性能,系统也有机会对db buffer进行一定整理后集中写入,毕竟db数据随机写入的开销比较大。log file一般是追加内容,可以认为是顺序写。
kv
MyRocks: MySQL + RocksDB,是单机 SQL over kv 的典型代表。
- 核心理念:用 RocksDB 替换 InnoDB 。使用 RocksDB 能够有效缓解单机容量瓶颈的问题;
- 特点:一是:数据可压缩比例较高。RocksDB 实现了一种比较优秀的压缩算法,根据实际调研结果显示,在关系型数据库场景,基本上它能实现 2-4 倍的压缩比,能有效缓解单机的容量瓶颈问题。例如,单机原本挂载了 10 块磁盘,只能承载 10 TB 数据,使用 RocksDB 就能在不改变硬件条件下帮助单机承载 20 TB 或 30 TB 等更多的数据;二是,顺序写性能较好,这也是 LSM-Tree 这种数据结构在 HDD 年代出现的核心原因。
- 难点:Compaction 会导致性能抖动,且兼容性一般。众所周知,RocksDB 基于 LSM-Tree 构建,必然会遇到一些典型的 LSM-Tree-based 系统的问题。虽然 RocksDB 对顺序写特别友好,但它一定程度上牺牲了读性能—— RocksDB 在读的过程中会触发 Compaction,可能引发性能抖动,导致前台的写出现卡顿现象;同时,这一类 SQL over kv 解决方案的兼容性能表现较为一般。
计算存储分离
- Amazon Aurora核心理念:计算存储分离,Log is Database。存储层带有特定的数据库计算逻辑,除了具备存储能力之外,还具备 Redo Log 解析、回放生成数据库 Page、维护多版本数据的能力。
- Spanner 系: 计算存储分离,且 Share-Nothing。Spanner 系的数据库系统一般基于分布式 k-v 存储构建,由存储层保证事务特性,计算层做成纯计算的无状态节点。
列式存储
当一行数据有 100 个字段,而我们的分析程序只需要其中 5 个字段的时候,就很尴尬了。因为如果我们顺序解析读取数据,我们就要白白多读 20 倍的数据。那么,能不能跳着只读我们需要的字段呢?当然也是不行的,因为对于硬盘来说,顺序读远远要优于随机读。
列存模型中数据按列而不是按行组织。这意味着,同一列的所有数据值在物理存储上是连续存放的,与行内数据的排列无关。这种存储方式尤其适合于数据分析场景,因为能够高效地处理对特定列的聚合操作和筛选(能够显著减少 I/O 操作)。同类数据存储在一起有利于高效的数据压缩,因为相同类型的数据往往具有较高的相似性和重复性,从而节省存储空间。
不过,这样存储之后
- 数据写入就变得有些麻烦了。原先我们只需要顺序追加写入数据,而现在我们需要向很多个文件去追加写入数据,每次写入都需要更新多个列的存储位置。进而难以不支持复杂的事务处理,如 ACID 特性较弱。
- 查询灵活性受限:虽然对特定列的查询非常高效,但执行涉及多列联合查询或非主键列的查询时,性能可能不如预期,尤其是在需要跨列进行复杂运算时。
那有没有什么好办法呢?对于追加写入的数据,我们可以先写 WAL 日志,然后再把数据更新到内存中,接着再从内存里面,定期导出按列存储的文件到硬盘上。事实上,在一个分布式的环境里,我们的数据其实并不能称之为 100% 的列存储。因为我们在分析数据的时候,可能需要多个列的组合筛选条件。所以,更合理的解决方案是行列混合存储。在单个服务器上,数据是列存储的,但是在全局,数据又根据行进行分区,分配到了不同的服务器节点上。
未来发展
在谈及数据库存储的未来演进时,首先我们可以思考一下哪些因素会触发数据库存储架构的变革和演进?答案可能包含:存储架构自身的革命、数据库理论的突破、或者新硬件冲击引发存储系统架构迭代。基于这三个方向的思考,我们总结了以下几个数据库存储系统的演进趋势:
- 在 HTAP/HSAP 系统中,“实时”是第一关键词。为了支持实时,存储系统可能会发生架构演进和变革,因此我们需要探索:
- 行列存 All-in-one:既要存储行式的数据,又要存储列式的数据。
- 近实时,写时计算:我们需要在存储层实现写时计算的逻辑来支持实时性。
- 在硬件变革趋势上,我们总结了三个变革方向:
- 前几年,我们可能更多关注 SSD、HDD。目前我们处于 SSD 往 persistent memory 转变的风口,那么如何利用 persistent memory 去定制软件架构?
- 计算单元变革:CPU 产品已经从 multi-core 变成了 many-core (从 96c 变成了 192c、384c)。要怎么利用多核的能力?对于非计算密集型的存储系统而言,多余的算力能否用来加速数据库算子?一些无锁的数据结构是不是需要要重新设计?以上都需要我们认真考虑。
- 网络设施变革:例如 RDMA ,以及可编程的 P4 交换机这类全新的一些网络设施,可能会对我们的软件架构特别是分布式存储架构造成较大的冲击。相应地,我们需要在存储侧做出调整。
为什么要用 Tair 来服务低延时场景 - 从购物车升级说起 未读
- 大部分云原生数据库将 SQL 语句解析、物理计划执行、事务处理等都放在一层,统称为计算层。而将事务产生的日志、数据的存储放在共享存储层,统称为存储层。在存储层,数据采用多副本确保数据的可靠性,并通过 Raft 等协议保证数据的一致性。计算节点与存储节点之间采用高速网络互联,并通过 RDMA 协议传输数据,让 I/O 性能不再成为瓶颈。
- 云原生数据库拆解了计算、存储,并利用网络发挥分布式的能力,在这三个层面都充分结合新硬件的特性进行设计。未来的数据库将步入全栈优化时代,从硬件平台优化到架构层优化再到上面的应用层优化。所谓“软件优化三年不如硬件更新一代”,比如算力上,一定是充分利用 CPU 最底层的指令集和最新的加速器。
开发者的“技术无感化”时代,从 Serverless HTAP 数据库开始 “数据库作为一个软件形态本身会消亡,而数据库的平台化、微服务化会取代原来的数据库软件形式”。PS:我只是去调一个服务,接口是SQL,与XXService.QueryXX并没有区别。
- 我们一开始花了很长时间去构建了一个稳定的数据库内核,可以弹性扩展、自动 Failover、ACID Transaction 等非常硬核的基础能力。但这些都是基础能力,这些东西应该隐藏在发动机里。作为一个开车的人,不用关心变速箱里有哪些特性;
- HTAP 能够提供实时的一栈式数据服务。用户不需要关心什么是 OLAP,什么是 OLTP。一套系统可以支撑所有负载,也不用担心 OLAP 负载影响 OLTP 的正常服务;
- 基础设施层面,Serverless 部署的成本变得极低,极致的 Serverless 不用关心任何运维的细节。你可以通过代码和 open API 控制这些集群的起停。真正的按需计费。过去我们其实还是按照服务器、虚拟机这样的资源来去看待一个月多少钱,这个服务能不能粒度更细一些,只收业务流量的钱?尤其是对于偏分析的场景来说,有很多时候我们做大数据分析,比如每天半夜要去跑个报表,可能需要一千个虚拟机算,20 秒钟算完,然后再缩回来。
- 我自己写了一个小程序,在一个全新的环境下,通过代码启动一个 TiDB 的 Serverless Tier 实例。在这个过程里,我只是告诉这个程序,要启动一个集群,这个集群叫什么名字,然后把密码一输,20 秒之后可以直接拿一个 MySQL 客户端连上去了,这个时间未来会进一步缩短。你不用关心它的扩展性,即使上线以后,业务流量变得巨大无比的时候,它也能够很好地扩容上去,没有流量的时候,它还能缩回来。
- 我们过去开发程序,不同的模块看到的环境是同构且确定的,即使近几年的分布式系统的兴起,但对于经典的分布式软件来说,大致还是单机软件设计思路的延伸,只是通过 RPC 将多台计算机连接在一起,但是仍然环境是相对确定的,尽管很多软件对于底层的环境变化做了一些适配:例如分布式数据库的动态扩容,数据重均衡 Re-balance 等,但是本质并未变化,只是能够操控和调度的资源变多了。但是在云上,这些假设都发生了变化:
- 多样且几乎无限的资源通过 Service API 的形式提供,对于资源的调度和分配可以通过代码完成,这是革命性的变革。
- 一切资源明码标价,所以程序优化的方向从过去的一维的榨取最好的性能(因为硬件的成本已经事先支付),变成一个动态的问题:尽量花小钱办大事。
- 假设的变化带来的技术上的变化:云上的数据库,首先应该是 多个自治的微服务组成的网络。放弃掉对于同步和单机的幻想
- 最近几年被聊烂的存算分离
- 对于数据库来说,一些内部组件的微服务化,比如:日志(CPU 使用少,但是对于存储要求高),LSM-Tree 存储引擎的 Compaction,数据压缩,元信息服务,连接池,CDC 等等,都是可以且很适合被剥离的对象。
How do you build a database
摘自How do you build a database? ,为防止链接失效,贴上原文。
Its a great question, and deserves a long answer. Most database servers are built in C, and store data using B-tree type constructs. In the old days there was a product called C-Isam (c library for an indexed sequential access method) which is a low level library to help C programmers write data in B-tree format. So you need to know about btrees and understand what these are. BTree 很重要
Most databases store data separate to indexes. Lets assume a record (or row) is 800 bytes long and you write 5 rows of data to a file. If the row contains columns such as first name, last name, address etc. and you want to search for a specific record by last name, you can open the file and sequentially search through each record but this is very slow. Instead you open an index file which just contains the lastname and the position of the record in the data file. Then when you have the position you open the data file, lseek to that position and read the data. Because index data is very small it is much quicker to search through index files. Also as the index files are stored in btrees in it very quick to effectively do a quicksearch (divide and conquer) to find the record you are looking for. 一个表单单数据文件是不够的,需要一/多个索引文件。
So you understand for one “table” you will have a data file with the data and one (or many) index files. The first index file could be for lastname, the next could be to search by SS number etc. When the user defines their query to get some data, they decide which index file to search through. If you can find any info on C-ISAM (there used to be an open source version (or cheap commercial) called D-ISAM) you will understand this concept quite well.
Once you have stored data and have index files, using an ISAM type approach allows you to GET a record based on a value, or PUT a new record. However modern database servers all support SQL, so you need an SQL parser that translates the SQL statement into a sequence of related GETs. SQL may join 2 tables so an optimizer(优化器最初是为了加快join表的速度么?) is also needed to decide which table to read first (normally based on number of rows in each table and indexes available) and how to relate it to the next table. SQL can INSERT data so you need to parse that into PUT statements but it can also combine multiple INSERTS into transactions so you need a transaction manager to control this, and you will need transaction logs to store wip/completed transactions.
It is possible you will need some backup/restore commands to backup your data files and index files and maybe also your transaction log files, and if you really want to go for it you could write some replication tools to read your transaction log and replicate the transactions to a backup database on a different server. Note if you want your client programs (for example an SQL UI like phpmyadmin) to reside on separate machine than your database server you will need to write a connection manager that sends the SQL requests over TCP/IP to your server, then authenticate it using some credentials, parse the request, run your GETS and send back the data to the client. So these database servers can be a lot of work, especially for one person. But you can create simple versions of these tools one at a time. Start with how to store data and indexes, and how to retrieve data using an ISAM type interface. There are books out there - look for older books on mysql and msql, look for anything on google re btrees and isam, look for open source C libraries that already do isam. Get a good understanding on file IO on a linux machine using C. Many commercial databases now dont even use the filesystem for their data files because of cacheing issues - they write directly to raw disk. You want to just write to files initially. I hope this helps a little bit.
概要内容:
- 知道BTree 很重要
- 一个表单单数据文件是不够的,需要一/多个索引文件,数据文件和索引文件分开存储
- 有了数据文件和索引文件,你就可以读写数据了,但你需要SQL parser 将sql 翻译成读写操作,需要optimizer加快join表的速度,需要Transaction manager 管理事务
- 备份儿/恢复数据文件、索引文件、Transaction log文件。如果支持客户端程序的话,还需要一个Connection manager
如何从零构建一个可存储/读取数据的”数据库”?
从零开始深入理解存储引擎 非常经典。
单机实现
我们先看如下这个最简单的”数据引擎”。
#!/bin/bash
db_set() {
echo "$1,$2" >> database
}
db_get() {
grep "^$1," database | sed -e "s/^$1,//" | tail -n 1
}
上面这个”数据引擎”写操作性能足够好,因为只需要数据文件追加写入一条记录即可;但它的读性能较差,因为需要全文件检索 (grep | sed),同一个key若有过多次写操作,在数据文件中会存在多行记录。
引入索引提高读性能。当前的第一个任务就是 提高读性能。我们可以引入单独维护的索引(内存中维护的Hash Map)提升查询性能;因此写入时除了写数据文件,还需要写索引,这会 降低写入的速度 ;这也是存储系统中很重要的权衡设计;到底关注读性能还是写性能,在技术选型的时候需要开发人员决定。添加了内存中的Hash Map来快速定位Key所在的位置,hash value是文件字节偏移量(byte offset);读取时直接从文件指定偏移位置读取到换行符即是Value值。此时可以提供高性能的读写,但需要所有的 Key 可以全部放在内存中供索引即可;写操作仍是一次追加写,读操作只需要一次磁盘寻址即可。引入了内存索引之后,很自然的一个问题就是机器重启,内存索引丢失怎么办? 可以重新遍历文件构建索引,后面再讨论其他更合理的方案。
如何避免磁盘耗尽?文件分段,分段压缩。假定数据文件写满1GB之后就可以关闭,创建新的数据文件供后续的写入,每个 segment 就是一个独立的文件;为实现区间查询和快速文件合并,对上面的日志段文件添加一个要求:Key有序。则该文件就可称之为 有序字符串表(SSTable - sorted string table);SSTable相比上述无序的哈希索引的日志段,有如下优点:
- 合并更高效:多个有序文件可以使用多路归并排序,简单高效; 文件合并过程中会去除相同的键;
- 内存中的hash map不需要保存所有键:得益于键有序,类似二分查找,找到最大的小于目标键的值之后顺序遍历即可; 现在有两个问题需要解决:
- 如何构造出来这个有序的数据文件,因为数据写入时乱序的,总要有个地方对数据进行排序
- 这个数据文件内部是如何存储和检索kv对的,也就是SSTable内部文件结构如何?
持续的数据写入排序不可能在文件中完成,因此我们使用内存来解决这个问题;基于内存的有序数据结构还是很多的,出于简单高效的原则,我们选择跳表作为有序数据的内存实现:数据写入时直接写入到内存中的跳表即可,当跳表数据量达到阈值时(如1GB)就可以持久化写入(dump)到磁盘文件中,因为跳表是有序的,因此生成的文件也就是有序的,符合 SSTable的要求;正在dump的跳表是不能够再接收写入的,但是系统还是要接收来自客户端的写请求,因此还需要一个能够接受写请求的跳表(一个活跃跳表接受写请求,一个不活跃跳表/dumping跳表)。
详解SSTable的文件格式。首先,需要思考一个问题:一对kv如何在文件中存储?比如name:zhengwei,如果在文件中直接拼接编码成namezhengwei, 我们不知道key是name,还是namezheng;若使用特殊字符区分,则kv对中也就不允许存在特殊字符;最合理的办法还是存储key和value的长度;读取指定长度的字节序列作为目标值。key_length,value_length,key,value
,这样的一条记录,我们先称它为Entry。这里有一个小问题就是:key_length和value_length分别用几个字节来存储呢?1字节太少,只能存储256长度的字节序列,若有超长字符串就存不下;若字节太多,如4字节,又存在了很大的空间浪费;可以参照UTF-8变长字节编码的方式来实现,根据前几个比特位是否为0来表示使用几个字节表示字节长。
我们已经有了一条记录,那么这条记录如何组织进SSTable中呢?也为了利用磁盘的页缓存特性,我们将多条记录组织成块(Block)。在字典序上,Entry1 < Entry2 < ... < Entry n
;虽然有序,但是每个Entry的长度是不相等的,所以就不能直接利用数组的下标索引直接进行二分查找;为了实现二分查找,我们在Entry后面附加和每条记录一一对应的的offset数组,数组的每个元素存储的是对应Entry的偏移地址;offset数组只记录对应Entry的偏移量,在offset中实现二分查找,需要查找对应key的时候,回溯到红色箭头所指向的Entry查找即可,类似于间接二分查找。
以上的Block存储的是数据,因此我们称它为DataBlock。将每个DataBlock经过压缩并生成CRC校验码,写入到文件之后我们就能得到每个DataBlock在文件中的偏移量offset和size。同时我们也知道该DataBlock中的 max key;因此,max key 、offset、 size就是该DataBlock的索引信息。随着向DataBlock添加数据达到DataBlock的阈值之后,就将DataBlock写入文件,等所有DataBlock持久化之后,Index Block也完成了构建,Index Block中的每一个Entry索引了一个DataBlock,Key就是DataBlock的最后一个Entry Key,Value就是DataBlock在数据文件中的起始位置和大小。IndexBlock本质上和DataBlock是一致的,无非存储的Value是DataBlock的索引信息,最后将Index Block也追加写入到数据文件中。
汇总一下我们目前的设计: 数据都落盘到了SSTable中,自然就会存在空间放大,而且虽然每个文件是有序的,但是并不能做到全部SSTable的整体有序,在读命令还是需要在所有文件中同时检索,读放大也很明显;每个immutable持久化到磁盘中的SSTable文件是有序且可能存在重复键的,如同一个key: name,可能在 SSTable1、SSTable2或其他SSTable中存在,如下图所示,每个SSTable都可以看作一段时间内写入值的有序集合。我们把从immutable直接生成的SSTable的集合称为Level 0。因此,Level 0中存在严重的磁盘空间放大问题,自然就会想到消除重复,而消除重复的方法就是合并(compaction)。
如上图所示,Level 0层的 SSTable 1 和 SSTable 2合并成Level 1层的SSTable1,Level 1层的SSTable 2同样由上层的SSTable和本层的SSTable合并而成。
到这里
- 如何读取数据: 首先读取memtable,读到则直接返回;读不到则读取immutable,进而读取Level 0 -> Level 1 … 直到每一层的 SSTable都读完;若在其中的一步读到了数据,则不再往下读取,适时终止。
- 如何删除数据:需要删除的数据, Value中存入特殊值,若读取到特定值则返回不存在;在Compaction过程中也会跳过这些有特殊值的键(也称标记删除或“墓碑”)
此时还有一个问题就是:数据初始是写入到:memtable中的,若还没来得及dump到文件中,发生了机器故障,重启之后内存丢失,memtable中写入的值也会丢失。要想保证不丢失数据必须要落盘,为了保证写入性能不受影响,以及磁盘顺序读写性能是最高的,我们可以引入预写日志(WAL-write ahead log)。数据首先顺序追加到预写日志中,待数据落盘落盘之后再写入到memtable中,待memtable中的数据持久化到磁盘时,该memtable对应的预写日志也就可以删除了。
讨论到此,我们已经有了一个单机存储数据的数据库,即使发生重启,数据也不会丢失。实际上这就是一个LSM Tree存储引擎。也是是LevelDB / RocksDB 所采用的方案;在 Cassandra/HBase 中也有该方案的身影;基于合并和压缩排序文件原理的存储引擎通常称为 LSM存储引擎;除了上面提到的基于LSM的存储引擎之外,还有基于B+树的存储引擎,它也几乎是关系数据库的标准实现,3-4层的B+树就可存储大量数据,不需要遍历太深(分支因子为500的4KB页的四级树可存储256TB)。我们来对比一下 B+ Tree 和 LSM-Tree
- B+树适合读多写少,LSM树适合写多读少;LSM树写入的时候只需要一次顺序写WAL日志文件及一次内存写操作即可,成本很小;但是读取却需要多层读取,只有所有的SSTable都不存在键才能返回不存在;B+树写入需要随机写磁盘,极端情况下面对页分裂还会有多次的随机写磁盘;而读取的时候从目标位置返回值即可;在有索引和页缓存的情况下,读性能表现更好;
- B+树至少写两次数据,一次WAL,一次页本身; LSM因为压缩及合并,也会存在写放大;B+树是原地更新数据,读放大较小,写放大较大。LSM树是非原地更新,同一条数据存在多条记录,会存在空间放大;数据读取需要检测多个文件,读放大比较严重,compaction/压缩缓解了读放大和空间放大,但是又引入了写放大;因此有很多技术用来优化写放大,比如 KV分离技术和延迟压缩技术,不再讨论。
- LSM树磁盘空间利用率更高,碎片更少;因为是顺序写,Block构建好之后顺序写磁盘即可。
- LSM压缩过程可能会影响正在进行的读写操作;后台压缩合并操作抢占业务进程对磁盘的读写操作;
- B+树在事务方面表现更好,键只有一处,方便加锁; 我们详细的讨论了LSM 树,LSM 树,并简单对比了B+树,它们是OLAP(online analytic processing)和OLTP中日志结构流派和原地更新流派的代表;我们可以简单认为OLTP服务与在线业务,直接和C端用户交互;在线数据经过ETL之后存储到OLAP中一份用于商业分析或离线特征计算后再反哺到在线业务(比如TDW / 用户画像特征等)将不同业务系统的数据库经过提取之后转换为分析需要的数据结构,加载到OLAP等数据仓库中,供分析师使用;一般情况下供分析师使用的表通常很宽(有几百上千个字段/列,经过聚合多个数据源和业务数据得到),但是每次分析时可能只会使用其中很少的列(比如用户画像表,会有很多字段,但是一次sql可能只是涉及到很少的字段- select max(age) from table where gender = ‘male’);在OLTP数据库中,存储以面向行的方式来布局;为提高查询性能,面向列存储可优化分析场景下的查询性能;列存如下图所示:
分布式
数据复制:经过第一部分的讨论,我们在单容器上得到了一个可高效读写的存储引擎,但机器总会故障,如何保证在机器故障的情况下,服务对外提供的读写能力不受到影响?自然就是数据在多个容器上存储多份,待机器故障后,使用其他机器的数据对外提供服务。那如何保证不同机器上有多份数据,且它们是一致的就成为接下来要解决的问题。
- 主从复制:同步复制与异步复制。复制滞后问题;
- 多主节点复制。多数据中心:在每个数据中心都配置主节点,数据中心内部仍是主从复制,跨数据中心则由主节点负责数据中心间的数据交换和更新。多主复制最大的挑战就是解决写冲突,跨地域的 用户1 和 用户2 同时修改了title,主节点1收到主节点2同步过来的请求时发现是冲突的,必需有一种冲突解决方案决定title最终是改为B还是改为C。你可能想不到,处理冲突最理想的策略就是:避免发生冲突 。 应用层保证对特定记录的写请求总是路由到同一个主节点,就不会发生写冲突。比如我们的服务部署了天津/深圳两个地域,两个地域是多主节点复制,则每一个用户只会路由到天津或者深圳其中一个地域,不会存在写冲突;从用户的角度开看,基本等价于主从复制模型。实现收敛于一致的可能方式:
- 每个写请求分配唯一的ID(时间戳/随机数/UUID),每个副本仅保留最高ID作为胜利者写入,其他写入请求则丢弃;
- 为每个副本分配一个序号,序号大的副本写入优先级高于低序号的副本;
- 将冲突的结果都记录下来,依靠应用层(或用户)来决策。如上例中,将B/C都记录下来,让用户决策最终使用哪个标题;
数据分片:基于关键字区间分片;基于键的哈希值分片;分片再平衡;
- 固定数量的分片:最简单的方案:创建远超实际节点数的分片数量,为每个节点分配多个分片;需要迁移时就从现有机器上挑选分片移动到新机器上即可;
- 动态分片:初始仅创建少量分片,当分片的数据增长超过一定阈值时(如10GB),就会拆分成2个分片,每个分片承担一半的数据;反之,分片也会合并;每个分片只会分配给一个机器,但是一个机器可以承载多个分片数据;
- 按节点比例分区 请求路由:分片数据已经就绪,客户端应该把请求发送到哪个机器上呢?尤其是若发生了分片动态再平衡,分片与节点的关系也会随之变化;这本质上是一个服务发现问题;通常有三种方式:
- 节点转发:客户端连接任意节点,若节点恰好该数据则直接返回,若节点没有数据,则将请求转发到合适的节点,并将结果返回给客户端
- 代理层转发;在客户端和数据库之间增加一个代理层(Proxy), Proxy记录分片和节点机器的映射关系,负责请求的转发和响应;Proxy本身不处理请求,只是一个感知分片的负载均衡器。该方案采用较多,一来客户端不需要有复杂的逻辑,Proxy可屏蔽分片/节点的动态变化;再者,处理类似于Redis中的 MGet 等涉及多个键的命令时,Proxy可以完成分发&合并结果的工作;最后,Proxy还可以处理”迁移中”的数据,如一个分片正在从一台机器迁移到另一台机器,命中该分片的请求该如何处理?
- 客户端缓存分区关系。客户端感知分区和节点的分配关系,客户端可直接联系到目标节点,不需要任何Proxy 分片和节点的映射关系如何维护?在使用代理转发的选择下,需要去存储并感知分片和节点IP的映射关系:一般采用独立的协调服务(zookeeper/ETCD)跟踪集群范围内的元数据变化。节点分片的动态再平衡(可能是人工通过控制节点触发,也可能是自动再平衡)会同步写到 Zookeeper中,Proxy通过watch感知到节点变化之后会将后续请求转发到正确的节点;
经过上面所有的讨论,我们可以得到如下这个相对通用的分布式存储架构: