CN112287062B - 实时交通信息的同步方法、装置及电子设备 - Google Patents

Abstract

本申请是关于一种实时交通信息的同步方法、装置及电子设备。该方法中，至少一个辅数据库中存储至少部分地图道路数据，全部地图道路数据还另外存储于主数据库中；每一辅数据库按照预设周期查询对应的地图道路数据与主数据库中对应的地图道路数据是否相同；如果辅数据库中的地图道路数据与主数据库中对应的地图道路数据不同，所述辅数据库接收所述主数据库发送的对应的所述地图道路数据；辅数据库根据接收的位置信息发送对应的实时交通信息至用户端。本申请的方法避免由单个主数据库同时对接众多的用户端，通过多个辅数据库分发实时交通信息至对应的用户端，多个辅数据库可以均衡负载，降低对主数据库的数据处理负荷，提高实时交通信息的更新效率。

Description

实时交通信息的同步方法、装置及电子设备

技术领域

本申请涉及导航技术领域，尤其涉及一种实时交通信息的同步方法、装置及电子设备。

背景技术

TMC(Traffic Message Channel)是实时交通信息的简称，能够实时反映电子地图区域内道路的交通状态。通过将TMC信息发送到终端的电子地图上显示，可以提示出行者避开拥挤路段，合理规划行车路线。

相关技术中，针对全国性的TMC系统，一般是通过一台服务器处理，在每分钟将上百万条TMC信息发送至对应的用户端。然而，TMC信息需要实时更新，由于数据负载大，可能会使部分用户端的数据更新延迟。

发明内容

为克服相关技术中存在的问题，本申请提供一种实时交通信息的同步方法、装置及电子设备，该实时交通信息的同步方法、装置及电子设备，能够降低服务器的负载，提高数据更新效率。

本申请第一方面提供一种实时交通信息的同步方法，其包括：

至少一个辅数据库中存储至少部分地图道路数据，其中，全部所述地图道路数据还另外存储于主数据库中；

每一所述辅数据库按照预设周期查询对应的所述地图道路数据与所述主数据库中对应的所述地图道路数据是否相同；

如果所述辅数据库中的所述地图道路数据与所述主数据库中对应的所述地图道路数据不同，所述辅数据库接收所述主数据库发送的对应的所述地图道路数据，以更新所述辅数据库中对应的地图道路数据；

所述辅数据库根据接收的位置信息发送对应的实时交通信息至用户端。

在其中一个实施例中，所述至少一个辅数据库中存储至少部分地图道路数据，包括：

全部所述地图道路数据根据地图区域划分，每一所述地图区域的所述地图道路数据分别存储于对应的所述辅数据库中。

在其中一个实施例中，所述每一所述地图区域的所述地图道路数据分别存储于对应的所述辅数据库中，包括：

根据地图瓦片数量，设置相应数量的辅数据库；

将所述地图道路数据按照地图瓦片分割形成多个所述地图区域，并将分割后每一所述地图区域对应的地图道路数据分配存储至对应的所述辅数据库中。

在其中一个实施例中，所述将所述地图道路数据按照地图瓦片分割形成多个所述地图区域，并将分割后的每一所述地图区域对应的地图道路数据分配存储至对应的所述辅数据库中，包括：

根据所述地图瓦片的数量和所述辅数据库的数量，计算获得待分配的地图道路数据的份数；

将每一份所述地图道路数据分配存储于对应的所述辅数据库中。

在其中一个实施例中，所述辅数据库为4个、16个或64个。

在其中一个实施例中，所述方法还包括：

如果所述辅数据库中的所述地图道路数据与所述主数据库中对应的所述地图道路数据相同，则将所述辅数据库中的实时交通信息发送至用户端。

在其中一个实施例中，所述主数据库设置于主服务器，每一所述辅数据库分别设置于对应的辅服务器。

本申请第二方面提供一种实时交通信息的同步装置，其包括：

存储模块，用于在至少一个辅数据库中存储至少部分地图道路数据，其中，全部所述地图道路数据还另外存储于主数据库中；

查询模块，用于将每一所述辅数据库按照预设周期查询对应的所述地图道路数据与所述主数据库中对应的所述地图道路数据是否相同；

