CN111680100B - redis数据同步方法及服务器 - Google Patents

Abstract

本申请实施例提供了一种redis数据同步方法及服务器，方法包括：同步单元和源redis建立连接；同步单元判断预设位置是否存储有持久化的位置信息，其中，所述位置信息包括所述同步单元的位置偏移量、所述同步单元上次与所述源redis连接时记录的运行身份信息；如果所述预设位置存储有所述位置信息，同步单元根据所述位置信息向所述源redis发送增量同步请求；同步单元根据接收到来自所述源redis的增量同步信息，执行增量同步，并定时持久化位置信息。本申请实施例通过定时持久化位置信息，解决了同步单元和不能进行增量同步而导致的redis数据同步效率低的问题。

Description

redis数据同步方法及服务器

技术领域

本申请涉及电视的智能测试技术领域，尤其涉及一种redis数据同步方法及服务器。

背景技术

随着互联网的迅速发展，各公司的业务逐步扩大，业务的稳定性备受关注。目前，很多公司采用异地双活的系统架构，异地的两个机房之间进行redis(Remote DictionaryServer，远程字典服务)数据单向同步，这样，当一个机房出现故障后，该机房的业务可迅速切换到另一个机房，以提高业务的稳定性。

基于RedisShake的数据同步方法是实现redis数据单向同步的一种重要方法，该方法利用RedisShake模拟redis主从协议，使RedisShake作为源redis的从节点接收redis数据，再将redis数据写到目标redis，从而实现数据单向同步。该方法可在异地机房配置高可用的目标redis，从而提高业务稳定性。

然而，向RedisShake写redis数据的机房有时会发生主从切换，即该机房中作为源redis的redis主节点挂掉，redis从节点被提升为redis主节点，而redis主节点和redis从节点的运行身份信息在重新上线后会改变，源redis只能匹配自己的从节点或自己的旧主节点的从节点，这将导致源redis发生两次及以上的主从切换时，RedisShake作为旧主节点之前的主节点的从节点，无法与源redis进行匹配，只能作为一个新的从节点与源redis进行匹配，导致原有的数据单向同步不能增量进行，只能重新进行全量同步，导致同步效率降低。

发明内容

为解决上述技术问题，本申请提供了一种redis数据同步方法及服务器。

第一方面，本申请实施例提供了一种redis数据同步方法，该方法包括：

同步单元和源redis建立连接；

判断预设位置是否存储有持久化的位置信息，其中，所述位置信息包括所述同步单元的位置偏移量、所述同步单元上次与所述源redis连接时记录的运行身份信息；

如果所述预设位置存储有所述位置信息，则根据所述位置信息向所述源redis发送增量同步请求；

根据接收到来自所述源redis的增量同步信息，执行增量同步，并定时持久化位置信息。

第二方面，本申请实施例提供了一种服务器，该服务器被配置为：

同步单元与源redis建立连接；

同步单元判断预设位置是否存储有持久化的位置信息，其中，所述位置信息包括所述同步单元的位置偏移量、所述同步单元上次与所述源redis连接时记录的运行身份信息；

如果所述预设位置存储有所述位置信息，同步单元根据所述位置信息向所述源redis发送增量同步请求；

同步单元根据接收到来自所述源redis的增量同步信息，执行增量同步，并定时持久化位置信息。

本申请提供redis数据同步方法及服务器的有益效果包括：

本申请实施例利用同步单元定时获取源redis的运行身份信息和同步单元的位置偏移量，并将二者持久化为位置信息，使得同步单元在与源redis进行非首次连接时，能够根据位置信息提供较新的运行身份信息，以与源redis进行匹配，解决了由于同步单元无法和源redis匹配而导致的不能进行增量同步的问题，大大提高了同步效率，节省了网络带宽成本。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种异地redis单向同步示意图；

图2为本申请实施例提供的一种RedisShake更新runid的示意图；

图3为本申请实施例提供的一种redis数据同步方法的流程示意图；

图4为本申请实施例提供的另一种redis数据同步方法的流程示意图；

图5为本申请实施例提供的一种offset持久化示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

图1为本申请实施例提供的一种异地redis单向同步示意图，如图1所示，机房一和机房二为两个数据中心，可同时承担业务。在一些实施例中，机房一可承担60～70％的业务，机房二可承担40％～30％的业务。机房二可对机房一进行redis数据单向同步，当机房一挂掉后，可将机房一的业务及时切换到机房二，避免了机房一挂掉后，机房一上的业务中断。

