Log：被BigData遗忘的奠基者

Log是关系数据库对计算机行业的巨大年夜供献。在大年夜数据时代，Log更是基本技巧之一。然而在大年夜家热烈评论辩论GFS, NoSQL，甚至Paxos， LSM tree等词语的时刻，Log这个基本技巧以及它对大年夜数据行业的巨大年夜供献却一向以来都被业界所忽视。除了Kafka作者之一Jay Kreps2013年一篇非有名的文┞仿以外，我几乎不克不及发明太多评论辩论Log的。不论这种忽视有意无意，都让我认为有须要写一篇文┞仿。本文结合了Jay的文┞仿的不雅点和本人在这个范畴的实践经验，旨在对我们司空见惯的Log在大年夜数据体系琅绫擎的巨大年夜感化做一个推广和普及。

当我们说Log的时刻，平日在指两种不合器械，其一是应用法度榜样的调试信息，平日词攀类log是人浏览的，情势也不固定，有时刻须要像Splunk如许的对象来协助。别的一种则是我们今天要讲的log，由关系数据库范畴创造出来，最开端的目标是为了做故障恢复。这种log教科书上有Undo Log， Redo Log 或者Undo/Redo Log三种。然则实践来说，Redo Log是最常用的，也是今天我们要谈论的。所以大年夜这里往下，整篇文┞仿我们评论辩论的是关系数据库琅绫擎的Redo Log。有关这个的定义我会鄙人面一节展开。

要懂得Log，我们可以把它看做一个数据构造，类似于Hash Table或者Stack。至于这个数据构造怎么实现，本文不做具体评论辩论，也不影响懂得本文的内容。

Log这个数据构造的根本情势是一个记录的的序列。每个记录分为两部分：一个时光戳，和记录的内容。Log请求时光戳是严格递增的。也就是说下一笔记录老是比上一笔记录的时光戳要大年夜。时光序列不必定是机械时光，任何严格递增的序列，都是可以的。

对于Log的操作有两种，第一种是在序列的末尾加一条新的记录，第二是次序浏览这个记录序列。Log琅绫擎的所有记录一旦写入今后就是只读的了。

在Log的记录里，每笔记录可以存放的内容平日有两种情势，一种是记录要对数据库的表做什么样的操作，一种是记录数据库的表经由操作今后值产生了什么改变。我们经由过程一个例子来展示这两种方法的不合。

假设一个数据库表琅绫擎存的是用户和他存的钱的金额，而所有的晃荡仅仅限于存钱和花钱。我们假设张三的初始存款是500块。那么第一种log的方法看起来像如许：

1 张三 + 100

2 张三 - 200

4 张三 + 100

而第二种方法则看起来像如许：

1 张三 800

2 张三 600

4 张三 650

两种方法的差别在于第二种记录了钱变更后的结不雅，而不记录是什么样的操作导致了钱的变更。第一种则记录了实际的操作。

作为一个Log，我们平日还会有对应操作的对象，在关系数据库琅绫擎，平日这个是表或者数据库。而在NoSQL琅绫擎则是Key和Value。我们可以说，对应操作的对象存的是对象的当缁ご态，而Log琅绫擎则记录了大年夜初始状况到当缁ご态的所有变更。所以作为Log的第一个感化，就是当体系产生故障今后，对体系进行恢复。

作为体系恢复的Log，第一种方法和第二种方法的记录有着本质的不合。当我们应用第二种方法的时刻，我们没有任何须要担心的，独一的一点，我们也同样损掉了是什么原因导致了数值的改变。这种损掉对于一个机械浏览的Log是无所谓的。而第一种方法就不一样了，我们必须假设所有的操作在给定初始状况和操作今后，返回的结不雅是肯定的。一些操作比如撒谎取当前体系时光，或者取一个随机数如许的器械，是不合法的操作，不然Log作为恢复数据的感化也就不存在了。是以实践来说，应用第二种方法记录数据改变的Log居多。然则在分布式体系琅绫擎，应用第一种方法来记录也并非不存在。

Log作为恢复手段，在分布式体系和大年夜数据体系中无处不在。比如说袈溱BigTable里，对Memory Table进行更新之前，就要先写Log。

举个例子，有名Spanner中国盗窟弱化版TiDB就是如许一个New SQL,用的是MySQL的dialect。这个体系出来须要用户用的时刻，有一个问题就比较麻烦了。怎么样可以或许大年夜MySQL琅绫擎把数据倒出来然后塞进本身琅绫擎去。TiDB的人有很强的工程才能和思维才能。他们的解决办法就是把本身装成是一个MySQL的Slave，然后就经由过程MySQL的同步机制经由过程BinLog来同步了。BinLog固然说格局上更复杂一些，然则本质上来说就是一个Redo Log。

Log的重要特点：如不雅知道初始状况和Log，就可以恢复出时代随便率性一?状况。

这个特点让Log在故障恢复以外的范畴很快就找到了用武之地。在分布式数据库琅绫擎，不管是高大年夜上的Oracle照样白菜化的MySQL，在不合的备份之间进行同步，其根本的思路就是一方把Log传给别的一方。别的一方只要老诚实实的按照次序履行Log上的操作。根据我们讲过的Log的重要特点，我们知道最终的状况也必定是一致的。

当我们进入到大年夜数据时代今后，这种传统的分布式数据库的同步方法就被代替了。无论是Chubby照样BigTable照样Spanner，有一个异常有名的刺眼的名词Paxos就如许仁慈登场了。

简单来讲不管是Paxos照样Raft，都是一种可以容忍必定程度的failure的分布式一致协定。题外话插一句，这些协定纸面上看起来都简单，然则在临盆实践琅绫擎要有一个实用的实现，却不是一件轻易的工作。平日来说，也只有大年夜公司在吃亏无数次今后才能逐渐形成一个可用的版本。然则实用分布式一致性协定去代替传统的Log备份是大年夜势所趋。譬如说Chubby的第一代体系应当是基于Oracle数据库实现的，而后面就很快切换到了基于Paxos的实现。

然而最重要的一点是，比如说Paxos协定，它所谓的分布式一致性，其实是指对某个递增序列琅绫擎的某个数字杀青一致。可是我们知道在实践琅绫擎，任何体系对于某个数字杀青一致是没有意义的。

实际的做法是如许的，对于杀青一致的┞封个数字，我们可以认为是Log琅绫擎的某个时光戳，而大年夜家同步的过程也就是按照Log的记录次序履行到当前的时光戳。所以固然说我们换用了分布式一致协定，其底下每个投票的介入者依然是须要经由过程Log来维系状况的一致性。

1/2 1 2 下一页尾页

关于spring redis框架的应用，网上的例子很多很多。然则在本身比来一段时光的应用中，发明这些教程都是入门教程，包含很多的应用办法，与spring redis丰富的api大年夜相径庭，真是浪费了>>>详细阅读

本文标题：Log：被BigData遗忘的奠基者

地址：http://www.17bianji.com/lsqh/35092.html

1/2 1