更新模块，用于如果所述辅数据库中的所述地图道路数据与所述主数据库中对应的所述地图道路数据不同，则所述辅数据库接收所述主数据库发送的对应的所述地图道路数据，以更新所述辅数据库中对应的地图道路数据。

发送模块，用于将所述辅数据库根据接收的位置信息发送对应的实时交通信息至用户端。

本申请第三方面提供一种电子设备，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如上所述的方法。

本申请第四方面提供一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如上所述的方法。

本申请提供的技术方案可以包括以下有益效果：

本申请的技术方案，通过设置一个主数据库和多个辅数据库分别来存储全部地图道路数据，主数据库对需要更新的辅数据库中的地图道路数据进行更新，再由更新后的辅数据库将实时交通信息发送至用户端。这样的设计，避免由单个主数据库同时对接众多的用户端，通过多个辅数据库分发实时交通信息至对应的用户端，多个辅数据库可以均衡负载，从而降低对主数据库的数据处理负荷，提高实时交通信息的更新效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

通过结合附图对本申请示例性实施方式进行更详细的描述，本申请的上述以及其它目的、特征和优势将变得更加明显，其中，在本申请示例性实施方式中，相同的参考标号通常代表相同部件。

图1是本申请实施例示出的实时交通信息的同步方法的流程示意图；

图2是本申请实施例示出的实时交通信息的同步方法的另一流程示意图；

图3是本申请实施例示出的实时交通信息的同步装置的结构示意图；

图4是本申请实施例示出的电子设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的优选实施方式。虽然附图中显示了本申请的优选实施方式，然而应该理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本申请更加透彻和完整，并且能够将本申请的范围完整地传达给本领域的技术人员。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语“第一”、“第二”、“第三”等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

在相关技术中，针对全国性的TMC系统，一般通过一个服务器处理来自全国的TMC信息请求，每分钟需要处理上百万条TMC信息的发送，数据负载量大，可能会使部分用户端的数据更新延迟。针对上述问题，本申请实施例提供一种实时交通信息的同步方法，能够降低服务器的负载，提高数据更新效率。以下结合附图详细描述本申请实施例的技术方案。

实施例一

图1是本申请实施例示出的实时交通信息的同步方法的流程示意图。

参见图1，该实时交通信息的同步方法，包括：

步骤S110，至少一个辅数据库中存储至少部分地图道路数据，其中，全部地图道路数据还另外存储于主数据库中。

在其中一个实施例中，主数据库和多个辅数据库可以设置于同一个服务器，也可以分别设置于不同的服务器。即主数据库及每一辅数据库可以均设置于不同的服务器。在其中一个具体的实施方式中，当辅数据库的数量为多个时，全部地图道路数据分散存储于不同的辅数据库中。多个辅数据库协同存储的地图道路数据与主数据库存储的全部地图道路数据相同。即地图道路数据在主数据库中存储的同时，地图道路数据还可以按照地图区域分配存储于多个辅数据库中，每一辅数据库仅存储某一地图区域的地图道路数据，多个辅数据库按照地图区域分配协同存储全部地图道路数据。

步骤S120，每一辅数据库按照预设周期查询对应的地图道路数据与主数据库中对应的地图道路数据是否相同。

在其中一个具体的实施方式中，主数据库实时接收来自各用户端的位置信息，并根据各位置信息更新更新实时交通信息。可以理解，主数据库内存储的地图道路数据包括最新的实时交通信息。由于各辅数据库存储的地图道路数据互不相同，每一辅数据库按照预设周期查询自身对应的地图道路数据与主数据库中对应的地图道路数据是否相同。通过设置预设周期，避免辅数据库实时不停地与主数据库进行数据交互，从而避免因交互频繁而增加系统运行的负载，仅按照预设周期进行查询，即可以确保各辅数据库的数据及时更新。在其中一个实施例中，预设周期可以是5分钟、10分钟、30分钟或1小时。在其中一个实施例中，各辅数据库可以同时按照预设周期进行查询，或者，各辅数据库分批按照预设周期进行查询，避免查询请求过于集中，分散与主数据库进行数据交互，降低系统数据处理负载。

步骤S130，如果辅数据库中的地图道路数据与主数据库中对应的地图道路数据不同，则辅数据库接收主数据库发送的对应的地图道路数据，以更新辅数据库中对应的地图道路数据。

