两台服务器,一个放程序的,一个放数据库换季,redis装在哪个服务器上好

应用Redis实现数据的读写，同时利用队列处理器定时将数据写入mysql，此种情况存在的问题主要是如何保证mysql与redis的数据同步，二者数据同步的关键在于mysql数据库中

主键，方案是在redis启动时去mysql读取所有表键值存入redis中，往redis写数据时，对redis主键自增并进行读取，若mysql更新

失败，则需要及时清除缓存及同步redis主键。Stringtbname="login";//获取mysql表主键值--redis启动时

longid=MySQLgetID(tbname);//设置redis主键值--redis启动时

redisServiceset(tbname,StringvalueOf(id));Systemoutprintln(id);longl=redisServiceincr(tbname);

Systemoutprintln(l);Loginlogin=newLogin();loginsetId(l);

loginsetName("redis");redisServicehmset(StringvalueOf(logingetId()),login);booleanb=MySQLinsert("insertintologin(id,name)values("+logingetId()+",'"+logingetName()+"')");

/队列处理器更新mysql失败：清除缓存数据，同时主键值自减/if(!b)

{redisServicedelKeyAndDecr(tbname,"Login:"+StringvalueOf(logingetId()));}Systemoutprintln(redisServiceexists("Login:"+StringvalueOf(logingetId())));Systemoutprintln(redisServiceget(tbname))

redis缓存原理是sql语句时key值，查询结果resultSet是value，当同一个查询语句访问时（select from t_product），只要曾经查询过，调用缓存直接返回resultSet，节省了数据库读取磁盘数据的时间。

redis的存储分为内存存储、磁盘存储和log文件三部分，配置文件中有三个参数对其进行配置。

save seconds updates，save配置，指出在多长时间内，有多少次更新操作，就将数据同步到数据文件。这个可以多个条件配合，比如默认配置文件中的设置，就设置了三个条件。

appendonly yes/no ，appendonly配置，指出是否在每次更新操作后进行日志记录，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面的save条件来同步的，所以有的数据会在一段时间内只存在于内存中。

扩展资料

redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。 

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。

存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

redis的官网地址，redisio。（域名后缀io属于国家域名，是british Indian Ocean territory，即英属印度洋领地）

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助。

概述

在现有企业中80%公司大部分使用的是redis单机服务，在实际的场景当中单一节点的redis容易面临风险。

2、容量瓶颈。 当我们有需求需要扩容 Redis 内存时，从 16G 的内存升到 64G，单机肯定是满足不了。当然，你可以重新买个 128G 的新机器。

解决办法

要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上。

Redis 为了解决这个单一节点的问题，也会把数据复制多个副本部署到其他节点上进行复制，实现 Redis的高可用，实现对数据的冗余备份，从而保证数据和服务的高可用。

主从复制

什么是主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)，数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的作用

1、数据冗余： 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2、故障恢复： 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3、负载均衡： 在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4、读写分离： 可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量。

5、高可用基石： 除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

主从复制启用

从节点开启主从复制，有3种方式：

1、配置文件： 在从服务器的配置文件中加入 slaveof<masterip><masterport>。

2、启动命令： redis-server启动命令后加入 --slaveof<masterip><masterport>。

3、客户端命令： Redis服务器启动后，直接通过客户端执行命令 slaveof<masterip><masterport>，则该Redis实例成为从节点。

通过 info replication 命令可以看到复制的一些信息。

主从复制原理

主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。

在从节点执行 slaveof 命令后，复制过程便开始运作，下面图示可以看出复制过程大致分为6个过程。

主从配置之后的日志记录也可以看出这个流程。

1、保存主节点（master）信息

执行 slaveof 后 Redis 会打印如下日志：

2、从节点与主节点建立网络连接

从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。

从节点与主节点建立网络连接。

从节点会建立一个 socket 套接字，从节点建立了一个端口为51234的套接字，专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志：

如果从节点无法建立连接，定时任务会无限重试直到连接成功或者执行 slaveofnoone 取消复制。

关于连接失败，可以在从节点执行 info replication 查看 master_link_down_since_seconds 指标，它会记录与主节点连接失败的系统时间。从节点连接主节点失败时也会每秒打印如下日志，方便发现问题：

3、发送 ping 命令

连接建立成功后从节点发送 ping 请求进行首次通信， ping 请求主要目的如下：

如果发送 ping 命令后，从节点没有收到主节点的 pong 回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连。

从节点发送的 ping 命令成功返回，Redis 打印如下日志，并继续后续复制流程：

4、权限验证

如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证。如果验证失败复制将终止，从节点重新发起复制流程。

5、同步数据集

