CN112513832A - 一种数据的存储方法及设备 - Google Patents

Abstract

本申请实施例公开了一种数据的存储方法及设备，应用于数据存储技术领域，该方法包括：在轮式移动设备(如智能汽车、自动驾驶汽车、网联汽车等)上部署双节点构成的数据存储服务系统，第一节点为主节点，第二节点为备节点，第一节点和第二节点上分别运行第一进程和第二进程，当第一节点接收到写数据请求时，第一节点先通过第一进程调用第一数据库引擎向第一节点上的第一存储模块写数据，再阻塞式使得第二节点通过第二进程调用第二数据库引擎向第二节点上的第二存储模块进行同样的写数据操作，从而在轮式移动设备上部署两个节点前提下，通过强一致性的数据同步流程实现数据实时备份，保障了数据可靠性，同时降低了轮式移动设备的硬件成本。

Description

一种数据的存储方法及设备

技术领域

本申请涉及数据存储技术领域，尤其涉及一种数据的存储方法及设备。

背景技术

随着汽车智能化的演进，越来越多的数据被生成和利用，尤其是在智能驾驶领域，由于车辆的运行状态数据、感知数据、中间计算结果、面向服务架构(service-orientedarchitecture，SOA)信息等数据需要频繁被读取，因此其对数据读取的实时性、数据存储的可靠性以及数据的可用性等要求高。在此背景下，对数据处理能力、数据存储可靠性等要求不断提升，从而使得对数据存储的需求更加多样化。

现有技术中，为了提升数据存储的可靠性，一般采用分布式集群部署的方式，利用轻量级的数据库引擎，结合分布式一致性算法，构建出集群化的数据存储服务系统，该数据存储服务系统的部署方式有两种：1)如图1所示，图1以部署3个节点设备(也可简称为节点)为例进行示意，作为客户端的各个应用程序(application，APP)的读/写数据的请求集中由主节点(leader)上运行的进程S2处理，再由进程S2通过向集群内的其他节点的进程(如，进程S1和进程S3)发送同步命令请求(synchronization，SYNC)，对各个节点上存储模块的数据进行同步(由节点上的数据库引擎实现，也可简称为引擎)；2)如图2所示，图2依然以部署3个节点为例进行示意，作为客户端的各个APP就近访问节点，若某节点有更新数据，再由该节点上运行的进程向其他节点上运行的进程发送SYNC，实现各个节点上存储模块内的数据同步。

上述部署方式都依赖于分布式一致性算法(如，paxos算法及其演变算法、raft算法等)，这些算法都具有一个关键约束：所有的选举过程(如，选举leader的过程)、数据的写操作等都要求集群内所有节点中过半数的进程同意才认为是达成共识。由于过半数的硬性要求，一般都是采用3个以上的奇数个节点的部署方式。但在汽车领域中，车用器件成本控制严格，数据可靠性要求高，上述这种部署3个节点的方式数据冗余备份多、资源消耗大，导致硬件成本高，使得其无法同时满足数据可靠性高和成本低等要求，尤其是很多中低端车型无法承受这些硬件成本的增加。

发明内容

本申请实施例提供了一种数据的存储方法及设备，可以用于在轮式移动设备(如，自动驾驶车辆)上部署2个节点设备的前提下，通过强一致性(即在任意时刻下，系统里第一节点设备和第二节点设备中的数据都是一样的)的数据同步流程实现数据的实时备份，保障了数据的可靠性，同时相比于现有技术中至少部署3个节点设备的方式，本申请部署2个节点设备的方式降低了轮式移动设备的硬件成本，即在低成本的轮式移动设备的硬件架构中实现高可靠性的数据存储。

基于此，本申请实施例提供以下技术方案，其中，在本申请以下各实施方式中，第一节点设备简称为第一节点，第二节点设备简称为第二节点。

第一方面，本申请实施例首先提供一种数据的存储方法，该方法包括：首先，第一节点作为主节点，通过运行在第一节点上的第一进程接收第一APP发送的第一请求，该第一APP可以是与第一进程对应的APP，其中，该第一进程是指用于处理数据存储相关的进程，该第一APP用于获取轮式移动设备周围环境的感知信息(如，可通过部署在轮式移动设备上的摄像头、雷达等传感器获得感知信息)，并基于感知信息生成对数据的操作指令(即第一请求)，该第一请求经由第一APP向与该第一APP对应的第一节点上运行的第一进程发送。在本申请实施例中，该第一请求是用于指示向存储模块(如，硬盘、内存等)写目标数据(可称为第一数据)。第一节点获取到第一APP发送的第一请求，响应于该第一请求，第一进程就可以基于第一进程上的第一数据库引擎，向第一节点上的第一存储模块写第一数据。这里需要注意的是，第一请求是用于指示向存储模块写第一数据，并没有限定是对哪个存储模块写第一数据，例如，若是第一节点通过第一进程调用第一数据库引擎，那么就是根据该第一请求向第一节点上的第一存储模块写该第一数据。又例如，若是第二节点通过第二进程调用第二数据库引擎，那么就是根据该第一请求向第二节点上的第二存储模块写该第一数据。在向第一存储模块写第一数据的操作已完成的情况下，第一节点才会通过第一进程将第一请求向所述第二节点发送，将第一请求向第二节点发送的目的在于：使得第二节点根据该第二请求向第二节点上的第二存储模块也写入该第一数据。第二节点接收到第一节点通过第一进程发送的第一请求后，将通过调用第二进程(运行在第二节点)上的第二数据库引擎向第二节点上的第二存储模块写该第一数据，这样第二节点上的第二存储模块与第一存储模块更新后的数据就能保持完全一致。其中，与第一进程类似，该第二进程也是指用于处理数据存储相关的进程。第二节点通过调用第二进程上的第二数据库引擎向第二节点上的第二存储模块写第一数据的操作完成的情况下，就会通过第二进程向第一节点发送第一响应消息，该第一响应消息就用于指示向第二存储模块写第一数据的操作已完成。当第一节点通过第一进程在预设时长内接收到第二节点通过第二进程发送的第一响应消息，那么第一节点就可确定第二节点也完成了对第一数据的写操作，那么第一节点将会通过第一进程向第一应用程序发送第二响应消息，该第二响应消息就用于指示向第一存储模块写第一数据的操作和向第二存储模块写第一数据的操作均已完成。在一些实施方式中，该方法可以应用于轮式移动设备，该轮式移动设备就可以包括上述所述的第一节点和第二节点。

在本申请上述实施方式中，在轮式移动设备(如，自动驾驶车辆、智能汽车、网联汽车等)上仅部署2个节点的前提下，且向第一节点(作为主节点)发送第一请求的APP与第一节点上的第一进程均为运行在同一个OS的情况时，通过上述强一致性(即在任意时刻下，系统里第一节点设备和第二节点设备中的数据都是一样的)的数据同步流程实现数据的实时备份，即保障了数据的可靠性，同时相比于现有技术中至少部署3个节点设备的方式，本申请部署2个节点设备的方式降低了轮式移动设备的硬件成本，即在低成本的轮式移动设备的硬件架构中实现高可靠性的数据存储。

在第一方面的一种可能的设计中，如果第一节点故障，那么第二节点会立即取代第一节点继续提供服务，并缓存数据，该缓存的数据就为第二节点取代第一节点作为主节点后第二存储模块内更新的数据，并且在第一节点恢复正常使用后，通过第二进程将该缓存的数据向第一节点发送，使得第一节点通过调用第一数据库引擎将该缓存的数据更新至自身的第一存储模块，从而实现两个节点之间的数据同步。

在本申请上述实施方式中，若第一节点故障(第一节点作为主节点，第二节点作为备节点)，则第二节点立即升为主节点，取代第一节点进行服务，从而保障数据存储服务系统的可用性，数据不丢失。

在第一方面的一种可能的设计中，第二节点取代第一节点继续提供服务具体可以包括以下几种取代方式：a、第二节点取代第一节点提供服务，直至第一节点恢复正常使用，也就是说，等第一节点恢复了正常使用，第二节点就不再取代，第二节点依然作为备节点工作，一般这种情况是第一节点是高配，第二节点是低配，即第一节点与第二节点的硬件配置不同，主数据库引擎运行在高配的第一节点上，当高配的第一节点故障，则可以短期内由低配的第二节点取代第一节点提供服务，等第一节点恢复正常使用后，再由第一节点继续作为主节点提供服务，这种设置高低配置节点的方式也是为了节约成本。b、第二节点始终取代第一节点提供服务，也就是说，第二节点取代第一节点作为主节点提供服务后，不管后续第一节点是否恢复正常使用，第二节点就一直作为主节点提供服务，若第一节点恢复正常使用后，就一直作为备节点使用，一般这种一直取代的方式是第一节点和第二节点的硬件配置没有差别的情况。

在本申请上述实施方式中，具体阐述了当第一节点故障，第二节点取代第一节点提供服务的两种方式，具备灵活性和可选择性。

在第一方面的一种可能的设计中，对第一节点故障的判断具体可以包括如下几种方式：

a、第一节点向第二节点发送的心跳异常，例如，假设第一节点向第二节点发送心跳的频率正常是300毫秒一次，由于第一节点向第二节点发送心跳的目的就是告知对端自身是在正常运行，但在预设时长内(如，1秒内)第二节点都没有收到第一节点发送的心跳，那么第二节点就认为第一节点故障。b、第一节点向第二节点主动发送故障通知消息，例如，当第一节点上运行的第一进程上的软件正常或异常退出，则第一节点会主动向第二节点发送故障通知消息；又例如，当第一节点上监控第一进程的第三进程监控到第一进程异常时，则第一节点也会向第二节点主动发送故障通知消息；还例如，第一节点的通信异常，那么第一节点也会主动向第二节点发送故障通知消息，具体此次不做举例示意。

在本申请上述实施方式中，上述两种感知故障的方式都是为了使得第二节点能够快速感知到第一节点出现了故障，缩短了故障检测时延。其中，第二种故障感知的方式相比第一种故障感知的方式，能够让第二节点更快感知到第一节点出现了故障，而不必等待预设时长第二节点没有收到第一节点的心跳才确定第一节点故障，从而进一步缩短了故障检测时延。

在第一方面的一种可能的设计中，如果第二节点故障，那么第一节点可以将对端设置为异常状态，而第一节点作为主节点继续提供服务，并缓存数据(即第二数据)，该缓存的数据就为第一节点通过第一进程向第一存储模块写第一数据的操作后得到的数据，并且在第二节点恢复正常使用后，通过第一进程将该缓存的数据向第二节点发送，使得第二节点通过调用第二数据库引擎将该缓存的数据更新至自身的第二存储模块，从而实现两个节点之间的数据同步。

在本申请上述实施方式中，阐述了如果是第二节点故障，那么第一节点将作为主节点继续提供服务，并且在第二节点恢复正常使用后，通过第一进程将该缓存的第二数据向第二节点发送，使得第二节点通过调用第二数据库引擎将该缓存的第二数据更新至自身的第二存储模块，从而实现两个节点之间的数据同步，具备可实现性。

在第一方面的一种可能的设计中，对第二节点故障的判断具体也可以包括如下几种方式：a、第二节点向第一节点发送的心跳异常，例如，假设第二节点向第一节点发送心跳的频率正常是300毫秒一次，由于第二节点向第一节点发送心跳的目的也是告知对端自身是在正常运行，但在预设时长内(如，1秒内)第一节点都没有收到第二节点发送的心跳，那么第一节点就认为第二节点故障。b、第二节点向第一节点主动发送故障通知消息，例如，当第二节点上运行的第二进程上的软件正常或异常退出，则第二节点会主动向第一节点发送故障通知消息；又例如，当第二节点上监控第二进程的第四进程监控到第二进程异常时，则第二节点也会向第一节点主动发送故障通知消息；还例如，第二节点的通信异常，那么第二节点也会主动向第一节点发送故障通知消息，具体此次不做举例示意。

在本申请上述实施方式中，上述两种感知故障的方式都是为了使得第一节点能够快速感知到第二节点出现了故障，缩短了故障检测时延。其中，第二种故障感知的方式相比第一种故障感知的方式，能够让第一节点更快感知到第二节点出现了故障，而不必等待预设时长第一节点没有收到第二节点的心跳才确定第二节点故障，从而进一步缩短了故障检测时延。

在第一方面的一种可能的设计中，在一种可能的设计中，该第一存储模块包括第一内存数据库；和/或，该第二存储模块包括第二内存数据库。

在本申请上述实施方式中，阐述了第一存储模块和第二存储模块可以是内存数据库，相对于传统的硬盘，内存数据库的读取速度更快，尤其是在智能驾驶领域，由于车辆的运行状态数据、感知数据、中间计算结果、SOA信息等数据需频繁被读取，若第一存储模块和第二存储模块为硬盘，那么反复频繁的读/写数据会缩短硬盘寿命，从而导致车用器件的更换成本提高。

在第一方面的一种可能的设计中，第一节点通过第一进程调用第一数据库引擎向第一节点上的第一存储模块写入第一数据的操作执行完成之后，还可以进一步通过第一进程记录(如，更新)当前的数据版本号，该当前数据版本号可称为第一数据版本号，其用于表示第一存储模块数据更新后的数据版本(可称为第一数据版本)，该更新后的数据版本为向第一存储模块写第一数据的操作已完成的情况下的数据版本。例如，假设此次数据写操作之前的数据版本号为P，那么当前对第一数据写操作完成后，当前第一存储模块内的数据是最新版本的，则可记录数据版本号为P+1。

在本申请上述实施方式中，通过第一进程执行完第一数据的写操作后，还要记录此次更新后的数据版本号，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。

在第一方面的一种可能的设计中，第二节点通过第二进程调用第二数据库引擎向第二节点上的第二存储模块写入第一数据的操作执行完成之后，也可以进一步通过第二进程记录(如，更新)当前的数据版本号，该当前数据版本号可称为第二数据版本号，其用于表示第二存储模块数据更新后的数据版本(可称为第二数据版本)，所述更新后的数据版本为向第二存储模块写第一数据的操作已完成的情况下的数据版本。例如，假设此次数据写操作之前的数据版本号为Q，那么当前对第一数据写操作完成后，当前第二存储模块内的数据是最新版本的，则可记录数据版本号为Q+1，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。这里需要注意的是，由于每次节点对数据的写操作，都会同步更新第一节点上的第一存储模块和第二节点上的第二存储模块，因此实质上P和Q的取值相同。