可以理解，经过查询，如果辅数据库的地图道路数据与主数据库对应的地图道路数据不同，则说明辅数据库中的地图道路数据版本处于滞后状态，需要更新。主数据库即可以将最新版本的地图道路数据发送至辅数据库进行对应的更新。更新的地图道路数据包括对应的实时交通信息。由于每一辅数据库存储的地图道路数据不同，即并非每一辅数据库中的地图道路数据都需要更新，只需对应更新滞后的辅数据库中的地图道路数据，避免进行全面更新，从而降低了系统的数据更新压力。

步骤S140，辅数据库根据接收的位置信息发送对应的实时交通信息至用户端。

根据位置信息，存储有包括对应位置信息的地图道路数据的辅数据库将实时交通信息发送至用户端。可以理解，由于辅数据库按照预设周期进行查询和更新存储的地图道路数据，也就是说，在相邻两个预设周期之间，辅数据库存储的地图道路数据所对应的实时交通信息并非最新的。在其中一个实施例中，通过缩短查询的预设周期，可以加快实时交通信息的更新程度。当然，稍微滞后的实时交通信息也不会大的影响。在其中一个实施例中，用户端可以是终端，例如各种个人计算机、笔记本电脑、智能手机、平板电脑、导航设备和便携式可穿戴设备等。

上述的实时交通信息的同步方法，通过设置一个主数据库和至少一个辅数据库来分别存储全部地图道路数据，主数据库对需要更新的辅数据库中的地图道路数据进行更新，再由更新后的辅数据库将实时交通信息发送至用户端。这样的设计，避免由单个主数据库同时对接众多的用户端，通过多个辅数据库分发实时交通信息至对应的用户端，多个辅数据库可以均衡负载，从而降低对主数据库的数据处理负荷，提高实时交通信息的更新效率。同时，通过分散处理还可以降低对单个服务器的性能要求，从而降低运行成本。

实施例二

为了进一步介绍本申请的实时交通信息的同步方法，参见图2，该实时交通信息的同步方法，包括：

步骤S210，将全部地图道路数据预先存储于主数据库中，及，将全部地图道路数据根据地图区域划分，每一地图区域的地图道路数据分别存储于对应的辅数据库中。

在其中一个实施例中，主数据库设置于主服务器，每一辅数据库分别设置于对应的辅服务器。主服务器分别与各辅服务器通信连接。通过将每一辅数据库对应一辅服务器，分散管理，提高运行效率。在其中一个实施例中，主数据库和辅数据库均为Redis数据库。具体地，Redis（Remote Dictionary Server，远程数据服务）是一款内存高速缓存数据库，使用C语言编写，数据模型为key-value。由于Redis可支持丰富的数据类型，如String（字符串）、List（列表）、Hash（散列）、Set（集合）、Sorted Set（有序集合）等，因此被广泛应用。通过将地图道路数据存储于Redis数据库，通过在Redis缓存，避免调用服务器的本地数据，从而实现快速读取，同时减少对服务器的占用，从而降低硬件成本。

为了便于分配存储地图道路数据，在其中一个具体的实施方式中，根据地图瓦片数量，设置相应数量的辅数据库；将地图道路数据按照地图瓦片分割形成多个所述地图区域，并将分割后的每一所述地图区域对应的地图道路数据分配存储至对应的辅数据库中。

相关技术中，电子地图可以通过瓦片地图金字塔模型进行模拟和搭建。具体地，瓦片地图金字塔模型是一种多分辨率层次模型，从瓦片金字塔的底层到顶层，分辨率越来越低，但表示的地理范围不变。首先确定地图服务平台所要提供的缩放级别的数量N，把缩放级别最高、地图比例尺最大的地图图片作为金字塔的底层，即第0层，并对其进行分块，从地图图片的左上角开始，从左至右、从上到下进行切割，分割成相同大小（比如256×256像素）的正方形地图瓦片，形成第0层瓦片矩阵；在第0层地图图片的基础上，按每2×2像素合成为一个像素的方法生成第1层地图图片，并对其进行分块，分割成与下一层相同大小的正方形地图瓦片，形成第1层瓦片矩阵；采用同样的方法生成第2层瓦片矩阵；…；如此下去，直到第N-1层，构成整个瓦片金字塔。

