概念

先弄清楚几点概念, 注意大小写区别.

• WSGI - 全称为Python Web Server Gateway Interface, 即Python服务器网关接口. 是为Python语言定义的Web服务器和Web应用程序或Web应用框架之间的一种简单而通用的接口. WSGI只是一种通信协议. 更详细信息请查看维基百科WSGI.
  通俗一点说就是写Python程序时不想花费大量的时间去处理TCP连接、HTTP的请求和响应等等, 于是就把这些都统一成了一个接口(即WSGI). 然后由专门的Web服务器(uWSGI等)和Web应用框架(Django等)去实现. 既降低了开发门槛又节约了时间.
• uWSGI - uWSGI是一个实现了WSGI协议的Web服务器, uWSGI处理了HTTP的响应解析等, 并转成WSGI协议, 这样我们编写的Web应用程序或Web应用框架才可以对传递过来的信息进行处理.
• uwsgi - uwsgi是实现了WSGI协议的服务器的内部自有协议, 它定义了传输信息的类型, 用于实现了WSGI协议的服务器与其他网络服务器的数据通信.

了解了基本的概念之后, 就知道了为什么要Django+uWSGI. Django是Python的Web应用框架, 他帮我们做了很多基础工作, 让开发者可以专心的写业务代码. 而uWSGI是实现了WSGI协议的Web服务器, 只有这两者组合在一起, Python的应用程序才可以发挥作用.

理论上, 有了这一套, 就可以部署到服务器使用了. 而我们还要加上Nginx的原因, 当然是因为Nginx可以做一些uWSGI做不到的事情, 或者把事情做得更好.

Nginx是一款面向性能设计的HTTP服务器，相较于Apache具有占有内存少，稳定性高等优势. 可以被用作反向代理，负载平衡器 和 HTTP缓存. 所以使用Nginx的最大原因之一就是性能问题. 如果只是个小网站, 不会有很大了流量, 当然uWSGI可以满足要求, 但是在高并发情况下就需要Nginx了, 并且Nginx相比Apache有很大的高并发优势.

另外, Nginx能带来更好的安全性. 并且可以直接处理静态内容, 不需要通过uWSGI, 让uWSGI专心处理动态内容, 从而提高性能.

部署过程

我的机器已经安装了anaconda

1. 打开python虚拟环境

   1 2 3 4 5 6

   $ conda info -e # conda environments: # python27 /home/chris/anaconda2/envs/python27 $ source activate python27

2. 安装nginx

3. 安装uwsgi

   1	pip install uwsgi

安装完成后，出现了如下错误

1
2

# uwsgi --version
uwsgi: error while loading shared libraries: libpcre.so.1: cannot open...

可以按照下面的方法解决：
https://stackoverflow.com/questions/43301339/pcre-issue-when-setting-up-wsgi-application

1. 在django项目下新建uwsgi.ini文件，配置如下

   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

   # uwsig使用配置文件启动 [uwsgi] # 项目目录 chdir=/home/chris/myspace/python/myblog # 指定项目的application module=myblog.wsgi:application # 指定sock的文件路径 socket=127.0.0.1:8080 #socket=/home/chris/myspace/python/myblog/script/uwsgi.sock # 进程个数 workers=5 pidfile=/home/chris/myspace/python/myblog/script/uwsgi.pid # 指定IP端口 http=127.0.0.1:8080 # 指定静态文件 static-map=/static=/home/chris/myspace/python/myblog/static # 启动uwsgi的用户名和用户组 uid=root gid=root # 启用主进程 master=true # 自动移除unix Socket和pid文件当服务停止的时候 vacuum=true # 序列化接受的内容，如果可能的话 thunder-lock=true # 启用线程 enable-threads=true # 设置自中断时间 harakiri=30 # 设置缓冲 post-buffering=100004096 # 设置日志目录 daemonize=/home/chris/myspace/python/myblog/script/uwsgi.log

socket参数这里配置为网络地址

1

socket=127.0.0.1:7070

但如果Nginx和uWSGI同在一个服务器上，可以使用socket文件的形式

1

socket=/home/chris/myspace/python/myblog/script/uwsgi.sock

使用netstat查看8080端口，已经在监听，说明服务已启动

1
2

(python27) $ sudo netstat -apn |grep 8080
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      19700/uwsgi

1. 配置nginx

拷贝nginx默认的配置文件nginx.conf并重命名为nginx_django.conf，配置如下

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

http {
    ···
            server {
                listen       8000;
                server_name  localhost;
                location / {
                        include     /usr/local/nginx/conf/uwsgi_params;
                        #include uwsgi_params;
                        uwsgi_pass  127.0.0.1:8080;
                        #uwsgi_pass unix:/home/chris/myspace/python/myblog/script/uwsgi.sock;
                        uwsgi_connect_timeout      300; #nginx跟后端服务器连接超时时间(代理连接超时)
                        uwsgi_send_timeout         300; #后端服务器数据回传时间(代理发送超时)
                        uwsgi_read_timeout         300; #连接成功后，后端服务器响应时间(代理接收超时)
                }
        }
    ···
}

1. 启动Nginx

   1	$ nginx -c nginx_django.conf

2. 在浏览器访问nginx配置的端口

   1	127.0.0.1:8000/index

到这里，就完了用Nginx+uWSGI+Django搭建Web服务。

进程

Linux创建进程采用fork()和exec()

• fork: 采用复制当前进程的方式来创建子进程，此时子进程与父进程的区别仅在于pid, ppid以及资源统计量(比如挂起的信号)
• exec：读取可执行文件并载入地址空间执行；一般称之为exec函数族，有一系列exec开头的函数，比如execl, execve等

