从数据库和分布式系统浅谈日志那些事

- 日理万妓 2023-02-14 15:54 28阅读 0赞

## 一.什么是日志？ ##

日志可能是最简单的存储抽象。它是按时间排序的仅附加的，完全排序的记录序列。看起来像这样：  
![在这里插入图片描述][20200603202214562.png]  
记录被追加到日志的末尾，并且读取从左到右进行。每个条目均分配有唯一的顺序日志条目号。

记录的顺序定义了“时间”的概念，因为左边的条目定义为比右边的条目更早。日志条目号可以视为条目的“时间戳记”。首先，将这种顺序描述为时间概念似乎有些奇怪，但是它具有方便的特性，即它可以与任何特定的物理时钟分离。当我们进入分布式系统时，此属性将变得至关重要。

记录的内容和格式对于此讨论而言并不重要。另外，我们不能只是继续向日志中添加记录，因为我们最终将用完空间。我会再回到这一点。

因此，日志与文件或表并没有什么不同。文件是字节数组，表是记录数组，日志实际上只是一种表或文件，其中记录按时间排序。

在这一点上，您可能想知道为什么值得谈论这么简单的事情？追加记录序列与数据系统有什么关系？答案是日志有特定的用途：它们记录发生的情况和时间。对于分布式数据系统，从很多方面来说，这是问题的核心。

但是，在我们走得太远之前，让我澄清一下令人困惑的事情。每个程序员都熟悉日志的另一种定义-应用程序可能使用syslog或log4j将非结构化的错误消息或跟踪信息写到本地文件中。为了清楚起见，我将其称为“应用程序日志记录”。应用程序日志是我正在描述的日志概念的退化形式。最大的区别是文本日志主要供人类阅读，而我描述的“日志”或“数据日志”是为程序访问而构建的。

（实际上，如果您考虑一下，人类在单台计算机上读取日志的想法是不合时宜的。当涉及到许多服务和服务器时，这种方法很快就变成了难以管理的策略，并且日志的目的很快就成为了输入的目的。查询和图形来了解许多机器上的行为-文件中的英文文本与此处描述的那种结构化日志不太相像。）

## 二.数据库 ##

我不知道日志概念起源于何处-可能是二进制搜索之类的事情之一，它对于发明人来说太简单了，无法意识到它是一项发明。它早在IBM的System R中就已存在。数据库的使用与出现崩溃时保持各种数据结构和索引的同步有关。为了使这种原子性和持久性，数据库在将更改应用到它维护的所有各种数据结构之前，使用日志写出有关它们将要修改的记录的信息。日志是发生的情况的记录，每个表或索引都是该历史记录到一些有用的数据结构或索引中的投影。由于日志会立即保留，因此在发生崩溃时，该日志将用作还原所有其他持久性结构的权威来源。

随着时间的流逝，日志的使用从ACID的实现细节发展为在数据库之间复制数据的方法。事实证明，数据库上发生的更改顺序正是保持远程副本数据库同步所需的。Oracle，MySQL和PostgreSQL包含日志传送协议，以将部分日志传输到充当从属的副本数据库。Oracle已将日志作为非Oracle数据订阅者的XStreams和GoldenGate的通用数据订阅机制的产品，并且MySQL和PostgreSQL中的类似功能是许多数据体系结构的关键组件。

由于这个原因，机器可读日志的概念在很大程度上局限于数据库内部。使用日志作为数据订阅机制似乎几乎是偶然的。但是，这种非常抽象的方法非常适合支持各种消息传递，数据流和实时数据处理。

## 三.分布式系统 ##

日志解决的两个问题（排序更改和分发数据）在分布式数据系统中更为重要。这些系统的核心设计问题包括同意更新顺序（或同意不同意并应对其副作用）。

以日志为中心的分布式系统方法源自一个简单的观察，我将其称为状态机复制原理：

如果两个相同的确定性过程以相同的状态开始并以相同的顺序获得相同的输入，则它们将产生相同的输出并以相同的状态结束。  
这似乎有点钝，所以让我们深入了解它的含义。

确定性意味着该处理与时序无关，并且不让任何其他“带外”输入影响其结果。例如，通常将其输出受线程执行的特定顺序或受调用gettimeofday或某些其他不可重复的东西影响的程序通常认为是不确定的。

进程的状态是在处理结束时计算机上保留在内存或磁盘中的任何数据。