机房一挂掉后，将给机房二带来较大的负担，为避免机房一挂掉，机房一通常设置有一个以上的redis节点。图1中，机房一设置有两个redis节点：第一节点101和第二节点102，R表示读数据，W表示写数据。两个redis节点工作在主从模式，其中一个redis节点作为主节点，另一个redis节点作为从节点，主节点设置为源redis，源redis可进行主从切换，即从节点可提升为主节点，从而成为源redis。

例如，第一节点101可作为Redis-M，即主节点，第二节点102可作为第一节点101的从节点，即Redis-S；或第二节点102可作为主节点，第一节点101作为第二节点102的从节点。机房一的业务可读写机房一的redis节点。当机房一的Redis-M有数据写入时，Redis-M会将写入的数据发送给Redis-S，使Redis-S与Redis-M同步。

在一些实施例中，可默认设置第一节点101为源redis，承担业务。当第一节点101挂掉后，进行主从切换，使第二节点102成为源redis，承担业务，当第一节点101上线后，第一节点101作为从节点；当第二节点102挂掉后，再次进行主从切换，使第一节点101成为源redis，第二节点102上线后，第二节点102作为从节点。

机房二也可设置有两个redis节点，其中一个redis节点作为机房二的Redis-M，另一个redis节点作为机房二的Redis-S。机房二的业务可写机房一的redis，或者机房二本身无写操作，读机房二的redis，这时就需要同步单元将机房一的redis数据实时同步到机房二的redis节点。

在一些实施例中，同步单元可为RedisShake或RedisPort，本申请实施例以RedisShak为例进行介绍。

RedisShake在启动后，可获取源redis的runid(运行身份信息)，模拟redis主从协议，作为源redis的从节点，这样，当源redis有redis数据写入时，源redis会将写入的redis数据发送给RedisShake，RedisShake再将redis数据写入异地目标redis节点，如机房二的redis节点，使机房二实现与机房一的redis数据同步。

当RedisShake进行机房二和机房一之间的redis数据同步时，机房一的两个redis节点可能相继挂掉，导致机房一的redis节点可能会发生两次及以上的主从切换。由于redis节点在每次启动后会自动生成一个包含四十个随机字符的runid，因此，在主从切换后，源redis的runid会发生变化。目前，redis4.0以上版本支持源redis根据RedisShake提供的runid为源redis当前的runid和上次的runid，能够与RedisShake进行匹配，然而，当机房一的redis节点发生两次及以上的主从切换时，将导致RedisShake请求增量同步时，RedisShake提供的runid不是源redis当前的runid，也不是源redis的旧主节点的runid，即源redis主从切换前的runid，导致匹配失败，进而不能进行增量同步。

为解决上述技术问题，本申请实施例通过使RedisShake定时获取源redis的runid，使得RedisShake在请求增量同步时，提供较新的runid，从而避免因runid不正确不能进行增量同步的问题。

图2为本申请实施例提供的一种RedisShake更新runid的示意图，如图2所示，在主从切换前，Redis-M的runid为id1，Redis-S的runid为id2。Redis为高可用部署，对外只提供redis统一的地址，如一个虚ip，实时指向redis的主节点。RedisShake定时获取该统一的地址，得到id1，将Runid＝id1存储到DB(数据库)中，该数据库可为mysql类型的数据库，除了数据库，还可将源redis的runid存储到预设文件，如预设本地文件中，只要RedisShake能够获取该runid，并能将该runid进行更新即可。

在主从切换后，Redis-M的runid为id2，Redis-S的runid为id3。RedisShake定时获取该统一的地址，得到id2，在数据库或预设文件中将源redis的runid更新为id2。当再次发生主从切换后，runid为id3的redis节点成为源redis，RedisShake向源redis提供id2，源redis根据id2为自己的旧主节点，能够与RedisShake成功匹配，避免了因runid不正确不能进行增量同步的问题。

为了对RedisShake通过定时获取源redis的runid以实现增量同步的过程做进一步说明，本申请实施例提供了一种redis数据同步方法的流程示意图，参见图3，该方法包括以下步骤：

步骤S101：同步单元和源redis建立首次连接。

RedisShake与源redis建立首次连接，使RedisShake第一次和源redis建立起主从关系。