在本申请上述实施方式中，通过第二进程执行完第一数据的写操作后，也要记录此次更新后的数据版本号，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。

在一种可能的设计中，轮式移动设备可以是自动驾驶车辆，自动驾驶车辆可以为轿车、卡车、摩托车、公共汽车、船、飞机、直升飞机、割草机、娱乐车、游乐场车辆、施工设备、电车、高尔夫球车、火车、和手推车等，本申请实施例不做特别的限定。

在本申请上述实施方式中，阐述了轮式移动设备可以是自动驾驶车辆，具备可实现性。

本申请实施例第二方面还提供一种数据的存储方法，应用于轮式移动设备，该轮式移动设备包括第一节点和第二节点，该方法包括：首先，第二节点作为备节点，通过运行在第二节点上的第二进程接收与第二进程对应的第二APP发送的第二请求，其中，该第二进程是指用于处理数据存储相关的进程，该第二APP用于获取轮式移动设备周围环境的感知信息(如，可通过部署在轮式移动设备上的摄像头、雷达等传感器获得感知信息)，并基于感知信息生成对数据的操作指令(即第二请求)，该第二请求经由第二APP向与该第二APP对应的第二节点上运行的第二进程发送。在本申请实施例中，该第二请求是用于指示向存储模块(如，硬盘、内存等)写目标数据(可称为第三数据)。在本申请实施例中，由于第二节点是作为备节点使用，因此，第二节点接收到对应的第二APP发送的第二请求，需要把第二请求转发给作为主节点的第一节点进行处理。具体地，第一节点通过运行在第一节点上的第一进程接收运行在第二节点上的第二进程转发的第二请求。第一节点获取到第一APP发送的第二请求，根据该第二请求，就可通过第一进程调用第一进程上的第一数据库引擎向第一节点上的第一存储模块写第三数据。这里需要注意的是，第二请求是用于指示向存储模块写第三数据，并没有限定是向哪个存储模块写第三数据，例如，若是第一节点通过第一进程调用第一数据库引擎，那么就是根据该第二请求向第一节点上的第一存储模块写该第三数据。又例如，若是第二节点通过第二进程调用第二数据库引擎，那么就是根据该第二请求向第二节点上的第二存储模块写该第三数据。在向第一存储模块写第三数据的操作执行已完成的情况下，第一节点会通过第一进程向第二节点发送第三响应消息，该第三响应消息就用于指示第二节点根据第二请求，通过第二进程调用第二进程上的第二数据库引擎向第二节点上的第二存储模块写第三数据。第二节点接收到第一节点通过第一进程发送的第二请求后，将通过调用第二进程上的第二数据库引擎对第二节点上的第二存储模块执行该第三数据的写操作，这样第二节点上的第二存储模块与第一存储模块更新后的数据就能保持完全一致。其中，与第一进程类似，该第二进程也是指用于处理数据存储相关的进程。第二节点通过调用第二进程上的第二数据库引擎向第二节点上的第二存储模块写第三数据的操作完成的情况下，就会通过第二进程向第一节点发送第四响应消息，该第四响应消息就用于指示向第二存储模块写第三数据的操作已完成。当第一节点通过第一进程在预设时长内接收到第二节点通过第二进程发送的第四响应消息，那么第一节点通过第一进程向第二节点发送第五响应消息，该第五响应消息就用于指示向第一存储模块写第三数据的操作和向第二存储模块写第三数据的操作均已完成。第二节点通过第二进程接收到第一节点通过第一进程发送的第五响应消息，将会将该第五响应消息向第二应用程序转发，这样第二应用程序也就可以感知到第一节点和第二节点均完成了对第三数据的写操作。

在本申请上述实施方式中，在轮式移动设备(如，自动驾驶车辆、智能汽车、网联汽车等)上仅部署2个节点的前提下，且向第二节点(作为备节点)发送第二请求的APP与第一节点上的第一进程为运行在不同OS的情况时，通过上述强一致性(即在任意时刻下，系统里第一节点设备和第二节点设备中的数据都是一样的)的数据同步流程实现数据的实时备份，即保障了数据的可靠性，同时相比于现有技术中至少部署3个节点的方式，本申请部署2个节点的方式又降低了轮式移动设备的硬件成本，即在低成本的轮式移动设备的硬件架构中实现高可靠性的数据存储。

在第一方面的一种可能的设计中，如果第一节点故障，那么第二节点会立即取代第一节点继续提供服务，并缓存数据，该缓存的数据就为第二节点取代第一节点作为主节点后第二存储模块内更新的数据，并且在第一节点恢复正常使用后，通过第二进程将该缓存的数据向第一节点发送，使得第一节点通过调用第一数据库引擎将该缓存的数据更新至自身的第一存储模块，从而实现两个节点之间的数据同步。

在本申请上述实施方式中，若第一节点故障(第一节点作为主节点，第二节点作为备节点)，则第二节点立即升为主节点，取代第一节点进行服务，从而保障数据存储服务系统的可用性，数据不丢失。

在第一方面的一种可能的设计中，第二节点取代第一节点继续提供服务具体可以包括以下几种取代方式：a、第二节点取代第一节点提供服务，直至第一节点恢复正常使用，也就是说，等第一节点恢复了正常使用，第二节点就不再取代，第二节点依然作为备节点工作，一般这种情况是第一节点是高配，第二节点是低配，即第一节点与第二节点的硬件配置不同，主数据库引擎运行在高配的第一节点上，当高配的第一节点故障，则可以短期内由低配的第二节点取代第一节点提供服务，等第一节点恢复正常使用后，再由第一节点继续作为主节点提供服务，这种设置高低配置节点的方式也是为了节约成本。b、第二节点始终取代第一节点提供服务，也就是说，第二节点取代第一节点作为主节点提供服务后，不管后续第一节点是否恢复正常使用，第二节点就一直作为主节点提供服务，若第一节点恢复正常使用后，就一直作为备节点使用，一般这种一直取代的方式是第一节点和第二节点的硬件配置没有差别的情况。

在本申请上述实施方式中，具体阐述了当第一节点故障，第二节点取代第一节点提供服务的两种方式，具备灵活性和可选择性。

在第一方面的一种可能的设计中，对第一节点故障的判断具体可以包括如下几种方式：

a、第一节点向第二节点发送的心跳异常，例如，假设第一节点向第二节点发送心跳的频率正常是300毫秒一次，由于第一节点向第二节点发送心跳的目的就是告知对端自身是在正常运行，但在预设时长内(如，1秒内)第二节点都没有收到第一节点发送的心跳，那么第二节点就认为第一节点故障。b、第一节点向第二节点主动发送故障通知消息，例如，当第一节点上运行的第一进程上的软件正常或异常退出，则第一节点会主动向第二节点发送故障通知消息；又例如，当第一节点上监控第一进程的第三进程监控到第一进程异常时，则第一节点也会向第二节点主动发送故障通知消息；还例如，第一节点的通信异常，那么第一节点也会主动向第二节点发送故障通知消息，具体此次不做举例示意。

在本申请上述实施方式中，上述两种感知故障的方式都是为了使得第二节点能够快速感知到第一节点出现了故障，缩短了故障检测时延。其中，第二种故障感知的方式相比第一种故障感知的方式，能够让第二节点更快感知到第一节点出现了故障，而不必等待预设时长第二节点没有收到第一节点的心跳才确定第一节点故障，从而进一步缩短了故障检测时延。

在第一方面的一种可能的设计中，如果第二节点故障，那么第一节点可以将对端设置为异常状态，而第一节点作为主节点继续提供服务，并缓存数据(即第二数据)，该缓存的数据就为第一节点通过第一进程向第一存储模块写第一数据的操作后得到的数据，并且在第二节点恢复正常使用后，通过第一进程将该缓存的数据向第二节点发送，使得第二节点通过调用第二数据库引擎将该缓存的数据更新至自身的第二存储模块，从而实现两个节点之间的数据同步。

在本申请上述实施方式中，阐述了如果是第二节点故障，那么第一节点将作为主节点继续提供服务，并且在第二节点恢复正常使用后，通过第一进程将该缓存的第二数据向第二节点发送，使得第二节点通过调用第二数据库引擎将该缓存的第二数据更新至自身的第二存储模块，从而实现两个节点之间的数据同步，具备可实现性。

在第一方面的一种可能的设计中，对第二节点故障的判断具体也可以包括如下几种方式：a、第二节点向第一节点发送的心跳异常，例如，假设第二节点向第一节点发送心跳的频率正常是300毫秒一次，由于第二节点向第一节点发送心跳的目的也是告知对端自身是在正常运行，但在预设时长内(如，1秒内)第一节点都没有收到第二节点发送的心跳，那么第一节点就认为第二节点故障。b、第二节点向第一节点主动发送故障通知消息，例如，当第二节点上运行的第二进程上的软件正常或异常退出，则第二节点会主动向第一节点发送故障通知消息；又例如，当第二节点上监控第二进程的第四进程监控到第二进程异常时，则第二节点也会向第一节点主动发送故障通知消息；还例如，第二节点的通信异常，那么第二节点也会主动向第一节点发送故障通知消息，具体此次不做举例示意。

在本申请上述实施方式中，上述两种感知故障的方式都是为了使得第一节点能够快速感知到第二节点出现了故障，缩短了故障检测时延。其中，第二种故障感知的方式相比第一种故障感知的方式，能够让第一节点更快感知到第二节点出现了故障，而不必等待预设时长第一节点没有收到第二节点的心跳才确定第二节点故障，从而进一步缩短了故障检测时延。

在第二方面的一种可能的设计中，在一种可能的设计中，该第一存储模块包括第一内存数据库；和/或，该第二存储模块包括第二内存数据库。

在本申请上述实施方式中，阐述了第一存储模块和第二存储模块可以是内存数据库，相对于传统的硬盘，内存数据库的读取速度更快，尤其是在智能驾驶领域，由于车辆的运行状态数据、感知数据、中间计算结果、SOA信息等数据需频繁被读取，若第一存储模块和第二存储模块为硬盘，那么反复频繁的读/写数据会缩短硬盘寿命，从而导致车用器件的更换成本提高。

在第二方面的一种可能的设计中，第一节点通过第一进程调用第一数据库引擎向第一节点上的第一存储模块写第三数据的操作执行完成之后，还可以进一步通过第一进程记录(如，更新)当前的数据版本号，该当前数据版本号可称为第一数据版本号，其用于表示第一存储模块数据更新后的数据版本(可称为第一数据版本)，所述更新后的数据版本为向第一存储模块写第三数据的操作已完成的情况下的数据版本。例如，假设此次数据写操作之前的数据版本号为X，那么当前对第三数据写操作完成后，当前第一存储模块内的数据是最新版本的，则可记录数据版本号为X+1。

在本申请上述实施方式中，通过第一进程执行完第三数据的写操作后，还要记录此次更新后的数据版本号，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。

在第二方面的一种可能的设计中，第二节点通过第二进程调用第二数据库引擎向第二节点上的第二存储模块写第三数据的操作执行完成之后，也可以进一步通过第二进程记录(如，更新)当前的数据版本号，该当前数据版本号可称为第二数据版本号，其用于表示第二存储模块数据更新后的数据版本(可称为第二数据版本)，所述更新后的数据版本为向第二存储模块写第三数据的操作已完成的情况下的数据版本。例如，假设此次数据写操作之前的数据版本号为Y，那么当前对第三数据写操作完成后，当前第二存储模块内的数据是最新版本的，则可记录数据版本号为Y+1，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。这里需要注意的是，由于每次节点对数据的写操作，都会同步更新第一节点上的第一存储模块和第二节点上的第二存储模块，因此实质上X和Y的取值相同。

在本申请上述实施方式中，通过第二进程执行完第三数据的写操作后，也要记录此次更新后的数据版本号，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。

在一种可能的设计中，轮式移动设备可以是自动驾驶车辆，自动驾驶车辆可以为轿车、卡车、摩托车、公共汽车、船、飞机、直升飞机、割草机、娱乐车、游乐场车辆、施工设备、电车、高尔夫球车、火车、和手推车等，本申请实施例不做特别的限定。

在本申请上述实施方式中，阐述了轮式移动设备可以是自动驾驶车辆，具备可实现性。

本申请实施例第三方面提供一种数据存储服务系统，该系统部署于轮式移动设备，该系统包括第一节点和第二节点，所述第一节点和第二节点具有实现上述第一方面或第一方面任意一种可能实现方式的方法的功能。

本申请实施例第四方面还提供一种数据存储服务系统，该系统部署于轮式移动设备，该系统包括第一节点和第二节点，所述第一节点和第二节点具有实现上述第二方面或第二方面任意一种可能实现方式的方法的功能。

本申请实施例第五方面还提供一种节点，该节点应用于数据存储服务系统，所述系统部署于轮式移动设备，所述系统包括第一节点和第二节点，所述节点作为第一节点，具有实现上述第一方面或第一方面任意一种可能实现方式的方法中第一节点的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本申请实施例第六方面还提供一种节点，该节点应用于数据存储服务系统，所述系统部署于轮式移动设备，所述系统包括第一节点和第二节点，所述节点作为第一节点，具有实现上述第二方面或第二方面任意一种可能实现方式的方法中第一节点的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本申请实施例第七方面提供一种数据存储服务系统，该系统部署于轮式移动设备，该系统包括第一节点和第二节点，第一节点包括第一处理器和第一存储器，第一处理器与第一存储器耦合，第二节点包括第二处理器和第二存储器，第二处理器与第二存储器耦合；其中，第一存储器和第二存储器分别用于存储第一程序和第二程序，第一处理器用于调用该第一存储器中存储的第一程序以执行本申请实施例第一方面或第一方面任意一种可能实现方式中由第一节点所执行的步骤，或，第一处理器用于调用该第一存储器中存储的第一程序以执行本申请实施例第二方面或第二方面任意一种可能实现方式中由第一节点所执行的步骤；第二处理器用于调用该第二存储器中存储的第二程序以执行本申请实施例第一方面或第一方面任意一种可能实现方式中由第二节点所执行的步骤，或，第二处理器用于调用该第二存储器中存储的第二程序以执行本申请实施例第二方面或第二方面任意一种可能实现方式中由第二节点所执行的步骤。

