NoSQLVDL:唯品会强一致、高可用、高性能分布式日志存储介绍(产品篇)

“You can’t fully understand databases, NoSQL stores, key value stores,
replication, paxos, hadoop, version control, or almost any software
system without understanding logs。”

–《The Log: What every software engineer should know about real-time
data’s unifying abstraction》

VDL是VIP Distributed
Log的缩写,是唯品会自研的基于Raft协议的新一代分布式Log存储系统。这里的Log不是指glog或者log4j等日志库记录的应用程序日志,可以简简单单地把Log了然成广义的Data,和Database中的Data本质上是同一的,无非是VDL存储的Data数据Schema-less的,业务和用户可以灵活自解析,而Database中的Data平常和一直或直接和Schema相关。

 

VDL介绍序列分两篇随笔对VDL举行介绍,包括:

– 产品篇: 介绍VDL暴发的背景、当前产品形象和特色、后续演进思路等;
– 实现篇和质地管控篇: 实现重点分析VDL的技术实现细节与高性能手段,和豪门享受大家受到的挑衅和踩过的坑。质料管控则介绍VDL怎么着保证产品质料,紧要不外乎分布式系统怎么样测试,怎样举行分外和错误注入,以及分布式系统中逐条节点间的数额一致性如何注脚等。

 

本篇是成品篇,会透过分布式系统的本质,讲解VDL的暴发背景和产品稳定。通过这篇著作,希望有更两人领会VDL,也目的在于为工作系统带来方便并发生价值。

 VDL的出品稳定

NoSQL 1

在论述VDL的制品一定在此之前,我们先考虑一个题目:用户对一个Storage
System的诉求是怎样?以及Client的诉求被正确地领略并满意了啊?如下图所示,大多数用户对一个囤积系统的诉求,可以省略地包括为两点:

 

-存储系统依据用户写入的顺序存储数据;

-用户总是能从存储系统查询到新型的写入(结果)。

NoSQL 2

在最初的单机系统或者遵照IOE的系统,这种诉求看起来无可厚非,而且也正如便于被满足,例如一个单机的MySQL数据库,由于其本人具有RDBMS系统的ACID属性,配置得当的话,这样的诉求大多数情状下都是可以满足的。

 

再重返大家公司最近的现状(也是大部分互联网集团的现状),Scale
Up已经无力回天解决工作扩大的需要,不知不觉中,大家的连串现已Scale
Out到一个本色上的分布式系统,存储系统也是如此。

NoSQL 3

诸如此类的话,对于同一的用户诉求,现在的仓储系统需要满足的束缚原则发出了很大的转变:

 

-要求一律次写入,要在六个节点上不变地、遵照用户发起的相继写入;

-要求五个节点组成的贮存集群,总是可以查询重临最新的写入结果。

 

