CN116185895A - 一种支持多级缓存高并发的实时告警处理方法 - Google Patents

一种支持多级缓存高并发的实时告警处理方法 Download PDF

Info

Publication number
CN116185895A
CN116185895A CN202211618351.XA CN202211618351A CN116185895A CN 116185895 A CN116185895 A CN 116185895A CN 202211618351 A CN202211618351 A CN 202211618351A CN 116185895 A CN116185895 A CN 116185895A
Authority
CN
China
Prior art keywords
alarm
level cache
cache
data
type
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211618351.XA
Other languages
English (en)
Inventor
胡振洲
周福
陶定元
张艳
何鸣一
吕非
宗伟康
陈凯旋
王立旭
马德超
王晓超
侯继鑫
赵京虎
张名扬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nari Technology Co Ltd
NARI Nanjing Control System Co Ltd
Original Assignee
Nari Technology Co Ltd
NARI Nanjing Control System Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nari Technology Co Ltd, NARI Nanjing Control System Co Ltd filed Critical Nari Technology Co Ltd
Priority to CN202211618351.XA priority Critical patent/CN116185895A/zh
Publication of CN116185895A publication Critical patent/CN116185895A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0811—Multiuser, multiprocessor or multiprocessing cache systems with multilevel cache hierarchies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/324—Display of status information
    • G06F11/327—Alarm or error message display
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3485—Performance evaluation by tracing or monitoring for I/O devices
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种支持多级缓存高并发的实时告警处理方法，基于微服务架构，通过整合多级缓存框架（Redis+Caffeine），支持多元化、多生命周期数据缓存，实现了多级缓存下数据的批量查询、批量缓存、异步更新功能，解决了分布式环境下应用级本地缓存数据的一致性问题，提高了配电云主站整体数据处理的吞吐率。本发明提供的一种支持多级缓存高并发的实时告警处理方法，在充分考虑分布式流计算引擎无法缓存大量数据的特性下，结合了微服务架构并整合多级缓存技术后，使本地服务实例能够缓存大量热点数据，同时，保证这些重要数据的一致性，解决了海量遥信、遥测数据处理产生告警时高频率从数据库查询模型引发的性能瓶颈问题，大大提高了海量实时告警处理的吞吐率。

Description