进程创建

• Linux进程创建： 通过fork()系统调用创建进程
• Linux用户级线程创建：通过pthread库中的pthread_create()创建线程
• Linux内核线程创建： 通过kthread_create()
  Linux线程，也并非”轻量级进程”，在Linux看来线程是一种进程间共享资源的方式，线程可看做是跟其他进程共享资源的进程。

fork, vfork, clone根据不同参数调用do_fork：

• pthread_create: flags参数为 CLONE_VM, CLONE_FS, CLONE_FILES, CLONE_SIGHAND
• fork: flags参数为 SIGCHLD
• vfork: flags参数为 CLONE_VFORK, CLONE_VM, SIGCHLD

fork的具体流程

进程/线程创建的方法fork(),pthread_create(), 万物归一，最终在linux都是调用do_fork方法。 当然还有vfork其实也是一样的， 通过系统调用到sys_vfork，然后再调用do_fork方法，该方法 现在很少使用，所以下图省略该方法。

fork执行流程:

1. 用户空间调用fork()方法;
2. 经过syscall陷入内核空间, 内核根据系统调用号找到相应的sys_fork系统调用;
3. sys_fork()过程会在调用do_fork(), 该方法参数有一个flags很重要, 代表的是父子进程之间需要共享的资源; 对于进程创建flags=SIGCHLD, 即当子进程退出时向父进程发送SIGCHLD信号;
4. do_fork(),会进行一些check过程,之后便是进入核心方法copy_process.

进程复制

使用fork函数得到的子进程从父进程的继承了整个进程的地址空间，包括：进程上下文、进程堆栈、内存信息、打开的文件描述符、信号控制设置、进程优先级、进程组号、当前工作目录、根目录、资源限制、控制终端等。

子进程与父进程的区别在于：

1. 父进程设置的锁，子进程不继承（因为如果是排它锁，被继承的话，矛盾了）
2. 各自的进程ID和父进程ID不同
3. 子进程的未决告警被清除；
4. 子进程的未决信号集设置为空集。

写时复制（copy on write）

linux系统为了提高系统性能和资源利用率，在fork出一个新进程时，系统并没有真正复制一个副本。

如果多个进程要读取它们自己的那部分资源的副本，那么复制是不必要的。每个进程只要保存一个指向这个资源的指针就可以了。

如果一个进程要修改自己的那份资源的“副本”，那么就会复制那份资源。这就是写时复制的含义

fork 和vfork：
在fork还没实现copy on write之前。Unix设计者很关心fork之后立刻执行exec所造成的地址空间浪费，所以引入了vfork系统调用。

vfork有个限制，子进程必须立刻执行_exit或者exec函数。

即使fork实现了copy on write，效率也没有vfork高，但是我们不推荐使用vfork，因为几乎每一个vfork的实现，都或多或少存在一定的问题。

孤儿进程&僵尸进程

fork系统调用之后，父子进程将交替执行，执行顺序不定。

• 孤儿进程：如果父进程先退出，子进程还没退出那么子进程的父进程将变为init进程（托孤给了init进程）。（注：任何一个进程都必须有父进程）

• 僵尸进程：如果子进程先退出，父进程还没退出，那么子进程必须等到父进程捕获到了子进程的退出状态才真正结束，否则这个时候子进程就成为僵进程（僵尸进程：只保留一些退出信息供父进程查询）

  僵尸进程的影响：
  比如进程采用exit()退出的时候，操作系统会进行一些列的处理工作，包括关闭打开的文件描述符、占用的内存等等，但是，操作系统也会为该进程保留少量的信息，以供父进程使用。例如进程的ID号、进程的退出状态、进程运行的CPU时间等，因而占用了系统的资源。
  在一种极端的情况下，档僵尸进程过多的时候，占用了大量的进程ID，系统将无法产生新的进程，相当于系统的资源被耗尽。
  

• 代码例子-孤儿进程

  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

  #include <unistd.h> #include <sys/types.h> #include <sys/wait.h> #include <cstdio> #include <cstdlib> #include <iostream> using namespace std; int main(int argc, char const *argv[]) { int childpid = 0; int i; pid_t pid = fork(); if (pid == 0) { //child process sleep(20); printf("child:%d, parent: %d\n", getpid(), getppid()); // char * execv_str[] = {"echo", "executed by execv",NULL}; // if (execv("/bin/echo",execv_str) <0 ){ // perror("error on exec"); // exit(0); // } printf("child process end\n\n"); } else if (pid > 0) { //parent process printf("parent: %d\n", getpid()); //sleep(20); //wait(NULL); printf("parent process end\n\n"); } else { perror("fork"); return -1; } return 0; }

例子中先让父进程退出，子进程在fork后sleep一段时间，用ps命令查看进程信息，可以看到5083的父进程是1

1
2
3

$ ps -eF |grep exec_test
chris     5083     1  0  3180   172   3 17:01 pts/1    00:00:00 ./exec_test
chris     5095  4391  0 24366   980   3 17:01 pts/2    00:00:00 grep --color=auto exec_test

• 代码例子-僵尸进程

  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

  #include <unistd.h> #include <sys/types.h> #include <sys/wait.h> #include <cstdio> #include <cstdlib> #include <iostream> using namespace std; int main(int argc, char const *argv[]) { int childpid = 0; int i; pid_t pid = fork(); if (pid == 0) { //child process //sleep(20); printf("child:%d, parent: %d\n", getpid(), getppid()); // char * execv_str[] = {"echo", "executed by execv",NULL}; // if (execv("/bin/echo",execv_str) <0 ){ // perror("error on exec"); // exit(0); // } printf("child process end\n\n"); } else if (pid > 0) { //parent process printf("parent: %d\n", getpid()); sleep(30); //wait(NULL); printf("parent process end\n\n"); } else { perror("fork"); return -1; } return 0; }

