70 | 备忘录模式：对于大对象的备份和恢复，如何优化内存和时间的消耗？

文章 2020-04-13



00:00

1.0x

讲述：冯永吉大小：7.81M时长：08:31

上两节课，我们学习了访问者模式。在 23 种设计模式中，访问者模式的原理和实现可以说是最难理解的了，特别是它的代码实现。其中，用 Single Dispatch 来模拟 Double Dispatch 的实现思路尤其不好理解。不知道你有没有将它拿下呢？如果还没有弄得很清楚，那就要多看几遍、多自己动脑经琢磨一下。

今天，我们学习另外一种行为型模式，备忘录模式。这个模式理解、掌握起来不难，代码实现比较灵活，应用场景也比较明确和有限，主要是用来防丢失、撤销、恢复等。所以，相对于上两节课，今天的内容学起来相对会比较轻松些。

话不多说，让我们正式开始今天的学习吧！

备忘录模式的原理与实现

备忘录模式，也叫快照（Snapshot）模式，英文翻译是 Memento Design Pattern。在 GoF 的《设计模式》一书中，备忘录模式是这么定义的：

Captures and externalizes an object’s internal state so that it can be restored later, all without violating encapsulation.

翻译成中文就是：在不违背封装原则的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便之后恢复对象为先前的状态。

在我看来，这个模式的定义主要表达了两部分内容。一部分是，存储副本以便后期恢复。这一部分很好理解。另一部分是，要在不违背封装原则的前提下，进行对象的备份和恢复。这部分不太好理解。接下来，我就结合一个例子来解释一下，特别带你搞清楚这两个问题：

为什么存储和恢复副本会违背封装原则？

备忘录模式是如何做到不违背封装原则的？

假设有这样一道面试题，希望你编写一个小程序，可以接收命令行的输入。用户输入文本时，程序将其追加存储在内存文本中；用户输入“:list”，程序在命令行中输出内存文本的内容；用户输入“:undo”，程序会撤销上一次输入的文本，也就是从内存文本中将上次输入的文本删除掉。

我举了个小例子来解释一下这个需求，如下所示：

hello

:list

hello

world

:list

helloworld

:undo

:list

hello

怎么来编程实现呢？你可以打开 IDE 自己先试着编写一下，然后再看我下面的讲解。整体上来讲，这个小程序实现起来并不复杂。我写了一种实现思路，如下所示：

public class InputText {

private StringBuilder text = new StringBuilder();

public String getText() {

return text.toString();

}

public void append(String input) {

text.append(input);

}

public void setText(String text) {

this.text.replace(0, this.text.length(), text);

}

}

public class SnapshotHolder {

private Stack snapshots = new Stack<>();

public InputText popSnapshot() {

return snapshots.pop();

}

public void pushSnapshot(InputText inputText) {

InputText deepClonedInputText = new InputText();
deepClonedInputText.setText(inputText.getText());
snapshots.push(deepClonedInputText);

}

}

public class ApplicationMain {

public static void main(String[] args) {

InputText inputText = new InputText();
SnapshotHolder snapshotsHolder = new SnapshotHolder();
Scanner scanner = new Scanner(System.in);
while (scanner.hasNext()) {
  String input = scanner.next();
  if (input.equals(":list")) {
    System.out.println(inputText.getText());
  } else if (input.equals(":undo")) {
    InputText snapshot = snapshotsHolder.popSnapshot();
    inputText.setText(snapshot.getText());
  } else {
    snapshotsHolder.pushSnapshot(inputText);
    inputText.append(input);
  }
}

}

}

实际上，备忘录模式的实现很灵活，也没有很固定的实现方式，在不同的业务需求、不同编程语言下，代码实现可能都不大一样。上面的代码基本上已经实现了最基本的备忘录的功能。但是，如果我们深究一下的话，还有一些问题要解决，那就是前面定义中提到的第二点：要在不违背封装原则的前提下，进行对象的备份和恢复。而上面的代码并不满足这一点，主要体现在下面两方面：

第一，为了能用快照恢复 InputText 对象，我们在 InputText 类中定义了 setText() 函数，但这个函数有可能会被其他业务使用，所以，暴露不应该暴露的函数违背了封装原则；

第二，快照本身是不可变的，理论上讲，不应该包含任何 set() 等修改内部状态的函数，但在上面的代码实现中，“快照“这个业务模型复用了 InputText 类的定义，而 InputText 类本身有一系列修改内部状态的函数，所以，用 InputText 类来表示快照违背了封装原则。