一种支持多级缓存高并发的实时告警处理方法
技术领域
本发明涉及一种支持多级缓存高并发的实时告警处理方法，属于电网实时数据处理技术领域。
背景技术
目前配电云主站面临大量设备与终端接入，设备上下线、遥信、遥测等实时数据的处理面临重大考验，在采用Spark Streaming、Flink等流式处理技术后，性能得到了进一步提升。
然而当配电云主站集成告警处理后，性能明显有所下降，主要原因在于告警数据的原子性，即针对每条数据都需要从数据库或分布式缓存中查询对应的模型进行组装，而Spark Streaming/Flink等流处理是分布式计算，原生不支持大量数据的缓存与共享，导致流处理耗费大量时间拉取模型数据，极大的降低了数据处理的性能。
因此，如何提高配电云主站告警处理的性能，是本领域技术人员急需要解决的技术问题。
发明内容
目的：为了克服现有技术中存在的配电网中流计算处理告警数据的性能瓶颈问题，本发明提供一种支持多级缓存高并发的实时告警处理方法，基于微服务架构，通过整合多级缓存框架（Redis+Caffeine），支持多元化、多生命周期数据缓存，实现了多级缓存下数据的批量查询、批量缓存、异步更新功能，解决了分布式环境下应用级本地缓存数据的一致性问题，提高了配电云主站整体数据处理的吞吐率。
技术方案：为解决上述技术问题，本发明采用的技术方案为：
一种支持多级缓存高并发的实时告警处理方法，包括如下步骤：
步骤1：从数据库查询告警定义元数据，将告警定义元数据初始化到多级缓存中。
步骤2：监控Redis中告警定义元数据变化Topic，消费告警定义元数据变化Topic会话中的告警定义元数据变化消息。
步骤3：解析告警定义元数据变化消息，更新多级缓存中的告警定义元数据。
步骤4：监控Kafka中遥信事件变化Topic，消费遥信事件变化Topic中一次设备的遥信变化消息。
步骤5：提取遥信变化消息中的KeyId属性，根据KeyId属性从多级缓存中获取设备的模型信息。
步骤6：当多级缓存中不存在当前变化消息对应的设备的模型信息时，再根据KeyId属性从数据库中查询当前设备的模型信息。
步骤7：将从数据库中查询的设备的模型信息缓存到多级缓存中。
步骤8：结合告警接口规范，将遥信变化消息与设备的模型信息组装成告警消息。
作为优选方案，所述步骤1中的告警定义元数据是指在配电云主站系统中用来标识告警类型和告警状态，告警类型分为告警父类型与告警子类型，在设置告警类型时，当子类型存在则取子类型，子类型不存在取父类型；告警父类型是系统内置类型，不支持自定义，存储在告警类型定义表中；告警子类型支持自定义，存储在告警子类型定义表中。
作为优选方案，所述步骤1中的多级缓存包括：一级缓存，二级缓存；一级缓存采用Caffeine，二级缓存采用Redis。
作为优选方案，所述一级缓存包括：静态区域、动态区域、实时区域。
其中，静态区域中缓存的模型属性信息数据，该区域数据不淘汰，不过期，在项目初始化阶段被载入，运行期间不再发生变化。
动态区域中缓存的是告警定义元数据，该区域数据不淘汰，不过期，在项目初始化阶段被载入，运行期间通过对Redis监听得到的告警定义元数据变化消息而动态更新的本地缓存数据。
实时区域中缓存的数据生命周期较短，有淘汰过期策略，存储一次设备的模型信息。
作为优选方案，所述步骤1中的将告警定义元数据初始化到多级缓存中，包括：
在项目启动阶段查询告警父类型定义表，以事件类型为Key，告警父类型为Value存储在多级缓存中；查询告警子类型定义表，以事件类型@表号@域号@遥信值为Key，告警子类型为Value存储在多级缓存。
作为优选方案，所述Redis作为消息中间件，支持基于频道的发布/订阅和基于模式的订阅/发布，在分布式多实例运行的场景下，使所有实例都能消费到告警定义元数据变化消息。
作为优选方案，所述步骤3包括：
当在告警定义页面操作告警定义元数据时，数据持久化到数据库，同时异步修改二级缓存中的告警定义元数据，并向二级缓存消息队列中发送告警定义元数据变化消息。
当Redis监听到二级缓存消息队列中告警定义元数据变化消息后，删除或更新当前实例中一级缓存里的告警定义元数据。
作为优选方案，所述步骤4中Kafka是分布式发布订阅消息系统，遥信事件变化Topic是用来存储遥信变化消息的一个Kafka会话Topic，生产者往Kafka的Topic中发布消息，消费者通过订阅Kafka中Topic消费生产者发布的消息。
作为优选方案，所述步骤4中一次设备的遥信变化消息，是一个字符串消息，一次设备的遥信变化消息格式是$id $feederId $termId $trArea $mainType $value $status $time $specialFlag $regionId，字段之间用空格隔开，其中$id是设备Id的填充，$feederId是馈线Id的填充，$termId是所属通讯终端Id的填充，$trArea是所属区域Id填充，$mainType是事件的类型填充，$value是遥信值的填充，$status是状态置的填充，$time是遥信变位时间的填充，$specialFlag是遥信变化类型的填充，$regionId是设备区域的填充。
作为优选方案，所述步骤5，包括：
解析一次设备的遥信变化消息，获取一次设备的$id由表号、域号、记录号组合而成作为KeyId属性，是Long类型数据，在从多级缓存查询当前设备的模型信息时，首先解析出$id的表号、域号，以Key[表号]从一级缓存查询该表号对应的模型属性名列表，循环属性列表中的数据名，以Key[KeyId@模型属性名]从多级缓存中查询模型信息。
作为优选方案，以Key[KeyId@模型属性名]从多级缓存中查询模型信息，包括：
当触发数据查询时，从一级缓存获取设备模型数据，命中的则返回；未命中的从二级缓存获取设备模型数据，命中后先返回设备模型数据。
再采用线程池异步更新到一级缓存；未命中继续从数据库查询设备模型数据，将查询设备模型数据返回后，采用线程池异步先将设备模型数据更新到二级缓存，再更新到一级缓存中。
作为优选方案，所述步骤6，包括：
当多级缓存中不存在设备模型信息时，通过SQL语句以步骤5中从$id解析出的表号为表名，步骤5中通过表号从一级缓存查询出的模型属性名列表为字段名，从数据库设备查询模型信息。
进一步的，所述步骤7，包括：
将模型信息以KeyId@模型属性名为Key，具体属性值为Value存储在多级缓存中。
进一步的，所述步骤8中的告警接口规范，用于对告警实体的字段类型定义与说明，包括：告警类型、告警时间、告警状态、告警内容、所属区域、告警其他字段的定义。
进一步的，所述步骤8，包括：
从遥信变化消息中解析出regionId为所属区域，解析出time为告警遥信变位时间。
根据KeyId与属性名从多级缓存查询告警类型、子类型填充告警类型，在从多级缓存查询告警类型时，先从一级缓存获取告警子类型，如果告警子类型存在，取告警子类型作为告警类型；如果告警子类型不存在，再从一级缓存查询告警父类型作为告警类型，告警父类型是一定存在的。
告警其他字段指的是在一级缓存静态区域中缓存的一次设备模型属性列表中的字段，不同表号对应着不同属性列表，这些字段对应模型信息查询如步骤5，然后将查询出的模型信息作为告警其他字段进行填充。
有益效果：本发明提供的一种支持多级缓存高并发的实时告警处理方法，重点解决海量遥信、遥测数据处理产生告警时高频率从数据库查询模型引发的性能瓶颈问题。通过将海量的实时告警从遥信、遥测数据处理中解耦出来，在海量模型数据批量查询时，根据模型数据变化较小的特点，引入多级缓存处理机制，大大降低对数据库访问的压力，减少了对分布式缓存的访问频次，提高了实时告警处理的吞吐率。
附图说明
图1为本发明的方法流程示意图。
图2为多级缓存数据查询与更新的流程示意图。
具体实施方式
下面结合具体实施例对本发明作更进一步的说明。
如图1所示，一种支持多级缓存高并发的实时告警处理方法，包括如下步骤：
步骤1：从数据库查询告警定义元数据，将告警定义元数据初始化到多级缓存中。
步骤2：监控Redis中告警定义元数据变化Topic，消费该Topic会话中的告警定义元数据变化消息。
步骤3：解析告警定义元数据变化消息，更新多级缓存中的告警定义元数据。
步骤4：监控Kafka中遥信事件变化Topic，消费该Topic中一次设备的遥信变化消息。
步骤5：提取遥信变化消息中的KeyId属性，根据KeyId属性从多级缓存中获取对应设备的模型信息。
步骤6：当多级缓存中不存在当前变化消息对应的设备的模型信息时，再根据KeyId属性从数据库中查询当前设备的模型信息。
步骤7：将从数据库中查询的设备的模型信息缓存到多级缓存中。
步骤8：结合告警接口规范，将遥信变化消息与设备的模型信息组装成告警消息。
步骤9：发送告警消息到Kafka的告警Topic中。
进一步的，所述步骤1中的告警定义元数据是指在配电云主站系统中用来标识具体告警类型和告警状态，此数据一部分是系统内置、另一部分是用户自定义生成；告警类型分为告警父类型与告警子类型，在设置具体告警类型时当子类型存在则取子类型，子类型不存在取父类型；告警父类型是系统内置类型，不支持自定义，存储在告警类型定义表中；告警子类型支持自定义，存储在告警子类型定义表中。
进一步的，所述步骤1中的多级缓存包含一级缓存，二级缓存，一级缓存采用Caffeine，二级缓存采用Redis。一级缓存的Caffeine是应用级缓存，服务启动时在本地开辟出一块内存区域，一级缓存通过配置多个实例与名称空间来管理不同生命周期的缓存数据，包含静态区域、动态区域、实时区域。其中静态区域中缓存的数据不淘汰，不过期，在项目初始化阶段被载入，运行期间不再发生变化；动态区域缓存的是告警定义元数据，该区域数据不淘汰，不过期，在项目初始化阶段被载入，运行期间通过对Redis监听得到的告警定义元数据变化消息而动态更新的本地缓存数据；实时区域缓存的数据生命周期较短，有淘汰过期策略，存储一次设备的模型信息。
进一步的，所述步骤1中的将告警定义元数据初始化到多级缓存中，是在项目启动阶段查询告警父类型定义表，以事件类型为Key，告警父类型为Value存储在多级缓存中；查询告警子类型定义表，以事件类型@表号@域号@遥信值为Key，告警子类型为Value存储在多级缓存。
进一步的，所述步骤2中的Redis是分布式缓存，也可以作为消息中间件，支持两种模式的订阅与发布，分别是基于频道的发布/订阅和基于模式的订阅/发布。
进一步的，所述步骤2中的告警定义元数据变化Topic，是Redis中的一个消息会话，接收告警子类型变化消息，当用户在告警定义页面修改/新增/删除告警类型时，产生告警类型变化消息并发送到该Topic中，所有消费者从该Topic中消费告警类型变化消息。
进一步的，所述步骤2中使用Redis是作为消息中间件，采用的是基于频道的发布/订阅模式，其特征是保证服务在分布式环境下运行多个实例时，各实例之间告警定义元数据数据一致性问题。原始方法是采用kafka作为消息中间件，在分布式多实例运行的场景下，告警定义元数据发生变化时，只有一个实例能消费到变化消息；使用Redis做为消息中间件，使所有实例都能消费到变化消息，如图2中2.1-2.3所示。
进一步的，所述步骤3中的解析告警定义元数据变化消息，更新多级缓存中的告警定义元数据。是根据告警定义元数据变化消息中的操作类型如新增/修改/删除，同步新增/修改/删除多级缓存中的相应告警定义元数据。
进一步的，所述步骤4中Kafka是一个开源流处理平台，是一种高吞吐量的分布式发布订阅消息系统，Topic是Kafka中的一个会话，是管理消息的单元，生产者可以往Kafka的Topic中发布消息，消费者通过订阅Kafka中Topic消费生产者发布的消息。
进一步的，所述步骤4中事件变化Topic，是专门用来存储遥信变化消息的一个Kafka会话。
进一步的，所述步骤4中一次设备的遥信变化消息，是一个字符串消息，该消息是由上游服务处理后发送到事件变化Topic中的，消息格式是$id $feederId $termId $trArea $mainType $value $status $time $specialFlag $regionId，字段之间用空格隔开，其中$id是设备Id的填充， $feederId是馈线Id的填充，$termId是所属通讯终端Id的填充，$trArea是所属区域Id填充，$mainType是事件的类型填充，$value是遥信值的填充，$status是状态置的填充，$time是遥信变位时间的填充，$specialFlag是遥信变化类型的填充，$regionId是设备区域的填充。
进一步的，所述步骤5中提取遥信变化消息中的KeyId属性值，是解析步骤4中的遥信变化消息，获取其中的$id值，是Long类型数据，其中，$id值由表号、域号、记录号组合而成KeyId属性值。
进一步的，根据KeyId属性从多级缓存中获取对应设备的模型信息，特别是此处的“当前设备”在电力系统一次设备范围内存在多种具体设备表，不同设备表在生成告警时需要的模型属性信息有所差异，本发明针对不同设备表，在项目启动阶段通过配置模型属性名[即表的字段名]列表，规定了需要查询设备表的哪些字段，这种模型属性名列表在运行阶段不发生变化，被缓存在一级缓存的静态区域中。在查询当前设备模型信息时，首先解析出$id的表号、域号，以Key[表号]从一级缓存查询该表号对应的模型属性名列表，循环属性列表中的数据名，以Key[KeyId@模型属性名]从多级缓存中查询模型信息。其中在从多级缓存查询设备模型数据时，如图2中1.1-1.7所示，具体流程如下：
当触发数据查询时，从一级缓存获取设备模型数据，命中的则返回；未命中的从二级缓存获取设备模型数据，命中后先返回设备模型数据。
再采用线程池异步更新到一级缓存；未命中继续从数据库查询设备模型数据，将查询设备模型数据返回后，采用线程池异步先将设备模型数据更新到二级缓存，再更新到一级缓存中。
例如大多一次设备同时具备设备名称、所属馈线、所属责任区、量测类型、所属区域属性。
例如，id[3799912185620001363]，表号[13500]，表号13505对应模型属性列表是[name,code,feeder_id,resp_area]，此时多级缓存有4条数据[3799912185620001363@name=value1;3799912185620001363@code=value2;3799912185620001363@feeder_id=value3;3799912185620001363@resp_area=value4]。
进一步的，所述步骤6中根据KeyId属性从数据库中查询当前设备的模型信息，当多级缓存中不存在设备模型信息时，通过SQL语句以步骤5中从$id解析出的表号为表名，步骤5中通过表号从一级缓存查询出的模型属性名列表为字段名，从数据库查询设备模型信息。
例如，id[3799912185620001363]，表号[13500]对应模型属性列表是[name,code,feeder_id,resp_area]，SQL语句为 select name,code,feeder_id,resp_area from13500[表名] where id=3799912185620001363。
进一步的，所述步骤7中是将从数据库中查询的设备模型信息缓存到多级缓存中，是将模型信息以KeyId@模型属性名为Key，具体属性值为Value存储在多级缓存中。
进一步的，所述步骤8中的告警接口规范，用于对告警实体的字段进行定义与说明，主要包括：告警类型、告警时间、告警状态、所属区域、告警其他字段的定义，告警接口详细数据格式如下：
{
"alarmTime": "2022-12-07",
"alarmType": 1234,
"otherColumn": {
"yx_value": 1,
"regionId": "420112",
"feeder_id": "3799912185620001363",
"event_time": 1670083200000,
...[其他属性]
},
"alarmContent": "2022年12月07日 17:25:22 10kV测试专线10kV斗门线154 101测试开关 动作 变位时间[2022年12月04日 00:00:00]",
"alarmStatus": 90
}
进一步的，所述步骤8中的结合告警接口规范，将遥信变化消息、告警元数据和模型信息组装告警消息，
告警时间alarmTime取步骤4中消费到遥信事件变化时的时间。
告警类型alarmType是根据KeyId与属性名从多级缓存查询告警类型、子类型。
告警状态alarmStatus的缓存、查询、更新流程与方法同告警类型是一致的。
告警区域regionId是从遥信变化消息中解析出的regionId。
告警遥信值yx_value是从遥信变化消息中解析出的value。
告警遥信变位时间event_time是从遥信变化消息中解析出的time。
告警的馈线feeder_id从遥信变化消息中解析出的feeder_id。
告警其他字段otherColumn如接口数据格式中定义所示，包括yx_value/regionId/feeder_id/event_time和其他属性构成，其中其他属性是在一级缓存静态区域中以表号为Key缓存的一次设备模型属性列表中的字段，这些字段对应的值是根据遥信变化消息中解析出的id和表号，在数据库查询出模型属性列表对应的模型信息，如步骤6所述。
告警内容字段alarmContent是有多个字段合并组合而成由“告警时间 馈线名称开关名称 告警状态 变位时间”组合而成，其中告警时间取接收到遥信变化消息时的当前时间，馈线名称是根据遥信变化消息中解析出的feeder_id通过步骤4提到的方法获取到的名称，开关名称是根据遥信变化消息中解析出的id通过步骤4提到的方法获取到的名称，告警状态和变位时间分别取alarmStatus，yx_value字段。
从遥信变化消息中解析出regionId为所属区域，解析出time为告警遥信变位时间。
根据KeyId与属性名从多级缓存查询告警类型、子类型填充告警类型，在从多级缓存查询告警类型时，先从一级缓存获取告警子类型，如果告警子类型存在，取告警子类型作为告警类型；如果告警子类型不存在，再从一级缓存查询告警父类型作为告警类型，告警父类型是一定存在的。
告警其他字段指的是在一级缓存静态区域中缓存的一次设备模型属性列表中的字段，不同表号对应着不同属性列表，这些字段对应模型信息查询如步骤5，然后将查询出的模型信息作为告警其他字段进行填充。
本发明基于微服务架构，提供了一种多级缓存方案处理实时告警数据的方法，包含了多级缓存的架构与操作流程，及实时告警数据处理流程。
如图1所示为的多级缓存包含一级缓存Caffeine，二级缓存Redis，通过多级缓存客户端进行管理，该多级缓存客户端是本发明基于Spring中抽象类AbstractValueAdaptingCache的一个子类实现，其中一级缓存中三个静态区域、动态区域、实时区域是多级缓存客户端的三个实例对象。
其中，多级缓存客户端其特点对一次设备模型信息的批量查询、对一级缓存Caffeine中告警元数据进行实时更新操作。一次设备模型数据批量查询流程如图2中1.1-1.7，从在根据KeyId多级缓存查询模型数据时，优先从一级缓存查询，查询到模型数据则返回；未查询到的模型数据再从二级缓存查询，二级缓存查询不到再从数据库查询。在将查询到的设备模型信息数据缓存到多级缓存时，如果是从数据库中查询到的模型数据，优先将设备模型数据缓存到二级缓存中，再采用线程池异步的方式将设备模型数据缓存到一级缓存中，在分布式多实例运行的场景，减少对数据库的查询操作；如果是从二级缓存中查询到的模型数据，则直接采用线程池异步的方式将设备模型数据缓存到一级缓存。
一级缓存中告警定义元数据实时更新数据流程如图2中2.1-2.3所示，当用户在告警定义页面操作告警定义元数据时，数据持久化到数据库，同时异步修改二级缓存中的告警定义元数据，并向二级缓存消息队列中发送告警定义元数据变化消息；在分布式环境多实例运行的场景下，通过实现一个二级缓存消息监听器，当各个实例在监听到二级缓存消息队列中告警定义元数据变化消息后，删除或更新当前实例中一级缓存里的告警定义元数据，以此保证各实例的一级缓存中存储的告警定义元数据的一致性与实时性。
本发明提供的一种支持多级缓存高并发的实时告警处理方法，在充分考虑分布式流计算引擎无法缓存大量数据的特性下，结合了微服务架构并整合多级缓存技术后，使本地服务实例能够缓存大量热点数据，同时，保证这些重要数据的一致性，解决了海量遥信、遥测数据处理产生告警时高频率从数据库查询模型引发的性能瓶颈问题，大大提高了海量实时告警处理的吞吐率。
本发明中的多级缓存支持多元数据、多生命周期数据的批量缓存与批量查询，支持在分布式环境下多实例一级缓存中动态区域中告警元数据的实时更新与同步。本发明以微服务架构为依托，基于（Redis+Caffeine）整合多级缓存框架大大提高了海量告警实时处理的吞吐率，极大降低了对数据库与分布式缓存的访问压力。
以上所述仅是本发明的优选实施方式，应当指出：对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (13)