根据对源redis的预先设置，源redis可能是第一节点，也可能是第二节点，本步骤中，假设源redis是第一节点。

步骤S102：同步单元向源redis发送全量同步请求。

RedisShake和源redis第一次建立起主从关系，需要请求与源redis进行全量同步。

全量同步请求可为PSYNC？-1命令，RedisShake将PSYNC？-1命令发送给源redis。

源redis接收到PSYNC？-1命令后，可向RedisShake发送全量同步信息，使RedisShake能够进行全量同步。全量同步信息可为+FULLRESYNC<runid><offset>，其中，runid为源redis的runid，假设第一机房的两个redis节点在上线后，第一节点生成的runid为id1，第二节点生成的runid为id2，且第一节点为源redis，则RedisShake获取到的源redis的runid为id1。

全量同步信息中的offset(位置偏移量)为源redis中redis数据的偏移位置，例如，源redis可根据源redis的redis数据偏移到10000，可在全量同步信息中设置offset为10000，表明RedisShake需要偏移到10000的位置。

步骤S103：同步单元根据接收到来自源redis的全量同步信息，执行全量同步。

RedisShake接收到全量同步信息后，执行全量同步，全量同步的方法为现有技术，本实施例不再详细描述。全量同步后，RedisShake将全量同步信息中的offset，也是此时RedisShake的位置偏移量，设置为初始化偏移量，并记录源redis的runid，生成位置信息，位置信息包括RedisShake的位置偏移量和源redis当前的runid。

步骤S104：当源redis发生第一次主从切换后，同步单元与源redis建立第二次连接。

当作为源redis的redis节点挂掉后，RedisShake与该redis节点的连接断开。第一机房的另一个redis节点成为源redis，RedisShake与该源redis建立主从关系。由于RedisShake之前与源redis建立过连接，因此，此次与源redis的连接称为第二次连接。

例如，在之前的步骤中，源redis为第一节点，在T1时刻，第一节点挂掉，RedisShake与第一节点的连接断开，第二节点成为源redis。从T1时刻起，第二节点作为源redis，承担业务，如果业务产生了新的redis命令，新的redis数据将会被写入第二节点，使源redis的redis数据发生偏移，如偏移到了12000，该位置偏移量12000被存储到源redis的offset中；并且，源redis偏移的redis数据同步写入到buffer(缓存)中，即10000-12000对应的redis数据被存储到了缓存中，缓存的大小可以设置，例如，可设置为10M，如果缓存溢出，则最先存进缓存的redis数据将被删除，以空出空间存进新的redis数据。

在T1时刻之后的某一时刻，如T1’时刻，第一节点可能重新上线，并得到一个新的身份信息，如id3，此时，由于第二节点为源redis，因此，第一节点成为第二节点的从节点，即第一节点成为Redis-S。在第一节点上线后，源redis给第一节点同步redis数据，使新上线的第一节点的Redis数据偏移位置同步到与源redis一致。

在T1时刻之后的某一时刻，如T2时刻，RedisShake与第二节点连接。此时，RedisShake与第二节点的Redis数据偏移位置可能不一致，例如，RedisShake偏移到了10000，第二节点已经偏移到了12000。

步骤S105：同步单元向源redis发送增量同步请求。

RedisShake与源redis第二次连接后，RedisShake与第二节点的Redis数据偏移位置可能不一致，RedisShake可向源redis请求增量同步。

RedisShake从数据库或预设文件中读取位置信息，根据位置信息中的offset得到上次与源redis连接时的偏移位置，根据位置信息中的runid得到上次与源redis连接时记录的运行身份信息。

RedisShake根据位置信息生成增量同步请求，将增量同步请求发送给源redis。增量同步请求可为PSYNC<runid><offset>指令，在该指令中，runid为RedisShake在位置信息中记录的源节点的runid，由于RedisShake无法感知到本次与源redis连接后，源redis是哪一个redis节点，因此，在增量同步请求中的runid仍为RedisShake上次与源redis连接时定时更新后的源redis的runid；offset为RedisShake在位置信息中记录的位置偏移量。

例如，RedisShake上次与源redis连接时，源redis为第一节点，offste为10000，则增量同步请求中的runid为id1，offset为10000。