主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。

6、命令持续复制

当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

作者：LoyaltyLu

链接：https://segmentfaultcom/a/1190000018268350

前言

上篇文章简单介绍canal概念，本文结合常见的缓存业务去讲解canal使用。在实际开发过程中，通常都会把数据往redis缓存中保存一份，做下简单的查询优化。如果这时候数据库数据发生变更操作，就不得不在业务代码中写一段同步更新redis的代码，但是这种 数据同步的代码和业务代码糅合在一起 看起来不是很优雅，而且还会出现数据不一致问题。那能不能把这部分同步代码从中抽离出来，形成独立模块呢？答案是肯定的，下面通过canal结合Kafka来实现mysql与redis之间的数据同步。

架构设计

通过上述结构设计图可以很清晰的知道用到的组件：MySQL、Canal、Kafka、ZooKeeper、Redis。

Kafka&Zookeeper搭建

首先在 官网 下载Kafka：

下载后解压文件夹，可以看到以下几个文件：

Kafka内部自带了zookeeper，所以暂不需要去下载搭建zookeeper集群，本文就使用Kafka自带zookeeper来实现。

通过上述zookeeper启动命令以及Kafka启动命令把服务启动，可以通过以下简单实现下是否成功：

Canal搭建

canal搭建具体可以参考上文，这里只讲解具体的参数配置：

找到/conf目录下的canalproperties配置文件：

然后配置instance，找到/conf/example/instanceproperties配置文件：

经过上述配置后，就可以启动canal了。

测试

环境搭建完成后，就可以编写代码进行测试。

1、引入pom依赖

2、封装Redis工具类

在applicationyml文件增加以下配置：

封装一个操作Redis的工具类：

3、创建MQ消费者进行同步

创建一个CanalBean对象进行接收：

最后就可以创建一个消费者CanalConsumer进行消费：

测试Mysql与Redis同步

mysql对应的表结构如下：

启动项目后，新增一条数据：

可以在控制台看到以下输出：

如果更新呢？试一下Update语句：

同样可以在控制台看到以下输出：

经过测试完全么有问题。

总结

既然canal这么强大，难道就没缺点嘛？答案当然是存在的啦，比如：canal只能同步增量数据、不是实时同步而是准实时同步、MQ顺序问题等； 尽管有一些缺点，毕竟没有一样技术或者产品是完美的，最重要是合适。比如公司目前有个视图服务提供宽表搜索查询功能就是通过 同步Mysql数据到Es采用Canal+Kafka的方式来实现的。

在完成事件接入的需求时，我们需要记录上一个批次拉取的事件，并与当前拉取到的事件做出比对，从而进行差分。我们目前的做法是使用redis来进行缓存:将上一个批次拉取到的事件缓存到一个list中。但是当事件数量过多时，value的大小会超过1M的限制，直接抛出异常。这其实是Tair出于性能的考虑而做出的限制，本文将谈谈我个人对于bigKey的理解。

顾名思义，bigKey指一个key对应的value占据的内存空间相对比较大，bigKey通常会有两种表现形式:

bigKey一旦产生，将会对tair的性能以及稳定性造成较大的影响，下面我将详细介绍一下bigKey的危害。

bigKey给tair带来的危害是多方面的，性能下降只是其中的一方面，极端情况下，bigKey甚至会导致缓存服务崩溃。下面我将从几个角度进行分析。

我们可以看到:

另外，在Redis执行异步重写操作时(bgrewriteaof)，主线程会fork出一个子进程来执行重写命令，这个子进程会与主线程共享内存。当主线程收到了新增或者修改一个key的命令，主线程会申请一块额外的内存空间来保存数据。但如果这个key是一个bigKey时，主线程会去申请一块更大空间，同样会阻塞主线程(与JVM分配内存一样，涉及锁和同步)。如果申请不到足够的空间，会导致Swap甚至会有OOM的风险，这同样会降低Redis的性能和稳定性。

Tair中一个key最大为1M，我们就以1M举例，当访问这个key的QPS为1000时，每秒将会有1GB左右的流量，对于带宽来说将是一个较大压力。如果这个bigKey是一个热点key时，后果将不堪设想。