本实施例中，地图道路数据是地图数据中的一部分。本申请中，可以仅通过存储地图道路数据所在的瓦片层，以对实时交通信息进行更新，减少冗余数据的存储，节约内存。为了均匀分配存储于每一辅数据库，在其中一个具体的实施方式中，根据地图瓦片的数量和辅数据库的数量，计算获得待分配的地图道路数据的份数；将每一份地图道路数据分配存储于对应的辅数据库中。在其中一个实施例中，根据地图瓦片的数量，除以辅数据库的数量，计算获得待分配的地图道路数据的份数。即，全部地图道路数据分配存储于按照预设倍数设置的多个辅数据库中。在其中一个实施例中，辅数据库为4个、16个或64个。这样的数量，当瓦片按照例如256×256像素进行分割时，瓦片总数有65536片，通过设置辅服务器的恰当数量，从而确保所有瓦片对应的地图道路数据得以分配，且便于各瓦片对应的地图数据均匀分配于各辅服务器上。即辅数据库可以按照预设倍数为4的倍数进行设置。

步骤S220，每一辅数据库按照预设周期查询对应的地图道路数据与主数据库中对应的地图道路数据是否相同，其中，地图道路数据包括道路的地理位置信息和对应的实时交通信息。

在其中一个具体的实施方式中，每一辅数据库所在的辅服务器按照预设周期向主服务器的主数据库进行查询。由于每一辅数据库仅存储所有地图道路数据中的一小部分地图道路数据，而主数据库存储有全部的地图道路数据，在查询时，辅服务器仅需要查找主服务器的主数据库中的对应的地图道路数据。

具体地，地图道路数据包括地理位置信息和实时交通路况信息。其中地理位置信息包括瓦片编号、每一道路的道路编号及对应的TMC编号、道路的行进方向、道路的位置信息及对应的TMC边框区域；实时交通路况信息包括路况标识及路况标识的最新刷新时间。其中，TMC边框区域（bouding box）可以通过道路的位置信息计算获得。每一TMC边框区域隶属于对应的瓦片下，即瓦片的片区覆盖TMC边框区域，且TMC边框区域为覆盖对应道路的区域。每一道路的位置信息可以具体明确道路在电子地图上的位置。为了进一步区分每一条道路，可以通过每一条道路唯一的道路编号（Road id）及该道路对应的唯一的TMC编号（TMCid）进行标记。同时，针对双向道路或单向道路，都需要明确每一条道路的行进方向（Heading）。路况标识（TMC Flag）用于标识交通拥堵与否。最新刷新时间（Update time）则根据交通拥堵与否的状态更新而刷新时间，即根据路况标识的更新而更新，从而可以实时体现对应道路的实时交通信息，即该道路在最新刷新时间是否拥堵。

也就是说，主数据库存储了各道路的地理位置信息，还存储有各道路对应的实时交通信息。在辅数据库向主数据库查找数据时，不仅可以通过查找路况标识来获得最新的实时交通信息，还可以对应更新地图道路数据的地理位置信息，这样的设计，确保辅服务器中的地图道路数据的完整性。

步骤S230，如果辅数据库中的地图道路数据与主数据库中对应的地图道路数据不同，则辅数据库接收主数据库发送的对应的地图道路数据，以更新辅数据库中对应的地图道路数据。

本实施例中，辅数据库中对应的地图道路数据的更新，可以包括地理位置信息的更新和/或实时交通信息的更新。根据实际情况，当地理位置信息需要变更时，将主数据库中的地理位置信息数据同步至辅数据库中，替换掉辅数据库中的原数据。当实时交通信息需要变更时，则将主数据库中对应的实时交通信息同步至辅数据库中。当二者兼有时，则同时将地理位置信息和实时交通信息分别进行更新。更新完毕后，执行步骤S240。

可以理解，经过查询，如果辅数据库中的地图道路数据与主数据库中对应的地图道路数据相同，无需更新数据，则直接执行步骤S240。

步骤S240，辅数据库根据接收的位置信息发送对应的实时交通信息至用户端。

在生活场景中，出于路线规划或导航的需求，众多的用户端各自分别发送实时交通信息请求至服务器。本申请中，直接由辅数据库接收用户端的请求，根据用户端的位置信息，将该实时交通信息请求分配至对应的辅数据库，再由该辅数据库根据位置信息对应的地图道路数据，将对应的实时交通信息发送至用户端。