在redis4.0以上版本，PSYNC<runid><offset>指令采用psync2实现，每个redis从节点都记录着主节点runid和offset，当第一次redis主从切换后，RedisShake在增量同步请求中提供旧主节点的runid和offset，新主节点里能匹配到旧主节点的runid和offset。

源redis接收到RedisShake的增量同步请求后，判断增量同步请求中的runid是否为自己的runid或旧主节点的runid，以及判断增量同步请求中的offset对应的redis数据是否还在缓存中，如果两个条件都满足，则生成增量同步信息，发送到RedisShake，如果有一个条件不满足，或者两个条件都不满足，则生成全量同步信息。

例如，第二节点在接收到RedisShake的增量同步请求后，根据增量同步请求中的runid为id1，offset为10000，判定增量同步请求中的id1为旧主节点的runid，同时，offset为10000对应的redis数据还存在于缓存，则判定可进行增量同步，生成增量同步信息，将增量同步信息发送到RedisShake。增量同步信息可为+CONTINUE，表示进行增量同步。

或者，第二节点在接收到RedisShake的增量同步请求后，根据增量同步请求中的runid为id1，offset为10000，判定增量同步请求中的id1为旧主节点的runid，但是，由于缓存已经溢出等原因，10000对应的redis数据已经丢失，则判定无法从偏移量10000位置处进行增量同步，需要进行全量同步，生成全量同步信息，将全量同步信息发送到RedisShake。全量同步信息为+FULLRESYNC<runid><offset>，其中，runid(运行身份信息)为源redis的身份信息，即第二节点的身份信息，如id2，offset为源redis的偏移位置，如12000，表明RedisShake需要偏移到12000。

步骤S106：同步单元根据接收到来自源redis的增量同步信息，执行增量同步，并定时持久化位置信息。

RedisShake接收到增量同步信息后，执行增量同步，增量同步的方法为现有技术，本实施例不再详细描述。

在同步数据过程中，随着RedisShake接收到redis数据，RedisShake实际的位置偏移量发生变化，由于redis性能比较高，位置偏移量变化较快，若在每次写redis命令后都将位置偏移量进行更新会造成很大的资源浪费，因此，在一些实施例中，可定时持久化一次位置信息。

定时持久化位置信息可为每秒获取一次源redis的runid和RedisShake的位置偏移量，根据源redis的runid和RedisShake的位置偏移量，在数据库或预设文件中更新位置信息。

在一些实施例中，在增量同步时，第二节点将缓存中10000-12000对应的redis数据发送给RedisShake，使RedisShake进行增量同步。

步骤S107：同步单元根据接收到来自源redis的全量同步信息，执行全量同步。

在步骤S105，RedisShake将增量同步请求发送给源redis后，源redis判断无法进行增量同步，会向RedisShake发送全量同步信息。

RedisShake接收到全量同步信息后，执行全量同步，全量同步后，根据RedisShake的位置偏移量和源redis的runid更新位置信息。

在一些实施例中，在全量同步之后，如果源redis已经以当前的运行身份信息承担业务，如果业务产生了新的redis命令，新的redis数据将会被写入第二节点，使源redis的redis数据发生偏移，如偏移到了12500，则位置偏移量12000-12500以源redis当前的运行身份信息，即id2写入到源redis的offset中。RedisShake可继续向源redis发送增量同步请求，此时，由于RedisShake在上次与源redis连接时，已经将源redis的runid更新为id2，因此，RedisShake可在增量同步请求中设置runid为id2，设置offset为全量同步后的位置偏移量，如12000。源redis接收该增量同步请求后，根据runid为源redis当前的运行身份信息，即第二节点自己的运行身份信息，以及位置偏移量对应的redis数据还存在于缓存，可生成增量同步信息，使RedisShake可执行12000-12500的增量同步。

步骤是S108：当源redis发生第二次主从切换后，同步单元与源redis建立第三次连接。

当作为源redis的redis节点挂掉后，RedisShake与该redis节点的连接断开。第一机房的另一个redis节点成为源redis，RedisShake与该源redis建立主从关系。由于RedisShake之前与源redis建立过两次连接，因此，此次与源redis的连接称为第三次连接。

例如，在之前的步骤中，源redis为第二节点，在T3时刻，第二节点挂掉，RedisShake与第二节点的连接断开，第一节点成为源redis，从T3时刻起，第一节点作为源redis，承担业务，如果业务产生了新的redis命令，新的redis数据将会被写入第一节点，使源redis的redis数据发生偏移，如偏移到了14000，该位置偏移量14000被存储到源redis的offset中；并且，源redis偏移的redis数据同步写入到buffer(缓存)中，即12000-14000对应的redis数据被存储到了缓存中。

