CN113392132B - Iot场景的分布式缓存方法及*** - Google Patents

Abstract

本发明涉一种IOT场景的分布式缓存方法，本发明解决现有技术的问题，其技术方案要点是：包括以下步骤，步骤一，对外暴露Dubbo服务接口，通过通用查询和变更数据的方式处理车载机通讯业务的热点数据；步骤二，热点数据和缓存数据的变更，通过执行引擎以异步的形式实现数据入盘存储，缓存数据的查询中的范围搜索两种查询形式，通过解析查询语句，通过责任链路来适配一个最适合该查询条件的引擎来查询数据；步骤三，在分布式环境下，缓存数据入盘存储若产生失败的情况，则对于网络等待超时的情况，执行引擎通过维护kafka的Topic实现一个重试队列，当超过重试次数配置值未成功时，则数据更新视为失败，并抛弃该条更新命令。

Description

IOT场景的分布式缓存方法及***

技术领域

本发明涉及了一种IOT场景的分布式缓存方法及***，特别是涉及了一种基于Base理论更适用于IOT场景的分布式缓存方法及***。

背景技术

在公交车辆车载机通讯和公交车辆调度***两个业务背景下，一个车载机GPS报文，往往会触发车辆匹配、车辆位置监控、车辆车次匹配等多种涉及数据读写的技术场景。以我司目前公交云智能调度通讯平台为例，杭州、上饶、威海三座城市的营运公交车辆在早晚高峰期间每分钟需要处理200万以上条车载机GPS报文。这批数据的读写操作如果全部通过数据库来实现，会引发下述问题：

资源利用率低下：很多数据读操作是重复读取相同数据，比如同一辆车的gps报文，我们要读取库里的车辆信息，那么就是根据gps报文的车辆自编号去查询数据库，然后返回结果。但是同一辆车的信息，往往在非常长的时间下是不会变动的。在限定机器配置的情况下，无法满足高并发业务场景：单台mysql实例，最多能支撑的qps约在2000左右，而早高峰期间，调度通讯平台最高同时在线车辆将在10000以上。***响应耗时高，延迟现象严重：数据库数据存在于物理磁盘中，读写响应速度与内存数据相比较而言，相差百倍以上。现有技术：传统的解决办法，多是基于Memcached、Redis等对象缓存***或者键值对缓存***，通过在内存开辟一块空间暂时存储临时数据用于响应业务读操作提升性能。但是对于IOT场景下的车载机通讯而言，键值对查询无法满足基于时间范围来查询车次数据。并且，在分布式的业务集群下，需要开发人员自己通过CAS等算法来解决缓存/数据库双写造成的数据不一致问题。

发明内容

针对上述背景技术中存在键值对查询无法满足基于时间范围来查询车次数据。并且，在分布式的业务集群下，需要开发人员自己通过CAS等算法来解决缓存/数据库双写造成的数据不一致的问题，本发明提供了一种基于Base理论更适用于IOT场景的分布式缓存方法及***。

本发明解决其技术问题所采用的技术方案是：一种IOT场景的分布式缓存方法，包括以下步骤，

步骤一，对外暴露服务接口，提供通用查询处理车载机通讯业务的热点数据、缓存数据，缓存数据的查询中的范围搜索，通过策略匹配最适合该查询条件的存储节点，来响应查询请求，将输入数据转换标准协议数据来变更热点数据、缓存数据；

步骤二，热点数据和缓存数据的变更，通过执行引擎以异步的形式实现数据入盘存储，缓存数据的查询中的范围搜索两种查询形式，通过解析查询语句，通过责任链路来适配一个最适合该查询条件的引擎来查询数据；输入数据转换为标准协议数据后，通过执行引擎以线程的方式实现数据在各个存储节点的数据更新，支持同步、异步响应方式；

步骤三，在分布式环境下，缓存数据存储节点更新失败的情况，采用本地重试策略，若超过一定失败次数，执行引擎通过维护分布式日志的一个topic实现重试队列，进行转发给别的服务器进行重试，超过重试次数配置值未成功时，则数据更新视为失败，并且抛弃该条更新命令。