如果主从同步的 client-output-buffer-limit 设置过小，并且 master 存在大量bigKey(数据量很大)，主从全量同步时可能会导致 buffer 溢出，溢出后主从全量同步就会失败。如果主从集群配置了哨兵，那么哨兵会让 slave 继续向 master 发起全量同步请求，然后 buffer 又溢出同步失败，如此反复，会形成复制风暴，这会浪费 master 大量的 CPU、内存、带宽资源，也会让 master 产生阻塞的风险。 另外，当我们使用Redis Cluster时，由于Redis Cluster采用了同步迁移的方式，bigKey同样会阻塞主线程。这里提一下Codis，Codis在迁移bigKey时，使用了异步迁移 + 指令拆分的方式，对于bigKey (集合类型) 中每个元素，用一条指令进行迁移，而不是把整个 bigKey 进行序列化后再整体传输。这种化整为零的方式，就避免了 bigKey 迁移时，因为要序列化大量数据而阻塞的问题。

当我们写入或者读取大量bigKey的时候，很有可能导致输入/输出缓冲区溢出。如果客户端占用的内存总量超过了服务器设置的maxmemory时(默认4GB)，将会直接触发服务器的内存淘汰策略，如果有数据被淘汰，再要获取这些数据就需要到后端回源，间接降低了缓存系统的性能。同时，淘汰的如果是bigKey也同样会阻塞主线程。另外，在极端情况下，多个客户端占用了过多的内存将导致OOM，进而使得整个redis进程崩溃。

使用切片集群的时候，我们通常会将不同的key存放在不同的实例上，如果存在bigKey的话，会导致相应实例的数据量增大，内存压力也相应增大。

常用的做法是通过/redis-cli --bigkeys命令对整个redis中的键值对进行统计，输出每种数据类型中最大的 bigkey 的信息。一般会配合-i参数一起使用,控制扫描间隔，避免长时间扫描降低 Redis 实例的性能。另外该命令不要在业务高峰期使用。

或者我们可以通过debug object key 命令去查看serializedlength属性，serializedlength表示key对应的value序列化后的字节数，通过观察serializedlength的大小可以辅助排查bigKey。使用scan + debug object key命令，我们可以计算其中每个key的serializedlength，进而发现其中的bigKey，并做好相应的监控和处理。不过对于集合类型的bigKey，debug object key 命令的执行效率不高，存在阻塞redis的风险。

另外，在读取bigKey的时候，我们尽量不要一次性将全部数据读取出来，而是采用分批的方式进行读取:利用scan命令进行渐进式遍历，将大量数据分批多次读取出来，减小redis的压力，避免阻塞的风险。

同样的，在删除bigKey的时候我们也可以使用scan命令来进行批量删除。如果你是用的redis是40之后的版本，则可以利用unlink命令配合lazy free配置(需要手动开启)来进行异步删除，避免主线程阻塞。

MYSQL快速同步数据到Redis

举例场景：存储游戏玩家的任务数据，游戏服务器启动时将mysql中玩家的数据同步到redis中。

从MySQL中将数据导入到Redis的Hash结构中。当然，最直接的做法就是遍历MySQL数据，一条一条写入到Redis中。这样没什么错，但是速度会非常慢。如果能够想法使得MySQL的查询输出数据直接能够与Redis命令行的输入数据协议相吻合，可以节省很多消耗和缩短时间。

Mysql数据库名称为：GAME_DB, 表结构举例：

CREATE TABLE TABLE_MISSION (

playerId int(11) unsigned NOT NULL,

missionList varchar(255) NOT NULL,

PRIMARY KEY (playerId)

);

Redis中的数据结构使用哈希表：

键KEY为mission, 哈希域为mysql中对应的playerId, 哈希值为mysql中对应的missionList。 数据如下：

[root@iZ23zcsdouzZ ~]# redis-cli

127001:6379> hget missions 36598

"{\"10001\":{\"status\":1,\"progress\":0},\"10002\":{\"status\":1,\"progress\":0},\"10003\":{\"status\":1,\"progress\":0},\"10004\":{\"status\":1,\"progress\":0}}"

快速同步方法：

新建一个后缀sql文件：mysql2redis_missionsql

内容如下：

SELECT CONCAT(

"4\r\n",

'$', LENGTH(redis_cmd), '\r\n',

redis_cmd, '\r\n',

'$', LENGTH(redis_key), '\r\n',

redis_key, '\r\n',

'$', LENGTH(hkey), '\r\n',

hkey, '\r\n',

'$', LENGTH(hval), '\r\n',

hval, '\r'

)

FROM (

SELECT

'HSET' as redis_cmd,

'missions' AS redis_key,

playerId AS hkey,

missionList AS hval

FROM TABLE_MISSION

) AS t

创建shell脚本mysql2redis_missionsh

内容：

mysql GAME_DB --skip-column-names --raw < missionsql | redis-cli --pipe

Linux系统终端执行该shell脚本或者直接运行该系统命令，即可将mysql数据库GAME_DB的表TABLE_MISSION数据同步到redis中键missions中去。mysql2redis_missionsql文件就是将mysql数据的输出数据格式和redis的输入数据格式协议相匹配，从而大大缩短了同步时间。

