Systemd 应用

搬运自：Systemd 入门教程：命令篇、Systemd 入门教程：实战篇

Systemd 是 Linux 系统工具，用来启动守护进程，已成为大多数发行版的标准配置。

本文介绍它的基本用法，分为上下两篇。今天介绍它的主要命令，下一篇介绍如何用于实战。

由来

历史上，Linux 的启动一直采用init进程。

下面的命令用来启动服务。

1
2
3

$ sudo /etc/init.d/apache2 start
# 或者
$ service apache2 start

这种方法有两个缺点。

一是启动时间长。init进程是串行启动，只有前一个进程启动完，才会启动下一个进程。

二是启动脚本复杂。init进程只是执行启动脚本，不管其他事情。脚本需要自己处理各种
情况，这往往使得脚本变得很长。

Systemd 概述

Systemd 就是为了解决这些问题而诞生的。它的设计目标是，为系统的启动和管理提供一套
完整的解决方案。

根据 Linux 惯例，字母d是守护进程（daemon）的缩写。 Systemd 这个名字的含义，就
是它要守护整个系统。

使用了 Systemd，就不需要再用init了。Systemd 取代了initd，成为系统的第一个进
程（PID 等于 1），其他进程都是它的子进程。

1

$ systemctl --version

上面的命令查看 Systemd 的版本。

Systemd 的优点是功能强大，使用方便，缺点是体系庞大，非常复杂。事实上，现在还有很
多人反对使用 Systemd，理由就是它过于复杂，与操作系统的其他部分强耦合，违反”keep
simple, keep stupid”
的Unix 哲学。

（上图为 Systemd 架构图）

系统管理

Systemd 并不是一个命令，而是一组命令，涉及到系统管理的方方面面。

systemctl

systemctl是 Systemd 的主命令，用于管理系统。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 重启系统
$ sudo systemctl reboot

# 关闭系统，切断电源
$ sudo systemctl poweroff

# CPU停止工作
$ sudo systemctl halt

# 暂停系统
$ sudo systemctl suspend

# 让系统进入冬眠状态
$ sudo systemctl hibernate

# 让系统进入交互式休眠状态
$ sudo systemctl hybrid-sleep

# 启动进入救援状态（单用户状态）
$ sudo systemctl rescue

systemd-analyze

systemd-analyze命令用于查看启动耗时。

1
2
3
4
5
6
7
8
9
10
11

# 查看启动耗时
$ systemd-analyze

# 查看每个服务的启动耗时
$ systemd-analyze blame

# 显示瀑布状的启动过程流
$ systemd-analyze critical-chain

# 显示指定服务的启动流
$ systemd-analyze critical-chain atd.service

hostnamectl

hostnamectl命令用于查看当前主机的信息。

1
2
3
4
5

# 显示当前主机的信息
$ hostnamectl

# 设置主机名。
$ sudo hostnamectl set-hostname rhel7

localectl

localectl命令用于查看本地化设置。

1
2
3
4
5
6

# 查看本地化设置
$ localectl

# 设置本地化参数。
$ sudo localectl set-locale LANG=en_GB.utf8
$ sudo localectl set-keymap en_GB

timedatectl

timedatectl命令用于查看当前时区设置。

1
2
3
4
5
6
7
8
9
10

# 查看当前时区设置
$ timedatectl

# 显示所有可用的时区
$ timedatectl list-timezones

# 设置当前时区
$ sudo timedatectl set-timezone America/New_York
$ sudo timedatectl set-time YYYY-MM-DD
$ sudo timedatectl set-time HH:MM:SS

loginctl

loginctl命令用于查看当前登录的用户。

1
2
3
4
5
6
7
8

# 列出当前session
$ loginctl list-sessions

# 列出当前登录用户
$ loginctl list-users

# 列出显示指定用户的信息
$ loginctl show-user ruanyf

Unit

含义

Systemd 可以管理所有系统资源。不同的资源统称为 Unit（单位）。

Unit 一共分成 12 种。

• Service unit：系统服务
• Target unit：多个 Unit 构成的一个组
• Device Unit：硬件设备
• Mount Unit：文件系统的挂载点
• Automount Unit：自动挂载点
• Path Unit：文件或路径
• Scope Unit：不是由 Systemd 启动的外部进程
• Slice Unit：进程组
• Snapshot Unit：Systemd 快照，可以切回某个快照
• Socket Unit：进程间通信的 socket
• Swap Unit：swap 文件
• Timer Unit：定时器

systemctl list-units命令可以查看当前系统的所有 Unit 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 列出正在运行的 Unit
$ systemctl list-units

# 列出所有Unit，包括没有找到配置文件的或者启动失败的
$ systemctl list-units --all

# 列出所有没有运行的 Unit
$ systemctl list-units --all --state=inactive

# 列出所有加载失败的 Unit
$ systemctl list-units --failed

# 列出所有正在运行的、类型为 service 的 Unit
$ systemctl list-units --type=service

Unit 的状态

systemctl status命令用于查看系统状态和单个 Unit 的状态。

1
2
3
4
5
6
7
8

# 显示系统状态
$ systemctl status

# 显示单个 Unit 的状态
$ sysystemctl status bluetooth.service

# 显示远程主机的某个 Unit 的状态
$ systemctl -H root@rhel7.example.com status httpd.service

除了status命令，systemctl还提供了三个查询状态的简单方法，主要供脚本内部的判
断语句使用。

1
2
3
4
5
6
7
8

# 显示某个 Unit 是否正在运行
$ systemctl is-active application.service

# 显示某个 Unit 是否处于启动失败状态
$ systemctl is-failed application.service

# 显示某个 Unit 服务是否建立了启动链接
$ systemctl is-enabled application.service

Unit 管理

对于用户来说，最常用的是下面这些命令，用于启动和停止 Unit（主要是 service）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 立即启动一个服务
$ sudo systemctl start apache.service

# 立即停止一个服务
$ sudo systemctl stop apache.service

# 重启一个服务
$ sudo systemctl restart apache.service

# 杀死一个服务的所有子进程
$ sudo systemctl kill apache.service

# 重新加载一个服务的配置文件
$ sudo systemctl reload apache.service

# 重载所有修改过的配置文件
$ sudo systemctl daemon-reload

# 显示某个 Unit 的所有底层参数
$ systemctl show httpd.service

# 显示某个 Unit 的指定属性的值
$ systemctl show -p CPUShares httpd.service

# 设置某个 Unit 的指定属性
$ sudo systemctl set-property httpd.service CPUShares=500

依赖关系

Unit 之间存在依赖关系：A 依赖于 B，就意味着 Systemd 在启动 A 的时候，同时会去启
动 B。

systemctl list-dependencies命令列出一个 Unit 的所有依赖。

1

$ systemctl list-dependencies nginx.service

上面命令的输出结果之中，有些依赖是 Target 类型（详见下文），默认不会展开显示。如
果要展开 Target，就需要使用--all参数。

1

$ systemctl list-dependencies --all nginx.service

Unit 的配置文件

概述

每一个 Unit 都有一个配置文件，告诉 Systemd 怎么启动这个 Unit 。

Systemd 默认从目录/etc/systemd/system/读取配置文件。但是，里面存放的大部分文件
都是符号链接，指向目录/usr/lib/systemd/system/，真正的配置文件存放在那个目录。

systemctl enable命令用于在上面两个目录之间，建立符号链接关系。

1
2
3

$ sudo systemctl enable clamd@scan.service
# 等同于
$ sudo ln -s '/usr/lib/systemd/system/clamd@scan.service' '/etc/systemd/system/multi-user.target.wants/clamd@scan.service'

如果配置文件里面设置了开机启动，systemctl enable命令相当于激活开机启动。

与之对应的，systemctl disable命令用于在两个目录之间，撤销符号链接关系，相当于
撤销开机启动。

1

$ sudo systemctl disable clamd@scan.service

配置文件的后缀名，就是该 Unit 的种类，比如sshd.socket。如果省略，Systemd 默认
后缀名为.service，所以sshd会被理解成sshd.service。

配置文件的状态

systemctl list-unit-files命令用于列出所有配置文件。

1
2
3
4
5

# 列出所有配置文件
$ systemctl list-unit-files

# 列出指定类型的配置文件
$ systemctl list-unit-files --type=service

这个命令会输出一个列表。

1
2
3
4
5
6

$ systemctl list-unit-files

UNIT FILE              STATE
chronyd.service        enabled
clamd@.service         static
clamd@scan.service     disabled

这个列表显示每个配置文件的状态，一共有四种。

• enabled：已建立启动链接
• disabled：没建立启动链接
• static：该配置文件没有[Install]部分（无法执行），只能作为其他配置文件的依赖
• masked：该配置文件被禁止建立启动链接

注意，从配置文件的状态无法看出，该 Unit 是否正在运行。这必须执行前面提到
的systemctl status命令。

1

$ systemctl status bluetooth.service

一旦修改配置文件，就要让 SystemD 重新加载配置文件，然后重新启动，否则修改不会生
效。

1
2

$ sudo systemctl daemon-reload
$ sudo systemctl restart httpd.service

配置文件的格式

配置文件就是普通的文本文件，可以用文本编辑器打开。

systemctl cat命令可以查看配置文件的内容。

1
2
3
4
5
6
7
8
9
10
11

$ systemctl cat atd.service

[Unit]
Description=ATD daemon

[Service]
Type=forking
ExecStart=/usr/bin/atd

[Install]
WantedBy=multi-user.target

从上面的输出可以看到，配置文件分成几个区块。每个区块的第一行，是用方括号表示的区
别名，比如[Unit]。注意，配置文件的区块名和字段名，都是大小写敏感的。

每个区块内部是一些等号连接的键值对。

1
2
3
4
5

[Section]
Directive1=value
Directive2=value

. . .

注意，键值对的等号两侧不能有空格。

配置文件的区块

[Unit]区块通常是配置文件的第一个区块，用来定义 Unit 的元数据，以及配置与其他
Unit 的关系。它的主要字段如下。

• Description：简短描述
• Documentation：文档地址
• Requires：当前 Unit 依赖的其他 Unit，如果它们没有运行，当前 Unit 会启动失败
• Wants：与当前 Unit 配合的其他 Unit，如果它们没有运行，当前 Unit 不会启动失败
• BindsTo：与Requires类似，它指定的 Unit 如果退出，会导致当前 Unit 停止运行
• Before：如果该字段指定的 Unit 也要启动，那么必须在当前 Unit 之后启动
• After：如果该字段指定的 Unit 也要启动，那么必须在当前 Unit 之前启动
• Conflicts：这里指定的 Unit 不能与当前 Unit 同时运行
• Condition...：当前 Unit 运行必须满足的条件，否则不会运行
• Assert...：当前 Unit 运行必须满足的条件，否则会报启动失败