在T3时刻之后的某一时刻，如T3’时刻，第二节点可能重新上线，并得到一个新的身份信息，如id4，此时，由于第一节点为源redis，因此，第二节点成为第一节点的从节点，即第二节点成为Redis-S。在第二节点上线后，源redis给第二节点同步redis数据，使新上线的第二节点的Redis数据偏移位置同步到与源redis一致。

在T3时刻之后的某一时刻，如T4时刻，RedisShake与第一节点连接。此时，RedisShake与第一节点的Redis数据偏移位置可能不一致，例如，RedisShake偏移到了12000，第二节点已经偏移到了14000。

步骤S109：同步单元向源redis发送增量同步请求。

RedisShake与源redis第三次连接后，从数据库或预设文件中读取位置信息，得到上次与源redis连接时源节点的运行身份信息和RedisShake在offset中记录的位置偏移量据此，生成增量同步请求，将增量同步请求发送到源redis。

例如，RedisShake根据位置信息，得到上次与源redis连接时，源redis为第二节点，同步位置到了第12000，则增量同步请求中的runid为id2，offset为12000。

源redis接收到RedisShake的增量同步请求后，判断增量同步请求中的runid是否为自己的runid或旧主节点的runid，以及判断增量同步请求中的offset对应的redis数据是否还在缓存中，如果两个条件都满足，则生成增量同步信息，发送到RedisShake，如果有一个条件不满足，或者两个条件都不满足，则生成全量同步信息。

例如，第一节点在接收到RedisShake的增量同步请求后，根据增量同步请求中的runid为id2，offset为12000字节，判定增量同步请求中的id2为自己的旧主节点的runid，同时，该offset对应的redis数据，即12000对应的redis数据还存在于缓存，则判定可进行增量同步，生成增量同步信息，将增量同步信息发送到RedisShake。增量同步信息可为+CONTINUE，表示进行增量同步。

或者，第一节点在接收到RedisShake的增量同步请求后，根据增量同步请求中的runid为id2，offset为12000，判定增量同步请求中的id2为旧主节点的runid，但是，增量同步请求所请求的redis数据已经从缓存丢失，则判定无法进行增量同步，需要进行全量同步，生成全量同步信息，将全量同步信息发送到RedisShake。全量同步信息为+FULLRESYNC<runid><offset>，其中，runid(运行身份信息)为源redis的身份信息，即第一节点的身份信息，如id3，offset为14000字节，表明RedisShake需要偏移到第14000字节。

步骤S110：同步单元根据接收到来自源redis的增量同步信息，执行增量同步，并定时持久化位置信息。

RedisShake接收到增量同步信息后，执行增量同步，在同步数据过程中，定时获取RedisShake当前的位置偏移量和源redis的runid，持久化位置信息。

在一些实施例中，在增量同步时，第一节点将缓存中12000-14000对应的redis数据发送给RedisShake，使RedisShake进行增量同步。

步骤S111：同步单元根据接收到来自源redis的全量同步信息，执行全量同步。

在步骤S109，RedisShake将增量同步请求发送给源redis后，源redis判断无法进行增量同步，会向RedisShake发送全量同步信息。

RedisShake接收到全量同步信息后，执行全量同步，全量同步后，根据RedisShake的位置偏移量和源redis的runid更新位置信息。

通过上述步骤可以看出，RedisShake在与源redis进行同步的过程中，通过定时获取源redis的运行身份信息和同步位置偏移量，并将二者生成持久化的位置信息，将持久化的位置信息存储在预设文件或数据库中，使得RedisShake在与源redis进行重新连接时，能够将较新的运行身份信息提供给源redis，进而实现增量同步。

实际实施中，机房一的主从切换可达两次以上，为对任一次主从切换后的增量同步进行说明，本申请实施例还提供了另一种redis数据同步方法的流程示意图，参见图4，该方法包括以下步骤：

步骤S201：同步单元和源redis建立连接。

RedisShake与源redis建立的连接可为首次连接，也可为第N次连接，N大于1，在本步骤中，RedisShake无法判断与源redis建立的连接是第几次连接。

步骤S202：同步单元判断预设位置是否存储有持久化的位置信息。