经过测试，同样一份数据通过单条取出修改数据格式同步写入到redis消耗的时间为5min, 使用上面的sql文件和shell命令，同步完数据仅耗时3s左右。

最近学习了一下Redis写一篇文章来总结一下学习成果，学习的方式主要是看书，看的是Redis 5设计与源码分析；想系统学习的同学，可以好好看看很推荐这本书，那么，为什么标题选择Redis为什么会那么快？因为，我在学习的过程中，感受到Redis的精髓就是快，为了快这个属性，它有了很多自己特殊设计及实现；

Redis快，我主要是基于三大部分的理解

下面分别对这2,3部分进行展开：

首先，先要知道Redis工作线程是单线程的，但是，整个Redis来说，是多线程的；

Redis事件处理 :

Redis 服务器是典型的事件驱动程序，而事件又分为文件事件(socket 的可读可写事件)与时间事件(定时任务)两大类。已经注册的文件事件存储在event[]数组中， 时间事件形成链表；Redis 底层可以使用4中I/O多路复用模型（kqueue、epoll、select等）根据操作系统的不同选择不同， 关于，多路复用模型相关内容可以查看我的另一篇文章 操作系统IO进化史 所以，epoll本身就效率很高了；但是，随着我们网卡的不断升级，在Redis 60之后的版本中，对IO的处理变成了多线程；

为什么对IO的处理变成了多线程能提高速度？

下面是Redis60之前的情况：

如果到了Redis60之后：

所以，这也是Redis快的一个主要原因；

由于，Redis中设计的话，主要分为底层设计结构以及一些相应的功能，所以，特定将其分为2部分来进行讲解；

Redis底层数据结构有简单动态字符串，跳跃表，压缩列表，字典，整数集合；针对，简单动态字符串，压缩列表，主要是考虑到节约内存；像跳跃表，字典，主要是考虑到查询速度，整数集合即考虑到了空间又考虑到了时间；其实像字典中的渐进式rehash，以及间断key查找，都是考虑到了节约时间；具体的内容可以查看我的另一篇文章， Redis底层数据结构

具体细节可查看官网

优点：最多有25%的过期key存在内存中，这种方法会比轮询更加省时间；就是稍微牺牲内存，来保证 redis的性能，就是快； 还是以空间换时间的思想；

注意 ：个人觉得这里和 缓存雪崩 还能建立其联系，如果，一个大型的redis实例中所有的key在同一时间过期了，那么，redis会持续扫描keys 因为，一直大于25%；虽然，这是有扫描时间的上限的25ms;这个时候，刚好客户端请求过来了，如果，客户端将超时时间设置的比较短，比如说10ms，那么就会出现大量链接因为超时而关闭，业务端也会出现很多异常。（客户端超时时间，如果说设置得太小，那么容易导致访问redis失败，如果，设置太大，那么，在redis异常的时候，不容易及时作出切换；一般是通过网络延迟和redis慢日志来进行查看的）

redis的特点是快，它虽然有事务，但是，它是没有回滚的，事务的功能是不够完善的； 回滚：代表失败时，回滚到事务开始的时刻；

redis 是单线程的 如果，有多个客户端，一个客户端的事务 并不会阻塞到其他客户端； 客户端1 发送 开启事务的标记 客户端2 也开启事务 。随着时间发展；2又连续发了一些命令 1 也发了一些命令； 这时候，会先看谁的执行指令先到； 假设 2 先到达，这个时候，先执行2 的相关数据，在执行1相关的命令； 如果 1 先到达，这个时候，先执行1 的相关命令，再执行2；

事务失败处理

这个时候，会发现报错那条语句不执行，剩下的语句都会进行执行；也没有发生了回滚；

证明 ：redis是不支持事务回滚的。在运行期错误，即使事务中有某条/某些命令执行失败了，事务队列中的其他命令仍然会继续执行 -- Redis 不会停止执行事务中的命令；

为什么Redis 不支持事务回滚？

总结 ：Redis为了快，而不支持事务回滚；

在redis中，有两个东西 第一个为RDB ， 第二个为AOF RDB为快照/副本相关内容， AOF为日志相关的内容；

RDB的特点 ：1需要时点性 （比如说：我有1G的内存，需要持久化到硬盘，比如说：一个小时持久化一次。那么，假设在8点，就需要进行持久化）

如何实现RDB持久化呢？

方法一：阻塞Redis ，Redis不再对外提供服务了，但是，这种方式是需要阻塞的，很显然，如果，这个持久化需要花费1s，那么，这个时候，Redis 不能被客户端进行使用；