这六个约束的面目就是Linearizability
Consistency(https://en.wikipedia.org/wiki/Linearizability)。通俗地说,用户总是站在甲方的姿态,他不关心存储系统的后端如何实现,他要求一个分布式集群的行为,还是要满足单机系统的提供给他的承诺。

 

在一个分布式系统中,因为大家处于异步通讯的条件中,所以要满意这六个条件实在是异常费力的。万变不离其宗的就是分布式系统中的一致性,五个节点要就“五遍呼吁的全局写入顺序编号达成一致”和“哪个节点上所有新型的写入结果”等关键问题达成一致。仅仅是一致性达成这点,从Paxos、Viewstamp
Replication、ZAB到Raft等,要旨都是化解那么些题材,从理论到工程实践更是经历了一个旷日持久的长河。其实难题还不仅如此,即使我们就某一回写入的大局序号达成了一如既往,从而保证了富有的用户写入请求是一个大局有序的队列,但某一个写入请求在不同的节点上实施,也不自然会发出相同的结果:比如一回写入中凭借地方hostname、本地timestamp等等。所以我们这边商量的前提是Log是Deterministic的,对于non-deterministic的Log,一般都是经过中间一个Node执行拍卖,将以此non-deterministic转化成一个Deterministic的Phyciological
Log。

 

回眸,假设一个囤积系统不可以提供给用户这样的答应,这用户程序的逻辑势必异常复杂而且脆弱。用户可能面对的题目,比例:已经查询到某个数据的V3版本,当用户程序和仓储系统里头网络中断又重连后,只好读取到V2版本(V3版本所在的节点宕机,切换来一个数目尚未同台的节点下面)。卓殊长的一段时间内,MySQL数据库主从间的异步复制就可能存在那么些题目,只是只要用户程序没有同时Crash切换,大家平日可以在用户程序本地缓存一些数量操作的水流,遭遇这种情形开展补偿论理。

 

最终,回到核心即VDL的出品稳定,VDL的靶子是将那个扑朔迷离的题材尽可能地实现在VDL分布式存储集群的中间。给用户程序尽量简洁明了的语义承诺:线性一致性,那样用户总是能够像过去单机服务器时代一样自由(实际上,为了在不同的场景给用户更多选用,VDL可以提供此外一个一致性模型:严厉按照约束原则1,如若用户能够忍受读取到非最新写入的结果,放松约束规范2,也就是平凡讲的“时序一致性”)。可想而知,VDL的产品定位是所有如下条件的通用分布式存储系统:

 

强一致,提供线性一致性和时序一致性;

高吞吐,在合理牺牲RT的情状下,有效保证系统全体的吞吐量;

低延时,抛开实际部署拓扑中节点间物理距离引起的RTT开销,通过技术手段最大限度地回落单请求的端到端延时;

持久化,Ack给用户从前,一定已经在多数派节点上落盘,制止用户遭遇“回档”;

可控性,这多少个系统从筹划到落实到代码细节,大家要统统HOLD住,无法像拿一个重型开源软件随便用用,遇到严重问题就抓瞎。

 

介绍完VDL的产品稳定,先从我们权衡的角度来看望VDL和主流开开源产品间的定势差别,为啥不按照开源产品做二次开发?其实这些题目也相比较简单,对于一个特大型开源项目,例如MySQL/Kafka/Zookeeper/卡Sandra(Cassandra)等,从深切利益来看,其实要统统了解它们和起来开发一个同类产品,投入产出比一对一。

VDL和Kafka的联络和区别

NoSQL 4Kafka是一个老大干练的信息系统,除了拥有传统信息系统的Message
Queue和Message
Sub/Pub能力之外,还具备一些别样相比较出色的表征,例如:数据分区、灵活可控的副本策略等等。Kafka典型气象(https://kafka.apache.org/uses)包含:

 

-Traditional Message Broker
传统的Message Queue 和Message Sub/Pub功能

-Stream Processing – Staged Pipeline
和其余产品类似,比如Storm,就是可以让Message可以在多少个Stage间流转,每一个Stage的拍卖逻辑可能不平等,可是Stage之间的输入/输出接口是联合的

-Commit Log
作为Commit
Log来采纳,这或多或少和VDL的目标场景之一是一模一样的。不过为啥大家并没有拔取Kafka来作为Commit
Log场景的选型呢?重要原因有五个,第一是LinkedIn公司温馨的开发espresso(https://www.percona.com/live/data-performance-conference-2016/sessions/espresso-linkedins-distributed-document-store-top-mysql)数据库,就采用Kafka作为Commit
Log来举办espresso数据库主从之间的复制。在汤姆 Quiggle二零一八年演说《espresso
database replication with
kafka》中多少来看,平均复制延迟为小于90ms,大家觉得这么些延迟太大了,不能满足我们对数据库复制高性能、低延时的要求。第二,Kafka的数据复制协议,尽管总体上参照了微软PacificA杂文作为辩护基础,但是相比PacificA杂谈说的同样,这是一个复制框架、一个原型系统,Kafka具体的贯彻其实差异依然很大。更紧要的是,从二零一二年Kafka复制协议的V1版本起首,直到二零一七年KIP-101(https://cwiki.apache.org/confluence/display/KAFKA/KIP-101+-+Alter+Replication+Protocol+to+use+Leader+Epoch+rather+than+High+Watermark+for+Truncation,最新Kafka
0.11.*本子),一直存在着比较严重的数额丢失的或是。即使这些复制协议变得尤为像Raft协议,可是平昔缺乏严刻的辩解推导讲明。第三,Kafka要用做一个保险的Commit
Log,需要的布置较为复杂,同时在这么些严俊的配置下,性能较差。具体可以参照:Jiangjie
(Becket) Qin 的演讲《Data Loss and Data Duplication in Kafka》。

-Others
Metric和采用调用链、Log聚合等。

 

换一个角度来看,除了Apache
Kafka官方的独占鳌头气象介绍,我们看看一个消息系统,其实提供给用户的合并抽象能够领略成这么:

NoSQL 5

也就是说,音讯系统是储存系统的一个空洞封装,而VDL其实定位就是音讯系统的一个囤积引擎。音讯系统于用户而言,一个通用抽象模型是:

NoSQL 6

为此,信息系统是Log存储之上的一个更高层级的空洞,对于事情序列,可以挑选使用信息系统、也可以选取直接利用Log存储系统。紧要借助工作特色,两者是相互补充的,共同构成公司数量处理的技术栈。

VDL和etcd/Zookepper/Consul的联系\区别

NoSQL 7etcd的永恒是一个分布式的强一致K/V存储系统,所以实际上etcd可以算是在VDL之上的一个更细分的积存形态。VDL的本色类似于etcd中的Write
Ahead Log。etcd其实也是一种基于Replicated State
Machine(前边大家会讲,这也是VDL使用情形之一)方法的分布式系统,不同在于VDL保证的边际是用户提交请求的大局有序,且持久化到集群中的各样副本上,之后State
Machine怎么着replay这么些Log可以遵照具体情状而定。比如K/V系统,假诺不考虑六个Key之间的业务关系关系,其实不比Key对应的写入请求可以并行replay到State
Machine(Parallel
RSM方向也有众多新收获,但落地的难度如故很大)。把Log一致性和State
Machine的贯彻完全解耦开来,为促成State
Machine的出现回看等,打下了巩固的基础,而且一个一致性的Log
Stream,可以对应四个State Machine实现。

 

etcd提议的应用情形包含(https://coreos.com/etcd/docs/latest/learning/why.html):

-Metadata存储,当然也得以储存一些布局信息;

-Distributed Coordination,这些和Zookeeper和Consul的常用场景类似。

 

此外,etcd/Zookeeper/consul可以当作全局上,就是一个独自的一致性协议实例。而VDL一个LogStream就是一个Raft
Group,我们因此在Raft
Group级另外调度和分红,达到更好的资源利用和负载均衡效果。

VDL的选用场景

NoSQL 8 我们着想中,VDL的优异使用意况如下: 

-RSM(Replicated State Machine)

NoSQL 9

-Database replication
时下,其实主流的数据库复制都是按照Log
Ship的办法,无论一个分布式系统拔取哪一种多少复制模式,其实基本的都是要确保Log在相同全局序号包含的情节一致,同时设有四个副本。Log可以是影响主库状态变化的Log(原始请求被主库处理后的出口),也可以是一贯的用户写入请求,只是后者平日需要有一手保证这么些Log是deterministic,也就是不会因为replay这多少个Log的节点不同,相同输入的Log发生了不同的结果输出。

NoSQL 10

 

-Storage Engine of Other Distributed System
正如前方提到的一律,如果大家要支付一个分布式强一致的K/V存储系统,那么使用LevelDB或者RocksDB作为本地的状态机就可以了。假使我们兑现一个分布式强一致的Cache存储系统,那么我们可以使用Redis或者Memcached作为本土的状态机。当然,实际贯彻的长河中,State
Machine的Snapshot如何兑现,也有些一定的复杂度,不过不管咋样这么些抽象分层已经很好第把这一个复杂度局限在了一个片段。

比如Apache Pulsar(http://pulsar.apache.org/),其实就是采用Apache
Bookkeeper作为其后端存储系统,Pulsar负责对音信语义举办抽象和元数据的管制等。VDL在这地点的拔取,基本考虑就是一种Pluggable
Store
Engine的思索。这在诸多重型仓储系统中,已经是一个为主的架构形态。 

-Unified Shared Log Abstraction

对店家来说,能否拔取好数据对自身的立即运行异常重要,而利用数据就事关到“数据的移位”和“数据的测算”。VDL的一个初衷就是去解决“数据移动”的问题,高效且容错地将Schema-less的数目共享在此外业务系统面前。同时,统一的共享Log服务,已经正在被不少特大型互联网集团采取和重视。比如,非死不可的LogDevice,腾讯的PaxosStore,Twitter的Distributed
Log等,都呈现出不同档次地对联合Schema-less
Log存储的推崇。Google平素对强一致高可用的贮存系统分外重视,GoogleResearch有一篇作品《Ubiq- A Scalable and Fault-tolerant Log Processing
Infrastructure》,大致讲到了不怎么接近的思路。

 

此外,无论基于传统音信系统的工作架构体系,仍旧如今提得相比多的Streaming
Platform(https://www.streaml.io/)体系,都非常依赖统一的Log存储系统。streamlio依赖Apache
Bookkeeper作为分布式Log存储系统。

 VDL的衍生产品

NoSQL 11

对唯品会来说,基于VDL衍生的第一个产品是Binlog
Server,这么些样子综合了RSM和Unified Log Abstraction二种现象。

 

NoSQL 12

这周将发表VDL的实现及质料管控介绍,敬请关注。

 

引进阅读

 

 

 

NoSQL 13

【唯实践】Memcached使用这么些事

 

网站地图xml地图