综上，上述实施例中，一方面，本申请通过在主数据库和辅数据库分别存储地图道路数据，主数据库统一存储，辅数据库按照地图瓦片进行地图区域的分割后分配存储，从而使每一辅数据库大大降低了数据处理量。主数据库只需负责对各辅数据库进行数据更新，再由各辅数据库直接对接用户端的TMC信息请求，分工协作，使每一数据库的数据运行量都得以缩减，提高系统运行效率，从而加快用户端的TMC信息更新速度。

与前述应用功能实现方法实施例相对应，本申请还提供了一种实时交通信息的同步装置、电子设备及相应的实施例。具体地，本申请实施例介绍的装置可以实施本申请结合图1-2介绍的实时交通信息的同步方法实施例中的部分或全部流程。

实施例三

图3是本申请实施例示出的实时交通信息的同步装置的结构示意图。

参见图3，该实施例提供一种实时交通信息的同步装置。该装置包括存储模块310、查询模块320、更新模块330及发送模块340。其中：

存储模块310，用于在至少一个辅数据库中存储至少部分地图道路数据，其中，全部所述地图道路数据还另外存储于主数据库中。

查询模块320，用于将每一辅数据库按照预设周期查询对应的地图道路数据与主数据库中对应的地图道路数据是否相同。

更新模块330，用于如果辅数据库中的地图道路数据与主数据库中对应的地图道路数据不同，则所述辅数据库接收所述主数据库发送的对应的所述地图道路数据，以更新辅数据库中对应的地图道路数据。

发送模块340，用于将辅数据库根据接收的位置信息发送对应的实时交通信息至用户端。

具体地，存储模块310将地图道路数据预先全部存储于主数据库中，以及，全部所述地图道路数据根据地图区域划分，每一所述地图区域的所述地图道路数据分别存储于对应的所述辅数据库中。进一步地，在辅数据库中，根据地图瓦片数量，设置相应数量的辅数据库；将地图道路数据按照地图瓦片分割形成多个所述地图区域，并将分割后的每一所述地图区域对应的地图道路数据分配存储至对应的辅数据库中。这样的设计，确保将各地图道路数据分散存储于不同的辅数据库，降低每一辅数据库的处理量。

查询模块320用于每一辅数据库按照预设周期查询对应的地图道路数据与主数据库中对应的地图道路数据是否相同，其中，地图道路数据包括道路的地理位置信息和对应的实时交通信息。通过查询，可以确定各辅数据库对应的地图道路数据是否需要更新。

更新模块330则在查询模块320确定辅数据库的地图道路数据需要更新时，对辅数据库的地图道路数据进行更新。可以理解，当查询模块320查询到辅数据库的地图道路数据无需更新时，则不用进行更新的处理。

发送模块340则用于将辅数据库中的地图道路数据发送至用户端，确保用户端可以查看实时交通信息。

本申请的实时交通信息的同步装置，通过存储模块310预先将地图数据按照不同的方式存储于主数据库和辅数据库，查询模块320定期查询辅数据库与主数据库中对应的地图道路数据是否相同；当不同时，则由更新模块330接收主数据库中对应的地图道路数据并更新同步至辅数据库，以便发送模块340得以将辅数据库中最新的实时交通信息发送至用户端显示。这样的设计，大大降低了单个服务器的数据负载，提高运行效率的同时，确保及时更新用户端的实时交通信息。

关于上述实时交通信息的同步装置的具体描述可以参见上文中对于实时交通信息的同步方法的描述，在此不再赘述。上述实时交通信息的同步装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

图4是本申请实施例示出的电子设备的结构示意图。

参见图4，电子设备400包括存储器410和处理器420。