[Install]通常是配置文件的最后一个区块，用来定义如何启动，以及是否开机启动。它
的主要字段如下。

• WantedBy：它的值是一个或多个 Target，当前 Unit 激活时（enable）符号链接会放
  入/etc/systemd/system目录下面以 Target 名 + .wants后缀构成的子目录中
• RequiredBy：它的值是一个或多个 Target，当前 Unit 激活时，符号链接会放
  入/etc/systemd/system目录下面以 Target 名 + .required后缀构成的子目录中
• Alias：当前 Unit 可用于启动的别名
• Also：当前 Unit 激活（enable）时，会被同时激活的其他 Unit

[Service]区块用来 Service 的配置，只有 Service 类型的 Unit 才有这个区块。它的
主要字段如下。

• Type：定义启动时的进程行为。它有以下几种值。
• Type=simple：默认值，执行ExecStart指定的命令，启动主进程
• Type=forking：以 fork 方式从父进程创建子进程，创建后父进程会立即退出
• Type=oneshot：一次性进程，Systemd 会等当前服务退出，再继续往下执行
• Type=dbus：当前服务通过 D-Bus 启动
• Type=notify：当前服务启动完毕，会通知Systemd，再继续往下执行
• Type=idle：若有其他任务执行完毕，当前服务才会运行
• ExecStart：启动当前服务的命令
• ExecStartPre：启动当前服务之前执行的命令
• ExecStartPost：启动当前服务之后执行的命令
• ExecReload：重启当前服务时执行的命令
• ExecStop：停止当前服务时执行的命令
• ExecStopPost：停止当其服务之后执行的命令
• RestartSec：自动重启当前服务间隔的秒数
• Restart：定义何种情况 Systemd 会自动重启当前服务，可能的值包括always（总是
  重启）、on-success、on-failure、on-abnormal、on-abort、on-watchdog
• TimeoutSec：定义 Systemd 停止当前服务之前等待的秒数
• Environment：指定环境变量

Unit 配置文件的完整字段清单，请参
考官方文档。

Target

启动计算机的时候，需要启动大量的 Unit。如果每一次启动，都要一一写明本次启动需要
哪些 Unit，显然非常不方便。Systemd 的解决方案就是 Target。

简单说，Target 就是一个 Unit 组，包含许多相关的 Unit 。启动某个 Target 的时候
，Systemd 就会启动里面所有的 Unit。从这个意义上说，Target 这个概念类似于”状态点
“，启动某个 Target 就好比启动到某种状态。

传统的init启动模式里面，有 RunLevel 的概念，跟 Target 的作用很类似。不同的是
，RunLevel 是互斥的，不可能多个 RunLevel 同时启动，但是多个 Target 可以同时启动
。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 查看当前系统的所有 Target
$ systemctl list-unit-files --type=target

# 查看一个 Target 包含的所有 Unit
$ systemctl list-dependencies multi-user.target

# 查看启动时的默认 Target
$ systemctl get-default

# 设置启动时的默认 Target
$ sudo systemctl set-default multi-user.target

# 切换 Target 时，默认不关闭前一个 Target 启动的进程，
# systemctl isolate 命令改变这种行为，
# 关闭前一个 Target 里面所有不属于后一个 Target 的进程
$ sudo systemctl isolate multi-user.target

Target 与 传统 RunLevel 的对应关系如下。

1
2
3
4
5
6
7
8
9

Traditional runlevel      New target name     Symbolically linked to...

Runlevel 0           |    runlevel0.target -> poweroff.target
Runlevel 1           |    runlevel1.target -> rescue.target
Runlevel 2           |    runlevel2.target -> multi-user.target
Runlevel 3           |    runlevel3.target -> multi-user.target
Runlevel 4           |    runlevel4.target -> multi-user.target
Runlevel 5           |    runlevel5.target -> graphical.target
Runlevel 6           |    runlevel6.target -> reboot.target

它与init进程的主要差别如下。

（1）默认的 RunLevel（在/etc/inittab文件设置）现在被默认的 Target 取代，
位置是/etc/systemd/system/default.target，通常符号链接到graphical.target（
图形界面）或者multi-user.target（多用户命令行）。

（2）启动脚本的位置，以前是/etc/init.d目录，符号链接到不同的 RunLevel 目
录 （比如/etc/rc3.d、/etc/rc5.d等），现在则存放
在/lib/systemd/system和/etc/systemd/system目录。

（3）配置文件的位置，以前init进程的配置文件是/etc/inittab，各种服务的
配置文件存放在/etc/sysconfig目录。现在的配置文件主要存放在/lib/systemd目录
，在/etc/systemd目录里面的修改可以覆盖原始设置。

日志管理

Systemd 统一管理所有 Unit 的启动日志。带来的好处就是，可以只用journalctl一个命
令，查看所有日志（内核日志和应用日志）。日志的配置文件
是/etc/systemd/journald.conf。

journalctl功能强大，用法非常多。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

# 查看所有日志（默认情况下 ，只保存本次启动的日志）
$ sudo journalctl

# 查看内核日志（不显示应用日志）
$ sudo journalctl -k

# 查看系统本次启动的日志
$ sudo journalctl -b
$ sudo journalctl -b -0

# 查看上一次启动的日志（需更改设置）
$ sudo journalctl -b -1

# 查看指定时间的日志
$ sudo journalctl --since="2012-10-30 18:17:16"
$ sudo journalctl --since "20 min ago"
$ sudo journalctl --since yesterday
$ sudo journalctl --since "2015-01-10" --until "2015-01-11 03:00"
$ sudo journalctl --since 09:00 --until "1 hour ago"

# 显示尾部的最新10行日志
$ sudo journalctl -n

# 显示尾部指定行数的日志
$ sudo journalctl -n 20

# 实时滚动显示最新日志
$ sudo journalctl -f

# 查看指定服务的日志
$ sudo journalctl /usr/lib/systemd/systemd

# 查看指定进程的日志
$ sudo journalctl _PID=1

# 查看某个路径的脚本的日志
$ sudo journalctl /usr/bin/bash

# 查看指定用户的日志
$ sudo journalctl _UID=33 --since today

# 查看某个 Unit 的日志
$ sudo journalctl -u nginx.service
$ sudo journalctl -u nginx.service --since today

# 实时滚动显示某个 Unit 的最新日志
$ sudo journalctl -u nginx.service -f

# 合并显示多个 Unit 的日志
$ journalctl -u nginx.service -u php-fpm.service --since today

# 查看指定优先级（及其以上级别）的日志，共有8级
# 0: emerg
# 1: alert
# 2: crit
# 3: err
# 4: warning
# 5: notice
# 6: info
# 7: debug
$ sudo journalctl -p err -b

# 日志默认分页输出，--no-pager 改为正常的标准输出
$ sudo journalctl --no-pager

# 以 JSON 格式（单行）输出
$ sudo journalctl -b -u nginx.service -o json

# 以 JSON 格式（多行）输出，可读性更好
$ sudo journalctl -b -u nginx.serviceqq
 -o json-pretty

# 显示日志占据的硬盘空间
$ sudo journalctl --disk-usage

# 指定日志文件占据的最大空间
$ sudo journalctl --vacuum-size=1G

# 指定日志文件保存多久
$ sudo journalctl --vacuum-time=1years

实战

开机启动

对于那些支持 Systemd 的软件，安装的时候，会自动在/usr/lib/systemd/system目录添
加一个配置文件。

如果你想让该软件开机启动，就执行下面的命令（以httpd.service为例）。

1

$ sudo systemctl enable httpd

上面的命令相当于在/etc/systemd/system目录添加一个符号链接，指
向/usr/lib/systemd/system里面的httpd.service文件。

这是因为开机时，Systemd只执行/etc/systemd/system目录里面的配置文件。这也意味
着，如果把修改后的配置文件放在该目录，就可以达到覆盖原始配置的效果。

启动服务

设置开机启动以后，软件并不会立即启动，必须等到下一次开机。如果想现在就运行该软件
，那么要执行systemctl start命令。

1

$ sudo systemctl start httpd

执行上面的命令以后，有可能启动失败，因此要用systemctl status命令查看一下该服务
的状态。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$ sudo systemctl status httpd

httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled)
Active: active (running) since 金 2014-12-05 12:18:22 JST; 7min ago
Main PID: 4349 (httpd)
Status: "Total requests: 1; Current requests/sec: 0; Current traffic:   0 B/sec"
CGroup: /system.slice/httpd.service
        ├─4349 /usr/sbin/httpd -DFOREGROUND
        ├─4350 /usr/sbin/httpd -DFOREGROUND
        ├─4351 /usr/sbin/httpd -DFOREGROUND
        ├─4352 /usr/sbin/httpd -DFOREGROUND
        ├─4353 /usr/sbin/httpd -DFOREGROUND
        └─4354 /usr/sbin/httpd -DFOREGROUND

12月 05 12:18:22 localhost.localdomain systemd[1]: Starting The Apache HTTP Server...
12月 05 12:18:22 localhost.localdomain systemd[1]: Started The Apache HTTP Server.
12月 05 12:22:40 localhost.localdomain systemd[1]: Started The Apache HTTP Server.

上面的输出结果含义如下。

• Loaded行：配置文件的位置，是否设为开机启动
• Active行：表示正在运行
• Main PID行：主进程 ID
• Status行：由应用本身（这里是 httpd ）提供的软件当前状态
• CGroup块：应用的所有子进程
• 日志块：应用的日志

停止服务

终止正在运行的服务，需要执行systemctl stop命令。

1

$ sudo systemctl stop httpd.service

有时候，该命令可能没有响应，服务停不下来。这时候就不得不”杀进程”了，向正在运行的
进程发出kill信号。

1

$ sudo systemctl kill httpd.service

此外，重启服务要执行systemctl restart命令。

1

$ sudo systemctl restart httpd.service

读懂配置文件

一个服务怎么启动，完全由它的配置文件决定。下面就来看，配置文件有些什么内容。

前面说过，配置文件主要放在/usr/lib/systemd/system目录，也可能
在/etc/systemd/system目录。找到配置文件以后，使用文本编辑器打开即可。

systemctl cat命令可以用来查看配置文件，下面以sshd.service文件为例，它的作用
是启动一个 SSH 服务器，供其他用户以 SSH 方式登录。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$ systemctl cat sshd.service