本申请第八方面提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第一方面或第一方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第二方面或第二方面任意一种可能实现方式的方法。

本申请实施例第九方面提供了一种计算机程序产品，当其在计算机上运行时，使得计算机可以执行上述第一方面或第一方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第二方面或第二方面任意一种可能实现方式的方法。

附图说明

图1为本申请实施例提供的数据存储服务系统的部署方式的一种示意图；

图2为本申请实施例提供的数据存储服务系统的部署方式的另一示意图；

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

图4为本申请实施例提供的数据的存储方法的另一流程示意图；

图5为本申请实施例提供的数据的存储方法的另一流程示意图；

图6为本申请实施例提供的数据的存储方法的另一流程示意图；

图7为本申请实施例提供的数据存储服务系统的一种结构示意图；

图8为本申请实施例提的第一节点的一种结构示意图；

图9为本申请实施例提的第一节点的另一结构示意图；

图10为本申请实施例提供的数据存储服务系统的一种结构示意图。

具体实施方式

本申请实施例提供了一种数据的存储方法及设备，可以用于在轮式移动设备(如，自动驾驶车辆)上部署2个节点设备的前提下，通过强一致性(即在任意时刻下，系统里第一节点设备和第二节点设备中的数据都是一样的)的数据同步流程实现数据的实时备份，保障了数据的可靠性，同时相比于现有技术中至少部署3个节点设备的方式，本申请部署2个节点设备的方式降低了轮式移动设备的硬件成本，即在低成本的轮式移动设备的硬件架构中实现高可靠性的数据存储。

本申请实施例涉及了许多关于数据存储相关知识，为了更好地理解本申请实施例的方案，下面先对本申请实施例可能涉及的相关术语和概念进行介绍。应理解的是，相关的概念解释可能会因为本申请实施例的具体情况有所限制，但并不代表本申请仅能局限于该具体情况，在不同实施例的具体情况可能也会存在差异，具体此处不做限定。

(1)轮式移动设备

是集环境感知、动态决策与规划、行为控制与执行等多功能于一体的综合系统，也可称为轮式移动机器人或轮式智能体，例如，可以是轮式施工设备、自动驾驶车辆、辅助驾驶车辆等，只要是具备轮式可移动的设备就都称为本申请所述的轮式移动设备。为便于理解，在本申请以下实施例中，均以轮式移动设备为自动驾驶车辆为例进行说明，自动驾驶车辆可以为轿车、卡车、摩托车、公共汽车、船、飞机、直升飞机、割草机、娱乐车、游乐场车辆、施工设备、电车、高尔夫球车、火车、和手推车等，本申请实施例不做特别的限定。

(2)节点

节点也可称为计算机网络节点或物理节点，在数据通信中，一个物理节点可以是数据电路端接设备，如调制解调器、集线器、桥接器或交换机；也可以是一个数据终端设备，如数字手机，打印机或主机(例如路由器、工作站或服务器)。在本申请实施例中，该节点特指一个物理的硬件单元，例如，可以是主机。节点也称为节点设备，在本申请实施例中，第一节点设备和第二节点设备均分别简称为第一节点和第二节点。

(3)进程(process)

进程是计算机中的程序关于某数据集合上的运行活动，是系统进行资源分配和调度的基本单位，是操作系统(operating system，OS)结构的基础。在早期面向进程设计的计算机结构中，进程是程序的基本执行实体；在当代面向线程设计的计算机结构中，进程是线程的容器。程序是指令、数据及其组织形式的描述，进程是程序的实体。它可以申请和拥有系统资源，是一个活动的实体。它不只是程序的代码，还包括当前的活动，通过程序计数器的值和处理寄存器的内容来表示。进程的概念主要有两点：第一，进程是一个实体。每一个进程都有它自己的地址空间，一般情况下，包括文本区域(text region)、数据区域(dataregion)和堆栈(stack region)。文本区域存储处理器执行的代码；数据区域存储变量和进程执行期间使用的动态分配的内存；堆栈区域存储着活动过程调用的指令和本地变量。第二，进程是一个“执行中的程序”。程序是一个没有生命的实体，只有处理器赋予程序生命时(操作系统执行之)，它才能成为一个活动的实体，才被称为进程。

(4)数据库引擎

也可称为数据引擎，数据库引擎是用于存储、处理和保护数据的核心服务。利用数据库引擎可控制访问权限并快速处理事务，从而满足大多数需要处理大量数据的应用程序的要求。使用数据库引擎可创建用于联机事务处理或联机分析处理数据的关系数据库，包括创建用于存储数据的表和用于查看、管理和保护数据安全的数据库对象(如索引、视图和存储过程)。在本申请实施例中，每个进程上都运行有一个轻量级的数据库引擎。

(5)分布式一致性算法

一致性是指数据保持一致，在分布式系统中，可以理解为多个节点中存储模块的数据是一致的。分布性一致性算法是为了解决以下两个问题而存在：1)数据不能只存在单个节点上，否则可能出现单点故障，导致数据丢失；2)多个节点需要保证具有相同的数据，旨在保证数据可靠性。

分布式一致性算法大体可分为两类，一类称为强一致性算法，即系统保证改变提交以后立即改变集群中各节点内数据的状态，代表算法有paxos算法、raft算法、ZAB算法等；另一类称为弱一致性算法，也可称为最终一致性算法，即系统不保证改变提交以后立即改变集群中各节点内数据的状态，但随着时间的推移各节点内数据的最终状态是一致的，代表算法有Gossip协议。

其中，所谓强一致性，也可称为原子一致性或线性一致性，其具备两个要求：1)任何一次读数据都能读到某个数据的最近一次写的数据；2)系统中各节点所有进程的操作顺序，都和全局时钟下的顺序一致。在本申请实施例中，简言之，就是在任意时刻下，系统里第一节点和第二节点中的数据都是一样的。

下面以raft算法为例，且以图1所示的部署方式为例，介绍如何在分布式系统(即集群)中的多个节点中实现数据同步，这里需要说明的是，前提是每个节点上都运行一个对应的进程，所有的过程均通过各自节点运行的进程实现。

raft算法是对paxos算法的简化和优化，该算法将分布式系统内的各个节点区分为主节点(leader)和备节点(也可称为追随者节点follower)，其中，主节点负责发出提案，提案实质为分布式系统的读/写数据的请求，该请求一般由客户端提出，该提案可表示为[提案编号n，提案内容value]，备节点负责为接收到的主节点发出的提案进行表决，表决的原则是：不同意比自己以前接收过的提案编号要小的提案，其他提案都同意，例如备节点a以前给m号提案表决过，那么再收到小于等于m号的提案时就直接投反对票。当主节点出现故障，此时所有的备节点自动成为主节点候选者(candidate)，来争夺成为新的主节点。

下面简单介绍该raft算法的基本逻辑：首先是主节点选举过程，每个备节点都持有一个定时器，当定时器时间到了而集群中仍然没有主节点，备节点将声明自己是主节点候选者，并参与主节点选举，同时将选举消息发给其他备节点来争取它们的投票，若其他节点长时间没有响应该主节点候选者，则该主节点候选者将重新发送选举信息，当集群中其他节点收到该选举消息，将给该主节点候选者进行表决，获得过半数节点同意的主节点候选者将成为第M任主节点(M任是最新的任期，前提是第M-1任的主节点故障或失去主节点资格)，在任期内的主节点会不断发送心跳给其他节点(即M任的备节点)证明自己还活着，其他节点收到心跳以后就清空自己的计时器并回复主节点的心跳，该机制用于保证其他节点不会在主节点任期内参加主节点选举。当主节点出现故障而导致主节点失联，没有接收到心跳的其他节点将准备成为主节点候选者进入下一轮主节点选举。若出现两个主节点候选者同时向其他节点发送了选举消息并获得了相同的支持票数，那么这两个主节点候选者将随机推迟一段时间后再向其他节点发出选举消息，这保证了再次发送选取消息以后不冲突。其次，是各个节点数据状态的复制过程，在图1的这种部署方式中，主节点负责接收来自应用程序的提案(也就是读/写数据的请求)，提案内容将包含在主节点发出的下一个心跳中，备节点接收到主节点的心跳以后，若备节点同意该提案，则回复主节点的心跳，主节点接收到过半数的备节点的回复以后确认该提案通过，之后将该提案写入自己的存储空间，并回复应用程序，同时，主节点通知备节点确认提案并写入各自的存储空间，最终分布式系统内的所有节点都拥有相同的数据。

上述仅是以raft算法为例对分布式一致性算法的基本逻辑进行示意，其他算法的逻辑是类似的，即要实现分布式系统内各个节点的数据同步，均需要超过半数的节点同意才行，也就是说，每个分布式系统中至少需要部署3个节点才行(超半数同意的原则需要奇数个节点)。

下面结合附图，对本申请的实施例进行描述。本领域普通技术人员可知，随着技术的发展和新场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

本申请实施例提供了一种数据的存储方法，该方法可以应用于轮式移动设备(如，自动驾驶车辆、智能汽车、网联汽车等)，该轮式移动设备包括两个节点，分别为第一节点和第二节点，在本申请实施例中，第一APP与第一进程运行在同一个OS上，一般是指运行在同一个节点(即第一节点)上，其中，第一节点作为主节点，第二节点作为备节点，具体请参阅图3，图3为本申请实施例提供的数据的存储方法的一种流程示意图，可以包括如下步骤：

301、第一节点通过运行在第一节点上的第一进程接收第一APP发送的第一请求。

首先，第一节点作为主节点，通过运行在第一节点上的第一进程接收第一APP发送的第一请求，其中，该第一进程是指用于处理数据存储相关的进程，该第一APP用于获取轮式移动设备周围环境的感知信息(如，可通过部署在轮式移动设备上的摄像头、雷达等传感器获得感知信息)，并基于感知信息生成对数据的操作指令(即第一请求)，该第一请求经由第一APP向与该第一APP对应的第一节点上运行的第一进程发送。在本申请实施例中，该第一请求是用于指示向存储模块(如，硬盘、内存等)写目标数据(可称为第一数据)。

需要说明的是，由于对数据的操作一般包括两种方式：读数据和写数据，其中，读数据是指读取存储模块中的数据(即“查”)，APP读取存储模块的数据均通过主节点进行读取，由于读数据不会改变存储模块中的数据，因此本申请实施例方案不涉及对数据的读操作；而写数据是指对存储模块中的数据进行增加、删除或修改等操作(即“增”、“删”、“改”)，每个节点上运行的APP都可要求对存储模块中的数据进行增加、删除或修改等操作，这些操作都会使得存储模块内的数据被改变，因此，本申请实施例方案中，APP对数据的操作指令只包括对存储模块执行数据的写操作，即第一请求是用于指示向存储模块写第一数据。其中，若写数据为“增”数据，那么该第一数据就为需要增加进存储模块的数据，其包含在第一请求中由第一APP向第一节点发送；若写数据为“删”数据，那么该第一数据就为存储模块内待删除的对应数据，用于指示该第一数据的相关标识信息就包含在第一请求中由第一APP向第一节点发送；若写数据为“改”数据，那么该第一数据就为存储模块内待修改的对应数据，该第一数据对应的具体修改信息和相关标识信息就也包含在第一请求中由第一APP向第一节点发送。

还需要说明的是，在本申请的一些实施方式中，该第一APP与第一进程对应，具体地，与第一进程对应的第一APP一般是指第一进程与该第一APP运行在同一个OS上，或者，第一进程与第一APP均运行在第一节点上，具体此处不做限定。

还需要说明的是，在本申请的一些实施方式中，该第一进程是指用于处理数据存储相关的进程，在该第一节点上，可能还会同时运行其他的进程，不同的进程所处理的对象不同，一般来说，一个节点上只会运行一个用于处理数据存储相关的进程。

302、响应于第一请求，并基于第一进程上的第一数据库引擎，第一节点通过第一进程向第一节点上的第一存储模块写第一数据。

第一节点获取到第一APP发送的第一请求，根据该第一请求，就可通过第一进程调用第一进程上的第一数据库引擎，向第一节点上的第一存储模块写入该第一数据。

这里需要注意的是，第一请求是用于指示向存储模块写第一数据，并没有限定是向哪个存储模块写第一数据，例如，若是第一节点通过第一进程调用第一数据库引擎，那么就是根据该第一请求向第一节点上的第一存储模块写该第一数据。又例如，若是第二节点通过第二进程调用第二数据库引擎，那么就是根据该第一请求向第二节点上的第二存储模块写该第一数据。

需要说明的是，在本申请的一些实施方式中，第一节点通过第一进程调用第一数据库引擎向第一节点上的第一存储模块写第一数据的操作执行完成之后，还可以进一步通过第一进程记录(如，更新)当前的数据版本号，该当前数据版本号可称为第一数据版本号，其用于表示第一存储模块数据更新后的数据版本(可称为第一数据版本)，该更新后的数据版本为向第一存储模块写第一数据的操作已完成的情况下的数据版本。例如，假设此次数据写操作之前的数据版本号为P，那么当前对第一数据写操作完成后，当前第一存储模块内的数据是最新版本的，则可记录数据版本号为P+1，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。

303、在向第一存储模块写第一数据的操作已完成的情况下，第一节点通过第一进程向第二节点发送第一请求。

在向第一存储模块写第一数据的操作已完成的情况下，第一节点才会通过第一进程将第一请求向所述第二节点发送，将第一请求向第二节点发送的目的在于：使得第二节点根据该第二请求向第二节点上的第二存储模块也写入该第一数据。

304、第二节点响应于接收到的第一请求，基于第二进程上的第二数据库引擎，通过第二进程向第二节点上的第二存储模块写该第一数据。

第二节点接收到第一节点通过第一进程发送的第一请求后，将通过调用第二进程(运行在第二节点)上的第二数据库引擎，向第二节点上的第二存储模块写该第一数据，这样第二节点上的第二存储模块与第一存储模块更新后的数据就能保持完全一致。其中，与第一进程类似，该第二进程也是指用于处理数据存储相关的进程。