本发明具备高并发性能良好、多业务隔离性良好、无需开发人员处理缓存/数据库双写不一致问题且与业务***完全解耦，不需要考虑业务***复杂的场景以及更新策略，只关注最终的数据落地，然后同步通用缓存，供别的业务***使用的优点。

作为优选，执行引擎中针对业务线程执行器采用线程隔离方法，首先进行业务隔离，对任务进行增强，然后通过任务id进行Hash取模，分配到任务线程池队列，通过线程池里面的队列技术，将任务进行排队。

作为优选，执行引擎采用数据双写策略，任务进入执行引擎后，优先同步进行数据存储，然后再将任务消息进行ACK确认，如果获取任务但是存在异常失败，消息没有ACK确认，则会转发给其他服务器。

作为优选，执行引擎为保证任务的最终一致性采用重试策略方法进行，首先执行本地重试策略，针对每个业务，流程编排节点会初始化一个步长数，设置与执行流程相对应的节点步长，当前任务的执行匹配相应的节点，当完成一个任务，通过位运算左移一位，流程编排引擎通过责任链相应的流转下一个节点，若某个节点执行失败，执行引擎则将任务推送到任务的队首进行重试，重试次数配置为设定次，对于失败超过设定次的任务，执行引擎则执行远端重试策略；

远端重试策略，通过消息队列kafka进行持久化，并且分发给其余的服务器进行重试，采用kafka的Ack确认机制，如果重试失败kafka的消息将会重复重发，如果kafka的消息超出重试次数则有执行引擎执行抛弃策略，若出现服务器异常、关机或断电情况导致任务在服务器内没有消费完成，则执行异常重试策略；

异常重试策略，通过定时器补偿任务数据双写到Redis里面未消费的消息，进行任务重试。

作为优选，当执行引擎的任务更新成功后，执行引擎记录更新成功日志，进行数据统计，回调不同业务类型的函数，将成功的任务按照业务类型广播到不同的消息队列，订阅更新的***将获得更新。

作为优选，执行引擎在执行任务时，通用缓存内部采用的异步执行机制，业务***调用选择同步或异步方式进行，同步方式为调用过程中等待返回结果，异步方式为单程，业务***不关注成功或者失败，任务添加成功即返回。

作为优选，kafka消息执行时间超过任务创建的时间一分钟或重试次数超过若干次，则将任务进行抛弃，记录Error日志，告警给技术人员进行排查定位。

作为优选，在变更数据过程中，将包含Rpc同步调用适配器、开放队列、Canal适配器和Mysql适配器在内的数据进行协议适配时，采用以下同步子步骤，

全量同步子步骤，在业务启动初始化时候，进行数据的加载，为基于Rpc接口开放和数据库方式同步的数据，进行数据拉取转换为通用缓存的标准化协议数据，进行数据加载；

增量同步子步骤，基于满足协议的数据消息更新，采用基于Rpc接口开放将数据转化为标准的协议数据格式、Canal消息通知和业务***推送方式；

过期删除同步子步骤，通过***内置的定时器，定期清除无效数据，定期清除规则由对应的业务类型自定义。

作为优选，在通用查询适配时，如果是主键查询，则适配Redis查询缓存，如果是复杂查询语句，则适配es查询缓存，如果是大数据查询则适配hbase查询。

一种IOT场景的分布式缓存***，适用于如上所述的IOT场景的分布式缓存方法，包括执行以下装置，

Dubbo服务接口，提供通用查询处理车载机通讯业务的热点数据、缓存数据。缓存数据的查询中的范围搜索，通过策略匹配最适合该查询条件的存储节点，来响应查询请求，提供包括dubbo、kafka、canal在内的方式，将输入数据转换标准协议数据来变更热点数据、缓存数据；

执行引擎以异步的形式实现数据入盘存储，缓存数据的查询中的范围搜索两种查询形式，通过解析查询语句，通过责任链路来适配一个最适合该查询条件的引擎来查询数据；输入数据转换为标准协议数据后，通过执行引擎以线程的方式实现数据在各个存储节点的数据更新，支持同步、异步响应方式；