[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.service
Wants=sshd-keygen.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
Type=simple
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

可以看到，配置文件分成几个区块，每个区块包含若干条键值对。

下面依次解释每个区块的内容。

[Unit] 区块：启动顺序与依赖关系。

Unit区块的Description字段给出当前服务的简单描述，Documentation字段给出文档
位置。

接下来的设置是启动顺序和依赖关系，这个比较重要。

After字段：表示如果network.target或sshd-keygen.service需要启动，那
么sshd.service应该在它们之后启动。

相应地，还有一个Before字段，定义sshd.service应该在哪些服务之前启动。

注意，After和Before字段只涉及启动顺序，不涉及依赖关系。

举例来说，某 Web 应用需要 postgresql 数据库储存数据。在配置文件中，它只定义要在
postgresql 之后启动，而没有定义依赖 postgresql 。上线后，由于某种原因
，postgresql 需要重新启动，在停止服务期间，该 Web 应用就会无法建立数据库连接。

设置依赖关系，需要使用Wants字段和Requires字段。

Wants字段：表示sshd.service与sshd-keygen.service之间存在”弱依赖”关系，即
如果”sshd-keygen.service”启动失败或停止运行，不影响sshd.service继续执行。

Requires字段则表示”强依赖”关系，即如果该服务启动失败或异常退出，那
么sshd.service也必须退出。

注意，Wants字段与Requires字段只涉及依赖关系，与启动顺序无关，默认情况下是同
时启动的。

[Service] 区块：启动行为

Service区块定义如何启动当前服务。

启动命令

许多软件都有自己的环境参数文件，该文件可以用EnvironmentFile字段读取。

EnvironmentFile字段：指定当前服务的环境参数文件。该文件内部的key=value键值
对，可以用$key的形式，在当前配置文件中获取。

上面的例子中，sshd 的环境参数文件是/etc/sysconfig/sshd。

配置文件里面最重要的字段是ExecStart。

ExecStart字段：定义启动进程时执行的命令。

上面的例子中，启动sshd，执行的命令是/usr/sbin/sshd -D $OPTIONS，其中的变
量$OPTIONS就来自EnvironmentFile字段指定的环境参数文件。

与之作用相似的，还有如下这些字段。

• ExecReload字段：重启服务时执行的命令
• ExecStop字段：停止服务时执行的命令
• ExecStartPre字段：启动服务之前执行的命令
• ExecStartPost字段：启动服务之后执行的命令
• ExecStopPost字段：停止服务之后执行的命令

请看下面的例子。

1
2
3
4
5
6

[Service]
ExecStart=/bin/echo execstart1
ExecStart=
ExecStart=/bin/echo execstart2
ExecStartPost=/bin/echo post1
ExecStartPost=/bin/echo post2

上面这个配置文件，第二行ExecStart设为空值，等于取消了第一行的设置，运行结果如
下。

1
2
3

execstart2
post1
post2

所有的启动设置之前，都可以加上一个连词号（-），表示”抑制错误”，即发生错误的时
候，不影响其他命令的执行。比如，EnvironmentFile=-/etc/sysconfig/sshd（注意等号
后面的那个连词号），就表示即使/etc/sysconfig/sshd文件不存在，也不会抛出错误。

启动类型

Type字段定义启动类型。它可以设置的值如下。

• simple（默认值）：ExecStart字段启动的进程为主进程
• forking：ExecStart字段将以fork()方式启动，此时父进程将会退出，子进程将成
  为主进程
• oneshot：类似于simple，但只执行一次，Systemd 会等它执行完，才启动其他服务
• dbus：类似于simple，但会等待 D-Bus 信号后启动
• notify：类似于simple，启动结束后会发出通知信号，然后 Systemd 再启动其他服
  务
• idle：类似于simple，但是要等到其他任务都执行完，才会启动该服务。一种使用场
  合是为让该服务的输出，不与其他服务的输出相混合

下面是一个oneshot的例子，笔记本电脑启动时，要把触摸板关掉，配置文件可以这样写
。

1
2
3
4
5
6
7
8
9

[Unit]
Description=Switch-off Touchpad

[Service]
Type=oneshot
ExecStart=/usr/bin/touchpad-off

[Install]
WantedBy=multi-user.target

上面的配置文件，启动类型设为oneshot，就表明这个服务只要运行一次就够了，不需要
长期运行。

如果关闭以后，将来某个时候还想打开，配置文件修改如下。

1
2
3
4
5
6
7
8
9
10
11

[Unit]
Description=Switch-off Touchpad

[Service]
Type=oneshot
ExecStart=/usr/bin/touchpad-off start
ExecStop=/usr/bin/touchpad-off stop
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

上面配置文件中，RemainAfterExit字段设为yes，表示进程退出以后，服务仍然保持执
行。这样的话，一旦使用systemctl stop命令停止服务，ExecStop指定的命令就会执行
，从而重新开启触摸板。

重启行为

Service区块有一些字段，定义了重启行为。

KillMode字段：定义 Systemd 如何停止 sshd 服务。

上面这个例子中，将KillMode设为process，表示只停止主进程，不停止任何 sshd 子
进程，即子进程打开的 SSH session 仍然保持连接。这个设置不太常见，但对 sshd 很重
要，否则你停止服务的时候，会连自己打开的 SSH session 一起杀掉。

KillMode字段可以设置的值如下。

• control-group（默认值）：当前控制组里面的所有子进程，都会被杀掉
• process：只杀主进程
• mixed：主进程将收到 SIGTERM 信号，子进程收到 SIGKILL 信号
• none：没有进程会被杀掉，只是执行服务的 stop 命令。

接下来是Restart字段。

Restart字段：定义了 sshd 退出后，Systemd 的重启方式。

上面的例子中，Restart设为on-failure，表示任何意外的失败，就将重启 sshd。如果
sshd 正常停止（比如执行systemctl stop命令），它就不会重启。

Restart字段可以设置的值如下。

• no（默认值）：退出后不会重启
• on-success：只有正常退出时（退出状态码为 0），才会重启
• on-failure：非正常退出时（退出状态码非 0），包括被信号终止和超时，才会重启
• on-abnormal：只有被信号终止和超时，才会重启
• on-abort：只有在收到没有捕捉到的信号终止时，才会重启
• on-watchdog：超时退出，才会重启
• always：不管是什么退出原因，总是重启

对于守护进程，推荐设为on-failure。对于那些允许发生错误退出的服务，可以设
为on-abnormal。

最后是RestartSec字段。

RestartSec字段：表示 Systemd 重启服务之前，需要等待的秒数。上面的例子设为等
待 42 秒。

[Install] 区块

Install区块，定义如何安装这个配置文件，即怎样做到开机启动。

WantedBy字段：表示该服务所在的 Target。

Target的含义是服务组，表示一组服务。WantedBy=multi-user.target指的是，sshd
所在的 Target 是multi-user.target。

这个设置非常重要，因为执行systemctl enable sshd.service命令时
，sshd.service的一个符号链接，就会放在/etc/systemd/system目录下面
的multi-user.target.wants子目录之中。

Systemd 有默认的启动 Target。

1
2

$ systemctl get-default
multi-user.target

上面的结果表示，默认的启动 Target 是multi-user.target。在这个组里的所有服务，
都将开机启动。这就是为什么systemctl enable命令能设置开机启动的原因。

使用 Target 的时候，systemctl list-dependencies命令和systemctl isolate命令也
很有用。

1
2
3
4
5
6

# 查看 multi-user.target 包含的所有服务
$ systemctl list-dependencies multi-user.target

# 切换到另一个 target
# shutdown.target 就是关机状态
$ sudo systemctl isolate shutdown.target

一般来说，常用的 Target 有两个：一个是multi-user.target，表示多用户命令行状态
；另一个是graphical.target，表示图形用户状态，它依赖于multi-user.target。官
方文档有一张非常清晰的
Target 依赖关系图。

Target 的配置文件

Target 也有自己的配置文件。

1
2
3
4
5
6
7
8
9

$ systemctl cat multi-user.target

[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes

注意，Target 配置文件里面没有启动命令。

上面输出结果中，主要字段含义如下。

• Requires字段：要求basic.target一起运行。
• Conflicts字段：冲突字段。如果rescue.service或rescue.target正在运行
  ，multi-user.target就不能运行，反之亦然。
• After：表示multi-user.target在basic.target 、 rescue.service、
  rescue.target之后启动，如果它们有启动的话。
• AllowIsolate：允许使用systemctl isolate命令切换到multi-user.target。

修改配置文件后重启

修改配置文件以后，需要重新加载配置文件，然后重新启动相关服务。

1
2
3
4
5

# 重新加载配置文件
$ sudo systemctl daemon-reload

# 重启相关服务
$ sudo systemctl restart foobar

参考资料

• Systemd 入门教程：命令篇
• Systemd 入门教程：实战篇

Spring 资源管理

Version 6.0.3

Resource 接口

相对标准 URL 访问机制，Spring 的 org.springframework.core.io.Resource 接口抽象了对底层资源的访问接口，提供了一套更好的访问方式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public interface Resource extends InputStreamSource {

    boolean exists();

    boolean isReadable();

    boolean isOpen();

    boolean isFile();

    URL getURL() throws IOException;

    URI getURI() throws IOException;

    File getFile() throws IOException;

    ReadableByteChannel readableChannel() throws IOException;

    long contentLength() throws IOException;

    long lastModified() throws IOException;

    Resource createRelative(String relativePath) throws IOException;

    String getFilename();

    String getDescription();
}

正如 Resource 接口的定义所示，它扩展了 InputStreamSource 接口。Resource 最核心的方法如下：

• getInputStream() - 定位并且打开当前资源，返回当前资源的 InputStream。每次调用都会返回一个新的 InputStream。调用者需要负责关闭流。
• exists() - 判断当前资源是否真的存在。
• isOpen() - 判断当前资源是否是一个已打开的 InputStream。如果为 true，则 InputStream 不能被多次读取，必须只读取一次然后关闭以避免资源泄漏。对所有常用资源实现返回 false，InputStreamResource 除外。
• getDescription() - 返回当前资源的描述，当处理资源出错时，资源的描述会用于错误信息的输出。一般来说，资源的描述是一个完全限定的文件名称，或者是当前资源的真实 URL。

常见 Spring 资源接口：

内置的 Resource 实现

Spring 包括几个内置的 Resource 实现：

ResourceLoader 接口

ResourceLoader 接口用于加载 Resource 对象。其定义如下：

1
2
3
4
5
6

public interface ResourceLoader {

    Resource getResource(String location);

    ClassLoader getClassLoader();
}

Spring 中主要的 ResourceLoader 实现：

Spring 中，所有的 ApplicationContext 都实现了 ResourceLoader 接口。因此，所有 ApplicationContext 都可以通过 getResource() 方法获取 Resource 实例。

【示例】

1
2
3
4
5
6
7

// 如果没有指定资源前缀，Spring 会尝试返回合适的资源
Resource template = ctx.getResource("some/resource/path/myTemplate.txt");
// 如果指定 classpath: 前缀，Spring 会强制使用 ClassPathResource
Resource template = ctx.getResource("classpath:some/resource/path/myTemplate.txt");
// 如果指定 file:、http 等 URL 前缀，Spring 会强制使用 UrlResource
Resource template = ctx.getResource("file:///some/resource/path/myTemplate.txt");
Resource template = ctx.getResource("http://myhost.com/resource/path/myTemplate.txt");

下表列举了 Spring 根据各种位置路径加载资源的策略：

ResourcePatternResolver 接口

ResourcePatternResolver 接口是 ResourceLoader 接口的扩展，它的作用是定义策略，根据位置模式解析 Resource 对象。

1
2
3
4
5
6

public interface ResourcePatternResolver extends ResourceLoader {

    String CLASSPATH_ALL_URL_PREFIX = "classpath*:";

    Resource[] getResources(String locationPattern) throws IOException;
}

PathMatchingResourcePatternResolver 是一个独立的实现，可以在 ApplicationContext 之外使用，也可以被 ResourceArrayPropertyEditor 用于填充 Resource[] bean 属性。PathMatchingResourcePatternResolver 能够将指定的资源位置路径解析为一个或多个匹配的 Resource 对象。

注意：任何标准 ApplicationContext 中的默认 ResourceLoader 实际上是 PathMatchingResourcePatternResolver 的一个实例，它实现了 ResourcePatternResolver 接口。

ResourceLoaderAware 接口

ResourceLoaderAware 接口是一个特殊的回调接口，用来标记提供 ResourceLoader 引用的对象。ResourceLoaderAware 接口定义如下：

1
2
3

public interface ResourceLoaderAware {
    void setResourceLoader(ResourceLoader resourceLoader);
}

当一个类实现 ResourceLoaderAware 并部署到应用程序上下文中（作为 Spring 管理的 bean）时，它会被应用程序上下文识别为 ResourceLoaderAware，然后，应用程序上下文会调用 setResourceLoader(ResourceLoader)，将自身作为参数提供（请记住，Spring 中的所有应用程序上下文都实现 ResourceLoader 接口）。

由于 ApplicationContext 是一个 ResourceLoader，该 bean 还可以实现 ApplicationContextAware 接口并直接使用提供的应用程序上下文来加载资源。 但是，一般来说，如果您只需要这些，最好使用专门的 ResourceLoader 接口。 该代码将仅耦合到资源加载接口（可以被视为实用程序接口），而不耦合到整个 Spring ApplicationContext 接口。

在应用程序中，还可以使用 ResourceLoader 的自动装配作为实现 ResourceLoaderAware 接口的替代方法。传统的构造函数和 byType 自动装配模式能够分别为构造函数参数或 setter 方法参数提供 ResourceLoader。 为了获得更大的灵活性（包括自动装配字段和多参数方法的能力），请考虑使用基于注解的自动装配功能。 在这种情况下，ResourceLoader 会自动连接到需要 ResourceLoader 类型的字段、构造函数参数或方法参数中，只要相关字段、构造函数或方法带有 @Autowired 注解即可。

资源依赖

如果 bean 本身要通过某种动态过程来确定和提供资源路径，那么 bean 可以使用 ResourceLoader 或 ResourcePatternResolver 接口来加载资源。 例如，考虑加载某种模板，其中所需的特定资源取决于用户的角色。 如果资源是静态的，完全消除 ResourceLoader 接口（或 ResourcePatternResolver 接口）的使用，让 bean 公开它需要的 Resource 属性，并期望将它们注入其中是有意义的。

使注入这些属性变得简单的原因是所有应用程序上下文都注册并使用一个特殊的 JavaBeans PropertyEditor，它可以将 String 路径转换为 Resource 对象。 例如，下面的 MyBean 类有一个 Resource 类型的模板属性。

【示例】

1
2
3

<bean id="myBean" class="example.MyBean">
    <property name="template" value="some/resource/path/myTemplate.txt"/>
</bean>

请注意，配置中引用的模板资源路径没有前缀，因为应用程序上下文本身将用作 ResourceLoader，资源本身将根据需要通过 ClassPathResource，FileSystemResource 或 ServletContextResource 加载，具体取决于上下文的确切类型。

如果需要强制使用特定的资源类型，则可以使用前缀。 以下两个示例显示如何强制使用 ClassPathResource 和 UrlResource（后者用于访问文件系统文件）。

1
2

<property name="template" value="classpath:some/resource/path/myTemplate.txt">
<property name="template" value="file:///some/resource/path/myTemplate.txt"/>

可以通过 @Value 注解加载资源文件 myTemplate.txt，示例如下：

1
2
3
4
5
6
7
8
9
10
11

@Component
public class MyBean {

    private final Resource template;

    public MyBean(@Value("${template.path}") Resource template) {
        this.template = template;
    }

    // ...
}

Spring 的 PropertyEditor 会根据资源文件的路径字符串，加载 Resource 对象，并将其注入到 MyBean 的构造方法。

如果想要加载多个资源文件，可以使用 classpath*: 前缀，例如：classpath*:/config/templates/*.txt。

1
2
3
4
5
6
7
8
9
10
11

@Component
public class MyBean {

    private final Resource[] templates;

    public MyBean(@Value("${templates.path}") Resource[] templates) {
        this.templates = templates;
    }

    // ...
}

应用上下文和资源路径

构造应用上下文

应用上下文构造函数（针对特定的应用上下文类型）通常将字符串或字符串数组作为资源的位置路径，例如构成上下文定义的 XML 文件。

【示例】

1
2
3
4
5

ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");
ApplicationContext ctx = new FileSystemXmlApplicationContext("conf/appContext.xml");
ApplicationContext ctx = new FileSystemXmlApplicationContext("classpath:conf/appContext.xml");
ApplicationContext ctx = new ClassPathXmlApplicationContext(
                new String[] {"services.xml", "daos.xml"}, MessengerService.class);

使用通配符构造应用上下文

ApplicationContext 构造器的中的资源路径可以是单一的路径（即一对一地映射到目标资源）；也可以是通配符形式——可包含 classpath*：也可以是前缀或 ant 风格的正则表达式（使用 spring 的 PathMatcher 来匹配）。

示例：

1

ApplicationContext ctx = new ClassPathXmlApplicationContext("classpath*:conf/appContext.xml");

使用 classpath* 表示类路径下所有匹配文件名称的资源都会被获取(本质上就是调用了 ClassLoader.getResources(…) 方法），接着将获取到的资源组装成最终的应用上下文。

在位置路径的其余部分，classpath*: 前缀可以与 PathMatcher 结合使用，如：classpath*:META-INF/*-beans.xml。

问题

Spring 配置资源中有哪些常见类型？

• XML 资源
• Properties 资源
• YAML 资源

参考资料

• Spring 官方文档之 Core Technologies
• 《小马哥讲 Spring 核心编程思想》

版本管理中间件 Flyway

Flyway 是一个数据迁移工具。

简介

什么是 Flyway

Flyway 是一个开源的数据库迁移工具。

为什么要使用数据迁移

为了说明数据迁移的作用，我们来举一个示例：

（1）假设，有一个叫做 Shiny 的项目，它的架构是一个叫做 Shiny Soft 的 App 连接叫做 Shiny DB 的数据库。

（2）对于大多数项目而言，最简单的持续集成场景如下所示：

这意味着，我们不仅仅要处理一份环境中的修改，由此会引入一些版本冲突问题：

在代码侧（即应用软件）的版本问题比较容易解决：

• 有方便的版本控制工具
• 有可复用的构建和持续集成
• 规范的发布和部署过程

那么，数据库层面的版本问题如何解决呢？

目前仍然没有方便的数据库版本工具。许多项目仍使用 sql 脚本来解决版本冲突，甚至是遇到冲突问题时才想起用 sql 语句去解决。

由此，引发一些问题：

• 机器上的数据库是什么状态？
• 脚本到底生效没有？
• 生产环境修复的问题是否也在测试环境修复了？
• 如何建立一个新的数据库实例？

数据迁移就是用来搞定这些混乱的问题：

• 通过草稿重建一个数据库。
• 在任何时候都可以清楚的了解数据库的状态。
• 以一种明确的方式将数据库从当前版本迁移到一个新版本。

Flyway 如何工作？

最简单的场景是指定 Flyway 迁移到一个空的数据库。

Flyway 会尝试查找它的 schema 历史表，如果数据库是空的，Flyway 就不再查找，而是直接创建数据库。

现再你就有了一个仅包含一张空表的数据库，默认情况下，这张表叫 flyway_schema_history。

这张表将被用于追踪数据库的状态。

然后，Flyway 将开始扫描文件系统或应用 classpath 中的 migrations。这些 migrations 可以是 sql 或 java。

这些 migrations 将根据他们的版本号进行排序。

任意 migration 应用后，schema 历史表将更新。当元数据和初始状态替换后，可以称之为：迁移到新版本。

Flyway 一旦扫描了文件系统或应用 classpath 下的 migrations，这些 migrations 会检查 schema 历史表。如果它们的版本号低于或等于当前的版本，将被忽略。保留下来的 migrations 是等待的 migrations，有效但没有应用。

migrations 将根据版本号排序并按序执行。

快速上手

Flyway 有 4 种使用方式：

• 命令行
• JAVA API
• Maven
• Gradle

命令行

适用于非 Java 用户，无需构建。

1

> flyway migrate -url=... -user=... -password=...

（1）下载解压

进入官方下载页面，选择合适版本，下载并解压到本地。

（2）配置 flyway

编辑 /conf/flyway.conf：

1
2
3

flyway.url=jdbc:h2:file:./foobardb
flyway.user=SA
flyway.password=

（3）创建第一个 migration

在 /sql 目录下创建 V1__Create_person_table.sql 文件，内容如下：

1
2
3
4

create table PERSON (
    ID int not null,
    NAME varchar(100) not null
);

（4）迁移数据库

运行 Flyway 来迁移数据库：

1

flyway-5.1.4> flyway migrate

运行正常的情况下，应该可以看到如下结果：

1
2
3
4
5
6

Database: jdbc:h2:file:./foobardb (H2 1.4)
Successfully validated 1 migration (execution time 00:00.008s)
Creating Schema History table: "PUBLIC"."flyway_schema_history"
Current version of schema "PUBLIC": << Empty Schema >>
Migrating schema "PUBLIC" to version 1 - Create person table
Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.033s)

（5）添加第二个 migration

在 /sql 目录下创建 V2__Add_people.sql 文件，内容如下：

1
2
3

insert into PERSON (ID, NAME) values (1, 'Axel');
insert into PERSON (ID, NAME) values (2, 'Mr. Foo');
insert into PERSON (ID, NAME) values (3, 'Ms. Bar');

运行 Flyway

1

flyway-5.1.4> flyway migrate

运行正常的情况下，应该可以看到如下结果：

1
2
3
4
5

Database: jdbc:h2:file:./foobardb (H2 1.4)
Successfully validated 2 migrations (execution time 00:00.018s)
Current version of schema "PUBLIC": 1
Migrating schema "PUBLIC" to version 2 - Add people
Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.016s)

JAVA API

（1）准备

• Java8+
• Maven 3.x

（2）添加依赖

在 pom.xml 中添加依赖：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<project ...>
    ...
    <dependencies>
        <dependency>
            <groupId>org.flywaydb</groupId>
            <artifactId>flyway-core</artifactId>
            <version>5.1.4</version>
        </dependency>
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <version>1.3.170</version>
        </dependency>
        ...
    </dependencies>
    ...
</project>

（3）集成 Flyway

添加 App.java 文件，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import org.flywaydb.core.Flyway;

public class App {
    public static void main(String[] args) {
        // Create the Flyway instance
        Flyway flyway = new Flyway();

        // Point it to the database
        flyway.setDataSource("jdbc:h2:file:./target/foobar", "sa", null);

        // Start the migration
        flyway.migrate();
    }
}

（4）创建第一个 migration

添加 src/main/resources/db/migration/V1__Create_person_table.sql 文件，内容如下：

1
2
3
4

create table PERSON (
    ID int not null,
    NAME varchar(100) not null
);

（5）执行程序

执行 App#main：

运行正常的情况下，应该可以看到如下结果：

1
2
3
4

INFO: Creating schema history table: "PUBLIC"."flyway_schema_history"
INFO: Current version of schema "PUBLIC": << Empty Schema >>
INFO: Migrating schema "PUBLIC" to version 1 - Create person table
INFO: Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.062s).

（6）添加第二个 migration

添加 src/main/resources/db/migration/V2__Add_people.sql 文件，内容如下：

1
2
3

insert into PERSON (ID, NAME) values (1, 'Axel');
insert into PERSON (ID, NAME) values (2, 'Mr. Foo');
insert into PERSON (ID, NAME) values (3, 'Ms. Bar');

运行正常的情况下，应该可以看到如下结果：

1
2
3

INFO: Current version of schema "PUBLIC": 1
INFO: Migrating schema "PUBLIC" to version 2 - Add people
INFO: Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.090s).

Maven

与 Java API 方式大体相同，区别在 集成 Flyway 步骤：

Maven 方式使用插件来集成 Flyway：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<project xmlns="...">
    ...
    <build>
        <plugins>
            <plugin>
                <groupId>org.flywaydb</groupId>
                <artifactId>flyway-maven-plugin</artifactId>
                <version>5.1.4</version>
                <configuration>
                    <url>jdbc:h2:file:./target/foobar</url>
                    <user>sa</user>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>com.h2database</groupId>
                        <artifactId>h2</artifactId>
                        <version>1.4.191</version>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </build>
</project>

因为用的是插件，所以执行方式不再是运行 Java 类，而是执行 maven 插件：

1

> mvn flyway:migrate

:point_right: 参考：示例源码

Gradle

本人不用 Gradle，略。

入门篇

概念

Migrations

在 Flyway 中，对于数据库的任何改变都称之为 Migrations。

Migrations 可以分为 Versioned migrations 和 Repeatable migrations。

Versioned migrations 有 2 种形式：regular 和 undo。

Versioned migrations 和 Repeatable migrations 都可以使用 SQL 或 JAVA 来编写。

Versioned migrations

由一个版本号（version）、一段描述（description）、一个校验（checksum）组成。版本号必须是惟一的。Versioned migrations 只能按顺序执行一次。

一般用于：

• 增删改 tables/indexes/foreign keys/enums/UDTs。
• 引用数据更新
• 用户数据校正

Regular 示例：

1
2
3
4
5
6
7
8
9

CREATE TABLE car (
    id INT NOT NULL PRIMARY KEY,
    license_plate VARCHAR NOT NULL,
    color VARCHAR NOT NULL
);

ALTER TABLE owner ADD driver_license_id VARCHAR;

INSERT INTO brand (name) VALUES ('DeLorean');

Undo migrations

注：仅专业版支持

Undo Versioned Migrations 负责撤销 Regular Versioned migrations 的影响。

Undo 示例：

1
2
3
4
5

DELETE FROM brand WHERE name='DeLorean';

ALTER TABLE owner DROP driver_license_id;

DROP TABLE car;

Repeatable migrations

由一段描述（description）、一个校验（checksum）组成。Versioned migrations 每次执行后，校验（checksum）会更新。

Repeatable migrations 用于管理可以通过一个文件来维护版本控制的数据库对象。

一般用于：

• 创建（重建）views/procedures/functions/packages 等。
• 大量引用数据重新插入

示例：

1
2

CREATE OR REPLACE VIEW blue_cars AS
    SELECT id, license_plate FROM cars WHERE color='blue';

基于 SQL 的 migrations

migrations 最常用的编写形式就是 SQL。

基于 SQL 的 migrations 一般用于：

• DDL 变更（针对 TABLES,VIEWS,TRIGGERS,SEQUENCES 等的 CREATE/ALTER/DROP 操作）
• 简单的引用数据变更（引用数据表中的 CRUD）
• 简单的大量数据变更（常规数据表中的 CRUD）

命名规则

为了被 Flyway 自动识别，SQL migrations 的文件命名必须遵循规定的模式：

• Prefix - V 代表 versioned migrations (可配置), U 代表 undo migrations (可配置)、 R 代表 repeatable migrations (可配置)
• Version - 版本号通过.(点)或_(下划线)分隔 (repeatable migrations 不需要)
• Separator - __ (两个下划线) (可配置)
• Description - 下划线或空格分隔的单词
• Suffix - .sql (可配置)

基于 JAVA 的 migrations

基于 JAVA 的 migrations 适用于使用 SQL 不容易表达的场景：

• BLOB 和 CLOB 变更
• 大量数据的高级变更（重新计算、高级格式变更）

命名规则

为了被 Flyway 自动识别，JAVA migrations 的文件命名必须遵循规定的模式：

• Prefix - V 代表 versioned migrations (可配置), U 代表 undo migrations (可配置)、 R 代表 repeatable migrations (可配置)
• Version - 版本号通过.(点)或_(下划线)分隔 (repeatable migrations 不需要)
• Separator - __ (两个下划线) (可配置)
• Description - 下划线或空格分隔的单词

:point_right: 更多细节请参考：https://flywaydb.org/documentation/migrations

Callbacks

注：部分 events 仅专业版支持。

尽管 Migrations 可能已经满足绝大部分场景的需要，但是某些情况下需要你一遍又一遍的执行相同的行为。这可能会重新编译存储过程，更新视图以及许多其他类型的开销。

因为以上原因，Flyway 提供了 Callbacks，用于在 Migrations 生命周期中添加钩子。

Callbacks 可以用 SQL 或 JAVA 来实现。

SQL Callbacks

SQL Callbacks 的命名规则为：event 名 + SQL migration。

如： beforeMigrate.sql, beforeEachMigrate.sql, afterEachMigrate.sql 等。

SQL Callbacks 也可以包含描述（description）。这种情况下，SQL Callbacks 文件名 = event 名 + 分隔符 + 描述 + 后缀。例：beforeRepair__vacuum.sql

当同一个 event 有多个 SQL callbacks，将按照它们描述（description）的顺序执行。

注： Flyway 也支持你配置的 sqlMigrationSuffixes。

JAVA Callbacks

当 SQL Callbacks 不够方便时，才应考虑 JAVA Callbacks。

JAVA Callbacks 有 3 种形式：

1. 基于 Java 的 Migrations - 实现 JdbcMigration、SpringJdbcMigration、MigrationInfoProvider、MigrationChecksumProvider、ConfigurationAware、FlywayConfiguration
2. 基于 Java 的 Callbacks - 实现 org.flywaydb.core.api.callback 接口。
3. 自定义 Migration resolvers 和 executors - 实现 MigrationResolver、MigrationExecutor、ConfigurationAware、FlywayConfiguration 接口。

:point_right: 更多细节请参考：https://flywaydb.org/documentation/callbacks

Error Handlers

注：仅专业版支持。

（略）

Dry Runs

注：仅专业版支持。

（略）

命令

Flyway 的功能主要围绕着 7 个基本命令：Migrate、Clean、Info、Validate、Undo、Baseline 和 Repair。

注：各命令的使用方法细节请查阅官方文档。

支持的数据库

• Oracle
• SQL Server
• DB2
• MySQL
• MariaDB
• PostgreSQL
• Redshift
• CockroachDB
• SAP HANA
• Sybase ASE
• Informix
• H2
• HSQLDB
• Derby
• SQLite

资料

| Github | 官方文档 |

🚪 传送

◾ 💧 钝悟的 IT 知识图谱 ◾

H2

概述

H2 是一个开源的嵌入式数据库引擎，采用 java 语言编写，不受平台的限制。同时 H2 提供了一个十分方便的 web 控制台用于操作和管理数据库内容。H2 还提供兼容模式，可以兼容一些主流的数据库，因此采用 H2 作为开发期的数据库非常方便。

使用说明

H2 控制台应用

H2 允许用户通过浏览器接口方式访问 SQL 数据库。

1. 进入官方下载地址，选择合适版本，下载并安装到本地。
2. 启动方式：在 bin 目录下，双击 jar 包；执行 java -jar h2*.jar；执行脚本：h2.bat 或 h2.sh。
3. 在浏览器中访问：http://localhost:8082，应该可以看到下图中的页面：

点击 Connect ，可以进入操作界面：

操作界面十分简单，不一一细说。

嵌入式应用

JDBC API

1
2
3

Connection conn = DriverManager.
    getConnection("jdbc:h2:~/test");
conn.close();

详见：Using the JDBC API

连接池

1
2
3
4
5

import org.h2.jdbcx.JdbcConnectionPool;
JdbcConnectionPool cp = JdbcConnectionPool.
create("jdbc:h2:~/test", "sa", "sa");
Connection conn = cp.getConnection();
conn.close(); cp.dispose();

详见：Connection Pool

Maven

1
2
3
4
5

<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>1.4.197</version>
</dependency>

详见：Maven 2

Hibernate

hibernate.cfg.xml (or use the HSQLDialect):

1
2
3

<property name="dialect">
    org.hibernate.dialect.H2Dialect
</property>

详见：Hibernate

TopLink 和 Glassfish

Datasource class: org.h2.jdbcx.JdbcDataSource
oracle.toplink.essentials.platform.database.H2Platform

详见：TopLink and Glassfish

运行方式

嵌入式

数据库持久化存储为单个文件。

连接字符串：\~/.h2/DBName 表示数据库文件的存储位置，如果第一次连接则会自动创建数据库。

• jdbc:h2:\~/test - ‘test’ 在用户根目录下
• jdbc:h2:/data/test - ‘test’ 在 /data 目录下
• jdbc:h2:test - ‘test’ 在当前工作目录

内存式

数据库只在内存中运行，关闭连接后数据库将被清空，适合测试环境

连接字符串：jdbc:h2:mem:DBName;DB_CLOSE_DELAY=-1

如果不指定 DBName，则以私有方式启动，只允许一个连接。

• jdbc:h2:mem:test - 一个进程中有多个连接
• jdbc:h2:mem: - 未命名的私有库，一个连接

服务模式

H2 支持三种服务模式：

• web server：此种运行方式支持使用浏览器访问 H2 Console
• TCP server：支持客户端/服务器端的连接方式
• PG server：支持 PostgreSQL 客户端

启动 tcp 服务连接字符串示例：

• jdbc:h2:tcp://localhost/\~/test - 用户根目录
• jdbc:h2:tcp://localhost//data/test - 绝对路径

启动服务

执行 java -cp *.jar org.h2.tools.Server

执行如下命令，获取选项列表及默认值

1

java -cp h2*.jar org.h2.tools.Server -?

常见的选项如下：

• -web：启动支持 H2 Console 的服务
• -webPort <port>：服务启动端口，默认为 8082
• -browser：启动 H2 Console web 管理页面
• -tcp：使用 TCP server 模式启动
• -pg：使用 PG server 模式启动

设置

• jdbc:h2:..;MODE=MySQL 兼容模式（或 HSQLDB 等）
• jdbc:h2:..;TRACE_LEVEL_FILE=3 记录到 *.trace.db

连接字符串参数

• DB_CLOSE_DELAY - 要求最后一个正在连接的连接断开后，不要关闭数据库
• MODE=MySQL - 兼容模式，H2 兼容多种数据库，该值可以为：DB2、Derby、HSQLDB、MSSQLServer、MySQL、Oracle、PostgreSQL
• AUTO_RECONNECT=TRUE - 连接丢失后自动重新连接
• AUTO_SERVER=TRUE - 启动自动混合模式，允许开启多个连接，该参数不支持在内存中运行模式
• TRACE_LEVEL_SYSTEM_OUT、TRACE_LEVEL_FILE - 输出跟踪日志到控制台或文件， 取值 0 为 OFF，1 为 ERROR（默认值），2 为 INFO，3 为 DEBUG
• SET TRACE_MAX_FILE_SIZE mb - 设置跟踪日志文件的大小，默认为 16M

maven 方式

此外，使用 maven 也可以启动 H2 服务。添加以下插件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>exec-maven-plugin</artifactId>
  <executions>
    <execution>
      <goals>
        <goal>java</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <mainClass>org.h2.tools.Server</mainClass>
    <arguments>
      <argument>-web</argument>
      <argument>-webPort</argument>
      <argument>8090</argument>
      <argument>-browser</argument>
    </arguments>
  </configuration>
</plugin>

在命令行中执行如下命令启动 H2 Console

1

mvn exec:java

或者建立一个 bat 文件

1
2
3

@echo off
call mvn exec:java
pause

此操作相当于执行了如下命令：

1

java -jar h2-1.3.168.jar -web -webPort 8090 -browser

Spring 整合 H2

（1）添加依赖

1
2
3
4
5

<dependency>
  <groupId>com.h2database</groupId>
  <artifactId>h2</artifactId>
  <version>1.4.194</version>
</dependency>

（2）spring 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jdbc="http://www.springframework.org/schema/jdbc"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
            http://www.springframework.org/schema/jdbc
            http://www.springframework.org/schema/jdbc/spring-jdbc.xsd">

  <!--配置数据源-->
  <bean id="dataSource" class="org.h2.jdbcx.JdbcConnectionPool"
        destroy-method="dispose">
    <constructor-arg>
      <bean class="org.h2.jdbcx.JdbcDataSource">
        <!-- 内存模式 -->
        <property name="URL" value="jdbc:h2:mem:test"/>
        <!-- 文件模式 -->
        <!-- <property name="URL" value="jdbc:h2:testRestDB" /> -->
        <property name="user" value="root"/>
        <property name="password" value="root"/>
      </bean>
    </constructor-arg>
  </bean>

  <!-- JDBC模板 -->
  <bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
    <constructor-arg ref="dataSource"/>
  </bean>
  <bean id="myJdbcTemplate" class="org.zp.notes.spring.jdbc.MyJdbcTemplate">
    <property name="jdbcTemplate" ref="jdbcTemplate"/>
  </bean>

  <!-- 初始化数据表结构 -->
  <jdbc:initialize-database data-source="dataSource" ignore-failures="ALL">
    <jdbc:script location="classpath:sql/h2/create_table_student.sql"/>
  </jdbc:initialize-database>
</beans>

H2 SQL

SELECT

INSERT

UPDATE

DELETE

BACKUP

EXPLAIN

7、MERGE

RUNSCRIPT

运行 sql 脚本文件

SCRIPT

根据数据库创建 sql 脚本

SHOW

ALTER

ALTER INDEX RENAME

ALTER SCHEMA RENAME

ALTER SEQUENCE

ALTER TABLE

增加约束

修改列

删除列

删除序列

ALTER USER

修改用户名

修改用户密码

ALTER VIEW

COMMENT

CREATE CONSTANT

CREATE INDEX

CREATE ROLE

CREATE SCHEMA

CREATE SEQUENCE

CREATE TABLE

CREATE TRIGGER

CREATE USER

CREATE VIEW

DROP

GRANT RIGHT

给 schema 授权授权

给 schema 授权给 schema 授权

复制角色的权限

REVOKE RIGHT

移除授权

移除角色具有的权限

ROLLBACK

从某个还原点（savepoint）回滚

回滚事务

创建 savepoint

数据类型

INT Type

集群

H2 支持两台服务器运行两个数据库成为集群，两个数据库互为备份，如果一个服务器失效，另一个服务器仍然可以工作。另外只有服务模式支持集群配置。

H2 可以通过 CreateCluster 工具创建集群，示例步骤如下（在在一台服务器上模拟两个数据库组成集群）：

• 创建目录
  • 创建两个服务器工作的目录
• 启动 tcp 服务
  • 执行如下命令分别在 9101、9102 端口启动两个使用 tcp 服务模式的数据库
• 使用 CreateCluster 工具创建集群
  • 如果两个数据库不存在，该命令将会自动创建数据库。如果一个数据库失效，可以先删除坏的数据库文件，重新启动数据库，然后重新运行 CreateCluster 工具
• 连接数据库现在可以使用如下连接字符串连接集群数据库
  • 监控集群运行状态
  • 可以使用如下命令查看配置的集群服务器是否都在运行
• 限制
  • H2 的集群并不支持针对事务的负载均衡，所以很多操作会使两个数据库产生不一致的结果
• 执行如下操作时请小心：
  • 自动增长列和标识列不支持集群，当插入数据时，序列值需要手动创建不支持 SET AUTOCOMMIT FALSE 语句；
  • 如果需要设置成为不自动提交，可以执行方法 Connection.setAutoCommit(false)

参考资料

• h2database 官网
• Java 嵌入式数据库 H2 学习总结(一)——H2 数据库入门

🚪 传送

◾ 💧 钝悟的 IT 知识图谱 ◾

PostgreSQL

PostgreSQL 是一个关系型数据库（RDBM）。

关键词：Database, RDBM, psql

安装

本文仅以运行在 Centos 环境下举例。

进入官方下载页面，根据操作系统选择合适版本。

官方下载页面要求用户选择相应版本，然后动态的给出安装提示，如下图所示：

前 3 步要求用户选择，后 4 步是根据选择动态提示的安装步骤

（1）选择 PostgreSQL 版本

（2）选择平台

（3）选择架构

（4）安装 PostgreSQL 的 rpm 仓库（为了识别下载源）

1

yum install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm

（5）安装客户端

1

yum install postgresql10

（6）安装服务端（可选的）

1

yum install postgresql10-server

（7）设置开机启动（可选的）

1
2
3

/usr/pgsql-10/bin/postgresql-10-setup initdb
systemctl enable postgresql-10
systemctl start postgresql-10

添加新用户和新数据库

初次安装后，默认生成一个名为 postgres 的数据库和一个名为 postgres 的数据库用户。这里需要注意的是，同时还生成了一个名为 postgres 的 Linux 系统用户。

首先，新建一个 Linux 新用户，可以取你想要的名字，这里为 dbuser。

1

sudo adduser dbuser

使用 psql 命令登录 PostgreSQL 控制台：

1

sudo -u postgres psql

这时相当于系统用户 postgres 以同名数据库用户的身份，登录数据库，这是不用输入密码的。如果一切正常，系统提示符会变为”postgres=#”，表示这时已经进入了数据库控制台。以下的命令都在控制台内完成。

（1）使用 \password 命令，为 postgres 用户设置一个密码。

1

postgres=# \password postgres

（2）创建数据库用户 dbuser（刚才创建的是 Linux 系统用户），并设置密码。

1

CREATE USER dbuser WITH PASSWORD 'password';

（3）创建用户数据库，这里为 exampledb，并指定所有者为 dbuser。

1

CREATE DATABASE exampledb OWNER dbuser;

（4）将 exampledb 数据库的所有权限都赋予 dbuser，否则 dbuser 只能登录控制台，没有任何数据库操作权限。

1

GRANT ALL PRIVILEGES ON DATABASE exampledb to dbuser;

（5）使用\q 命令退出控制台（也可以直接按 ctrl+D）。

登录数据库

添加新用户和新数据库以后，就要以新用户的名义登录数据库，这时使用的是 psql 命令。

1

psql -U dbuser -d exampledb -h 127.0.0.1 -p 5432

上面命令的参数含义如下：-U 指定用户，-d 指定数据库，-h 指定服务器，-p 指定端口。

输入上面命令以后，系统会提示输入 dbuser 用户的密码。输入正确，就可以登录控制台了。

psql 命令存在简写形式。如果当前 Linux 系统用户，同时也是 PostgreSQL 用户，则可以省略用户名（-U 参数的部分）。举例来说，我的 Linux 系统用户名为 ruanyf，且 PostgreSQL 数据库存在同名用户，则我以 ruanyf 身份登录 Linux 系统后，可以直接使用下面的命令登录数据库，且不需要密码。

1

psql exampledb

此时，如果 PostgreSQL 内部还存在与当前系统用户同名的数据库，则连数据库名都可以省略。比如，假定存在一个叫做 ruanyf 的数据库，则直接键入 psql 就可以登录该数据库。

psql

另外，如果要恢复外部数据，可以使用下面的命令。

1

psql exampledb < exampledb.sql

控制台命令

除了前面已经用到的 \password 命令（设置密码）和 \q 命令（退出）以外，控制台还提供一系列其他命令。

1
2
3
4
5
6
7
8
9
10

\password           设置密码
\q                  退出
\h                  查看SQL命令的解释，比如\h select
\?                  查看psql命令列表
\l                  列出所有数据库
\c [database_name]  连接其他数据库
\d                  列出当前数据库的所有表格
\d [table_name]     列出某一张表格的结构
\x                  对数据做展开操作
\du                 列出所有用户

数据库操作

基本的数据库操作，就是使用一般的 SQL 语言。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 创建新表
CREATE TABLE user_tbl(name VARCHAR(20), signup_date DATE);
# 插入数据
INSERT INTO user_tbl(name, signup_date) VALUES('张三', '2013-12-22');
# 选择记录
SELECT * FROM user_tbl;
# 更新数据
UPDATE user_tbl set name = '李四' WHERE name = '张三';
# 删除记录
DELETE FROM user_tbl WHERE name = '李四' ;
# 添加栏位
ALTER TABLE user_tbl ADD email VARCHAR(40);
# 更新结构
ALTER TABLE user_tbl ALTER COLUMN signup_date SET NOT NULL;
# 更名栏位
ALTER TABLE user_tbl RENAME COLUMN signup_date TO signup;
# 删除栏位
ALTER TABLE user_tbl DROP COLUMN email;
# 表格更名
ALTER TABLE user_tbl RENAME TO backup_tbl;
# 删除表格
DROP TABLE IF EXISTS backup_tbl;

备份和恢复

1
2

pg_dump --format=t -d db_name -U user_name -h 127.0.0.1 -O -W  > dump.sql
psql -h 127.0.0.1 -U user_name db_name < dump.sql

参考资料

• https://www.postgresql.org/download/
• http://www.ruanyifeng.com/blog/2013/12/getting_started_with_postgresql.html

🚪 传送

◾ 💧 钝悟的 IT 知识图谱 ◾

SQLite

SQLite 是一个无服务器的、零配置的、事务性的的开源数据库引擎。
💻 完整示例源码

SQLite 简介

SQLite 是一个C语言编写的轻量级、全功能、无服务器、零配置的的开源数据库引擎。

SQLite 的设计目标是嵌入式的数据库，很多嵌入式产品中都使用了它。SQLite 十分轻量，占用资源非常的低，在嵌入式设备中，可能只需要几百K的内存就够了。SQLite 能够支持Windows/Linux/Unix等等主流的操作系统，同时能够跟很多程序语言相结合，同样比起Mysql、PostgreSQL这两款开源的世界著名数据库管理系统来讲，它的处理速度比他们都快。

SQLite 大小只有 3M 左右，可以将整个 SQLite 嵌入到应用中，而不用采用传统的客户端／服务器（Client/Server）的架构。这样做的好处就是非常轻便，在许多智能设备和应用中都可以使用 SQLite，比如微信就采用了 SQLite 作为本地聊天记录的存储。

优点

• SQLite 是自给自足的，这意味着不需要任何外部的依赖。
• SQLite 是无服务器的、零配置的，这意味着不需要安装或管理。
• SQLite 事务是完全兼容 ACID 的，允许从多个进程或线程安全访问。
• SQLite 是非常小的，是轻量级的，完全配置时小于 400KiB，省略可选功能配置时小于 250KiB。
• SQLite 支持 SQL92（SQL2）标准的大多数查询语言的功能。
• 一个完整的 SQLite 数据库是存储在一个单一的跨平台的磁盘文件。
• SQLite 使用 ANSI-C 编写的，并提供了简单和易于使用的 API。
• SQLite 可在 UNIX（Linux, Mac OS-X, Android, iOS）和 Windows（Win32, WinCE, WinRT）中运行。

局限

安装

Sqlite 可在 UNIX（Linux, Mac OS-X, Android, iOS）和 Windows（Win32, WinCE, WinRT）中运行。

一般，Linux 和 Mac 上会预安装 sqlite。如果没有安装，可以在官方下载地址下载合适安装版本，自行安装。

SQLite 语法

这里不会详细列举所有 SQL 语法，仅列举 SQLite 除标准 SQL 以外的，一些自身特殊的 SQL 语法。

📖 扩展阅读：标准 SQL 基本语法

大小写敏感

SQLite 是不区分大小写的，但也有一些命令是大小写敏感的，比如 GLOB 和 glob 在 SQLite 的语句中有不同的含义。

注释

1
2
3
4
5

-- 单行注释
/*
 多行注释1
 多行注释2
 */

创建数据库

如下，创建一个名为 test 的数据库：

1
2
3
4

$ sqlite3 test.db
SQLite version 3.7.17 2013-05-20 00:56:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"

查看数据库

1
2
3
4

sqlite> .databases
seq  name             file
---  ---------------  ----------------------------------------------------------
0    main             /root/test.db

退出数据库

1

sqlite> .quit

附加数据库

假设这样一种情况，当在同一时间有多个数据库可用，您想使用其中的任何一个。

SQLite 的 ATTACH DATABASE 语句是用来选择一个特定的数据库，使用该命令后，所有的 SQLite 语句将在附加的数据库下执行。

1
2
3
4
5
6

sqlite> ATTACH DATABASE 'test.db' AS 'test';
sqlite> .databases
seq  name             file
---  ---------------  ----------------------------------------------------------
0    main             /root/test.db
2    test             /root/test.db

🔔 注意：数据库名 main 和 temp 被保留用于主数据库和存储临时表及其他临时数据对象的数据库。这两个数据库名称可用于每个数据库连接，且不应该被用于附加，否则将得到一个警告消息。

分离数据库

SQLite 的 DETACH DATABASE 语句是用来把命名数据库从一个数据库连接分离和游离出来，连接是之前使用 ATTACH 语句附加的。

1
2
3
4
5
6
7
8
9
10

sqlite> .databases
seq  name             file
---  ---------------  ----------------------------------------------------------
0    main             /root/test.db
2    test             /root/test.db
sqlite> DETACH DATABASE 'test';
sqlite> .databases
seq  name             file
---  ---------------  ----------------------------------------------------------
0    main             /root/test.db

备份数据库

如下，备份 test 数据库到 /home/test.sql

1

sqlite3 test.db .dump > /home/test.sql

恢复数据库

如下，根据 /home/test.sql 恢复 test 数据库

1

sqlite3 test.db < test.sql

SQLite 数据类型

SQLite 使用一个更普遍的动态类型系统。在 SQLite 中，值的数据类型与值本身是相关的，而不是与它的容器相关。

SQLite 存储类

每个存储在 SQLite 数据库中的值都具有以下存储类之一：

SQLite 的存储类稍微比数据类型更普遍。INTEGER 存储类，例如，包含 6 种不同的不同长度的整数数据类型。

SQLite 亲和(Affinity)类型

SQLite 支持列的亲和类型概念。任何列仍然可以存储任何类型的数据，当数据插入时，该字段的数据将会优先采用亲缘类型作为该值的存储方式。SQLite 目前的版本支持以下五种亲缘类型：

SQLite 亲和类型(Affinity)及类型名称

下表列出了当创建 SQLite3 表时可使用的各种数据类型名称，同时也显示了相应的亲和类型：

Boolean 数据类型

SQLite 没有单独的 Boolean 存储类。相反，布尔值被存储为整数 0（false）和 1（true）。

Date 与 Time 数据类型

SQLite 没有一个单独的用于存储日期和/或时间的存储类，但 SQLite 能够把日期和时间存储为 TEXT、REAL 或 INTEGER 值。

您可以以任何上述格式来存储日期和时间，并且可以使用内置的日期和时间函数来自由转换不同格式。

SQLite 命令

快速开始

进入 SQLite 控制台

1
2
3
4
5

$ sqlite3
SQLite version 3.7.17 2013-05-20 00:56:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>

进入 SQLite 控制台并指定数据库

1
2
3
4
5

$ sqlite3 test.db
SQLite version 3.7.17 2013-05-20 00:56:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>

退出 SQLite 控制台

1

sqlite>.quit

查看命令帮助

1

sqlite>.help

常用命令清单

实战

格式化输出

1
2
3
4

sqlite>.header on
sqlite>.mode column
sqlite>.timer on
sqlite>

输出结果到文件

1
2
3
4
5
6
7
8
9

sqlite> .mode list
sqlite> .separator |
sqlite> .output teyptest_file_1.txt
sqlite> select * from tbl1;
sqlite> .exit
$ cat test_file_1.txt
hello|10
goodbye|20
$

SQLite JAVA Client

（1）在官方下载地址下载 sqlite-jdbc-(VERSION).jar ，然后将 jar 包放在项目中的 classpath。

（2）通过 API 打开一个 SQLite 数据库连接。

执行方法：

1
2
3
4
5
6
7
8

> javac Sample.java
> java -classpath ".;sqlite-jdbc-(VERSION).jar" Sample   # in Windows
or
> java -classpath ".:sqlite-jdbc-(VERSION).jar" Sample   # in Mac or Linux
name = leo
id = 1
name = yui
id = 2

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

public class Sample {
    public static void main(String[] args) {
        Connection connection = null;
        try {
            // 创建数据库连接
            connection = DriverManager.getConnection("jdbc:sqlite:sample.db");
            Statement statement = connection.createStatement();
            statement.setQueryTimeout(30);  // 设置 sql 执行超时时间为 30s

            statement.executeUpdate("drop table if exists person");
            statement.executeUpdate("create table person (id integer, name string)");
            statement.executeUpdate("insert into person values(1, 'leo')");
            statement.executeUpdate("insert into person values(2, 'yui')");
            ResultSet rs = statement.executeQuery("select * from person");
            while (rs.next()) {
                // 读取结果集
                System.out.println("name = " + rs.getString("name"));
                System.out.println("id = " + rs.getInt("id"));
            }
        } catch (SQLException e) {
            // 如果错误信息是 "out of memory"，可能是找不到数据库文件
            System.err.println(e.getMessage());
        } finally {
            try {
                if (connection != null) {
                    connection.close();
                }
            } catch (SQLException e) {
                // 关闭连接失败
                System.err.println(e.getMessage());
            }
        }
    }
}

如何指定数据库文件

Windows

1

Connection connection = DriverManager.getConnection("jdbc:sqlite:C:/work/mydatabase.db");

Unix (Linux, Mac OS X, etc)

1

Connection connection = DriverManager.getConnection("jdbc:sqlite:/home/leo/work/mydatabase.db");

如何使用内存数据库

1

Connection connection = DriverManager.getConnection("jdbc:sqlite::memory:");

参考资料

• SQLite 官网
• SQLite Github
• SQLite 官方文档
• SQLite 官方命令行手册
• http://www.runoob.com/sqlite/sqlite-commands.html
• https://github.com/xerial/sqlite-jdbc
• http://www.runoob.com/sqlite/sqlite-java.html

🚪 传送

◾ 💧 钝悟的 IT 知识图谱 ◾

Cassandra

Apache Cassandra 是一个高度可扩展的分区行存储。行被组织成具有所需主键的表。

最新版本：v4.0

Quick Start

安装

先决条件

• JDK8+
• Python 2.7

简介

Apache Cassandra 是一套开源分布式 Key-Value 存储系统。它最初由 Facebook 开发，用于储存特别大的数据。

特性

主要特性

• 分布式
• 基于 column 的结构化
• 高伸展性

Cassandra 的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对 Cassandra 的一个写操作，会被复制到其他节点上去，对 Cassandra 的读操作，也会被路由到某个节点上面去读取。对于一个 Cassandra 群集来说，扩展性能 是比较简单的事情，只管在群集里面添加节点就可以了。

突出特性

• 模式灵活 - 使用 Cassandra，像文档存储，不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。这是一个惊人的效率提升，特别是在大型部署上。
• 真正的可扩展性 - Cassandra 是纯粹意义上的水平扩展。为给集群添加更多容量，可以指向另一台电脑。你不必重启任何进程，改变应用查询，或手动迁移任何数据。
• 多数据中心识别 - 你可以调整你的节点布局来避免某一个数据中心起火，一个备用的数据中心将至少有每条记录的完全复制。
• 范围查询 - 如果你不喜欢全部的键值查询，则可以设置键的范围来查询。
• 列表数据结构 - 在混合模式可以将超级列添加到 5 维。对于每个用户的索引，这是非常方便的。
• 分布式写操作 - 有可以在任何地方任何时间集中读或写任何数据。并且不会有任何单点失败。

更多内容

• Cassandra 官网
• Cassandra Github

🚪 传送

◾ 💧 钝悟的 IT 知识图谱 ◾

分布式 ID

分布式 ID 简介

什么是分布式 ID？

ID 是 Identity 的缩写，用于唯一的标识一条数据。分布式 ID，顾名思义，是用于在分布式系统中唯一标识数据的 ID。

为什么需要分布式 ID？

传统数据库基本都支持针对单表生成唯一性的自增主键。随着数据的膨胀，单机成为了性能和容量的瓶颈。为了解决这个问题，有了分库分表技术。分库分表所要面临的第一个问题是：数据分布在不同机器上，数据库无法保证多个节点上产生的主键唯一。 这就需要用到分布式 ID 了，它起到了分布式系统中全局 ID 的作用。

分布式 ID 的设计目标

首先，分布式 ID 应该具备哪些特性呢？

1. 全局唯一性 - 不能出现重复的 ID 号，既然是唯一标识，这是最基本的要求。
2. 单调递增 - 保证下一个 ID 一定大于上一个 ID，例如事务版本号、IM 增量消息、排序等特殊需求。
3. 高性能 - 分布式 ID 的生成速度要快，对本地资源消耗要小。
4. 高可用 - 生成分布式 ID 的服务要保证可用性无限接近于 100%。
5. 安全性 - ID 中不应包括敏感信息。

UUID

UUID 是通用唯一识别码（Universally Unique Identifier）的缩写，是一种 128 位的标识符，由32个16进制字符表示。UUID 会根据运行应用的计算机网卡 MAC 地址、时间戳、命名空间等元素，通过一定的随机算法产生。

UUID 不保证全局唯一性，我们需要小心 ID 冲突（尽管这种可能性很小）。

维基百科 - UUID 中介绍了 5 种 UUID 算法。

版本 1

UUID 版本 1 根据时间和 MAC 地址生成 UUID。

组成参数说明：

• time_low - 与日期时间信息的低值有关
• time_mid - 与日期时间信息的 mid 值有关
• time_high_and_version - 与日期时间信息的高值有关
• clock_seq_hi_and_reserved - 与计算机系统的内部时钟序列有关
• MAC 地址 - 设备的 MAC 地址

版本 2

UUID 版本 2 根据时间和 MAC 地址、DCE Security 生成 UUID。

它将版本 1 中的日期时间信息替换为本地域名。它没有被广泛使用，因为它降低了唯一性。

版本 3

UUID 版本 3 使用命名空间和名称生成 UUID。命名空间本身是一个 UUID，URL 名称用作标识。二者组合后，通过 MD5 哈希算法计算生成 UUID。

版本 5

UUID 版本 5 和 版本 4 近似，都使用命名空间和名称生成 UUID。差异在于：版本 3 采用 MD5 作为哈希算法；版本 5 采用 SHA1 作为哈希算法。

版本 3 、版本 5 - 基于哈希命名空间标识符和名称生成 UUID，差异在于：版本 3 采用 MD5 作为哈希算法；版本 5 采用 SHA1 作为哈希算法。

版本 4

版本 4 随机生成 UUID，不包含其他 UUID 中使用的任何信息 （命名空间、MAC 地址、时间）。识别它的唯一方法是版本 4 UUID，字符只是 4 位于 UUID 第三部分的第一个位置。其他字符是随机生成的。

版本 4 是最常见的 UUID 实现，JDK 中也提供了实现，示例如下：

1

String uuid = UUID.randomUUID().toString();

UUID 的优缺点

• 优点
  • 简单、生成速度较快（本地生成，不依赖其他服务）
• 缺点
  • 无序 - 不能生成递增有序的数字，这不利于一些特定场景。如：MySQL InnoDB 存储引擎使用 B+ 树存储索引数据，索引数据在 B+ 树中是有序排列的。而 UUID 的无序性可能会引起数据位置频繁变动，严重影响性能。
  • 长度过长 - UUID 需要占用 32 个字节
  • 信息不安全 - 基于 MAC 地址生成 UUID 的算法，可能会造成 MAC 地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。

数据库自增序列

大多数数据库都支持自增主键。基于此特性，可以利用事务管理控制生成唯一 ID。

以 MySQL 举例，我们通过下面的方式即可。

（1）创建一个专用于生成 ID 的表

1
2
3
4
5
6

CREATE TABLE `sequence_id` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `stub` char(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `stub` (`stub`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

stub 字段无意义，只是为了占位，便于我们插入或者修改数据。并且，给 stub 字段创建了唯一索引，保证其唯一性。

（2）通过 replace into 来插入数据。

1
2
3
4

BEGIN;
REPLACE INTO sequence_id (stub) VALUES ('stub');
SELECT LAST_INSERT_ID();
COMMIT;

插入数据这里，我们没有使用 insert into 而是使用 replace into 来插入数据，具体步骤是这样的：

• 第一步：尝试把数据插入到表中。
• 第二步：如果主键或唯一索引字段出现重复数据错误而插入失败时，先从表中删除含有重复关键字值的冲突行，然后再次尝试把数据插入到表中。

这种方式的优缺点也比较明显：

• 优点：
  • 方案简单
  • 有序
  • ID 长度小
• 缺点：
  • 性能差
  • 每次获取 ID 都要访问一次数据库，增加了对数据库的压力
  • 不安全，根据发号数量信息可能推测出业务规模
  • 单点问题，如果数据库宕机会造成服务不可用，可以使用高可用方案来解决，但会增加复杂度

数据库生成号段

数据库自增序列这种模式，每次获取 ID 都要请求一次数据库。当请求并发量高时，会给数据库带来很大的压力，并且生成 ID 的性能也比较差。

可以采用批处理的思路来优化数据库自增序列方案。申请 ID 改为批量获取，不再一次只申请一个 ID，而是一次批量生成一个 segment（号段），号段的大小由 step（步长）控制。用完之后再去数据库获取新的号段，可以大大的减轻数据库的压力。各个业务不同的发号需求用 biz_tag 字段来区分，每个 biz_tag 的 ID 获取相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对 biz_tag 分库分表就行。

以 MySQL 举例，我们通过下面的方式即可。

1
2
3
4
5
6
7
8
9
10

CREATE TABLE `leaf_alloc` (
  `biz_tag` varchar(128)  NOT NULL DEFAULT '',
  `max_id` bigint(20) NOT NULL DEFAULT '1',
  `step` int(11) NOT NULL,
  `description` varchar(256)  DEFAULT NULL,
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;

insert into leaf_alloc(biz_tag, max_id, step, description) values('leaf-segment-test', 1, 2000, 'Test leaf Segment Mode Get Id')

重要字段说明：

• biz_tag 用来区分业务
• max_id 表示该 biz_tag 目前所被分配的 ID 号段的最大值
• step 表示每次分配的号段长度。原来获取 ID 每次都需要写数据库，现在只需要把 step 设置得足够大，比如 1000。那么只有当 1000 个号被消耗完了之后才会去重新读写一次数据库。读写数据库的频率从 1 减小到了 1/step。

大致架构如下图所示：

test_tag 在第一台 Leaf 机器上是 1~1000 的号段，当这个号段用完时，会去加载另一个长度为 step=1000 的号段，假设另外两台号段都没有更新，这个时候第一台机器新加载的号段就应该是 3001~4000。同时数据库对应的 biz_tag 这条数据的 max_id 会从 3000 被更新成 4000，更新号段的 SQL 语句如下：

1
2
3
4