需要说明的是，在本申请的一些实施方式中，与第一节点类似，第二节点通过第二进程调用第二数据库引擎向第二节点上的第二存储模块写第一数据的操作执行完成之后，也可以进一步通过第二进程记录(如，更新)当前的数据版本号，该当前数据版本号可称为第二数据版本号，其用于表示第二存储模块数据更新后的数据版本(可称为第二数据版本)，所述更新后的数据版本为向第二存储模块写第一数据的操作已完成的情况下的数据版本。例如，假设此次数据写操作之前的数据版本号为Q，那么当前对第一数据写操作完成后，当前第二存储模块内的数据是最新版本的，则可记录数据版本号为Q+1，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。这里需要注意的是，由于每次节点对数据的写操作，都会同步更新第一节点上的第一存储模块和第二节点上的第二存储模块，因此实质上P和Q的取值相同。

305、第一节点通过第一进程在预设时长内接收到第二节点通过第二进程发送的第一响应消息。

第二节点通过调用第二进程上的第二数据库引擎向第二节点上的第二存储模块写第一数据的操作执行完成的情况下，就会通过第二进程向第一节点发送第一响应消息，该第一响应消息就用于指示向第二存储模块写第一数据的操作已完成。

306、第一节点通过第一进程向第一应用程序发送第二响应消息。

当第一节点通过第一进程在预设时长内接收到第二节点通过第二进程发送的第一响应消息，那么第一节点就可确定第二节点也完成了对第一数据的写操作，那么第一节点将会通过第一进程向第一应用程序发送第二响应消息，该第二响应消息就用于指示向第一存储模块写第一数据的操作和向第二存储模块写第一数据的操作均已完成。

需要说明的是，在本申请的一些实施方式中，第一存储模块和第二存储模块均可以是硬盘，也可以是内存数据库，具体此处不做限定。优选地，在本申请实施例中，第一存储模块和第二存储模块都可以是内存数据库，如，第一存储模块为第一内存数据库，第二存储模块为第二内存数据库，这是因为：相对于传统的硬盘，内存数据库的读取速度更快，尤其是在智能驾驶领域，由于车辆的运行状态数据、感知数据、中间计算结果、SOA信息等数据需频繁被读取，若第一存储模块和第二存储模块为硬盘，那么反复频繁的读/写数据会缩短硬盘寿命，从而导致车用器件的更换成本提高。

在本申请上述实施方式中，在轮式移动设备(如，自动驾驶车辆、智能汽车、网联汽车等)上仅部署2个节点的前提下，且向第一节点(作为主节点)发送第一请求的APP与第一节点上的第一进程均为运行在同一个OS的情况时，通过上述强一致性(即在任意时刻下，系统里第一节点设备和第二节点设备中的数据都是一样的)的数据同步流程实现数据的实时备份，即保障了数据的可靠性，同时相比于现有技术中至少部署3个节点的方式，本申请部署2个节点的方式降低了轮式移动设备的硬件成本，即在低成本的轮式移动设备的硬件架构中实现高可靠性的数据存储。

为便于理解上述图3所对应的实施方式，下面从信息流向的角度，对上述步骤301至步骤306的过程进行示意，具体请参阅图4，图4为本申请实施例提供的数据的存储方法的另一流程示意图，其中，第一节点作为主节点，第二节点作为备节点，均部署在轮式移动设备上，第一节点上具有第一存储模块，用于存储数据，第一节点上还运行有APP1(实际可以同时运行多个APP，图4仅以一个APP为例进行示意)和第一进程S1，第一进程S1上包括有第一数据库引擎(即图4中的引擎1)，且在引擎1上设置有控制组件HA1，控制组件HA1就用于实现上述步骤301至步骤306所述相关信息的传递过程；类似的，第二节点上具有第二存储模块，用于存储数据，第二节点上还运行有APP2(实际可以同时运行多个APP，图4仅以一个APP为例进行示意)和第二进程S2，第二进程S2上包括有第二数据库引擎(即图4中的引擎2)，且在引擎2上设置有控制组件HA2，控制组件HA2就用于实现上述步骤301至步骤306相关各种信息的传递过程。具体地，主节点上的APP1发起的写数据的过程可以如下所示：

步骤①：第一节点上的APP1通过服务接口C1向第一进程上的控制组件HA1发送请求a，该请求a用于指示向存储模块写数据A。

步骤②：第一节点作为主节点，调用引擎1向第一存储模块写数据A，并记录当前的数据版本号M。

步骤③：当数据A被成功写入第一存储模块后，由控制组件HA1向第二节点的控制组件HA2发送该第一请求，该第一请求一般包含在第一节点向第二节点发送的心跳内(也可以单独发送，此处不做限定)。

步骤④：第二节点作为备节点，调用引擎2向第二存储模块写数据A，同样记录当前的数据版本号M。

步骤⑤：若数据A被成功写入第二存储模块，则第二节点会通过控制组件HA2向第一节点的控制组件HA1发送一个响应消息(即上述所述的第一响应消息)。

步骤⑥：当第一节点在预设时长内(如，3s内)接收到该第一响应消息，说明数据A被成功写入第二存储模块，那么第一节点就再通过控制组件HA1向APP1返回执行结果，该执行结果即为上述所述的第二响应消息，用于告知APP1第一节点和第二节点均对数据A完成了写操作。

需要说明的是，在本申请的一些实施方式中，引擎1和引擎2的选择完全独立，互相不强依赖，也就是说，引擎1和引擎2即可以是同构的数据库引擎，也可以是异构的数据存储引擎，具体此处不做限定。因为控制组件HA1和控制组件HA2中集成有一个适配模块，用于适配各种数据库引擎，即通过各自的控制组件屏蔽掉数据库引擎的差异。由于不同数据库引擎的资源消耗不同，性能表现也不同。数据库引擎可以运行在差异化的硬件上(比如一个高配，一个低配)。若引擎1和引擎2是采用异构的数据库引擎，那么，性能表现好的引擎一般运行在高配的主节点上，性能表现弱一些的引擎则运行在低配的备节点上。这样差异化的部署也是基于降低成本考虑。

在本申请上述实施方式中，在轮式移动设备(如，自动驾驶车辆)上仅部署2个节点的前提下，且向第一节点(作为主节点)发送请求a的APP1与第一节点上的第一进程S1均为运行在同一个OS的情况时，通过上述强一致性的数据同步流程实现数据的实时备份，即保障了数据的可靠性，同时又降低了轮式移动设备的硬件成本，即在低成本的轮式移动设备的硬件架构中实现高可靠性的数据存储。

需要说明的是，在上述图3和图4对应的实施例中，向第一节点发送第一请求的APP与第一进程为均运行在同一个OS上的情况，那么在发起请求的APP与第一进程不运行在同一个OS上的情况时，第一节点上的第一存储模块与第二节点上的第二存储模块数据同步的方式也不一样，下面详细进行论述，具体请参阅图5，同样地，该方法应用于轮式移动设备(如，自动驾驶车辆)，该轮式移动设备包括两个节点，分别为第一节点(即主节点)和第二节点(即备节点)，在本申请实施例中，第二APP与第一进程运行在不同的OS上，一般是指运行在不同节点(即第一节点)上，在本申请实施例中，第二APP运行在第二节点上，图5为本申请实施例提供的数据的存储方法的另一流程示意图，可以包括如下步骤：

501、第二节点通过运行在第二节点上的第二进程接收第二APP发送的第二请求。

首先，第二节点作为备节点，通过运行在第二节点上的第二进程接收第二APP发送的第二请求，其中，该第二进程是指用于处理数据存储相关的进程，该第二APP用于获取相关信息，该相关信息可以是轮式移动设备各个系统运行的数据，也可以是轮式移动设备周围环境的感知信息(如，可通过部署在轮式移动设备上的摄像头、雷达等传感器获得感知信息)，具体此处不做限定。假设该第二APP获取的是感知信息，那么该第二APP可基于感知信息生成对数据的操作指令(即第二请求)，该第二请求经由第二APP向与该第二APP对应的第二节点上运行的第二进程发送。在本申请实施例中，该第二请求是用于指示向存储模块(如，硬盘、内存等)写目标数据(可称为第三数据)。

需要说明的是，本申请实施例方案中，由于APP对数据的操作指令只包括对存储模块执行数据的写操作，即第二请求是用于指示向存储模块写第三数据。其中，若写数据为“增”数据，那么该第三数据就为需要增加进存储模块的数据，其包含在第二请求中由第二APP向第二节点发送；若写数据为“删”数据，那么该第三数据就为存储模块内待删除的对应数据，用于指示该第三数据的相关标识信息就包含在第二请求中由第二APP向第二节点发送；若写数据为“改”数据，那么该第三数据就为存储模块内待修改的对应数据，该第三数据对应的具体修改信息和相关标识信息就也包含在第二请求中由第二APP向第二节点发送。

还需要说明的是，在本申请的一些实施方式中，该第二进程是指用于处理数据存储相关的进程，在该第二节点上，可能还会同时运行其他的进程，不同的进程所处理的对象不同，一般来说，一个节点上只会运行一个用于处理数据存储相关的进程。

502、第一节点通过运行在第一节点上的第一进程接收运行在第二节点上的第二进程转发的第二请求。

在本申请实施例中，由于第二节点是作为备节点使用，因此，第二节点接收到对应的第二APP发送的第二请求，需要把第二请求转发给作为主节点的第一节点进行处理。具体地，第一节点通过运行在第一节点上的第一进程接收运行在第二节点上的第二进程转发的第二请求。

503、响应于第二请求，并基于第一进程上的第一数据库引擎，第一节点通过第一进程向第一节点的第一存储模块写第三数据。

第一节点获取到第一APP发送的第二请求，根据该第二请求，就可通过第一进程调用第一进程上的第一数据库引擎向第一节点上的第一存储模块写第三数据。

这里需要注意的是，第二请求是用于指示向存储模块写第三数据，并没有限定是向哪个存储模块写第三数据，例如，若是第一节点通过第一进程调用第一数据库引擎，那么就是根据该第二请求向第一节点上的第一存储模块写该第三数据。又例如，若是第二节点通过第二进程调用第二数据库引擎，那么就是根据该第二请求向第二节点上的第二存储模块写该第三数据。

需要说明的是，在本申请的一些实施方式中，第一节点通过第一进程调用第一数据库引擎向第一节点上的第一存储模块写第三数据的操作执行完成之后，还可以进一步通过第一进程记录(如，更新)当前的数据版本号，该当前数据版本号可称为第一数据版本号，其用于表示第一存储模块数据更新后的数据版本(可称为第一数据版本)，该更新后的数据版本为向第一存储模块写第三数据的操作已完成的情况下的数据版本。例如，假设此次数据写操作之前的数据版本号为X，那么当前对第三数据写操作完成后，当前第一存储模块内的数据是最新版本的，则可记录数据版本号为X+1，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。

504、在向第一存储模块写第三数据的操作已完成的情况下，第一节点通过第一进程向第二节点发送第三响应消息。

在向第一存储模块写第三数据的操作已完成的情况下，第一节点会通过第一进程向第二节点发送第三响应消息，该第三响应消息就用于指示第二节点根据第二请求，通过第二进程调用第二进程上的第二数据库引擎向第二节点上的第二存储模块写第三数据。

需要说明的是，在本申请的一些实施方式中，可以将第二请求包含在该第三响应消息中由第一节点上的第一进程向第二节点上的第二进程发送，这样做的好处在于：虽然第二节点上一开始已接收到第二APP发送的第二请求，但在实际处理过程中，第二节点在同一时间可能需要处理很多不同进程上的不同请求，每个请求并不会一直保留在节点上，因此为方便管理，第二请求可以在转发给第一节点后，第二节点就删除该第二请求，这种情况下，第一节点通过第一进程向第二节点发送的第三响应消息中就可包含该第二请求，使得第二节点根据该第二请求向第二节点上的第二存储模块也写入第三数据。

还需要说明的是，在本申请的一些实施方式中，该第三响应消息不包括第二请求(前提是第二节点上还存在有该第二请求)，这种情况下，该第三响应消息仅用于指示第二节点根据自身已有的第二请求，通过第二进程调用第二数据库引擎向第二存储模块写第三数据。

505、根据第三响应消息，第二节点响应于第二请求，通过调用第二进程上的第二数据库引擎向第二节点上的第二存储模块写第三数据。

第二节点接收到第一节点通过第一进程发送的第二请求后，将通过调用第二进程上的第二数据库引擎向第二节点上的第二存储模块写该第三数据，这样第二节点上的第二存储模块与第一存储模块更新后的数据就能保持完全一致。其中，与第一进程类似，该第二进程也是指用于处理数据存储相关的进程。

需要说明的是，在本申请的一些实施方式中，与第一节点类似，第二节点通过第二进程调用第二数据库引擎向第二节点上的第二存储模块写第三数据的操作执行完成之后，也可以进一步通过第二进程记录(如，更新)当前的数据版本号，该当前数据版本号可称为第二数据版本号，其用于表示第二存储模块数据更新后的数据版本(可称为第二数据版本)，所述更新后的数据版本为向第二存储模块写第三数据的操作已完成的情况下的数据版本。例如，假设此次数据写操作之前的数据版本号为Y，那么当前对第三数据写操作完成后，当前第二存储模块内的数据是最新版本的，则可记录数据版本号为Y+1，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。这里需要注意的是，由于每次节点对数据的写操作，都会同步更新第一节点上的第一存储模块和第二节点上的第二存储模块，因此实质上X和Y的取值相同。

506、第一节点通过第一进程在预设时长内接收到第二节点通过第二进程发送的第四响应消息。

第二节点通过调用第二进程上的第二数据库引擎向第二节点上的第二存储模块写第三数据完成的情况下，就会通过第二进程向第一节点发送第四响应消息，该第四响应消息就用于指示向第二存储模块写第三数据已完成。

507、第一节点通过第一进程向第二节点发送第五响应消息。

当第一节点通过第一进程在预设时长内接收到第二节点通过第二进程发送的第四响应消息，那么第一节点通过第一进程向第二节点发送第五响应消息，该第五响应消息就用于指示向第一存储模块写第三数据的操作和向第二存储模块写第三数据均已完成。