如果在步骤S201中，RedisShake与源redis建立的连接为首次连接，则表明RedisShake与源redis未同步过redis数据，预设位置，如数据库或预设文件将不会存储有持久化的位置信息；如果在步骤S201中，RedisShake与源redis建立的连接为第N次连接，则表明RedisShake与源redis同步过redis数据，预设位置将会存储有持久化的位置信息，因此，可根据预设位置是否存储有持久化的位置信息来判断步骤S201中RedisShake与源redis建立的连接是第几次连接。

步骤S203：如果预设位置存储有位置信息，同步单元根据位置信息向源redis发送增量同步请求。

如果预设位置存储有持久化的位置信息，则表明RedisShake与源redis建立的连接为第N次连接，根据持久化的位置信息可知RedisShake与源redis已经同步过redis数据，可根据持久化的位置信息向源redis发送增量同步请求，以尝试进行增量同步，从而减小同步工作量。

持久化的位置信息中存储的runid为RedisShake定时更新的源redis的runid，当定时更新的频率设置为每秒更新一次或更大时，RedisShake在发送增量同步请求之前，能够获取较新的runid，如源redis当前的runid或旧主节点的runid。而当源redis根据增量同步请求中的runid为源redis当前的runid或旧主节点的runid，且缓存中对应增量同步请求的redis数据存在时，生成增量同步信息。

当持久化位置信息定时更新的频率设置为小于每秒更新一次时，RedisShake在发送增量同步请求之前，获取的runid可能不是源redis当前的runid或旧主节点的runid，而是更早的runid，这种情况将会导致无法进行增量同步。另外，如果缓存中，对应增量同步请求的redis数据不存在，也就会无法进行增量同步。当源redis判定无法进行增量同步时，生成全量同步信息。

步骤S204：同步单元根据接收到来自源redis的增量同步信息，执行与源redis的增量同步，并定时持久化位置信息。

如果RedisShake接收到源redis发送的增量同步信息，则执行增量同步。

步骤S205：如果预设位置没有存储位置信息，同步单元向源redis发送全量同步请求。

如果预设位置没有存储持久化的位置信息，则表明RedisShake与源redis建立的连接为首次连接，RedisShake与源redis没有同步过redis数据，RedisShake需要向源redis发送全量同步请求，以尝试进行全量同步。

步骤S206：同步单元根据接收到来自源redis的全量同步信息，执行与源redis的全量同步。

如果RedisShake接收到源redis发送的全量同步信息，则执行全量同步。在全量同步结束后，存储或更新位置信息。

步骤S207：同步单元判断预设时间内同步的redis数据是否存在非幂等命令。

由于位置信息的定时更新频率为每秒更新一次，因此，当RedisShake和源redis断开连接时，位置信息中记录的同步位置对应的同步时刻可能比实际的同步位置对应的同步时刻稍微早一些，最多早一个位置信息的更新周期，即持久化周期。

假设如图5所示，位置信息的更新周期为1秒，RedisShake和源redis在t-1时刻和t时刻分别持久化offset，在t2时刻RedisShake和源redis断开连接，则最后一次持久化offset是在t1时刻。t1到t2时刻的redis数据在t2时刻前已经同步到目标redis，但在t1时刻持久化的offset中没有记录该t1到t2时刻的同步。当RedisShake和源redis重新建立连接后会从t1时刻持久化的offset开始增量同步，导致t1到t2时刻的redis数据被重新同步一次。

在一些实施例中，当redis数据为非幂等命令比如incr命令，多同步一次就会导致两次数据不一致，而幂等命令重新同步一次不会有该问题。为避免非幂等命令由于增量同步而导致同步前后两次数据不一致，在增量同步开始后，对预设时间内，即一个位置信息的更新周期内的redis数据，动态判断是否存在非幂等命令，如果存在非幂等命令，则断开增量同步，返回步骤S205，向源redis发送全量同步请求，以尝试进行全量同步。

通常情况下，t1到t2时刻时间在1秒以内，一般的业务场景产生非幂等命令概率是非常低的，大部分情况下都不需要重新全量同步。

步骤S208：如果预设时间内同步的redis数据不存在非幂等命令，同步单元继续执行增量同步，并定时持久化位置信息。