分布式环境，缓存数据存储节点更新失败的情况，采用本地重试策略，若超过一定失败次数，执行引擎通过维护Kafka的一个topic实现重试队列，进行转发给别的服务器进行重试，超过重试次数配置值未成功时，则数据更新视为失败，并且抛弃该条更新命令。

本发明的实质性效果是：与现有技术相比，定义通用业务数据模型，提供全量数据同步接口，增量事件通知接口；基于业务数据模型进行分线程，进行业务隔离；基于任务按照Id取模进行线程分片，相同任务在同一个服务器上单线程串行执行，无锁、无上下文切换；数据更新支持同步、异步方式，同步方式，利用事件回调，减少cpu空轮询消耗；利用es做数据模型的全文索引、利用redis做主键查询。因此，本发明具有以下效果和优点：1.高并发性能良好；2.多业务隔离性良好；3.无需开发人员处理缓存/数据库双写不一致问题。4.数据同步策略中，支持适配Canal技术，与业务***完全解耦，不需要考虑业务***复杂的场景以及更新策略，只关注最终的数据落地，然后同步通用缓存，供别的业务***使用。

附图说明

图1为本发明的一种***整体架构示意图；

图2为本发明的一种多线程策略流程示意图；

图3为本发明的一种单一性策略流程示意图；

图4为本发明的一种同步适配流程示意图；

具体实施方式

下面通过具体实施例，对本发明的技术方案作进一步的具体说明。

实施例1：

一种IOT场景的分布式缓存方法(参见附图2至附图4)，包括以下步骤，

步骤一，对外暴露Dubbo服务接口，提供通用查询处理车载机通讯业务的热点数据、缓存数据。缓存数据的查询中的范围搜索，通过策略匹配最适合该查询条件的存储节点，来响应查询请求，提供包括dubbo、kafka、canal在内的方式，将输入数据转换标准协议数据来变更热点数据、缓存数据；

步骤二，热点数据和缓存数据的变更，通过执行引擎以异步的形式实现数据入盘存储，缓存数据的查询中的范围搜索两种查询形式，通过解析查询语句，通过责任链路来适配一个最适合该查询条件的引擎来查询数据；输入数据转换为标准协议数据后，通过执行引擎以线程的方式实现数据在各个存储节点的数据更新，支持同步、异步响应方式；

步骤三，在分布式环境下，缓存数据存储节点更新失败的情况，采用本地重试策略，若超过一定失败次数，执行引擎通过维护Kafka的一个topic实现重试队列，进行转发给别的服务器进行重试，超过重试次数配置值未成功时，则数据更新视为失败，并且抛弃该条更新命令。

更具体的是：

对外暴露Dubbo服务接口，通过抽象封装业务表的查询语句，允许业务开发人员使用<范围、单行>，<相等、不等、大于、小于>,<是否为空>等查询条件获取缓存数据，变更数据同理。目前主要处理的车载机通讯业务为行车记录、司机考勤、车辆到离站、线路场站等热点数据。

热点数据的变更：比如车次表某一条数据发生修改变动，该***通过Kafka监听数据库Canal的变更通知，自动同步缓存数据的变动项。无需开发人员自己解决数据库/缓存的数据双写问题。同理，缓存数据的变更，也会通过执行引擎以异步的形式达到数据入盘的操作。

在分布式环境下，缓存数据入盘会因为网络等待超时、服务不可用等诸多原因产生失败的情况，对于网络等待超时，***引擎通过维护kafka的Topic实现一个重试队列，当超过重试次数配置值未成功时，数据更新视为失败，并抛弃该条更新命令。

缓存数据的查询，则具体分为主键直接命中和范围搜索两种查询形式。对于前者，我们直接使用业界成熟的Redis键值对缓存***来实现，对于后者，我们通过解析查询语句，通过责任链路来适配一个最适合该查询条件的引擎来查询数据。

执行引擎设计策略为：