需要说明的是，在本申请的一些实施方式中，第一存储模块和第二存储模块均可以是硬盘，也可以是内存数据库，具体此处不做限定。优选地，在本申请实施例中，第一存储模块和第二存储模块都可以是内存数据库，如，第一存储模块为第一内存数据库，第二存储模块为第二内存数据库，这是因为：相对于传统的硬盘，内存数据库的读取速度更快，尤其是在智能驾驶领域，由于车辆的运行状态数据、感知数据、中间计算结果、SOA信息等数据需频繁被读取，若第一存储模块和第二存储模块为硬盘，那么反复频繁的读/写数据会缩短硬盘寿命，从而导致车用器件的更换成本提高。

508、第二节点通过第二进程向第二应用程序转发第五响应消息。

第二节点通过第二进程接收到第一节点通过第一进程发送的第五响应消息，将会将该第五响应消息向第二应用程序转发，这样第二应用程序也就可以感知到第一节点和第二节点均完成了对第三数据的写操作。

需要注意的是，在本申请实施例中，由于第一节点是主节点，向APP发送的响应消息均需由第一节点发出，因此，需要由第一节点向第二节点发送第五响应消息，再由第二节点向第二应用程序转发。

还需要注意的是，在本申请实施例中，不管是由第一APP发出的第一请求，还是第二APP发出的第二请求，均需先由第一节点通过第一进程向第一存储模块写数据，在对第一存储模块写操作成功的情况下，再由第二节点通过第二进程向第二存储模块写数据。这是为了保证数据更新的强一致性，例如，假设与第一进程对应的某APP发出请求A，同时又有与第二进程对应的某APP发出请求B，如果两个节点各自都先写入本地，那么第一节点上第一存储模块数据更新的顺序是A→B，而第二节点上第二存储模块数据更新的顺序是B→A，两边存储模块在某时间段内数据是不一致的，且数据版本号也会对应不上。

在本申请上述实施方式中，在轮式移动设备(如，自动驾驶车辆)上仅部署2个节点的前提下，且向第二节点(作为备节点)发送第二请求的APP与第一节点上的第一进程为运行在不同OS的情况时，通过上述强一致性的数据同步流程实现数据的实时备份，即保障了数据的可靠性，同时又降低了轮式移动设备的硬件成本，即在低成本的轮式移动设备的硬件架构中实现高可靠性的数据存储。

为便于理解上述图5所对应的实施方式，下面从信息流向的角度，对上述步骤501至步骤508的过程进行示意，具体请参阅图6，图6为本申请实施例提供的数据的存储方法的另一流程示意图，其中，第一节点作为主节点，第二节点作为备节点，均部署在轮式移动设备上，第一节点上具有第一存储模块，用于存储数据，第一节点上还运行有APP1(实际可以同时运行多个APP，图6仅以一个APP为例进行示意)和第一进程S1，第一进程S1上包括有第一数据库引擎(即图6中的引擎1)，且在引擎1上设置有控制组件HA1，控制组件HA1就用于实现上述步骤501至步骤508所述相关信息的传递过程；类似的，第二节点上具有第二存储模块，用于存储数据，第二节点上还运行有APP2(实际可以同时运行多个APP，图6仅以一个APP为例进行示意)和第二进程S2，第二进程S2上包括有第二数据库引擎(即图6中的引擎2)，且在引擎2上设置有控制组件HA2，控制组件HA2就用于实现上述步骤501至步骤508相关各种信息的传递过程。具体地，备节点上的APP2发起的写数据的过程可以如下所示：

步骤①：第二节点上的APP2通过服务接口C2向第二进程上的控制组件HA2发送请求b，该请求b用于指示向存储模块写数据B。

步骤②：第二节点作为备节点，通过控制组件HA2将该请求b转发至作为主节点的第一节点进行处理。

步骤③：第一节点作为主节点，通过控制组件HA1接收到第二节点发送的请求b，调用引擎1向第一存储模块写数据B，并记录当前的数据版本号N。

步骤④：当数据B被成功写入第一存储模块后，由控制组件HA1向第二节点的控制组件HA2发送响应消息x(即上述所述的第三响应消息)，该响应消息x中可以包含请求b，该响应消息x就用于指示第二节点根据请求b，调用引擎2向第二存储模块写数据B。该响应消息x一般包含在第一节点向第二节点发送的心跳内(也可以单独发送，此处不做限定)。

步骤⑤：第二节点作为备节点，调用引擎2对第二存储模块执行数据B的写操作，同样记录当前的数据版本号N。

步骤⑥：若数据B被成功写入第二存储模块，则第二节点会通过控制组件HA2向第一节点的控制组件HA1发送响应消息y(即上述所述的第四响应消息)。

步骤⑦：当第一节点在预设时长内(如，3s内)接收到该响应消息y，说明数据B被成功写入第二存储模块，那么第一节点就再通过控制组件HA1向第二节点返回一个响应消息z(即上述所述的第五响应消息)，用于告知第二节点双方均对数据B完成了写操作。

步骤⑧：第二节点接收到第一节点发送的响应消息z，就向APP2返回执行结果，该执行结果即为上述所述的响应消息z，用于告知APP2，第一节点和第二节点均对数据B完成了写操作。

需要说明的是，在本申请的一些实施方式中，类似地，引擎1和引擎2的选择完全独立，互相不强依赖，也就是说，引擎1和引擎2即可以是同构的数据库引擎，也可以是异构的数据存储引擎，具体此处不做限定。因为控制组件HA1和控制组件HA2中集成有一个适配模块，用于适配各种数据库引擎，即通过各自的控制组件屏蔽掉数据库引擎的差异。由于不同数据库引擎的资源消耗不同，性能表现也不同。数据库引擎可以运行在差异化的硬件上(比如一个高配，一个低配)。若引擎1和引擎2是采用异构的数据库引擎，那么，性能表现好的引擎一般运行在高配的主节点上，性能表现弱一些的引擎则运行在低配的备节点上。这样差异化的部署也是基于降低成本考虑。

在本申请上述实施方式中，在轮式移动设备(如，自动驾驶车辆、智能汽车、网联汽车等)上仅部署2个节点的前提下，且向第二节点(作为备节点)发送请求b的APP2与第一节点上的第一进程S1为运行在不同OS的情况时，通过上述强一致性(即在任意时刻下，系统里第一节点设备和第二节点设备中的数据都是一样的)的数据同步流程实现数据的实时备份，即保障了数据的可靠性，同时相比于现有技术中至少部署3个节点的方式，本申请部署2个节点的方式降低了轮式移动设备的硬件成本，即在低成本的轮式移动设备的硬件架构中实现高可靠性的数据存储。

需要说明的是，在本申请实施例中，之所以需要主节点和备节点对数据进行备份，就是为了避免一个节点出现故障的话，另一个节点中存储有完全相同的数据，并基于该数据继续为轮式移动设备提供服务，从而保障可用性，数据也不会丢失，基于此，在本申请一些实施方式中，若某个节点发生故障，那么其他节点会以单机模式继续运行，为了提升可用性，本申请实施例融合内外部的检测结果，对故障进行快速感知，由于故障的节点不同，处理的方式也不同，下面分别进行说明。

(1)第一节点(主节点)故障

在上述图3至图6中任一项对应的实施方式中，如果第一节点故障，那么第二节点会立即取代第一节点继续提供服务，并缓存数据，该缓存的数据就为第二节点取代第一节点作为主节点后第二存储模块内更新的数据，并且在第一节点恢复正常使用后，通过第二进程将该缓存的数据向第一节点发送，使得第一节点通过调用第一数据库引擎将该缓存的数据更新至自身的第一存储模块，从而实现两个节点之间的数据同步。

需要说明的是，在本申请的一些实施方式中，对第一节点故障的判断具体可以包括如下几种方式：

a、第一节点向第二节点发送的心跳异常，例如，假设第一节点向第二节点发送心跳的频率正常是300毫秒一次，由于第一节点向第二节点发送心跳的目的就是告知对端自身是在正常运行，但在预设时长内(如，1秒内)第二节点都没有收到第一节点发送的心跳，那么第二节点就认为第一节点故障。

b、第一节点向第二节点主动发送故障通知消息，例如，当第一节点上运行的第一进程上的软件正常或异常退出，则第一节点会主动向第二节点发送故障通知消息；又例如，当第一节点上监控第一进程的第三进程监控到第一进程异常时，则第一节点也会向第二节点主动发送故障通知消息；还例如，第一节点的通信异常，那么第一节点也会主动向第二节点发送故障通知消息，具体此次不做举例示意。方式b相比方式a，能够让第二节点更快感知到第一节点出现了故障，而不必等待预设时长第二节点没有收到第一节点的心跳才确定第一节点故障，从而进一步缩短了故障检测时延。

还需要说明的是，在本申请的一些实施方式中，第二节点取代第一节点继续提供服务具体可以包括以下几种取代方式：

a、第二节点取代第一节点提供服务，直至第一节点恢复正常使用，也就是说，等第一节点恢复了正常使用，第二节点就不再取代，第二节点依然作为备节点工作，一般这种情况是第一节点是高配，第二节点是低配，即第一节点与第二节点的硬件配置不同，主数据库引擎运行在高配的第一节点上，当高配的第一节点故障，则可以短期内由低配的第二节点取代第一节点提供服务，等第一节点恢复正常使用后，再由第一节点继续作为主节点提供服务，这种设置高低配置节点的方式也是为了节约成本。

b、第二节点始终取代第一节点提供服务，也就是说，第二节点取代第一节点作为主节点提供服务后，不管后续第一节点是否恢复正常使用，第二节点就一直作为主节点提供服务，若第一节点恢复正常使用后，就一直作为备节点使用，一般这种一直取代的方式是第一节点和第二节点的硬件配置没有差别的情况。

(2)第二节点(备节点)故障

在上述图3至图6中任一项对应的实施方式中，如果第二节点故障，那么第一节点可以将对端设置为异常状态，而第一节点作为主节点继续提供服务，并缓存数据(如，上述图3和图4中所述的第二数据、图5和图6中所述的第四数据)，该缓存的数据就为第一节点通过第一进程向第一存储模块写数据(如，第一数据或第三数据)后得到的数据，并且在第二节点恢复正常使用后，通过第一进程将该缓存的数据向第二节点发送，使得第二节点通过调用第二数据库引擎将该缓存的数据更新至自身的第二存储模块，从而实现两个节点之间的数据同步。

需要说明的是，在本申请的一些实施方式中，缓存的数据量可能有上限约束，当缓存的数据达到该上限时，则按照先后顺序将缓存时间最早的数据丢弃，这是因为存储模块容量有限，为保证最新的数据能存储进存储模块，只能是删除最早缓存进来的数据。

类似地，在本申请的一些实施方式中，对第二节点故障的判断具体也可以包括如下几种方式：

a、第二节点向第一节点发送的心跳异常，例如，假设第二节点向第一节点发送心跳的频率正常是300毫秒一次，由于第二节点向第一节点发送心跳的目的也是告知对端自身是在正常运行，但在预设时长内(如，1秒内)第一节点都没有收到第二节点发送的心跳，那么第一节点就认为第二节点故障。

b、第二节点向第一节点主动发送故障通知消息，例如，当第二节点上运行的第二进程上的软件正常或异常退出，则第二节点会主动向第一节点发送故障通知消息；又例如，当第二节点上监控第二进程的第四进程监控到第二进程异常时，则第二节点也会向第一节点主动发送故障通知消息；还例如，第二节点的通信异常，那么第二节点也会主动向第一节点发送故障通知消息，具体此次不做举例示意。方式b相比方式a，能够让第一节点更快感知到第二节点出现了故障，而不必等待预设时长第一节点没有收到第二节点的心跳才确定第二节点故障，从而进一步缩短了故障检测时延。

还需要说明的是，在本申请上述实施方式中，不管是第一节点故障，还是第二节点故障，当故障端重启恢复后，第一节点和第二节点都需要进行数据同步，数据同步有增量同步和全量同步两种方式：根据数据版本号，优先尝试增量同步(即只将缓存的数据发给对端)，如果缓存数据不足，则进行全量同步(如，故障时间很长，此时可能大部分数据都是更新后的，因此直接将存储模块内的所有数据全部同步)。

在图3至图6所对应的实施例的基础上，为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关设备，具体请参阅图7，图7为本申请实施例提供的数据存储服务系统700的一种结构示意图，该数据存储服务系统700部署于轮式移动设备(如，自动驾驶车辆)，该数据存储服务系统700包括第一节点701和第二节点702，第一节点701为主节点，第二节点702为备节点。

当该数据存储服务系统700用于实现上述图3至图4所对应的实施例时，第一节点701，用于通过运行在该第一节点701上的第一进程接收与该第一进程对应的第一应用程序发送的第一请求，该第一请求用于指示向存储模块写第一数据；该第一节点701，还用于响应于第一请求，通过该第一进程调用该第一进程上的第一数据库引擎向该第一节点701上的第一存储模块写该第一数据；该第一节点701，还用于在向该第一存储模块写该第一数据已完成的情况下，通过该第一进程将该第一请求向该第二节点702发送；该第二节点702，用于根据该第一请求，通过调用第二进程上的第二数据库引擎向该第二节点702上的第二存储模块写该第一数据，该第二进程运行在该第二节点702上；该第一节点701，还用于当该第一节点701通过该第一进程在预设时长内接收到该第二节点702通过该第二进程发送的第一响应消息，通过该第一进程向该第一应用程序发送第二响应消息，该第一响应消息用于指示向该第二存储模块写该第一数据的操作已执行完成，该第二响应消息用于指示向该第一存储模块写该第一数据和对该第二存储模块执行该第一数据的写操作均已完成。

在本申请上述实施方式中，部署于轮式移动设备(如，自动驾驶车辆、智能汽车、网联汽车等)上的数据存储服务系统700在仅部署2个节点的前提下，且向第二节点702(作为备节点)发送第二请求的APP与第一节点701上的第一进程为运行在不同OS的情况时，通过上述强一致性的数据同步流程实现数据的实时备份，即保障了数据的可靠性，同时相比于现有技术中至少部署3个节点的方式，本申请部署2个节点的方式降低了轮式移动设备的硬件成本，即在低成本的轮式移动设备的硬件架构中实现高可靠性的数据存储。