父进程不调用wait等待子进程结束，使用ps命令查看进程状态，defunct表示僵尸进程。

1
2
3

$ ps -eF |grep exec_test
chris     5225  3922  0  3181  1116   2 17:17 pts/1    00:00:00 ./exec_test
chris     5226  5225  0     0     0   3 17:17 pts/1    00:00:00 [exec_test] <defunct>

也可以这这样查询：

1

ps -e -o stat,ppid,pid,cmd|egrep '^[Zz]'

如何避免僵尸进程

我们可以使用如下几种方法避免僵尸进程的产生:

1. 在fork后调用wait/waitpid函数取得子进程退出状态。
2. 调用fork两次（第一次调用产生一个子进程，第二次调用fork是在第一个子进程中调用，同时将父进程退出（第一个子进程退出），此时的第二个子进程的父进程id为init进程id。
3. 在程序中显示忽略SIGCHLD信号（子进程退出时会产生一个SIGCHLD信号，我们显示忽略此信号即可）。
4. 捕获SIGCHLD信号并在捕获程序中调用wait/waitpid函数。

参考文献

• http://gityuan.com/2017/08/05/linux-process-fork/

底层实现分析

• 先看下面的一段代码

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

  #include <stdio.h> #include <iostream> using namespace std; int main() { int x = 1; int &b = x; printf("&x=%x,&b=%x\n",&x,&b); printf("&x=%x,&x-1=%x\n",&x,&x-1); printf("&x=%x,&b=%x\n",&x,*(&x-1)); return 0; }

• 汇编后的代码

  1 2 3 4 5

  1 movl $1, -12(%rbp) 2 leaq -12(%rbp), %rax 3 movq %rax, -8(%rbp) 4 movl $0, %eax 5 popq %rbp

一、系统模型

1.1 数据模型

ZooKeeper的视图结构使用了其特有的“数据节点”概念，我们称之为ZNode。ZNode是ZooKeeper中数据的最小单元，每个ZNode上都可以保存数据，同时还可以挂载子节点，因此构成了一个层次化的命名空间，我们称之为树。

1.2 节点特性

我们已知，ZooKeeper的命名空间是由一系列数据节点组成的，我们将对数据节点做详细讲解。

节点类型

在ZooKeeper中，每个数据节点都是有生命周期的，其生命周期的长短取决于数据节点的节点类型。在ZooKeeper中，节点类型可以分为持久节点(PERSISTENT)、临时节点(EPHEMERAL)和顺序节点(SEQUENTIAL)三大类，ju’ti具体在节点创建过程中，通过组合使用，可以生成以下四种组合型节点类型：

• 持久节点(PERSISTENT)
  数据节点被创建后，就会一直存在于ZooKeeper服务器上，直到有删除操作来主动清除这个节点。

• 持久顺序节点(PERSISTENT_SEQUENTIAL)
  他的基本特性和持久节点是一致的，额外的特性表现在顺序性上。在ZooKeeper中，每个父节点都会为他的第一级子节点维护一份顺序，用于记录下每个子节点创建的先后顺序。基于这个顺序特性，在创建子节点的时候，可以设置这个标记，那么在创建节点过程中，ZooKeeper会自动为给定节点加上一个数字后缀，作为一个新的、完整的节点名。另外需要注意的是，这个数字后缀的上限是整型的最大值。

• 临时节点(EPHEMERAL)
  临时节点的生命周期和客户端的会话绑定在一起，也就是说，如果客户端会话失效，那么这个节点就会被自动清理掉。这里提到的客户端会话失效，而非TCP连接断开。

• 临时顺序节点(EPHEMERAL_SEQUENTIAL)
  在临时节点基础上，添加了顺序的特性。

状态信息

每个数据节点除了存储了数据内容外，还存储了数据节点本身的一些状态信息。

1.3 版本-保证分布式数据原子性操作

ZooKeeper中为数据节点引入了版本的概念，每个数据节点都具有三种类型的版本信息，对数据节点的任何更新操作都会引起版本号的变化。

在ZooKeeper中，version属性正是用来实现乐观锁机制中的“写入校验”的。

1.4 Watcher-数据变更的通知

在ZooKeeper中，引入了Watcher机制来实现这种分布式的通知功能。ZooKeeper允许客户端向服务端注册一个Watcher监听，当服务器的一些指定事件出发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。
[img01]
从图中我们可以看到，ZooKeeper的Watcher机制主要包括客户端线程、客户端WatcherManager和ZooKeeper服务器三部分。在具体工作流程上，客户端在向ZooKeeper服务器注册Watcher的同时，会将Watcher对象存储在客户端的WatcherManager中。当ZooKeeper服务器端触发Watcher事件后，会向客户端发送通知，客户端线程从WatcherManager中取出对应的Watcher对象来执行回调逻辑。

二、序列化协议

ZooKeeper的客户端和服务端之间会进行一系列的网络通信以实现数据的传输。对于一个网络通信，首先要解决的就是对数据的序列化和反序列化处理，在ZooKeeper中，使用了Jute这一序列化组件来进行数据的序列化和反序列化操作。同时，为了实现一个高效的网络通信程序，良好的通信协议设计也是至关重要的。