针对以上问题，我们对代码做两点修改。其一，定义一个独立的类（Snapshot 类）来表示快照，而不是复用 InputText 类。这个类只暴露 get() 方法，没有 set() 等任何修改内部状态的方法。其二，在 InputText 类中，我们把 setText() 方法重命名为 restoreSnapshot() 方法，用意更加明确，只用来恢复对象。

按照这个思路，我们对代码进行重构。重构之后的代码如下所示：

public class InputText {

private StringBuilder text = new StringBuilder();

public String getText() {

return text.toString();

}

public void append(String input) {

text.append(input);

}

public Snapshot createSnapshot() {

return new Snapshot(text.toString());

}

public void restoreSnapshot(Snapshot snapshot) {

this.text.replace(0, this.text.length(), snapshot.getText());

}

}

public class Snapshot {

private String text;

public Snapshot(String text) {

this.text = text;

}

public String getText() {

return this.text;

}

}

public class SnapshotHolder {

private Stack snapshots = new Stack<>();

public Snapshot popSnapshot() {

return snapshots.pop();

}

public void pushSnapshot(Snapshot snapshot) {

snapshots.push(snapshot);

}

}

public class ApplicationMain {

public static void main(String[] args) {

InputText inputText = new InputText();
SnapshotHolder snapshotsHolder = new SnapshotHolder();
Scanner scanner = new Scanner(System.in);
while (scanner.hasNext()) {
  String input = scanner.next();
  if (input.equals(":list")) {
    System.out.println(inputText.toString());
  } else if (input.equals(":undo")) {
    Snapshot snapshot = snapshotsHolder.popSnapshot();
    inputText.restoreSnapshot(snapshot);
  } else {
    snapshotsHolder.pushSnapshot(inputText.createSnapshot());
    inputText.append(input);
  }
}

}

}

实际上，上面的代码实现就是典型的备忘录模式的代码实现，也是很多书籍（包括 GoF 的《设计模式》）中给出的实现方法。

除了备忘录模式，还有一个跟它很类似的概念，“备份”，它在我们平时的开发中更常听到。那备忘录模式跟“备份”有什么区别和联系呢？实际上，这两者的应用场景很类似，都应用在防丢失、恢复、撤销等场景中。它们的区别在于，备忘录模式更侧重于代码的设计和实现，备份更侧重架构设计或产品设计。这个不难理解，这里我就不多说了。

如何优化内存和时间消耗？

前面我们只是简单介绍了备忘录模式的原理和经典实现，现在我们再继续深挖一下。如果要备份的对象数据比较大，备份频率又比较高，那快照占用的内存会比较大，备份和恢复的耗时会比较长。这个问题该如何解决呢？

不同的应用场景下有不同的解决方法。比如，我们前面举的那个例子，应用场景是利用备忘录来实现撤销操作，而且仅仅支持顺序撤销，也就是说，每次操作只能撤销上一次的输入，不能跳过上次输入撤销之前的输入。在具有这样特点的应用场景下，为了节省内存，我们不需要在快照中存储完整的文本，只需要记录少许信息，比如在获取快照当下的文本长度，用这个值结合 InputText 类对象存储的文本来做撤销操作。

我们再举一个例子。假设每当有数据改动，我们都需要生成一个备份，以备之后恢复。如果需要备份的数据很大，这样高频率的备份，不管是对存储（内存或者硬盘）的消耗，还是对时间的消耗，都可能是无法接受的。想要解决这个问题，我们一般会采用“低频率全量备份”和“高频率增量备份”相结合的方法。

全量备份就不用讲了，它跟我们上面的例子类似，就是把所有的数据“拍个快照”保存下来。所谓“增量备份”，指的是记录每次操作或数据变动。

当我们需要恢复到某一时间点的备份的时候，如果这一时间点有做全量备份，我们直接拿来恢复就可以了。如果这一时间点没有对应的全量备份，我们就先找到最近的一次全量备份，然后用它来恢复，之后执行此次全量备份跟这一时间点之间的所有增量备份，也就是对应的操作或者数据变动。这样就能减少全量备份的数量和频率，减少对时间、内存的消耗。

重点回顾

好了，今天的内容到此就讲完了。我们一块来总结回顾一下，你需要重点掌握的内容。

备忘录模式也叫快照模式，具体来说，就是在不违背封装原则的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便之后恢复对象为先前的状态。这个模式的定义表达了两部分内容：一部分是，存储副本以便后期恢复；另一部分是，要在不违背封装原则的前提下，进行对象的备份和恢复。