在一种可能的设计中，该第二节点702，还用于：当该第一节点701故障，取代该第一节点701提供服务，并缓存数据，该缓存的数据就为第二节点702取代第一节点701作为主节点后第二存储模块内更新的数据，并且在第一节点701恢复正常使用后，通过第二进程将该缓存的数据向第一节点701发送，使得第一节点701通过调用第一数据库引擎将该缓存的数据更新至自身的第一存储模块，从而实现两个节点之间的数据同步。

在本申请上述实施方式中，若第一节点701故障(第一节点701作为主节点，第二节点702作为备节点)，则第二节点702立即升为主节点，取代第一节点701进行服务，从而保障数据存储服务系统的可用性，数据不丢失。

在一种可能的设计中，该第二节点702，具体用于：取代该第一节点701提供服务，直至该第一节点701恢复正常使用，或，始终取代该第一节点701提供服务。也就是说，第一种取代方式是等第一节点701恢复了正常使用，第二节点702就不再取代，第二节点702依然作为备节点工作，一般这种情况是第一节点701是高配，第二节点702是低配，即第一节点701与第二节点702的硬件配置不同，主数据库引擎运行在高配的第一节点701上，当高配的第一节点701故障，则可以短期内由低配的第二节点702取代第一节点701提供服务，等第一节点701恢复正常使用后，再由第一节点701继续作为主节点提供服务，这种设置高低配置节点的方式也是为了节约成本。而第二种取代方式是第二节702点取代第一节点701作为主节点提供服务后，不管后续第一节点701是否恢复正常使用，第二节点702就一直作为主节点提供服务，若第一节点701恢复正常使用后，就一直作为备节点使用，一般这种一直取代的方式是第一节点701和第二节点702的硬件配置没有差别的情况。

在本申请上述实施方式中，具体阐述了当第一节点701故障，第二节点702取代第一节点701提供服务的两种方式，具备灵活性和可选择性。

在一种可能的设计中，该第一节点701故障包括：该第一节点701向该第二节点702发送的心跳异常；或，该第一节点701向该第二节点702发送故障通知消息。例如，假设第一节点701向第二节点702发送心跳的频率正常是300毫秒一次，由于第一节点701向第二节点702发送心跳的目的就是告知对端自身是在正常运行，但在预设时长内(如，1秒内)第二节点702都没有收到第一节点701发送的心跳，那么第二节点702就认为第一节点701故障。例如，当第一节点701上运行的第一进程上的软件正常或异常退出，则第一节点701会主动向第二节点702发送故障通知消息；又例如，当第一节点701上监控第一进程的第三进程监控到第一进程异常时，则第一节点701也会向第二节点702主动发送故障通知消息；还例如，第一节点701的通信异常，那么第一节点701也会主动向第二节点702发送故障通知消息，具体此次不做举例示意。

在本申请上述实施方式中，上述两种感知故障的方式都是为了使得第二节点702能够快速感知到第一节点701出现了故障，缩短了故障检测时延。其中，第二种故障感知的方式相比第一种故障感知的方式，能够让第二节点702更快感知到第一节点701出现了故障，而不必等待预设时长第二节点702没有收到第一节点701的心跳才确定第一节点701故障，从而进一步缩短了故障检测时延。

在一种可能的设计中，该第一节点701，还用于当该第二节点702故障，将对端设置为异常状态，并缓存第二数据，并在该第二节点702恢复正常使用后，通过该第一进程将该第二数据向该第二节点702发送；该第二节点702，还用于通过调用该第二数据库引擎将该第二数据更新至该第二存储模块，该第二数据为该第一节点701通过该第一进程向该第一存储模块写该第一数据后得到的数据。

在本申请上述实施方式中，阐述了如果是第二节点702故障，那么第一节点701将作为主节点继续提供服务，并且在第二节点702恢复正常使用后，通过第一进程将该缓存的第二数据向第二节点702发送，使得第二节点702通过调用第二数据库引擎将该缓存的第二数据更新至自身的第二存储模块，从而实现两个节点之间的数据同步，具备可实现性。

在一种可能的设计中，该第二节点702故障包括：该第二节点702向该第一节点701发送的心跳异常；或，该第二节点702向该第一节点701发送故障通知消息。例如，假设第二节点702向第一节点701发送心跳的频率正常是300毫秒一次，由于第二节点702向第一节点701发送心跳的目的是告知对端自身是在正常运行，但在预设时长内(如，1秒内)第一节点701都没有收到第二节点702发送的心跳，那么第一节点701就认为第二节点702故障。例如，当第二节点702上运行的第二进程上的软件正常或异常退出，则第二节点702会主动向第一节点701发送故障通知消息；又例如，当第二节点702上监控第二进程的第四进程监控到第二进程异常时，则第二节点702也会向第一节点701主动发送故障通知消息；还例如，第二节点702的通信异常，那么第二节点702也会主动向第一节点701发送故障通知消息，具体此次不做举例示意。

在本申请上述实施方式中，上述两种感知故障的方式都是为了使得第一节点701能够快速感知到第二节点702出现了故障，缩短了故障检测时延。其中，第二种故障感知的方式相比第一种故障感知的方式，能够让第一节点701更快感知到第二节点702出现了故障，而不必等待预设时长第一节点701没有收到第二节点702的心跳才确定第二节点702故障，从而进一步缩短了故障检测时延。

在一种可能的设计中，该第一存储模块包括第一内存数据库；和/或，该第二存储模块包括第二内存数据库。

在本申请上述实施方式中，阐述了第一存储模块和第二存储模块可以是内存数据库，相对于传统的硬盘，内存数据库的读取速度更快，尤其是在智能驾驶领域，由于车辆的运行状态数据、感知数据、中间计算结果、SOA信息等数据需频繁被读取，若第一存储模块和第二存储模块为硬盘，那么反复频繁的读/写数据会缩短硬盘寿命，从而导致车用器件的更换成本提高。

在一种可能的设计中，该第一节点701，还用于：通过该第一进程记录第一数据版本号，该第一数据版本号用于表示该第一存储模块数据更新后的数据版本(可称为第一数据版本)，该更新后的数据版本为向第一存储模块写第一数据的操作已完成的情况下的数据版本。

在本申请上述实施方式中，通过第一进程执行完第一数据的写操作后，还要记录此次更新后的数据版本号，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。

在一种可能的设计中，该第二节点702，还用于：通过该第二进程记录第二数据版本号，该第二数据版本号用于表示该第二存储模块数据更新后的数据版本(可称为第二数据版本)，所述更新后的数据版本为向第二存储模块写第一数据的操作已完成的情况下的数据版本。

在本申请上述实施方式中，通过第二进程执行完第一数据的写操作后，也要记录此次更新后的数据版本号，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。

在一种可能的设计中，部署有该数据存储服务系统700的轮式移动设备可以是自动驾驶车辆，自动驾驶车辆可以为轿车、卡车、摩托车、公共汽车、船、飞机、直升飞机、割草机、娱乐车、游乐场车辆、施工设备、电车、高尔夫球车、火车、和手推车等，本申请实施例不做特别的限定。

在本申请上述实施方式中，阐述了轮式移动设备可以是自动驾驶车辆，具备可实现性。

此外，当该数据存储服务系统700用于实现上述图5至图6所对应的实施例时，第二节点702，用于通过运行在该第二节点702上的第二进程接收与该第二进程对应的第二应用程序发送的第二请求，该第二请求用于指示向存储模块写第三数据；第一节点701，用于通过运行在该第一节点701上的第一进程接收该第二节点702通过该第二进程转发的第二请求；该第一节点701，还用于响应于该第二请求，通过该第一进程调用该第一进程上的第一数据库引擎向该第一节点701的第一存储模块写该第三数据；该第一节点701，还用于在向该第一存储模块写该第三数据的操作已完成的情况下，通过该第一进程向该第二节点702发送第三响应消息，该第三响应消息用于指示该第二节点702根据该第二请求，通过该第二进程调用该第二进程上的第二数据库引擎向该第二节点702的第二存储模块写该第三数据；该第二节点702，还用于根据该第三响应消息和该第二请求，通过该第二进程调用该第二数据库引擎向该第二存储模块写该第三数据；该第一节点701，还用于当该第一节点701通过该第一进程在预设时长内接收到该第二节点702通过该第二进程发送的第四响应消息，通过该第一进程向该第二节点702发送第五响应消息，该第四响应消息用于指示向该第二存储模块写该第三数据的操作已执行完成，该第五响应消息用于指示向该第一存储模块写该第三数据的操作和向该第二存储模块写该第三数据的操作均已执行完成；该第二节点702，还用于通过该第二进程向该第二应用程序转发该第五响应消息。

在本申请上述实施方式中，部署于轮式移动设备(如，自动驾驶车辆)上的数据存储服务系统700在仅部署2个节点的前提下，且向第二节点702(作为备节点)发送第二请求的APP与第一节点701上的第一进程为运行在不同OS的情况时，通过上述强一致性的数据同步流程实现数据的实时备份，即保障了数据的可靠性，同时又降低了轮式移动设备的硬件成本，即在低成本的轮式移动设备的硬件架构中实现高可靠性的数据存储。

在一种可能的设计中，该第二节点702，还用于：当该第一节点701故障，取代该第一节点701提供服务，并缓存数据，该缓存的数据就为第二节点702取代第一节点701作为主节点后第二存储模块内更新的数据，并且在第一节点701恢复正常使用后，通过第二进程将该缓存的数据向第一节点701发送，使得第一节点701通过调用第一数据库引擎将该缓存的数据更新至自身的第一存储模块，从而实现两个节点之间的数据同步。

在本申请上述实施方式中，若第一节点701故障(第一节点701作为主节点，第二节点702作为备节点)，则第二节点702立即升为主节点，取代第一节点701进行服务，从而保障数据存储服务系统的可用性，数据不丢失。

在一种可能的设计中，该第二节点702，具体用于：取代该第一节点701提供服务，直至该第一节点701恢复正常使用；或，始终取代该第一节点701提供服务。也就是说，第一种取代方式是等第一节点701恢复了正常使用，第二节点702就不再取代，第二节点702依然作为备节点工作，一般这种情况是第一节点701是高配，第二节点702是低配，即第一节点701与第二节点702的硬件配置不同，主数据库引擎运行在高配的第一节点701上，当高配的第一节点701故障，则可以短期内由低配的第二节点702取代第一节点701提供服务，等第一节点701恢复正常使用后，再由第一节点701继续作为主节点提供服务，这种设置高低配置节点的方式也是为了节约成本。而第二种取代方式是第二节702点取代第一节点701作为主节点提供服务后，不管后续第一节点701是否恢复正常使用，第二节点702就一直作为主节点提供服务，若第一节点701恢复正常使用后，就一直作为备节点使用，一般这种一直取代的方式是第一节点701和第二节点702的硬件配置没有差别的情况。

在本申请上述实施方式中，具体阐述了当第一节点701故障，第二节点702取代第一节点701提供服务的两种方式，具备灵活性和可选择性。

在一种可能的设计中，该第一节点701故障包括：该第一节点701向该第二节点702发送的心跳异常；或，该第一节点701向该第二节点702发送故障通知消息。例如，假设第一节点701向第二节点702发送心跳的频率正常是300毫秒一次，由于第一节点701向第二节点702发送心跳的目的就是告知对端自身是在正常运行，但在预设时长内(如，1秒内)第二节点702都没有收到第一节点701发送的心跳，那么第二节点702就认为第一节点701故障。例如，当第一节点701上运行的第一进程上的软件正常或异常退出，则第一节点701会主动向第二节点702发送故障通知消息；又例如，当第一节点701上监控第一进程的第三进程监控到第一进程异常时，则第一节点701也会向第二节点702主动发送故障通知消息；还例如，第一节点701的通信异常，那么第一节点701也会主动向第二节点702发送故障通知消息，具体此次不做举例示意。

在本申请上述实施方式中，上述两种感知故障的方式都是为了使得第二节点702能够快速感知到第一节点701出现了故障，缩短了故障检测时延。其中，第二种故障感知的方式相比第一种故障感知的方式，能够让第二节点702更快感知到第一节点701出现了故障，而不必等待预设时长第二节点702没有收到第一节点701的心跳才确定第一节点701故障，从而进一步缩短了故障检测时延。

在一种可能的设计中，该第一节点701，还用于当该第二节点702故障，将对端设置为异常状态，并缓存第四数据，并在该第二节点702恢复正常使用后，通过该第一进程将该第四数据向该第二节点702发送；该第二节点702，还用于通过调用该第二数据库引擎将该第四数据更新至该第二存储模块，该第四数据为该第一节点701通过该第一进程向该第一存储模块写入该第三数据后得到的数据。

在本申请上述实施方式中，阐述了如果是第二节点702故障，那么第一节点701将作为主节点继续提供服务，并且在第二节点702恢复正常使用后，通过第一进程将该缓存的第四数据向第二节点702发送，使得第二节点702通过调用第二数据库引擎将该缓存的第四数据更新至自身的第二存储模块，从而实现两个节点之间的数据同步，具备可实现性。

在一种可能的设计中，该第二节点702故障包括：该第二节点702向该第一节点701发送的心跳异常；或，该第二节点702向该第一节点701发送故障通知消息。例如，假设第二节点702向第一节点701发送心跳的频率正常是300毫秒一次，由于第二节点702向第一节点701发送心跳的目的是告知对端自身是在正常运行，但在预设时长内(如，1秒内)第一节点701都没有收到第二节点702发送的心跳，那么第一节点701就认为第二节点702故障。例如，当第二节点702上运行的第二进程上的软件正常或异常退出，则第二节点702会主动向第一节点701发送故障通知消息；又例如，当第二节点702上监控第二进程的第四进程监控到第二进程异常时，则第二节点702也会向第一节点701主动发送故障通知消息；还例如，第二节点702的通信异常，那么第二节点702也会主动向第一节点701发送故障通知消息，具体此次不做举例示意。

在本申请上述实施方式中，上述两种感知故障的方式都是为了使得第一节点701能够快速感知到第二节点702出现了故障，缩短了故障检测时延。其中，第二种故障感知的方式相比第一种故障感知的方式，能够让第一节点701更快感知到第二节点702出现了故障，而不必等待预设时长第一节点701没有收到第二节点702的心跳才确定第二节点702故障，从而进一步缩短了故障检测时延。