1.一种支持多级缓存高并发的实时告警处理方法，其特征在于：包括如下步骤：
步骤1：从数据库查询告警定义元数据，将告警定义元数据初始化到多级缓存中；
步骤2：监控Redis中告警定义元数据变化Topic，消费告警定义元数据变化Topic会话中的告警定义元数据变化消息；
步骤3：解析告警定义元数据变化消息，更新多级缓存中的告警定义元数据；
步骤4：监控Kafka中遥信事件变化Topic，消费遥信事件变化Topic中一次设备的遥信变化消息；
步骤5：提取遥信变化消息中的KeyId属性，根据KeyId属性从多级缓存中获取设备的模型信息；
步骤6：当多级缓存中不存在当前变化消息对应的设备的模型信息时，再根据KeyId属性从数据库中查询当前设备的模型信息；
步骤7：将从数据库中查询的设备的模型信息缓存到多级缓存中；
步骤8：结合告警接口规范，将遥信变化消息与设备的模型信息组装成告警消息。
2.根据权利要求1所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述步骤1中的告警定义元数据是指在配电云主站系统中用来标识告警类型和告警状态，告警类型分为告警父类型与告警子类型，在设置告警类型时，当子类型存在则取子类型，子类型不存在取父类型；告警父类型是系统内置类型，不支持自定义，存储在告警类型定义表中；告警子类型支持自定义，存储在告警子类型定义表中。
3.根据权利要求1所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述步骤1中的多级缓存包括：一级缓存，二级缓存；一级缓存采用Caffeine，二级缓存采用Redis。
4.根据权利要求3所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述一级缓存包括：静态区域、动态区域、实时区域；
其中，静态区域中缓存的模型属性信息数据，该区域数据不淘汰，不过期，在项目初始化阶段被载入，运行期间不再发生变化；
动态区域中缓存的是告警定义元数据，该区域数据不淘汰，不过期，在项目初始化阶段被载入，运行期间通过对Redis监听得到的告警定义元数据变化消息而动态更新的本地缓存数据；
实时区域中缓存的数据生命周期较短，有淘汰过期策略，存储一次设备的模型信息。
5.根据权利要求1所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述步骤1中的将告警定义元数据初始化到多级缓存中，包括：
在项目启动阶段查询告警父类型定义表，以事件类型为Key，告警父类型为Value存储在多级缓存中；查询告警子类型定义表，以事件类型@表号@域号@遥信值为Key，告警子类型为Value存储在多级缓存。
6.根据权利要求1所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述Redis作为消息中间件，支持基于频道的发布/订阅和基于模式的订阅/发布，在分布式多实例运行的场景下，使所有实例都能消费到告警定义元数据变化消息。
7.根据权利要求3所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述步骤3包括：
当在告警定义页面操作告警定义元数据时，数据持久化到数据库，同时异步修改二级缓存中的告警定义元数据，并向二级缓存消息队列中发送告警定义元数据变化消息；
当Redis监听到二级缓存消息队列中告警定义元数据变化消息后，删除或更新当前实例中一级缓存里的告警定义元数据。
8.根据权利要求1所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述步骤4中Kafka是分布式发布订阅消息系统，遥信事件变化Topic是用来存储遥信变化消息的一个Kafka会话Topic，生产者往Kafka的Topic中发布消息，消费者通过订阅Kafka中Topic消费生产者发布的消息。
9.根据权利要求3所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述步骤4中一次设备的遥信变化消息，是一个字符串消息，一次设备的遥信变化消息格式是$id $feederId $termId $trArea $mainType $value $status $time $specialFlag $regionId，字段之间用空格隔开，其中$id是设备Id的填充， $feederId是馈线Id的填充，$termId是所属通讯终端Id的填充，$trArea是所属区域Id填充，$mainType是事件的类型填充，$value是遥信值的填充，$status是状态置的填充，$time是遥信变位时间的填充，$specialFlag是遥信变化类型的填充，$regionId是设备区域的填充。
10.根据权利要求9所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述步骤5，包括：
解析一次设备的遥信变化消息，获取一次设备的$id由表号、域号、记录号组合而成作为KeyId属性，是Long类型数据，在从多级缓存查询当前设备的模型信息时，首先解析出$id的表号、域号，以Key[表号]从一级缓存查询该表号对应的模型属性名列表，循环属性列表中的数据名，以Key[KeyId@模型属性名]从多级缓存中查询设备模型信息；所述以Key[KeyId@模型属性名]从多级缓存中查询设备模型信息，包括：
当触发数据查询时，从一级缓存获取设备模型数据，命中的则返回；未命中的从二级缓存获取设备模型数据，命中后先返回模型数据；
再采用线程池异步更新到一级缓存；未命中继续从数据库查询设备模型数据，将查询设备模型数据返回后，采用线程池异步先将设备模型数据更新到二级缓存，再更新到一级缓存中。
11.根据权利要求3所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述步骤6，包括：当多级缓存中不存在设备模型信息时，通过SQL语句以从$id中解析出的表号为表名，通过表号从一级缓存查询出的模型属性名列表为字段名，从数据库设备查询模型信息。
12.根据权利要求1所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述步骤7，包括：
将模型信息以KeyId@模型属性名为Key，具体属性值为Value存储在多级缓存中。
13.根据权利要求3所述的一种支持多级缓存高并发的实时告警处理方法，其特征在于：所述步骤8，包括：
从遥信变化消息中解析出regionId为所属区域，解析出time为告警遥信变位时间；
根据KeyId与属性名从多级缓存查询告警类型、子类型填充告警类型，在从多级缓存查询告警类型时，先从一级缓存获取告警子类型，如果告警子类型存在，取告警子类型作为告警类型；如果告警子类型不存在，再从一级缓存查询告警父类型作为告警类型；
告警其他字段是在一级缓存静态区域中缓存的一次设备模型属性列表中的字段，不同表号对应着不同属性列表，通过从多级缓存中查询设备模型信息，将查询出的设备模型信息作为告警其他字段进行填充。
CN202211618351.XA 2022-12-15 2022-12-15 一种支持多级缓存高并发的实时告警处理方法 Pending CN116185895A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211618351.XA CN116185895A (zh) 2022-12-15 2022-12-15 一种支持多级缓存高并发的实时告警处理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211618351.XA CN116185895A (zh) 2022-12-15 2022-12-15 一种支持多级缓存高并发的实时告警处理方法