采用多线程策略，充分利用服务器资源的利用率，业务线程执行器，采用线程隔离，进行不同业务隔离，对任务进行增强(定义任务执行的流程)。然后通过任务id进行Hash取模，分配到任务线程池队列。通过线程池里面的队列技术，将任务进行排队，保证分配到同一个槽位的任务，是有序的。任务的有序性，保证任务的不同更新，结果是最终一致。

采用数据双写策略，任务进来，优先同步写Redis进行数据存储，然后再将任务消息进行ACK确认。保证数据已经持久化。如果机器获取任务但是异常挂了，消息没有ACK确认，会转发给别的服务器。

采用重试策略，保证任务的最终一致性，重试策略包含3层设计，一、本地重试策略：不同的业务，流程编排节点会初始化一个步长数，比如(1,2,4,8等)。增强的任务，会有个与执行流程相对应的节点步长。当前任务的执行需要匹配相应的节点。比如初始化任务节点是1，只能匹配响应的流程编排节点(1)。当完成一个任务，通过位运算左移一位，比如(2)。流程编排引擎通过责任链相应的流转下一个节点。如果某个节点执行失败，将任务推送到任务的队首进行重试，重试次数配置为3次，保证该线程里面的数据的有序性。通过这种设计方式，可以将重试的任务匹配到相应的流程编排节点进行任务执行，运用位运算提升运算速度。二、远端重试策略：失败超过3次的任务，通过消息队列Kafka进行持久化，并且分发给正常的服务器进行重试，采用Kafka的Ack确认机制。如果重试失败，Kafka的消息将会一直重发。如果超出重试次数触发抛弃策略。三、异常重试策略：服务器异常、关机、断电等情况导致，任务在服务器内没有消费完成。通过定时器补偿任务数据双写到Redis里面未消费的消息，进行任务重试。任务成功策略，不同业务类型的任务更新将广播到相应的消息队列，任务更新成功，记录更新成功日志，进行数据统计，回调不同业务类型的函数，将成功的任务按照业务类型广播到不同的消息队列，订阅更新的***将获得更新。

采用同步、异步策略，充分提升调用***的拓展性，通用缓存***内部采用的异步执行机制，业务***调用可以选择同步、异步等方式。同步方式为调用过程中等待返回结果。异步方式为单程，业务***不关注成功或者失败，任务添加成功即可返回。

最终一致性策略，保障多流程编排节点数据的最终一致性，通过将任务进行分片，单分片内通过加锁的方式，队列保障任务的有序性。通过重试策略、数据双写机制、MQ消息的ACK确认机制，保障任务数据不丢，实现数据的最终一致性。

抛弃策略，防止***因为错误的任务导致任务线程长时间阻塞，任务无限循环执行的问题Kafka消息执行时间超过任务创建的时间一分钟或者重试次数超过100次，将任务进行抛弃，并且记录Error日志，告警给技术人员进行排查定位。

数据同步策略，采用的标准化协议数据格式，满足数据协议就可以进行通用缓存***的数据同步更新。数据的更新包含三部分：全量同步、增量同步、过期删除。全量同步，一般在业务启动初始化时候，进行数据的加载。目前有基于Rpc接口开放、数据库等方式，进行数据拉取转换为通用缓存的标准化协议数据，进行数据加载。增量同步，基于满足协议的数据消息更新，目前是基于Rpc接口开放(接口将数据转化为标准的协议数据格式)、Canal消息通知、业务***推送等方式。过期删除，通过***内置的定时器，定期清除无效数据，具体规则由不同的业务类型定义。数据同步策略中，数据的来源包含Rpc同步调用适配器、开放队列、Canal适配器、Mysql适配器对数据进行协议适配。通用查询适配策略如下，如果是主键查询，则适配Redis查询缓存；如果是复杂查询语句，则适配es查询缓存；如果是大数据查询(查询最近三个月的车辆到离站数据等场景)，则适配hbase查询。

本实施例，线上的使用场景如下：以车辆GPS报文匹配行车记录为例，处理车辆GPS报文的业务层，按照需要匹配的时间范围，组织查询条件：