关于以相同顺序获得相同输入的一点应该响起—这就是日志的来源。这是一个非常直观的概念：如果您将两个确定性代码段输入相同的输入日志，它们将产生相同的输出。

分布式计算的应用非常明显。您可以减少使多台计算机都执行相同操作的问题，而可以减少实现分布式一致日志以馈送这些进程输入的问题。此处日志的目的是从输入流中挤出所有不确定性，以确保处理此输入的每个副本保持同步。

当您理解它时，这个原理并没有什么复杂或深奥的：它或多或少等于说“确定性处理是确定性的”。尽管如此，我认为它是用于分布式系统设计的更通用的工具之一。

这种方法的优点之一是，索引日志的时间戳现在充当副本状态的时钟-您可以用单个数字描述每个副本，即已处理的最大日志条目的时间戳。此时间戳与日志结合使用，可以唯一地捕获副本的整个状态。

有多种方法可以根据日志中的内容在系统中应用此原理。例如，我们可以将传入的请求记录到服务，或者服务响应于请求的状态更改，或者执行的转换命令。从理论上讲，我们甚至可以记录一系列机器指令，以便每个副本执行或在每个副本上调用方法名称和参数。只要两个进程以相同的方式处理这些输入，这些进程将在副本之间保持一致。

不同的人群似乎对日志的使用有不同的描述。数据库人员通常区分物理日志记录和逻辑日志记录。物理日志记录意味着记录更改的每一行的内容。逻辑日志记录意味着不记录更改的行，而是记录导致行更改的SQL命令（insert，update和delete语句）。

分布式系统文献通常区分两种主要的处理和复制方法。“状态机模型”通常是指主动-主动模型，其中我们记录传入请求的日志，每个副本处理每个请求。对此的略微修改（称为“主备份模型”）是选择一个副本作为领导者，并允许该领导者按请求到达的顺序处理请求，并从处理请求中注销对其状态的更改。应用其他副本的顺序是领导者进行状态更改的顺序，以便它们可以同步并准备在领导者失败时接任领导者的角色。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI3NjAwNzIz_size_16_color_FFFFFF_t_70]  
要了解这两种方法之间的区别，让我们看一个玩具问题。考虑一个复制的“算术服务”，该算术服务将一个数字作为其状态（初始化为零）并将该值加法和乘法。主动-主动方法可能注销要应用的转换，例如“ +1”，“ \* 2”等。每个副本都将应用这些转换，因此要经过相同的一组值。“主动-被动”方法将使单个主机执行转换并注销结果，例如“ 1”，“ 3”，“ 6”等。该示例还清楚说明了为什么排序对于确保两者之间的一致性至关重要。副本：对加法和乘法进行重新排序将产生不同的结果。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI3NjAwNzIz_size_16_color_FFFFFF_t_70 1]  
分布式日志可以看作是建模共识问题的数据结构。毕竟，日志代表对要附加的“下一个”值的一系列决策。您必须斜视一下才能看到Paxos系列算法中的日志，尽管日志构建是它们最常见的实际应用。对于Paxos，这通常使用称为“ multi-paxos”的协议扩展来完成，该协议将日志建模为一系列共识问题，每个问题对应一个日志。该日志在其他协议（例如ZAB ，RAFT和Viewstamped Replication）中更为突出，它们直接对维护分布式一致日志的问题进行建模。

我的怀疑是，我们对此的看法在一定程度上偏离了历史的轨迹，这也许是由于几十年来分布式计算的理论超过了其实际应用。实际上，共识问题有点太简单了。计算机系统很少需要确定单个值，它们几乎总是处理一系列请求。因此，日志而不是简单的单值寄存器是更自然的抽象。

此外，对算法的关注掩盖了底层日志抽象系统的需求。我怀疑我们最终将把日志作为商品化的构建基块而不管其实现如何，就像我们经常谈论哈希表一样，而不必费心弄清楚我们是指线性探测还是杂项哈希的细节其他变体。日志将变成商品化的界面，许多算法和实现会相互竞争以提供最佳的保证和最佳的性能。

[20200603202214562.png]: https://img-blog.csdnimg.cn/20200603202214562.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI3NjAwNzIz_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200604091743316.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI3NjAwNzIz,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI3NjAwNzIz_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200604091806502.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI3NjAwNzIz,size_16,color_FFFFFF,t_70