• 通信协议
  基于TCP/IP协议，ZooKeeper实现了自己的通信协议来完成客户端与服务端、服务端与服务端之间的网络通信。ZooKeeper通信协议整体上的设计非常简单，对于请求，主要包含请求头和请求体，对于响应，则主要包含响应头和相应体。

三、Leader选举

术语解释

• SID(myid)：服务器ID
• ZXID：事务ID
• Vote：投票
• Quorum：过半机器数

各服务器角色介绍

1. Leader
   Leader服务器是整个ZooKeeper集群工作机制的核心，其主要工作有以下两个:
   a. 事务请求的唯一调度和处理者，保证集群事务处理的顺序性。
   b. 集群内部各服务器的调度者。

2. Follower
   Follower服务器是ZooKeeper集群状态的跟随者，主要工作:
   a. 处理客户端非事务请求，转发事务请求给Leader服务器。
   b. 参与事务请求Proposal的投票
   c. 参与Leader选举投票

3. Observer
   工作原理与Follower基本一致，唯一区别在于Observer不参与任何形式的投票，包括事务请求Proposal的投票和Leader选举投票。简单的讲，Observer服务器只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。

服务器状态

• LOOKING
• FOLLOWING
• LEADING
• OBSERVING

服务器启动时leader选举

假设有两台服务器s1、s2

• step1. 每个server发出自己的投票，以 (myid, ZXID) 的形式表示一次投票，初始阶段都会将票投给自己，然后发给所有其他的机器，两台机器的投票如下：

  1 2	s1->(1, 0) s2->(2, 0)

• step2. 接受来自各个服务器的投票，集群中的每个服务器在接收到投票后，会先检查是否本轮投票、是否来自LOOKING状态的服务器

• step3. 处理投票，在接收到来自其他服务器的投票后，当前服务器需要和其进行pk，pk的规则如下：

  1. 首先比较ZXID，ZXID大者优先作为LEADER
  2. 其次比较myid，myid大的作为LEADER

     1 2	对于s1，更新投票信息为 (2, 0)，然后发给其他机器 对于s2，不用更新投票信息，直接将原投票(2, 0)发给其他机器

• step4. 统计投票，每次投票后，服务器都会统计是否有过半的机器收到相同的投票信息（>= n/2+1），若满足则认为已经选出了LEADER。

• step5. 改变服务器状态，若为LEADER则变为LEADING，若为FOLLOWER则变为FOLLOWING

服务器运行期间leader选举

在Zookeeper集群运行过程中，各自的角色一般不会变化，即使新加入机器或者FOLLOWER挂掉；但一旦LEADER挂掉，整个集群就暂时无法对外服务，会进入新一轮的LEADER选举，过程和启动时类似。

假设有s1、s2、s3三台服务器，s2是LEADER，s2挂了

• step1. 变更状态，所有的FOLLOWER将状态变更为LOOKING，进入选角流程

• step2. 每个server发出自己的投票，由于是在运行过程中，每台机器的ZXID可能不同，s1、s3两台机器的投票如下：

  1 2	s1->(1, 123) s3->(3, 122)

• step3. 接受来自各个服务器的投票

• step4. 处理投票，处理投票时pk的规则和启动时是一样的，s1最终会成为LEADER
• step5. 统计投票
• step6. 改变服务器状态

tcpdump

简介

用简单的话来定义tcpdump，就是：dump the traffic on a network，根据使用者的定义对网络上的数据包进行截获的包分析工具。 tcpdump可以将网络中传送的数据包的“头”完全截获下来提供分析。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息。

命令

1

tcpdump (选项)

选项

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

-a：尝试将网络和广播地址转换成名称；
-c<数据包数目>：收到指定的数据包数目后，就停止进行倾倒操作；
-d：把编译过的数据包编码转换成可阅读的格式，并倾倒到标准输出；
-dd：把编译过的数据包编码转换成C语言的格式，并倾倒到标准输出；
-ddd：把编译过的数据包编码转换成十进制数字的格式，并倾倒到标准输出；
-e：在每列倾倒资料上显示连接层级的文件头；
-f：用数字显示网际网络地址；
-F<表达文件>：指定内含表达方式的文件；
-i<网络界面>：使用指定的网络截面送出数据包；
-l：使用标准输出列的缓冲区；
-n：不把主机的网络地址转换成名字；
-N：不列出域名；
-O：不将数据包编码最佳化；
-p：不让网络界面进入混杂模式；
-q ：快速输出，仅列出少数的传输协议信息；
-r<数据包文件>：从指定的文件读取数据包数据；
-s<数据包大小>：设置每个数据包的大小；
-S：用绝对而非相对数值列出TCP关联数；
-t：在每列倾倒资料上不显示时间戳记；
-tt： 在每列倾倒资料上显示未经格式化的时间戳记；
-T<数据包类型>：强制将表达方式所指定的数据包转译成设置的数据包类型；
-v：详细显示指令执行过程；
-vv：更详细显示指令执行过程；
-x：用十六进制字码列出数据包资料；
-w<数据包文件>：把数据包数据写入指定的文件。

使用例子

1. 首先在端口5555启动一个监听程序

2. 执行命令

   1	sudo tcpdump -i lo tcp port 5555

3. telnet连接这个端口

   1	telnet 127.0.0.1 5555

4. 抓包结果

   1 2 3

   17:46:14.089113 IP localhost.17827 > localhost.5555: Flags [S], seq 3155508131, win 43690, options [mss 65495,sackOK,TS val 346898 ecr 0,nop,wscale 7], length 0 17:46:14.089133 IP localhost.5555 > localhost.17827: Flags [S.], seq 1578794747, ack 3155508132, win 43690, options [mss 65495,sackOK,TS val 346898 ecr 346898,nop,wscale 7], length 0 17:46:14.089180 IP localhost.17827 > localhost.5555: Flags [.], ack 1, win 342, options [nop,nop,TS val 346898 ecr 346898], length