在一种可能的设计中，该第一存储模块包括第一内存数据库；和/或，该第二存储模块包括第二内存数据库。

在本申请上述实施方式中，阐述了第一存储模块和第二存储模块可以是内存数据库，相对于传统的硬盘，内存数据库的读取速度更快，尤其是在智能驾驶领域，由于车辆的运行状态数据、感知数据、中间计算结果、SOA信息等数据需频繁被读取，若第一存储模块和第二存储模块为硬盘，那么反复频繁的读/写数据会缩短硬盘寿命，从而导致车用器件的更换成本提高。

在一种可能的设计中，该第一节点701，还用于：通过该第一进程记录第一数据版本号，该第一数据版本号用于表示该第一存储模块数据更新后的数据版本(可称为第一数据版本)，所述更新后的数据版本为向第一存储模块写第三数据的操作已完成的情况下的数据版本。

在本申请上述实施方式中，通过第一进程执行完第一数据的写操作后，还要记录此次更新后的数据版本号，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。

在一种可能的设计中，该第二节点702，还用于：通过该第二进程记录第二数据版本号，该第二数据版本号用于表示该第二存储模块数据更新后的数据版本(可称为第二数据版本)，所述更新后的数据版本为向第二存储模块写第三数据的操作已完成的情况下的数据版本。

在本申请上述实施方式中，通过第二进程执行完第一数据的写操作后，也要记录此次更新后的数据版本号，这样便于查找每次更新的数据是哪个版本，更新了哪些数据等。

在一种可能的设计中，部署有该数据存储服务系统700的轮式移动设备可以是自动驾驶车辆，自动驾驶车辆可以为轿车、卡车、摩托车、公共汽车、船、飞机、直升飞机、割草机、娱乐车、游乐场车辆、施工设备、电车、高尔夫球车、火车、和手推车等，本申请实施例不做特别的限定。

在本申请上述实施方式中，阐述了轮式移动设备可以是自动驾驶车辆，具备可实现性。

需要说明的是，图7对应实施例所述的各模块/单元之间的信息交互、执行过程等内容，与本申请中图3至图6对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

在图3至图4所对应的实施例的基础上，为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的节点，该节点作为第一节点，具体参阅图8，图8是本申请实施例提供的第一节点800的一种结构示意图，第一节点800具体可以包括：接收模块801，用于通过运行在所述第一节点800上的第一进程接收与所述第一进程对应的第一应用程序发送的第一请求，所述第一请求用于指示向存储模块写第一数据；调用模块802，用于根据所述第一请求，通过所述第一进程调用所述第一进程上的第一数据库引擎向所述第一节点800上的第一存储模块写所述第一数据；第一发送模块803，用于在向所述第一存储模块写所述第一数据的操作已完成的情况下，通过所述第一进程将所述第一请求向所述第二节点发送，以使得所述第二节点根据所述第一请求，通过调用第二进程上的第二数据库引擎向所述第二节点上的第二存储模块写该第一数据，所述第二进程运行在所述第二节点上；第二发送模块804，用于当通过所述第一进程在预设时长内接收到所述第二节点通过所述第二进程发送的第一响应消息，通过所述第一进程向所述第一应用程序发送第二响应消息，所述第一响应消息用于指示向所述第二存储模块写所述第一数据的操作已完成，所述第二响应消息用于指示向所述第一存储模块写所述第一数据的操作和向所述第二存储模块写所述第一数据的操作均已完成。

在一种可能的设计中，所述第一发送模块803，还用于：当所述第二节点故障，缓存第二数据，并在所述第二节点恢复正常使用后，通过所述第一进程将所述第二数据向所述第二节点发送，以使得所述第二节点通过调用所述第二数据库引擎将所述第二数据更新至所述第二存储模块，所述第二数据为所述第一节点800通过所述第一进程向所述第一存储模块写所述第一数据的操作后得到的数据。

在一种可能的设计中，所述第二节点故障包括：所述第二节点向所述第一节点800发送的心跳异常；或，所述第二节点向所述第一节点800发送故障通知消息。

在一种可能的设计中，所述第一存储模块包括第一内存数据库；和/或，所述第二存储模块包括第二内存数据库。

在一种可能的设计中，所述调用模块802，还用于：通过所述第一进程记录第一数据版本号，所述第一数据版本号用于表示所述第一存储模块数据更新后的数据版本。

需要说明的是，图3至图4对应实施例所述的第一节点上各模块/单元之间的信息交互、执行过程等内容，与本申请中图8对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

在图5至图6所对应的实施例的基础上，为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的节点，该节点作为第一节点，具体参阅图9，图9是本申请实施例提供的第一节点900的一种结构示意图，第一节点900具体可以包括：接收模块901，用于通过运行在所述第一节点900上的第一进程接收运行在所述第二节点上的第二进程转发的第二请求，所述第二请求由与所述第二进程对应的第二应用程序向所述第二节点发送，所述第二请求用于指示向存储模块写第三数据；调用模块902，用于根据所述第二请求，通过所述第一进程调用所述第一进程上的第一数据库引擎向所述第一节点900的第一存储模块写所述第三数据；第一发送模块903，用于在向所述第一存储模块写所述第三数据的操作已执行完成的情况下，通过所述第一进程向所述第二节点发送第三响应消息，所述第三响应消息用于指示所述第二节点根据所述第二请求，通过所述第二进程调用所述第二进程上的第二数据库引擎向所述第二节点的第二存储模块写所述第三数据；第二发送模块904，用于当通过所述第一进程在预设时长内接收到所述第二节点通过所述第二进程发送的第四响应消息，通过所述第一进程向所述第二节点发送第五响应消息，以使得所述第二节点通过所述第二进程向所述第二应用程序转发所述第五响应消息，所述第四响应消息用于指示向所述第二存储模块写所述第三数据的操作已完成，所述第五响应消息用于指示向所述第一存储模块写所述第三数据的操作和向所述第二存储模块写所述第三数据的操作均已完成。

在一种可能的设计中，所述第一发送模块903，还用于：当所述第二节点故障，缓存第四数据，并在所述第二节点恢复正常使用后，通过所述第一进程将所述第四数据向所述第二节点发送，以使得所述第二节点通过调用所述第二数据库引擎将所述第四数据更新至所述第二存储模块，所述第四数据为所述第一节点900通过所述第一进程向所述第一存储模块写所述第三数据后得到的数据。

在一种可能的设计中，所述第二节点故障包括：所述第二节点向所述第一节点900发送的心跳异常；或，所述第二节点向所述第一节点900发送故障通知消息。

在一种可能的设计中，所述第一存储模块包括第一内存数据库；和/或，所述第二存储模块包括第二内存数据库。

在一种可能的设计中，所述调用模块902，还用于：通过所述第一进程记录第一数据版本号，所述第一数据版本号用于表示所述第一存储模块数据更新后的数据版本。

需要说明的是，图5至图6对应实施例所述的第一节点上各模块/单元之间的信息交互、执行过程等内容，与本申请中图9对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

本申请实施例还提供了一种数据存储服务系统，该数据存储服务系统部署于轮式移动设备(如，自动驾驶车辆)上，请参阅图10，图10是本申请实施例提供的数据存储服务系统1000的一种结构示意图，为便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。数据存储服务系统1000上可以部署有图7对应实施例中所描述的数据存储服务系统的模块，用于实现图3至图6对应实施例的功能，具体的，数据存储服务系统1000由一个或多个服务器实现，数据存储服务系统1000可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessing units，CPU)1022(例如，一个或一个以上)和存储器1032，一个或一个以上存储应用程序1042或数据1044的存储介质1030(例如一个或一个以上海量存储设备)。其中，存储器1032和存储介质1030可以是短暂存储或持久存储。存储在存储介质1030的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对训练设备中的一系列指令操作。更进一步地，中央处理器1022可以设置为与存储介质1030通信，在数据存储服务系统1000上执行存储介质1030中的一系列指令操作。

数据存储服务系统1000还可以包括一个或一个以上电源1026，一个或一个以上有线或无线网络接口1050，一个或一个以上输入输出接口1058，和/或，一个或一个以上操作系统1041，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。

在本申请实施例中，上述图3至图6对应的实施例中由第一节点和第二节点所执行的步骤可以基于该图10所示的结构实现，具体此处不予赘述。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，训练设备，或者网络设备等)执行本申请各个实施例所述的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid statedisk，SSD))等。

Claims (38)

1.一种数据的存储方法，其特征在于，所述方法包括：

第一节点设备通过运行在所述第一节点设备上的第一进程接收第一应用程序发送的第一请求；

响应于所述第一请求，并基于所述第一进程上的第一数据库引擎，所述第一节点设备通过所述第一进程向所述第一节点设备上的第一存储模块写第一数据；

在向所述第一存储模块写所述第一数据的操作已完成的情况下，所述第一节点设备通过所述第一进程将所述第一请求向第二节点设备发送，以使得所述第二节点设备响应于所述第一请求，并使得所述第二节点设备基于第二进程上的第二数据库引擎，通过所述第二进程向所述第二节点设备上的第二存储模块写所述第一数据，所述第二进程运行在所述第二节点设备上；

当所述第一节点设备通过所述第一进程在预设时长内接收到所述第二节点设备通过所述第二进程发送的第一响应消息，所述第一节点设备通过所述第一进程向所述第一应用程序发送第二响应消息，所述第一响应消息用于指示向所述第二存储模块写所述第一数据的操作已完成，所述第二响应消息用于指示向所述第一存储模块写所述第一数据的操作和向所述第二存储模块写所述第一数据的操作均已完成。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当所述第一节点设备故障，所述第二节点设备取代所述第一节点设备提供服务。

3.根据权利要求2所述的方法，其特征在于，所述第二节点设备取代所述第一节点设备提供服务包括：

所述第二节点设备取代所述第一节点设备提供服务，直至所述第一节点设备恢复正常使用；

或，

所述第二节点设备始终取代所述第一节点设备提供服务。

4.根据权利要求2-3中任一项所述的方法，其特征在于，所述第一节点设备故障包括：

所述第一节点设备向所述第二节点设备发送的心跳异常；

或，

所述第一节点设备向所述第二节点设备发送故障通知消息。

5.根据权利要求1所述的方法，其特征在于，在所述第一节点设备通过所述第一进程向所述第一应用程序发送第二响应消息之前，所述方法还包括：

当所述第二节点设备故障，所述第一节点设备缓存第二数据，并在所述第二节点设备恢复正常使用后，通过所述第一进程将所述第二数据向所述第二节点设备发送，以使得所述第二节点设备基于所述第二数据库引擎将所述第二数据更新至所述第二存储模块，所述第二数据为所述第一节点设备通过所述第一进程向所述第一存储模块写所述第一数据后得到的数据。

6.根据权利要求5所述的方法，其特征在于，所述第二节点设备故障包括：

所述第二节点设备向所述第一节点设备发送的心跳异常；

或，

所述第二节点设备向所述第一节点设备发送故障通知消息。

7.根据权利要求1-6中任一项所述的方法，其特征在于，

所述第一存储模块包括第一内存数据库；

和/或，

所述第二存储模块包括第二内存数据库。

8.根据权利要求1-7中任一项所述的方法，其特征在于，在所述响应于所述第一请求，并基于所述第一进程上的第一数据库引擎，所述第一节点设备通过所述第一进程向所述第一节点设备上的第一存储模块写所述第一数据之后，所述方法还包括：

所述第一节点设备通过所述第一进程记录第一数据版本号，所述第一数据版本号用于表示所述第一存储模块数据更新后的第一数据版本，所述更新后的第一数据版本为向所述第一存储模块写所述第一数据的操作已完成的情况下的数据版本。

9.根据权利要求1-8中任一项所述的方法，其特征在于，所述第一节点设备通过所述第一进程将所述第一请求向所述第二节点设备发送，以使得所述第二节点设备响应于所述第一请求，并使得所述第二节点设备基于第二进程上的第二数据库引擎，通过所述第二进程向所述第二节点设备上的第二存储模块写所述第一数据包括：

所述第一节点设备通过所述第一进程将所述第一请求向所述第二节点设备发送，以使得所述第二节点设备响应于所述第一请求，并使得所述第二节点设备基于第二进程上的第二数据库引擎，通过所述第二进程向所述第二节点设备上的第二存储模块写所述第一数据，且还使得所述第二节点设备通过所述第二进程记录第二数据版本号，所述第二数据版本号用于表示所述第二存储模块数据更新后的第二数据版本，所述更新后的第二数据版本为向所述第二存储模块写所述第一数据的操作已完成的情况下的数据版本。

10.一种数据的存储方法，其特征在于，所述方法包括：

第一节点设备通过运行在所述第一节点设备上的第一进程接收运行在第二节点设备上的第二进程转发的第二请求，所述第二请求由第二应用程序向所述第二节点设备发送；

响应于所述第二请求，并基于所述第一进程上的第一数据库引擎，所述第一节点设备通过所述第一进程向所述第一节点设备上的第一存储模块写第三数据；

在向所述第一存储模块写所述第三数据的操作已完成的情况下，所述第一节点设备通过所述第一进程向所述第二节点设备发送第三响应消息，所述第三响应消息用于指示所述第二节点设备响应于所述第二请求，并用于指示所述第二节点设备基于所述第二进程上的第二数据库引擎，通过所述第二进程向所述第二节点设备上的第二存储模块写所述第三数据；

当所述第一节点设备通过所述第一进程在预设时长内接收到所述第二节点设备通过所述第二进程发送的第四响应消息，所述第一节点设备通过所述第一进程向所述第二节点设备发送第五响应消息，以使得所述第二节点设备通过所述第二进程向所述第二应用程序转发所述第五响应消息，所述第四响应消息用于指示向所述第二存储模块写所述第三数据的操作已完成，所述第五响应消息用于指示向所述第一存储模块写所述第三数据的操作和向所述第二存储模块写所述第三数据的操作均已完成。

11.根据权利要求10所述的方法，其特征在于，所述方法还包括：

当所述第一节点设备故障，所述第二节点设备取代所述第一节点设备提供服务。