上述语句的语义为：查询一个结果集，所有调度发车时间在beginTime到endTime之间的，指定车辆id、指定线路id、未被删除的、营运状态在1，2或者3之间的，并按照调度发车时间进行升序排序的结果集。此类复杂语义的查询，就将适配为es查询缓存，首先缓存引擎会对查询条件适配为es查询语句，调用es获取结果返回。在高并发的场景下(我司目前每分钟高峰200万GPS业务量的情况下)，es性能表现为：单实例8核16g的机器配置，其内存占用51％，cpu高峰占用30％，平峰15％，网络流入流出高峰16m/s，平峰4m/s。

一种IOT场景的分布式缓存***(参见附图1)，适用于如上所述的IOT场景的分布式缓存方法，包括执行以下装置，

Dubbo服务接口，提供通用查询处理车载机通讯业务的热点数据、缓存数据。缓存数据的查询中的范围搜索，通过策略匹配最适合该查询条件的存储节点，来响应查询请求，提供包括dubbo、kafka、canal在内的方式，将输入数据转换标准协议数据来变更热点数据、缓存数据；

执行引擎以异步的形式实现数据入盘存储，缓存数据的查询中的范围搜索两种查询形式，通过解析查询语句，通过责任链路来适配一个最适合该查询条件的引擎来查询数据；输入数据转换为标准协议数据后，通过执行引擎以线程的方式实现数据在各个存储节点的数据更新，支持同步、异步响应方式；

分布式环境，缓存数据存储节点更新失败的情况，采用本地重试策略，若超过一定失败次数，执行引擎通过维护Kafka的一个topic实现重试队列，进行转发给别的服务器进行重试，超过重试次数配置值未成功时，则数据更新视为失败，并且抛弃该条更新命令。

本实施例与现有技术相比，定义通用业务数据模型，提供全量数据同步接口，增量事件通知接口；基于业务数据模型进行分线程，进行业务隔离；基于任务按照Id取模进行线程分片，相同任务在同一个服务器上单线程串行执行，无锁、无上下文切换；数据更新支持同步、异步方式，同步方式，利用事件回调，减少cpu空轮询消耗；利用es做数据模型的全文索引、利用redis做主键查询。因此，本发明具有以下效果和优点：1.高并发性能良好；2.多业务隔离性良好；3.无需开发人员处理缓存/数据库双写不一致问题。4.数据同步策略中，支持适配Canal技术，与业务***完全解耦，不需要考虑业务***复杂的场景以及更新策略，只关注最终的数据落地，然后同步通用缓存，供别的业务***使用。

以上所述的实施例只是本发明的一种较佳的方案，并非对本发明作任何形式上的限制，在不超出权利要求所记载的技术方案的前提下还有其它的变体及改型。

Claims (7)

1.一种IOT场景的分布式缓存方法，其特征是，包括以下步骤，

步骤一，对外暴露服务接口，提供通用查询处理车载机通讯业务的热点数据、缓存数据，对于缓存数据进行查询使用范围搜索，通过策略匹配最适合查询条件的存储节点，来响应查询请求，将输入数据转换标准协议数据来变更热点数据、缓存数据；

步骤二，热点数据和缓存数据的变更，通过执行引擎以异步的形式实现数据入盘存储，缓存数据的查询中的范围搜索两种查询形式，通过解析查询语句，通过责任链路来适配一个最适合该查询条件的引擎来查询数据；输入数据转换为标准协议数据后，通过执行引擎以线程的方式实现数据在各个存储节点的数据更新，支持同步、异步响应方式；

步骤三，在分布式环境下，缓存数据存储节点更新失败的情况，采用本地重试策略，若超过一定失败次数，执行引擎通过一个重试队列，进行转发给别的服务器进行重试，超过重试次数配置值未成功时，则数据更新视为失败，并且抛弃更新命令；

执行引擎中针对业务线程执行器采用线程隔离方法，首先进行业务隔离，对任务进行增强，然后通过任务id进行Hash取模，分配到任务线程池队列，通过线程池里面的队列技术，将任务进行排队，执行引擎采用数据双写策略，任务进入执行引擎后，优先同步进行数据存储，然后再将任务消息进行ACK确认，如果获取任务但是存在异常失败，消息没有ACK确认，则会转发给其他服务器，执行引擎在执行任务时，通用缓存内部采用的异步执行机制，业务***调用选择同步或异步方式进行，同步方式为调用过程中等待返回结果，异步方式为单程，业务***不关注成功或者失败，任务添加成功即返回。