在增量同步开始后，如果在一个位置信息的更新周期内同步的redis数据不存在非幂等命令，则可继续执行增量同步，并需要定时持久化位置信息，以在下次主从切换后，能够进行增量同步。

在一些实施例中，还提供了一种服务器，服务器可被配置为执行图3或图4所示的redis数据同步方法，以实现同步单元与源redis的数据同步。

通过上述实施例可见，由于RedisShake定时获取源redis的运行身份信息和同步位置偏移量，并将二者生成持久化的位置信息，将持久化的位置信息存储在预设文件或数据库中，使得RedisShake在与源redis进行非首次连接时，能够进行增量同步的几率大幅提升，大大提高了同步效率，节省了网络带宽成本。

由于以上实施方式均是在其他方式之上引用结合进行说明，不同实施例之间均具有相同的部分，本说明书中各个实施例之间相同、相似的部分互相参见即可。在此不再详细阐述。

需要说明的是，在本说明书中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或暗示这些实体或操作之间存在任何这种实际的关系或顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的电路结构、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种电路结构、物品或者设备所固有的要素。在没有更多限制的情况下，有语句“包括一个……”限定的要素，并不排除在包括要素的电路结构、物品或者设备中还存在另外的相同要素。

本领域技术人员在考虑说明书及实践这里发明的公开后，将容易想到本申请的其他实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由权利要求的内容指出。以上的本申请实施方式并不构成对本申请保护范围的限定。

Claims (10)

1.一种redis数据同步方法，其特征在于，包括：

同步单元与源redis建立连接；

同步单元判断预设位置是否存储有持久化的位置信息，其中，所述位置信息包括所述同步单元的位置偏移量、所述同步单元上次与所述源redis连接时记录的运行身份信息；

如果所述预设位置存储有所述位置信息，同步单元根据所述位置信息向所述源redis发送增量同步请求；

同步单元根据接收到来自所述源redis的增量同步信息，执行增量同步，并定时持久化位置信息。

2.根据权利要求1所述的redis数据同步方法，其特征在于，所述增量同步信息由所述源redis根据所述运行身份信息为所述源redis的旧主节点的运行身份信息，且缓存中存储有所述位置偏移量对应的redis数据生成，其中，所述源redis的旧主节点为主从切换前的源redis。

3.根据权利要求1所述的redis数据同步方法，其特征在于，所述增量同步信息由所述源redis根据所述运行身份信息为所述源redis当前的运行身份信息，且缓存中存储有所述位置偏移量对应的redis数据生成。

4.根据权利要求1所述的redis数据同步方法，其特征在于，所述方法还包括：

同步单元根据接收到来自所述源redis的全量同步信息，执行全量同步。

5.根据权利要求4所述的redis数据同步方法，其特征在于，所述全量同步信息由所述源redis根据所述运行身份信息不是所述源redis的运行身份信息或源redis的旧主节点的运行身份信息，或缓存中没有存储所述位置偏移量对应的redis数据生成。

6.根据权利要求1所述的redis数据同步方法，其特征在于，所述方法还包括：

如果所述预设位置没有存储所述位置信息，同步单元向所述源redis发送全量同步请求；

同步单元根据接收到来自所述源redis的全量同步信息，执行全量同步。

7.根据权利要求1所述的redis数据同步方法，其特征在于，所述同步单元根据接收到来自所述源redis的增量同步信息，执行增量同步，并定时持久化位置信息，包括：

同步单元判断预设时间内同步的redis数据是否存在非幂等命令；

如果所述预设时间内同步的redis数据存在非幂等命令，同步单元向所述源redis发送全量同步请求；

同步单元根据接收到来自所述源redis的全量同步信息，执行全量同步。

8.根据权利要求7所述的redis数据同步方法，其特征在于，所述预设时间为所述位置信息的持久化周期。

9.根据权利要求1或8所述的redis数据同步方法，其特征在于，所述位置信息的持久化周期为一秒。

10.一种服务器，其特征在于，所述服务器被配置为：

同步单元与源redis建立连接；

同步单元判断预设位置是否存储有持久化的位置信息，其中，所述位置信息包括所述同步单元的位置偏移量、所述同步单元上次与所述源redis连接时记录的运行身份信息；

如果所述预设位置存储有所述位置信息，同步单元根据所述位置信息向所述源redis发送增量同步请求；

同步单元根据接收到来自所述源redis的增量同步信息，执行增量同步，并定时持久化位置信息。

Images