处理器420可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器 (Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列 (Field-Programmable Gate Array，FPGA) 或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器410可以包括各种类型的存储单元，例如系统内存、只读存储器（ROM），和永久存储系统。其中，ROM可以存储处理器420或者计算机的其他模块需要的静态数据或者指令。永久存储系统可以是可读写的存储系统。永久存储系统可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储系统采用大容量存储系统（例如磁或光盘、闪存）作为永久存储系统。另外一些实施方式中，永久性存储系统可以是可移除的存储设备（例如软盘、光驱）。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器410可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片（DRAM，SRAM，SDRAM，闪存，可编程只读存储器），磁盘和/或光盘也可以采用。在一些实施方式中，存储器410可以包括可读和/或写的可移除的存储设备，例如激光唱片（CD）、只读数字多功能光盘（例如DVD-ROM，双层DVD-ROM）、只读蓝光光盘、超密度光盘、闪存卡（例如SD卡、min SD卡、Micro-SD卡等等）、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器410上存储有可执行代码，当可执行代码被处理器420处理时，可以使处理器420执行上文述及的方法中的部分或全部。

上文中已经参考附图详细描述了本申请的方案。在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述的部分，可以参见其他实施例的相关描述。本领域技术人员也应该知悉，说明书中所涉及的动作和模块并不一定是本申请所必须的。另外，可以理解，本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减，本申请实施例系统中的模块可以根据实际需要进行合并、划分和删减。

此外，根据本申请的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本申请的上述方法中部分或全部步骤的计算机程序代码指令。

或者，本申请还可以实施为一种非暂时性机器可读存储介质（或计算机可读存储介质、或机器可读存储介质），其上存储有可执行代码（或计算机程序、或计算机指令代码），当所述可执行代码（或计算机程序、或计算机指令代码）被电子设备（或电子设备、服务器等）的处理器执行时，使所述处理器执行根据本申请的上述方法的各个步骤的部分或全部。

本领域技术人员还将明白的是，结合这里的申请所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本申请的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (8)

1.一种实时交通信息的同步方法，其特征在于：

至少一个辅数据库中存储至少部分地图道路数据；根据地图瓦片数量，设置相应数量的辅数据库，将所述地图道路数据按照地图瓦片分割形成多个所述地图区域，并将分割后的每一所述地图区域对应的地图道路数据分配存储至对应的所述辅数据库中；其中，全部所述地图道路数据还另外存储于主数据库中；

每一所述辅数据库按照预设周期查询对应的所述地图道路数据与所述主数据库中对应的所述地图道路数据是否相同；

如果所述辅数据库中的所述地图道路数据与所述主数据库中对应的所述地图道路数据不同，则所述辅数据库接收所述主数据库发送的对应的所述地图道路数据，以更新所述辅数据库中对应的地图道路数据；

所述辅数据库根据接收的位置信息发送对应的实时交通信息至用户端。

2.根据权利要求1所述的方法，其特征在于，所述将所述地图道路数据按照地图瓦片分割形成多个所述地图区域，并将分割后的每一所述地图区域对应的地图道路数据分配存储至对应的所述辅数据库中，包括：

根据所述地图瓦片的数量和所述辅数据库的数量，计算获得待分配的地图道路数据的份数；

将每一份所述地图道路数据分配存储于对应的所述辅数据库中。

3.根据权利要求1所述的方法，其特征在于，所述辅数据库为4个、16个或64个。

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

如果所述辅数据库中的所述地图道路数据与所述主数据库中对应的所述地图道路数据相同，则将所述辅数据库中的实时交通信息发送至用户端。

5.根据权利要求1所述的方法，其特征在于，所述主数据库设置于主服务器，每一所述辅数据库分别设置于对应的辅服务器。

6.一种实时交通信息的同步装置，其特征在于，包括：

存储模块，用于在至少一个辅数据库中存储至少部分地图道路数据；根据地图瓦片数量，设置相应数量的辅数据库，将所述地图道路数据按照地图瓦片分割形成多个所述地图区域，并将分割后的每一所述地图区域对应的地图道路数据分配存储至对应的所述辅数据库中；其中，全部所述地图道路数据还另外存储于主数据库中；

查询模块，用于将每一所述辅数据库按照预设周期查询对应的所述地图道路数据与所述主数据库中对应的所述地图道路数据是否相同；

更新模块，用于如果所述辅数据库中的所述地图道路数据与所述主数据库中对应的所述地图道路数据不同，则所述辅数据库接收所述主数据库发送的对应的所述地图道路数据，以更新所述辅数据库中对应的地图道路数据；

发送模块，用于将所述辅数据库根据接收的位置信息发送对应的实时交通信息至用户端。

7.一种电子设备，其特征在于，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1-5中任一项所述的方法。

8.一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1-5中任一项所述的方法。

Images