备忘录模式的应用场景也比较明确和有限，主要是用来防丢失、撤销、恢复等。它跟平时我们常说的“备份”很相似。两者的主要区别在于，备忘录模式更侧重于代码的设计和实现，备份更侧重架构设计或产品设计。

对于大对象的备份来说，备份占用的存储空间会比较大，备份和恢复的耗时会比较长。针对这个问题，不同的业务场景有不同的处理方式。比如，只备份必要的恢复信息，结合最新的数据来恢复；再比如，全量备份和增量备份相结合，低频全量备份，高频增量备份，两者结合来做恢复。

课堂讨论

今天我们讲到，备份在架构或产品设计中比较常见，比如，重启 Chrome 可以选择恢复之前打开的页面，你还能想到其他类似的应用场景吗？

欢迎留言和我分享你的想法。如果有收获，也欢迎你把这篇文章分享给你的朋友。

15人觉得很赞给文章提建议;)

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。

张创琦

Ctrl + Enter 发表

0/2000字

提交留言

精选留言(50)

• 
  DexterPoker
  MySQL数据库低频全量备份，结合binlog增量备份，来恢复数据。
  2020-04-13
  
  __64

• 
  jaryoung
  游戏存档是不是很典型的例子？想当年，玩《勇者斗恶龙》的时候，打不过boss不断回到存档的地方，不断尝试。
  2020-04-13
  _2
  _20

• 
  张晋 🇨🇳
  看了王争老师很多课了，觉得都很好，但是不知道是疲惫了还是这个模式不是很重要，感觉没讲好，后面查看了网上资料才知道
  Originator：发起者，负责创建一个备忘录，并且可以记录、恢复自身的内部状态。可以根据需要决定Memento保存自身的那些内部状态
  Memento：备忘录，用于存储Originator的状态，防止Originator以外的的对象访问Memento
  Caretaker：备忘录管理者，负责存储备忘录，不能对备忘录的内容进行操作和访问，只能够将备忘录传递给其他对象。
  作者：MrTrying
  链接：https://www.jianshu.com/p/78b519d39fe5
  来源：简书
  著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
  可能老师觉得比较基础所以没讲吧，感觉听的云里雾里的。
  2020-07-03
  _2
  _18

• 
  Jackey
  想起了Redis主从同步的增量和全量模式
  2020-04-13
  _1
  _16

• 
  忆水寒
  还有比如word写文章的时候，选择撤销。这也是一种备忘录模式的实现。可以参考这个文章https://mp.weixin.qq.com/s/J5a5ZcNCBBExpyCpU2o3wg
  2020-04-22
  
  __8

• 
  何用
  老师用词太过主观了，灌输访问者模式难理解的潜意识。我倒觉得 Single Dispatch 和 Double Dispatch 容易理解，反倒是今天的备忘模式难理解了。。。
  2020-04-13
  _6
  _8

• 
  Smile @ Life
  redis通过备份的形式进行持久化，分为两种模式
  1、RDS：低频率全量备份
  2、AOF: 高频率增量备份
  而在AOF模式下通过配置auto-aof-rewrite来达到全量备份和增量备份相结合以减小AOF的备份大小
  https://redis.io/topics/persistence
  2020-07-31
  
  __6

• 
  蹦哒
  理一下备忘录模式诞生的过程：
  1.对于备份这个需求，一开始自然的想法是一个备份类（snapshot）里面保存一份数据（inputText）来做备份。inputText原来是用来表示数据的，没有提供setText这样的方法的必要，但是由于需要备份，使得inputText需要提供setText方法以便实现备份需求
  2.为了实现备份需求，提供了setText方法，破坏了inputText原来的封装特性，即：类只需暴露有限的必要访问接口。这本不应该是inputText所应该提供的接口
  3.为了解决破坏封装性问题，备忘录模式里面单独定义了用来备份的数据类（String）。从而备份的需求就不影响原来的inputText的设计了
  4.除了备份还需要恢复，这个需求就不得不改动原来inputText的设计了，因为恢复的目标就是inputText，所以inputText需要提供相关恢复的restore方法
  以上便诞生了备忘录模式：单独用一个新的类保存原来的数据（备份），原来对象提供新接口接收数据恢复（恢复）
  2020-06-27
  
  __5

• 
  Demon.Lee
  System.out.println(inputText.toString()); —-> System.out.println(inputText.getText());
  作者回复: 嗯嗯，多谢！
  2020-04-13
  _2
  _5

• 
  辣么大
  我的电脑重不关机！
  2020-04-25
  _4
  _3