2.根据权利要求1所述的IOT场景的分布式缓存方法，其特征在于，执行引擎为保证任务的最终一致性采用重试策略方法进行，

首先执行本地重试策略，针对每个业务，流程编排节点会初始化一个步长数，设置与执行流程相对应的节点步长，当前任务的执行匹配相应的节点，当完成一个任务，通过位运算左移一位，流程编排引擎通过责任链相应的流转下一个节点，若某个节点执行失败，执行引擎则将任务推送到任务的队首进行重试，重试次数配置为设定次，对于失败超过设定次的任务，执行引擎则执行远端重试策略；

远端重试策略，通过消息队列kafka进行持久化，并且分发给其余的服务器进行重试，采用kafka的Ack确认机制，如果重试失败kafka的消息将会重复重发，如果kafka的消息超出重试次数则有执行引擎执行抛弃策略，若出现服务器异常、关机或断电情况导致任务在服务器内没有消费完成，则执行异常重试策略；

异常重试策略，通过定时器补偿任务数据双写到Redis里面未消费的消息，进行任务重试。

3.根据权利要求1所述的IOT场景的分布式缓存方法，其特征在于，当执行引擎的任务更新成功后，执行引擎记录更新成功日志，进行数据统计，回调不同业务类型的函数，将成功的任务按照业务类型广播到不同的消息队列，订阅更新的***将获得更新。

4.根据权利要求1所述的IOT场景的分布式缓存方法，其特征在于，kafka消息执行时间超过任务创建的时间一分钟或重试次数超过若干次，则将任务进行抛弃，记录Error日志，告警给技术人员进行排查定位。

5.根据权利要求1所述的IOT场景的分布式缓存方法，其特征在于，在变更数据过程中，将包含Rpc同步调用适配器、开放队列、Canal适配器和Mysql适配器在内的数据进行协议适配时，采用以下同步子步骤，

全量同步子步骤，在业务启动初始化时候，进行数据的加载，为基于Rpc接口开放和数据库方式同步的数据，进行数据拉取转换为通用缓存的标准化协议数据，进行数据加载；

增量同步子步骤，基于满足协议的数据消息更新，采用基于Rpc接口开放将数据转化为标准的协议数据格式、Canal消息通知和业务***推送方式；

过期删除同步子步骤，通过***内置的定时器，定期清除无效数据，定期清除规则由对应的业务类型自定义。

6.根据权利要求1所述的IOT场景的分布式缓存方法，其特征在于，在通用查询适配时，如果是主键查询，则适配Redis查询缓存，如果是复杂查询语句，则适配es查询缓存，如果是大数据查询则适配hbase查询。

7.一种IOT场景的分布式缓存***，其特征是，适用于如权利要求1所述的IOT场景的分布式缓存方法，包括执行以下装置，

Dubbo服务接口，提供通用查询处理车载机通讯业务的热点数据、缓存数据；

缓存数据的查询中的范围搜索，通过策略匹配最适合该查询条件的存储节点，来响应查询请求，提供包括dubbo、kafka、canal在内的方式，将输入数据转换标准协议数据来变更热点数据、缓存数据；

执行引擎以异步的形式实现数据入盘存储，缓存数据的查询中的范围搜索两种查询形式，通过解析查询语句，通过责任链路来适配一个最适合该查询条件的引擎来查询数据；输入数据转换为标准协议数据后，通过执行引擎以线程的方式实现数据在各个存储节点的数据更新，支持同步、异步响应方式；

分布式环境，缓存数据存储节点更新失败的情况，采用本地重试策略，若超过一定失败次数，执行引擎通过维护Kafka的一个topic实现重试队列，进行转发给别的服务器进行重试，超过重试次数配置值未成功时，则数据更新视为失败，并且抛弃更新命令。

Images