12.根据权利要求11所述的方法，其特征在于，所述第二节点设备取代所述第一节点设备提供服务包括：

所述第二节点设备取代所述第一节点设备提供服务，直至所述第一节点设备恢复正常使用；

或，

所述第二节点设备始终取代所述第一节点设备提供服务。

13.根据权利要求11-12中任一项所述的方法，其特征在于，所述第一节点设备故障包括：

所述第一节点设备向所述第二节点设备发送的心跳异常；

或，

所述第一节点设备向所述第二节点设备发送故障通知消息。

14.根据权利要求10所述的方法，其特征在于，在所述第一节点设备通过所述第一进程向所述第二节点设备发送第五响应消息之前，所述方法还包括：

当所述第二节点设备故障，所述第一节点设备缓存第四数据，并在所述第二节点设备恢复正常使用后，通过所述第一进程将所述第四数据向所述第二节点设备发送，以使得所述第二节点设备基于所述第二数据库引擎将所述第四数据更新至所述第二存储模块，所述第四数据为所述第一节点设备通过所述第一进程向所述第一存储模块写所述第三数据后得到的数据。

15.根据权利要求14所述的方法，其特征在于，所述第二节点设备故障包括：

所述第二节点设备向所述第一节点设备发送的心跳异常；

或，

所述第二节点设备向所述第一节点设备发送故障通知消息。

16.根据权利要求10-15中任一项所述的方法，其特征在于，

所述第一存储模块包括第一内存数据库；

和/或，

所述第二存储模块包括第二内存数据库。

17.根据权利要求10-16中任一项所述的方法，其特征在于，在所述响应于所述第二请求，并基于所述第一进程上的第一数据库引擎，所述第一节点设备通过所述第一进程向所述第一节点设备上的第一存储模块写第三数据之后，所述方法还包括：

所述第一节点设备通过所述第一进程记录第一数据版本号，所述第一数据版本号用于表示所述第一存储模块数据更新后的第一数据版本，所述更新后的第一数据版本为向所述第一存储模块写所述第三数据的操作已完成的情况下的数据版本。

18.根据权利要求10-17中任一项所述的方法，其特征在于，所述第三响应消息用于指示所述第二节点设备响应于所述第二请求，并用于指示所述第二节点设备基于所述第二进程上的第二数据库引擎，通过所述第二进程向所述第二节点设备上的第二存储模块写所述第三数据包括：

所述第三响应消息用于指示所述第一节点设备响应于所述第二请求，并用于指示所述第二节点设备基于所述第二进程上的第二数据库引擎，通过所述第二进程向所述第二节点设备上的第二存储模块写所述第三数据，且还用于指示所述第二节点设备通过所述第二进程记录第二数据版本号，所述第二数据版本号用于表示所述第二存储模块数据更新后的第二数据版本，所述更新后的第二数据版本为向所述第二存储模块写所述第三数据的操作已完成的情况下的数据版本。

19.一种数据存储服务系统，其特征在于，所述系统部署于轮式移动设备，所述系统包括：

第一节点设备，用于通过运行在所述第一节点设备上的第一进程接收第一应用程序发送的第一请求；

所述第一节点设备，还用于响应于所述第一请求，并基于所述第一进程上的第一数据库引擎，所述第一节点设备通过所述第一进程向所述第一节点设备上的第一存储模块写第一数据；

所述第一节点设备，还用于在向所述第一存储模块写所述第一数据的操作已完成的情况下，通过所述第一进程将所述第一请求向所述第二节点设备发送；

所述第二节点设备，用于响应于所述第一请求，并基于第二进程上的第二数据库引擎，通过所述第二进程向所述第二节点设备上的第二存储模块写所述第一数据，所述第二进程运行在所述第二节点设备上；

所述第一节点设备，还用于当所述第一节点设备通过所述第一进程在预设时长内接收到所述第二节点设备通过所述第二进程发送的第一响应消息，通过所述第一进程向所述第一应用程序发送第二响应消息，所述第一响应消息用于指示向所述第二存储模块写所述第一数据的操作已完成，所述第二响应消息用于指示向所述第一存储模块写所述第一数据的操作和向所述第二存储模块写所述第一数据的操作均已完成。

20.根据权利要求19所述的系统，其特征在于，所述第二节点设备，还用于：

当所述第一节点设备故障，取代所述第一节点设备提供服务。

21.根据权利要求20所述的系统，其特征在于，所述第二节点设备，具体用于：

取代所述第一节点设备提供服务，直至所述第一节点设备恢复正常使用；

或，

始终取代所述第一节点设备提供服务。

22.根据权利要求20-21中任一项所述的系统，其特征在于，所述第一节点设备故障包括：

所述第一节点设备向所述第二节点设备发送的心跳异常；

或，

所述第一节点设备向所述第二节点设备发送故障通知消息。

23.根据权利要求19所述的系统，其特征在于，

所述第一节点设备，还用于当所述第二节点设备故障，缓存第二数据，并在所述第二节点设备恢复正常使用后，通过所述第一进程将所述第二数据向所述第二节点设备发送；

所述第二节点设备，还用于基于所述第二数据库引擎将所述第二数据更新至所述第二存储模块，所述第二数据为所述第一节点设备通过所述第一进程向所述第一存储模块写所述第一数据后得到的数据。

24.根据权利要求23所述的系统，其特征在于，所述第二节点设备故障包括：

所述第二节点设备向所述第一节点设备发送的心跳异常；

或，

所述第二节点设备向所述第一节点设备发送故障通知消息。

25.根据权利要求19-24中任一项所述的系统，其特征在于，

所述第一存储模块包括第一内存数据库；

和/或，

所述第二存储模块包括第二内存数据库。

26.根据权利要求19-25中任一项所述的系统，其特征在于，所述第一节点设备，还用于：

通过所述第一进程记录第一数据版本号，所述第一数据版本号用于表示所述第一存储模块数据更新后的第一数据版本，所述更新后的第一数据版本为向所述第一存储模块写所述第一数据的操作已完成的情况下的数据版本。

27.根据权利要求19-26中任一项所述的系统，其特征在于，所述第二节点设备，还用于：

通过所述第二进程记录第二数据版本号，所述第二数据版本号用于表示所述第二存储模块数据更新后的第二数据版本，所述更新后的第二数据版本为向所述第二存储模块写所述第一数据的操作已完成的情况下的数据版本。

28.一种数据存储服务系统，其特征在于，所述系统部署于轮式移动设备，所述系统包括：

第二节点设备，用于通过运行在所述第二节点设备上的第二进程接收第二应用程序发送的第二请求；

第一节点设备，用于通过运行在所述第一节点设备上的第一进程接收所述第二节点设备通过所述第二进程转发的所述第二请求；

所述第一节点设备，还用于响应于所述第二请求，并基于所述第一进程上的第一数据库引擎，通过所述第一进程向所述第一节点设备上的第一存储模块写第三数据；

所述第一节点设备，还用于在向所述第一存储模块写所述第三数据的操作已完成的情况下，通过所述第一进程向所述第二节点设备发送第三响应消息，所述第三响应消息用于指示所述第二节点设备响应于所述第二请求，并用于指示所述第二节点设备基于所述第二进程上的第二数据库引擎，通过所述第二进程向所述第二节点设备上的第二存储模块写所述第三数据；

所述第二节点设备，还用于响应于所述第三响应消息和所述第二请求，基于所述第二数据库引擎，通过所述第二进程向所述第二存储模块写所述第三数据；

所述第一节点设备，还用于当所述第一节点设备通过所述第一进程在预设时长内接收到所述第二节点设备通过所述第二进程发送的第四响应消息，通过所述第一进程向所述第二节点设备发送第五响应消息，所述第四响应消息用于指示向所述第二存储模块写所述第三数据的操作已完成，所述第五响应消息用于指示向所述第一存储模块写所述第三数据的操作和向所述第二存储模块写所述第三数据的操作均已完成；

所述第二节点设备，还用于通过所述第二进程向所述第二应用程序转发所述第五响应消息。

29.根据权利要求28所述的系统，其特征在于，所述第二节点设备，还用于：

当所述第一节点设备故障，取代所述第一节点设备提供服务。

30.根据权利要求29所述的系统，其特征在于，所述第二节点设备，具体用于：

取代所述第一节点设备提供服务，直至所述第一节点设备恢复正常使用；

或，

始终取代所述第一节点设备提供服务。

31.根据权利要求28所述的系统，其特征在于，

所述第一节点设备，还用于当所述第二节点设备故障，缓存第四数据，并在所述第二节点设备恢复正常使用后，通过所述第一进程将所述第四数据向所述第二节点设备发送；

所述第二节点设备，还用于基于所述第二数据库引擎将所述第四数据更新至所述第二存储模块，所述第四数据为所述第一节点设备通过所述第一进程向所述第一存储模块写所述第三数据后得到的数据。

32.一种节点设备，其特征在于，所述节点设备应用于数据存储服务系统，所述系统部署于轮式移动设备，所述系统包括第一节点设备和第二节点设备，所述节点设备作为第一节点设备，包括：

接收模块，用于通过运行在所述第一节点设备上的第一进程接收第一应用程序发送的第一请求；

调用模块，用于响应于所述第一请求，并基于所述第一进程上的第一数据库引擎，通过所述第一进程向所述第一节点设备上的第一存储模块写第一数据；

第一发送模块，用于在向所述第一存储模块写所述第一数据的操作已完成的情况下，通过所述第一进程将所述第一请求向所述第二节点设备发送，以使得所述第二节点设备响应于所述第一请求，并使得所述第二节点设备基于第二进程上的第二数据库引擎，通过所述第二进程向所述第二节点设备上的第二存储模块写所述第一数据，所述第二进程运行在所述第二节点设备上；

第二发送模块，用于当通过所述第一进程在预设时长内接收到所述第二节点设备通过所述第二进程发送的第一响应消息，通过所述第一进程向所述第一应用程序发送第二响应消息，所述第一响应消息用于指示向所述第二存储模块写所述第一数据的操作已完成，所述第二响应消息用于指示向所述第一存储模块写所述第一数据的操作和向所述第二存储模块写所述第一数据的操作均已完成。

33.根据权利要求32所述的第一节点设备，其特征在于，所述第一发送模块，还用于：

当所述第二节点设备故障，缓存第二数据，并在所述第二节点设备恢复正常使用后，通过所述第一进程将所述第二数据向所述第二节点设备发送，以使得所述第二节点设备基于所述第二数据库引擎将所述第二数据更新至所述第二存储模块，所述第二数据为所述第一节点设备通过所述第一进程向所述第一存储模块写所述第一数据后得到的数据。

34.根据权利要求32-33中任一项所述的第一节点设备，其特征在于，所述调用模块，还用于：

通过所述第一进程记录第一数据版本号，所述第一数据版本号用于表示所述第一存储模块数据更新后的第一数据版本，所述更新后的第一数据版本为向所述第一存储模块写所述第一数据的操作已完成的情况下的数据版本。

35.一种节点设备，其特征在于，所述节点设备应用于数据存储服务系统，所述系统部署于轮式移动设备，所述系统包括第一节点设备和第二节点设备，所述节点设备作为第一节点设备，包括：

接收模块，用于通过运行在所述第一节点设备上的第一进程接收运行在所述第二节点设备上的第二进程转发的第二请求，所述第二请求由第二应用程序向所述第二节点设备发送；

调用模块，用于响应于所述第二请求，并基于所述第一进程上的第一数据库引擎，通过所述第一进程向所述第一节点设备上的第一存储模块写第三数据；

第一发送模块，用于在向所述第一存储模块写所述第三数据的操作已完成的情况下，通过所述第一进程向所述第二节点设备发送第三响应消息，所述第三响应消息用于指示所述第二节点设备响应于所述第二请求，并用于指示所述第二节点设备基于所述第二进程上的第二数据库引擎，通过所述第二进程向所述第二节点设备上的第二存储模块写所述第三数据；

第二发送模块，用于当通过所述第一进程在预设时长内接收到所述第二节点设备通过所述第二进程发送的第四响应消息，通过所述第一进程向所述第二节点设备发送第五响应消息，以使得所述第二节点设备通过所述第二进程向所述第二应用程序转发所述第五响应消息，所述第四响应消息用于指示向所述第二存储模块写所述第三数据的操作已完成，所述第五响应消息用于指示向所述第一存储模块写所述第三数据的操作和向所述第二存储模块写所述第三数据的操作均已完成。

36.根据权利要求35所述的第一节点设备，其特征在于，所述第一发送模块，还用于：

当所述第二节点设备故障，缓存第四数据，并在所述第二节点设备恢复正常使用后，通过所述第一进程将所述第四数据向所述第二节点设备发送，以使得所述第二节点设备基于所述第二数据库引擎将所述第四数据更新至所述第二存储模块，所述第四数据为所述第一节点设备通过所述第一进程向所述第一存储模块写所述第三数据后得到的数据。

37.根据权利要求35-36中任一项所述的第一节点设备，其特征在于，所述调用模块，还用于：

通过所述第一进程记录第一数据版本号，所述第一数据版本号用于表示所述第一存储模块数据更新后的第一数据版本，所述更新后的第一数据版本为向所述第一存储模块写所述第三数据的操作已完成的情况下的数据版本。

38.一种数据存储服务系统，其特征在于，所述系统部署于轮式移动设备，所述系统包括第一节点和第二节点，所述第一节点包括第一处理器和第一存储器，所述第一处理器与所述第一存储器耦合，所述第二节点包括第二处理器和第二存储器，所述第二处理器与所述第二存储器耦合，

所述第一存储器，用于存储第一程序；

所述第一处理器，用于执行所述第一存储器中的第一程序，使得所述数据存储服务系统执行如权利要求1-9中任一项所述方法中由所述第一节点设备所执行的步骤，或，使得所述数据存储服务系统执行如权利要求10-18中任一项所述方法中由所述第一节点所执行的步骤；

所述第二存储器，用于存储第二程序；

所述第二处理器，用于执行所述第二存储器中的第二程序，使得所述数据存储服务系统执行如权利要求1-9中任一项所述方法中由所述第二节点设备所执行的步骤，或，使得所述数据存储服务系统执行如权利要求10-18中任一项所述方法中由所述第二节点所执行的步骤。

Images