可以看到tcp的三次握手的过程

wireshark

tcpdump 对截获的数据并没有进行彻底解码，数据包内的大部分内容是使用十六进制的形式直接打印输出的。显然这不利于分析网络故障，通常的解决办法是先使用带-w参数的tcpdump 截获数据并保存到文件中，然后再使用其他程序(如Wireshark)进行解码分析。当然也应该定义过滤规则，以避免捕获的数据包填满整个硬盘

概念

cpu利用cache和内存之间交换数据的最小粒度不是字节，而是称为cacheline的一块固定大小的区域，这篇文章也对于cacheline作了很详细的分析

• Cache hierarchy
  Cache的层次，一般有L1, L2, L3 （L是level的意思）的cache。通常来说L1，L2是集成 在CPU里面的（可以称之为On-chip cache），而L3是放在CPU外面（可以称之为Off-chip cache）。当然这个不是绝对的，不同CPU的做法可能会不太一样。这里面应该还需要加上register，虽然register不是cache，但是把数据放到register里面是能够提高性能的。

• Cache size
  Cache的容量决定了有多少代码和数据可以放到Cache里面，有了Cache才有了竞争，才有了替换，才有了优化的空间。如果一个程序的热点(hotspot)已经完全填充了整Cache，那么再从Cache角度考虑优化就是白费力气了，巧妇难为无米之炊。我们优化程序的目标是把程序尽可能放到Cache里面，但是把程序写到能够占满整个Cache还是有一定难度的，这么大的一个Code path，相应的代码得有多少，代码逻辑肯定是相当的复杂（基本上是不可能，至少我没有见过）。

• Cache line size
  CPU从内存load数据是一次一个cache line；往内存里面写也是一次一个cache line，所以一个cache line里面的数据最好是读写分开，否则就会相互影响。

• Cache associative
  Cache的关联。有全关联(full associative)，内存可以映射到任意一个Cache line；也有N-way关联，这个就是一个哈希表的结构，N就是冲突链的长度，超过了N，就需要替换。

• Cache type
  有I-cache（指令cache），D-cache（数据cache），TLB（MMU的cache），每一种又有L1,L2等等，有区分指令和数据的cache，也有不区分指令和数据的cache。

查看cacheline大小的方法

1
2
3
4
5
6
7
8
9

cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
# 如何在程序中利用好cacheline
对于这个问题，brpc的文档中有这样的总结
 要提高性能，就要避免让CPU频繁同步cacheline。这不单和原子指令本身的性能有关，还会影响到程序的整体性能。最有效的解决方法很直白：尽量避免共享。
 * 一个依赖全局多生产者多消费者队列(MPMC)的程序难有很好的多核扩展性，因为这个队列的极限吞吐取决于同步cache的延时，而不是核心的个数。最好是用多个SPMC或多个MPSC队列，甚至多个SPSC队列代替，在源头就规避掉竞争。
 * 另一个例子是计数器，如果所有线程都频繁修改一个计数器，性能就会很差，原因同样在于不同的核心在不停地同步同一个cacheline。如果这个计数器只是用作打打日志之类的，那我们完全可以让每个线程修改thread-local变量，在需要时再合并所有线程中的值，性能可能有几十倍的差别。

参考文献

• http://cenalulu.github.io/linux/all-about-cpu-cache/
• http://igoro.com/archive/gallery-of-processor-cache-effects/

• new：不能被重载，其行为总是一致的。先调用operator
• new分配内存，然后调用构造函数初始化那段内存。
• operator new：要实现不同的内存分配行为，应该重载operator new，而不是new。

placement new：只是operator new重载的一个版本。它并不分配内存，只是返回指向已经分配好的某段内存的一个指针。因此在删除该对象时，需要调用对象的析构函数。

下面重点讲placement new:

placement new 是重载operator new的一个标准、全局的版本，它不能被自定义的版本代替（不像普通的operator new和operator delete能够被替换成用户自定义的版本）。

它的原型如下：

1

void *operator new( size_t, void *p ) throw() { return p; }

首先我们区分下几个容易混淆的关键词：new、operator new、placement new
new和delete操作符我们应该都用过，它们是对堆中的内存进行申请和释放，而这两个都是不能被重载的。要实现不同的内存分配行为，需要重载operator new，而不是new和delete。

看如下代码：

1
2

class MyClass {…};
MyClass * p=new MyClass;

这里的new实际上是执行如下3个过程：

1. 调用operator new分配内存；
2. 调用构造函数生成类对象；
3. 返回相应指针。

operator new就像operator+一样，是可以重载的。如果类中没有重载operator new，那么调用的就是全局的::operator new来完成堆的分配。同理，operator new[]、operator delete、operator delete[]也是可以重载的，一般你重载的其中一个，那么最后把其余的三个都重载一遍。

至于placement new才是本文的重点。其实它也只是operator new的一个重载的版本，只是我们很少用到它。如果你想在已经分配的内存中创建一个对象，使用new时行不通的。也就是说placement new允许你在一个已经分配好的内存中（栈或者堆中）构造一个新的对象。原型中void*p实际上就是指向一个已经分配好的内存缓冲区的的首地址。

我们知道使用new操作符分配内存需要在堆中查找足够大的剩余空间，这个操作速度是很慢的，而且有可能出现无法分配 内存的异常（空间不够）。 placement new就可以解决这个问题。我们构造对象都是在一个预先准备好了的内存缓冲区中进行，不需要查找内存，内存分配的时间是常数；而且不会出现在程序运行中途 出现内存不足的异常。所以，placement new非常适合那些对时间要求比较高，长时间运行不希望被打断的应用程序。

使用方法如下：

1. 缓冲区提前分配
   可以使用堆的空间，也可以使用栈的空间，所以分配方式有如下两种：

   1 2	class MyClass {…}; char *buf=new char[N*sizeof(MyClass)+sizeof(int)];或者char buf[N*sizeof(MyClass)+sizeof(int)];

2. 对象的构造

   1	MyClass * pClass=new(buf) MyClass;

3. 对象的销毁
   一旦这个对象使用完毕，你必须显式的调用类的析构函数进行销毁对象。但此时内存空间不会被释放，以便其他的对象的构造。
   pClass->~MyClass();

4. 内存的释放
   如果缓冲区在堆中，那么调用delete[] buf;进行内存的释放；如果在栈中，那么在其作用域内有效，跳出作用域，内存自动释放。

注意：

在C++标准中，对于placement operator new []有如下的说明： placement operator new[] needs implementation-defined amount of additional storage to save a size of array. 所以我们必须申请比原始对象大小多出sizeof(int)个字节来存放对象的个数，或者说数组的大小。
使用方法第二步中的new才是placement new，其实是没有申请内存的，只是调用了构造函数，返回一个指向已经分配好的内存的一个指针，所以对象销毁的时候不需要调用delete释放空间，但必须调用析构函数销毁对象。

我们都知道多核编程常用锁避免多个线程在修改同一个数据时产生race condition。当锁成为性能瓶颈时，我们又总想试着绕开它，而不可避免地接触了原子指令。但在实践中，用原子指令写出正确的代码是一件非常困难的事，琢磨不透的race condition、ABA problem、memory fence很烧脑，这篇文章试图通过介绍SMP架构下的原子指令帮助大家入门。C++11正式引入了原子指令，我们就以其语法描述。

顾名思义，原子指令是对软件不可再分的指令，比如x.fetch_add(n)指原子地给x加上n，这个指令对软件要么没做，要么完成，不会观察到中间状态。常见的原子指令有：

你已经可以用这些指令做原子计数，比如多个线程同时累加一个原子变量，以统计这些线程对一些资源的操作次数。但是，这可能会有两个问题：

• 这个操作没有你想象地快。
• 如果你尝试通过看似简单的原子操作控制对一些资源的访问，你的程序有很大几率会crash。

Cacheline

没有任何竞争或只被一个线程访问的原子操作是比较快的，“竞争”指的是多个线程同时访问同一个cacheline。现代CPU为了以低价格获得高性能，大量使用了cache，并把cache分了多级。常见的Intel E5-2620拥有32K的L1 Data Cache和Instruction Cache，256K的L2 cache和15M的L3 cache。其中L1和L2 cache为每个核心独有，L3则所有核心共享。一个核心写入自己的L1 cache是极快的(4 cycles, ~2ns)，但当另一个核心读或写同一处内存时，它得确认看到其他核心中对应的cacheline。对于软件来说，这个过程是原子的，不能在中间穿插其他代码，只能等待CPU完成一致性同步，这个复杂的硬件算法使得原子操作会变得很慢，在E5-2620上竞争激烈时fetch_add会耗费700纳秒左右。访问被多个线程频繁共享的内存往往是比较慢的。比如像一些场景临界区看着很小，但保护它的spinlock性能不佳，因为spinlock使用的exchange, fetch_add等指令必须等待最新的cacheline，看上去只有几条指令，花费若干微秒并不奇怪。

要提高性能，就要避免让CPU频繁同步cacheline。这不单和原子指令本身的性能有关，还会影响到程序的整体性能。最有效的解决方法很直白：尽量避免共享。

• 一个依赖全局多生产者多消费者队列(MPMC)的程序难有很好的多核扩展性，因为这个队列的极限吞吐取决于同步cache的延时，而不是核心的个数。最好是用多个SPMC或多个MPSC队列，甚至多个SPSC队列代替，在源头就规避掉竞争。
• 另一个例子是计数器，如果所有线程都频繁修改一个计数器，性能就会很差，原因同样在于不同的核心在不停地同步同一个cacheline。如果这个计数器只是用作打打日志之类的，那我们完全可以让每个线程修改thread-local变量，在需要时再合并所有线程中的值，性能可能有几十倍的差别。

一个相关的编程陷阱是false sharing：对那些不怎么被修改甚至只读变量的访问，由于同一个cacheline中的其他变量被频繁修改，而不得不经常等待cacheline同步而显著变慢了。多线程中的变量尽量按访问规律排列，频繁被其他线程修改的变量要放在独立的cacheline中。要让一个变量或结构体按cacheline对齐，可以include \后使用BAIDU_CACHELINE_ALIGNMENT宏，请自行grep brpc的代码了解用法。

Memory fence

仅靠原子技术实现不了对资源的访问控制，即使简单如spinlock或引用计数，看上去正确的代码也可能会crash。这里的关键在于重排指令导致了读写顺序的变化。只要没有依赖，代码中在后面的指令就可能跑到前面去，编译器和CPU都会这么做。

这么做的动机非常自然，CPU要尽量塞满每个cycle，在单位时间内运行尽量多的指令。如上节中提到的，访存指令在等待cacheline同步时要花费数百纳秒，最高效地自然是同时同步多个cacheline，而不是一个个做。一个线程在代码中对多个变量的依次修改，可能会以不同的次序同步到另一个线程所在的核心上。不同线程对数据的需求不同，按需同步也会导致cacheline的读序和写序不同。

如果其中第一个变量扮演了开关的作用，控制对后续变量的访问。那么当这些变量被一起同步到其他核心时，更新顺序可能变了，第一个变量未必是第一个更新的，然而其他线程还认为它代表着其他变量有效，去访问了实际已被删除的变量，从而导致未定义的行为。比如下面的代码片段：

1
2
3
4

// Thread 1
// ready was initialized to false
p.init();
ready = true;

1
2
3
4

// Thread2
if (ready) {
    p.bar();
}

从人的角度，这是对的，因为线程2在ready为true时才会访问p，按线程1的逻辑，此时p应该初始化好了。但对多核机器而言，这段代码可能难以正常运行：

• 线程1中的ready = true可能会被编译器或cpu重排到p.init()之前，从而使线程2看到ready为true时，p仍然未初始化。这种情况同样也会在线程2中发生，p.bar()中的一些代码可能被重排到检查ready之前。
• 即使没有重排，ready和p的值也会独立地同步到线程2所在核心的cache，线程2仍然可能在看到ready为true时看到未初始化的p。

注：x86/x64的load带acquire语意，store带release语意，上面的代码刨除编译器和CPU因素可以正确运行。

通过这个简单例子，你可以窥见原子指令编程的复杂性了吧。为了解决这个问题，CPU和编译器提供了memory fence，让用户可以声明访存指令间的可见性(visibility)关系，boost和C++11对memory fence做了抽象，总结为如下几种memory order.

有了memory order，上面的例子可以这么更正：

1
2
3
4

// Thread1
// ready was initialized to false
p.init();
ready.store(true, std::memory_order_release);

1
2
3
4

// Thread2
if (ready.load(std::memory_order_acquire)) {
    p.bar();
}

线程2中的acquire和线程1的release配对，确保线程2在看到ready==true时能看到线程1 release之前所有的访存操作。

注意，memory fence不等于可见性，即使线程2恰好在线程1在把ready设置为true后读取了ready也不意味着它能看到true，因为同步cache是有延时的。memory fence保证的是可见性的顺序：“假如我看到了a的最新值，那么我一定也得看到b的最新值”。

一个相关问题是：如何知道看到的值是新还是旧？一般分两种情况：

• 值是特殊的。比如在上面的例子中，ready=true是个特殊值，只要线程2看到ready为true就意味着更新了。只要设定了特殊值，读到或没有读到特殊值都代表了一种含义。
• 总是累加。一些场景下没有特殊值，那我们就用fetch_add之类的指令累加一个变量，只要变量的值域足够大，在很长一段时间内，新值和之前所有的旧值都会不相同，我们就能区分彼此了。

原子指令的例子可以看boost.atomic的Example，atomic的官方描述可以看这里。

wait-free & lock-free

原子指令能为我们的服务赋予两个重要属性：wait-free和lock-free。前者指不管OS如何调度线程，每个线程都始终在做有用的事；后者比前者弱一些，指不管OS如何调度线程，至少有一个线程在做有用的事。如果我们的服务中使用了锁，那么OS可能把一个刚获得锁的线程切换出去，这时候所有依赖这个锁的线程都在等待，而没有做有用的事，所以用了锁就不是lock-free，更不会是wait-free。为了确保一件事情总在确定时间内完成，实时系统的关键代码至少是lock-free的。在百度广泛又多样的在线服务中，对时效性也有着严苛的要求，如果RPC中最关键的部分满足wait-free或lock-free，就可以提供更稳定的服务质量。事实上，brpc中的读写都是wait-free的。

值得提醒的是，常见想法是lock-free或wait-free的算法会更快，但事实可能相反，因为：

• lock-free和wait-free必须处理更多更复杂的race condition和ABA problem，完成相同目的的代码比用锁更复杂。代码越多，耗时就越长。
• 使用mutex的算法变相带“后退”效果。后退(backoff)指出现竞争时尝试另一个途径以临时避免竞争，mutex出现竞争时会使调用者睡眠，使拿到锁的那个线程可以很快地独占完成一系列流程，总体吞吐可能反而高了。

mutex导致低性能往往是因为临界区过大（限制了并发度），或竞争过于激烈（上下文切换开销变得突出）。lock-free/wait-free算法的价值在于其保证了一个或所有线程始终在做有用的事，而不是绝对的高性能。但在一种情况下lock-free和wait-free算法的性能多半更高：就是算法本身可以用少量原子指令实现。实现锁也是要用原子指令的，当算法本身用一两条指令就能完成的时候，相比额外用锁肯定是更快了。

Redis 持久化

Redis 提供了多种不同级别的持久化方式：

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
你甚至可以关闭持久化功能，让数据只在服务器运行时存在。
了解 RDB 持久化和 AOF 持久化之间的异同是非常重要的， 以下几个小节将详细地介绍这这两种持久化功能， 并对它们的相同和不同之处进行说明。

RDB 的优点

RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。

RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB 的缺点

如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。

每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

AOF 的优点

使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync策略，比如无 fsync，每秒钟一次 fsync，或者每次执行写入命令时 fsync 。

AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync
会在后台线程执行，所以主线程可以继续努力地处理命令请求）。

AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof
工具也可以轻易地修复这种问题。

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 的缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
根据所使用的 fsync策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync的性能依然非常高， 而关闭 fsync可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

RDB 和 AOF ，我应该用哪一个？

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。

因为以上提到的种种原因， 未来我们可能会将 AOF 和 RDB 整合成单个持久化模型。 （这是一个长期计划。）
接下来的几个小节将介绍 RDB 和 AOF 的更多细节。

RDB 快照

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。

你可以对 Redis 进行设置， 让它在“ N秒内数据集至少有 M个改动”这一条件被满足时， 自动保存一次数据集。

你也可以通过调用 SAVE 或者 BGSAVE ， 手动让 Redis 进行数据集保存操作。

比如说， 以下设置会让 Redis 在满足“ 60秒内有至少有 1000个键被改动”这一条件时， 自动保存一次数据集：
save 60 1000

这种持久化方式被称为快照（snapshot）。

快照的运作方式

当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：

Redis 调用 fork() ，同时拥有父进程和子进程。
子进程将数据集写入到一个临时 RDB 文件中。
当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。

只进行追加操作的文件（append-only file，AOF）

快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。

尽管对于某些程序来说， 数据的耐久性并不是最重要的考虑因素， 但是对于那些追求完全耐久能力（full durability）的程序来说， 快照功能就不太适用了。

从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

你可以通过修改配置文件来打开 AOF 功能：

appendonly yes

从现在开始， 每当 Redis 执行一个改变数据集的命令时（比如 SET）， 这个命令就会被追加到 AOF 文件的末尾。

这样的话， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。

AOF 重写

因为 AOF 的运作方式是不断地将命令追加到文件的末尾， 所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大。

举个例子， 如果你对一个计数器调用了 100 次 INCR ， 那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录（entry）。

然而在实际上， 只使用一条 SET 命令已经足以保存计数器的当前值了， 其余 99 条记录实际上都是多余的。

为了处理这种情况， Redis 支持一种有趣的特性： 可以在不打断服务客户端的情况下， 对 AOF 文件进行重建（rebuild）。

执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。

Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令； Redis 2.4 则可以自动触发 AOF 重写， 具体信息请查看 2.4 的示例配置文件

AOF 有多耐久？

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。

有三个选项：

每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。
每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。
推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

总是 fsync 的策略在实际使用中非常慢， 即使在 Redis 2.0 对相关的程序进行了改进之后仍是如此 —— 频繁调用 fsync 注定了这种策略不可能快得起来。

如果 AOF 文件出错了，怎么办？(http://doc.redisfans.com/topic/persistence.html#id9)

服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。

当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：

为现有的 AOF 文件创建一个备份。
使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。
$ redis-check-aof –fix

（可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。
重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

AOF 的运作方式

AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制。

以下是 AOF 重写的执行步骤：

Redis 执行 fork() ，现在同时拥有父进程和子进程。

子进程开始将新 AOF 文件的内容写入到临时文件。

对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。

当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。

搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

怎么从 RDB 持久化切换到 AOF 持久化

在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF ：

为最新的 dump.rdb 文件创建一个备份。
将备份放到一个安全的地方。
执行以下两条命令：
redis-cli> CONFIG SET appendonly yes
redis-cli> CONFIG SET save “”

确保命令执行之后，数据库的键的数量没有改变。
确保写命令会被正确地追加到 AOF 文件的末尾。
步骤 3 执行的第一条命令开启了 AOF 功能： Redis 会阻塞直到初始 AOF 文件创建完成为止， 之后 Redis 会继续处理命令请求， 并开始将写入命令追加到 AOF 文件末尾。

步骤 3 执行的第二条命令用于关闭 RDB 功能。 这一步是可选的， 如果你愿意的话， 也可以同时使用 RDB 和 AOF 这两种持久化功能。

RDB 和 AOF 之间的相互作用

在版本号大于等于 2.4 的 Redis 中， BGSAVE 执行的过程中， 不可以执行 BGREWRITEAOF 。 反过来说， 在 BGREWRITEAOF 执行的过程中， 也不可以执行 BGSAVE 。

这可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。

如果 BGSAVE 正在执行， 并且用户显示地调用 BGREWRITEAOF 命令， 那么服务器将向用户回复一个 OK状态， 并告知用户，BGREWRITEAOF 已经被预定执行： 一旦 BGSAVE 执行完毕， BGREWRITEAOF 就会正式开始。

当 Redis 启动时， 如果 RDB 持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的。

备份 Redis 数据

在阅读这个小节前， 先将下面这句话铭记于心： 一定要备份你的数据库！

磁盘故障， 节点失效， 诸如此类的问题都可能让你的数据消失不见， 不进行备份是非常危险的。

Redis 对于数据备份是非常友好的， 因为你可以在服务器运行的时候对 RDB 文件进行复制： RDB 文件一旦被创建， 就不会进行任何修改。 当服务器要创建一个新的 RDB 文件时， 它先将文件的内容保存在一个临时文件里面， 当临时文件写入完毕时， 程序才使用 rename(2) 原子地用临时文件替换原来的 RDB 文件。

这也就是说， 无论何时， 复制 RDB 文件都是绝对安全的。

以下是我们的建议：

创建一个定期任务（cron job）， 每小时将一个 RDB 文件备份到一个文件夹， 并且每天将一个 RDB 文件备份到另一个文件夹。
确保快照的备份都带有相应的日期和时间信息， 每次执行定期任务脚本时， 使用 find 命令来删除过期的快照： 比如说， 你可以保留最近 48 小时内的每小时快照， 还可以保留最近一两个月的每日快照。
至少每天一次， 将 RDB 备份到你的数据中心之外， 或者至少是备份到你运行 Redis 服务器的物理机器之外。