方法二：非阻塞 Redis继续对外提供服务；

但是，这个时候会出现一个问题；比如说：8点开始RDB持久化，8点零1秒才持久化完，问题就来了：持久化的数据是8点的还是8点零1秒的呢？很显然，是8点的；那么，在8点到8点零1秒这个过程中，数据是会发生改变的，那么， 怎么解决这个数据不一致的问题呢？ 比如说：8点的时候，b = 10 到 8点零1秒的时候，b =20;

为了解决这个读写并存 使用CopyOnWrite 的思想来进行实现；

就是，在操作系统中，先使用fork() 创建子线程来复制一份副本（注意：这里拷贝的是指针，所以，速度会很快）然后，这个副本，就保持在8点不变了。然后，复制的时候，就复制这份副本就行了，对数据增删改查就在父进程中更改。

但是，因为父子进程都指向的是同一个内存，所以，不能在这个内存中改，比如说：不能在原来key 8 中进行更改，比如说要改key = 10 那么，就得在内存中，再创建一块区域，然后，让父进程中指针指向新的key ,这样两个进程就不会相互影响了。

这里也验证了Redis是多线程的；

具体实现：

RDB的缺点

RDB的优点 ：恢复数据的速度相对较快；

Redis内存大小选择 进程一般使用10G以内，因为从内存到磁盘持久化这个过程，如果说，10G需要写的时间比较久，那么，如何解决呢？1 减少内存 2 硬盘选择固态硬盘；

针对RDB容易丢失数据的问题，提出了AOF持久化机制

AOF : append on File 向文件中，进行追加；redis发生写操作时，会记录到文件中；

优点 ：1丢失的数据比较少

背景 ：RDB和AOF可以同时开启，如果，开启了AOF只会用AOF来进行恢复，即便RDB也开启了，也不会使用它；因为，AOF的修复比较准确；但是，AOF是比较慢的，所以，在40以后，AOF就包含了RDB全量，和增加的新的写操作。这样来提高速度；

缺点 ：由于，AOF是增加的方式，所以，如果一直增加的话，就会有 1体量无限变大 2恢复慢 的缺点；为了解决这个问题，需要设计出一个方案让日志AOF足够小；这个，就有了 重写 的方案；40之前，重写方案是将AOF进行瘦身，比如说：把创建key和删除key的命令进行抵消删除；40之后，就采用 混合持久化 比如说：我这个AOF已经到了100M文件了，这个时候，我先将老的数据变成RDB文件（二进制文件）然后，再存储到AOF中，再将增量以指令的方式Append 到AOF。所以，是一个混合体；这里的AOF日志不再是全量的日志，而是持久化开始到持久化结束这段时间的增量AOF日志通常很小；那么，它这么改变的 优点 是：在Redis重启时，可以先加载RDB的内容，在加载增量AOF日志，完全替代AOF全量日志重放，重启的效率将大幅度提升； 每次一重写完，就会变成RDB ；

脏数据刷入时机 ：AOF日志是以文件形式存在的，当程序对AOF日志进行写操作时， 实际上是先将数据写到一个内存缓存中，然后，让内存再把脏数据写回到磁盘中 那么，什么时候写呢？如果，还没来的及写就宕机了，那么可能会出现日志丢失；这时候有三个级别可以调；

no : 不调用fsync 等到它满了再进行调用（fsync 可以将指定文件的内容，强制从内核缓存刷到磁盘） 一般生产环境不用

always :每写了一个数据，就调用一次fsync 一般生产环境不用

everysec: redis每一秒调用一次flush

一般Redis 的主节点不会进行持久化操作，持久化操作主要是在从节点中进行。因为，没有来自客户端请求的压力；

上面是Redis持久化的两种方式 由于，持久化过程需要花费的时间是比较多的，所以，一般由从节点来进行持久化操作； 主服务器发现需要执行完整重同步时，会fork子进程执行RDB持久化，并将持久化数据发送给从服务器。这时候，有两种选择 1 直接通过Socket发送给从服务器(从服务器支持eof)，2 持久化数据到本地文件，待持久化完毕后再将该文件发送给从服务器。 默认第二种，具体情况是根据同步信息确定；但是，第一种效率会更高，速度会更快；

总结 ：为了Redis快的特性，Redis在持久化的时候，使用fork()函数，新开线程来执行；同时，如果主从服务器的话，还提供了psync2来进行部分重同步；eof功能；

redis的特点就是快，在系统设计的方方面面都体现了这个快的特性；这是我自己在学习Redis相关知识时，了解到的内容，做个记录。如果，有偏差欢迎读者进行指正!