Publications (1)

Publication Number Publication Date
CN116185895A true CN116185895A (zh) 2023-05-30

Family

ID=86447071

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211618351.XA Pending CN116185895A (zh) 2022-12-15 2022-12-15 一种支持多级缓存高并发的实时告警处理方法

Country Status (1)

Country Link
CN (1) CN116185895A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116886790A (zh) * 2023-09-06 2023-10-13 北京大禹智芯科技有限公司 一种支持动态高并发toe的方法
CN117708179A (zh) * 2024-02-02 2024-03-15 成都深瑞同华科技有限公司 电力综合监控系统测点数据缓存方法、装置、设备及介质

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116886790A (zh) * 2023-09-06 2023-10-13 北京大禹智芯科技有限公司 一种支持动态高并发toe的方法
CN117708179A (zh) * 2024-02-02 2024-03-15 成都深瑞同华科技有限公司 电力综合监控系统测点数据缓存方法、装置、设备及介质
CN117708179B (zh) * 2024-02-02 2024-05-03 成都深瑞同华科技有限公司 电力综合监控系统测点数据缓存方法、装置、设备及介质

Similar Documents

Publication Publication Date Title
CN116185895A (zh) 一种支持多级缓存高并发的实时告警处理方法
CN111309409B (zh) 一种api服务调用实时统计方法
US7890489B2 (en) Just-in-time publishing system and program product for a publish/subscribe messaging system using a subscribe-event model
CN110147398B (zh) 一种数据处理方法、装置、介质和电子设备
CN109063196B (zh) 数据处理方法、装置、电子设备及计算机可读存储介质
US20080196042A1 (en) System and computer program product for just-in-time publishing via a publish/subscribe messaging system having message publishing controls
US20150215386A1 (en) Management of data object sharing among applications
US20080244051A1 (en) Method And System For Managing Dynamic Associations Between Folksonomic Data And Resources
CN111026727A (zh) 基于日志文件的表维度检索数据同步方法、系统及装置
US20130179791A1 (en) System and method for real-time data in a graphical user interface
CN106487891B (zh) 一种基于kafka的处理消息的方法
CN111859132A (zh) 一种数据处理方法、装置及智能设备、存储介质
CN111782692B (zh) 一种频率控制方法及装置
WO2016037540A1 (zh) 基于pb和xpath的网元级网管业务配置适配系统及方法
CN103645904A (zh) 一种接口调用的缓存实现方法
Cugola et al. Raced: an adaptive middleware for complex event detection
US20230145069A1 (en) Automated data health reasoning
CN115840862B (zh) 一种网络靶场大规模场景中靶标的快速查询方法与系统
CN114443599A (zh) 数据同步方法、装置、电子设备及存储介质
CN115757552B (zh) 基于分布式微服务的银行历史数据管理系统
CN112256446B (zh) 一种Kafka消息总线管控方法及系统
Antunes et al. Semantic-based publish/subscribe for M2M
CN114911872A (zh) 内外网数据同步方法、装置、系统、外网服务器及存储介质
Makitalo et al. VisualREST: a content management system for cloud computing environment
Brunner et al. Software design for building model servers: Concurrency aspects

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination