A real-time alarm processing method supporting high concurrency of multi-level cache

Abstract

The application discloses a kind of real-time alarm processing methods of supporting multistage cache high concurrency, based on microservice architecture, by integrating multistage cache framework (Redis+Caffeine), support diversified, multilife cycle data cache, realized the batch query of data under multistage cache, batch cache, asynchronous update function, solve the consistency problem of application level local cache data under distributed environment, improve the throughput of power distribution cloud master station overall data processing.The real-time alarm processing method of supporting multistage cache high concurrency provided by the application, under the characteristics that distributed stream computing engine cannot cache a large amount of data, combined with microservice architecture and integrated multistage cache technology, so that local service instance can cache a large amount of hot data, at the same time, ensure the consistency of these important data, solve the performance bottleneck problem caused by high frequency database query model when mass telesign, telemeter data processing generates alarm, greatly improve the throughput of mass real-time alarm processing.

Description

Technical Field

[0001] This invention relates to a real-time alarm processing method that supports high concurrency with multi-level caching, belonging to the field of real-time data processing technology for power grids. Background Technology

[0002] Currently, the power distribution cloud master station faces a large number of device and terminal accesses, and the processing of real-time data such as device online / offline status, remote signaling, and telemetry faces significant challenges. After adopting streaming processing technologies such as Spark Streaming and Flink, the performance has been further improved.

[0003] However, after the power distribution cloud master station integrated alarm processing, the performance dropped significantly. The main reason is the atomicity of alarm data. That is, for each piece of data, the corresponding model needs to be queried from the database or distributed cache for assembly. Spark Streaming / Flink and other stream processing are distributed computing and do not natively support the caching and sharing of large amounts of data. This causes stream processing to spend a lot of time pulling model data, which greatly reduces the performance of data processing.

[0004] Therefore, how to improve the performance of alarm processing in the power distribution cloud master station is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] Objective: To overcome the performance bottleneck of current flow calculation in alarm data processing in distribution networks in existing technologies, this invention provides a real-time alarm processing method that supports high concurrency through multi-level caching. Based on a microservice architecture, it integrates a multi-level caching framework (Redis+Caffeine) to support diversified and multi-lifecycle data caching. It realizes batch query, batch caching, and asynchronous update functions for data under multi-level caching, solves the consistency problem of application-level local cached data in a distributed environment, and improves the overall data processing throughput of the distribution cloud master station.

[0006] Technical solution: To solve the above technical problems, the technical solution adopted by the present invention is as follows:

[0007] A real-time alarm processing method supporting high concurrency with multi-level caching includes the following steps:

[0008] Step 1: Query the alarm definition metadata from the database and initialize the alarm definition metadata into the multi-level cache.

[0009] Step 2: Monitor the Alarm Definition Metadata Change Topic in Redis and consume the Alarm Definition Metadata Change messages in the Alarm Definition Metadata Change Topic session.

[0010] Step 3: Parse the alarm definition metadata change message and update the alarm definition metadata in the multi-level cache.

[0011] Step 4: Monitor the remote signaling event change topic in Kafka and consume the remote signaling event change messages of the primary device in the remote signaling event change topic.

[0012] Step 5: Extract the KeyId attribute from the remote signaling change message, and obtain the device model information from the multi-level cache based on the KeyId attribute.

[0013] Step 6: If the model information of the device corresponding to the current change message does not exist in the multi-level cache, then query the model information of the current device from the database based on the KeyId attribute.

[0014] Step 7: Cache the device model information retrieved from the database into a multi-level cache.

[0015] Step 8: Combine the remote signaling change message with the device model information according to the alarm interface specification to form an alarm message.

[0016] As a preferred embodiment, the alarm definition metadata in step 1 refers to the data used in the power distribution cloud master station system to identify alarm types and alarm statuses. Alarm types are divided into alarm parent types and alarm subtypes. When setting alarm types, if a subtype exists, the subtype is used; if the subtype does not exist, the parent type is used. The alarm parent type is a built-in type of the system and does not support customization. It is stored in the alarm type definition table. Alarm subtypes support customization and are stored in the alarm subtype definition table.

[0017] As a preferred embodiment, the multi-level cache in step 1 includes: a first-level cache and a second-level cache; the first-level cache uses Caffeine, and the second-level cache uses Redis.

[0018] As a preferred embodiment, the first-level cache includes: a static region, a dynamic region, and a real-time region.

[0019] The model attribute information data cached in the static area is not discarded or expired. It is loaded during the project initialization phase and does not change during runtime.

[0020] The dynamic area caches alarm definition metadata. This data is not evicted or expired. It is loaded during the project initialization phase and dynamically updated during runtime by monitoring alarm definition metadata changes received from Redis.

[0021] Data cached in the real-time area has a short lifespan and is subject to an expiration policy. It stores the model information of the primary device.

[0022] As a preferred embodiment, step 1, initializing the alarm definition metadata into a multi-level cache, includes:

[0023] During the project startup phase, query the alarm parent type definition table, using the event type as the key and the alarm parent type as the value, and store it in a multi-level cache; query the alarm subtype definition table, using the event type@table number@domain number@remote signaling value as the key and the alarm subtype as the value, and store it in a multi-level cache.

[0024] As a preferred option, Redis, as a message middleware, supports channel-based publish / subscribe and schema-based publish / subscribe, enabling all instances to consume alarm definition metadata change messages in distributed multi-instance scenarios.

[0025] As a preferred embodiment, step 3 includes:

[0026] When alarm definition metadata is manipulated on the alarm definition page, the data is persisted to the database, the alarm definition metadata in the second-level cache is modified asynchronously, and an alarm definition metadata change message is sent to the second-level cache message queue.

[0027] When Redis detects a change in alarm definition metadata in the second-level cache message queue, it deletes or updates the alarm definition metadata in the first-level cache of the current instance.

[0028] As a preferred option, in step 4, Kafka is a distributed publish-subscribe messaging system. The remote information event change topic is a Kafka session topic used to store remote information change messages. Producers publish messages to Kafka topics, and consumers consume messages published by producers by subscribing to topics in Kafka.

[0029] As a preferred embodiment, the remote signaling change message of the primary device in step 4 is a string message. The format of the remote signaling change message of the primary device is $id $feederId $termId $trArea $mainType $value $status $time $specialFlag $regionId, with the fields separated by spaces. Among them, $id is the device ID, $feederId is the feeder ID, $termId is the communication terminal ID, $trArea is the region ID, $mainType is the event type, $value is the remote signaling value, $status is the status setting, $time is the remote signaling change time, $specialFlag is the remote signaling change type, and $regionId is the device region.

[0030] As a preferred embodiment, step 5 includes:

[0031] Parse the remote signaling change message of the primary device to obtain the $id of the primary device, which is composed of table number, domain number, and record number as the KeyId attribute. It is a Long type data. When querying the model information of the current device from the multi-level cache, first parse the table number and domain number of $id. Then, use Key[table number] to query the list of model attribute names corresponding to the table number from the first-level cache. Loop through the data names in the attribute list and use Key[KeyId@model attribute name] to query the model information from the multi-level cache.

[0032] As a preferred approach, model information is retrieved from the multi-level cache using Key[KeyId@model attribute name], including:

[0033] When a data query is triggered, device model data is retrieved from the first-level cache. If the data is found, it is returned. If the data is not found, device model data is retrieved from the second-level cache. If the data is found, the device model data is returned first.

[0034] Then, use a thread pool to asynchronously update the first-level cache; if a cache miss occurs, continue to query the device model data from the database. After the queried device model data is returned, use a thread pool to asynchronously update the device model data to the second-level cache first, and then update it to the first-level cache.

[0035] As a preferred embodiment, step 6 includes:

[0036] When device model information is not found in the multi-level cache, the model information is retrieved from the database device using an SQL statement with the table number parsed from $id in step 5 as the table name and the list of model attribute names retrieved from the first-level cache using the table number in step 5 as the field names.

[0037] Furthermore, step 7 includes:

[0038] The model information is stored in a multi-level cache with KeyId@model attribute name as the key and the specific attribute value as the value.

[0039] Furthermore, the alarm interface specification in step 8 is used to define and describe the field types of alarm entities, including: alarm type, alarm time, alarm status, alarm content, region, and other alarm fields.

[0040] Furthermore, step 8 includes:

[0041] The regionId is parsed from the remote signaling change message to indicate the region to which it belongs, and the time is parsed to indicate the time of the alarm remote signaling change.

[0042] The alarm type is retrieved from the multi-level cache based on the KeyId and attribute name, and the subtype is populated with the alarm type. When retrieving the alarm type from the multi-level cache, the alarm subtype is first retrieved from the first-level cache. If the alarm subtype exists, it is taken as the alarm type. If the alarm subtype does not exist, the alarm parent type is retrieved from the first-level cache as the alarm type. The alarm parent type must exist.

[0043] Other alarm fields refer to the fields in the primary device model attribute list cached in the first-level cache static area. Different table numbers correspond to different attribute lists. These fields correspond to model information queries as in step 5, and then the retrieved model information is used as the other alarm fields to fill in the data.

[0044] Beneficial Effects: This invention provides a real-time alarm processing method supporting high concurrency through multi-level caching, primarily addressing the performance bottleneck caused by frequent database queries when alarms are generated from massive amounts of remote signaling and telemetry data processing. By decoupling massive real-time alarms from remote signaling and telemetry data processing, and considering the relatively small changes in model data during batch queries, a multi-level caching mechanism is introduced, significantly reducing the pressure on database access, decreasing the frequency of access to the distributed cache, and improving the throughput of real-time alarm processing. Attached Figure Description

[0045] Figure 1 This is a schematic diagram of the method flow of the present invention.

[0046] Figure 2 This is a flowchart illustrating the process of querying and updating multi-level cached data. Detailed Implementation

[0047] The present invention will be further described below with reference to specific embodiments.

[0048] like Figure 1 As shown, a real-time alarm processing method supporting high concurrency with multi-level caching includes the following steps:

[0049] Step 1: Query the alarm definition metadata from the database and initialize the alarm definition metadata into the multi-level cache.

[0050] Step 2: Monitor the topic of alarm definition metadata changes in Redis and consume the alarm definition metadata change messages in the topic session.

[0051] Step 3: Parse the alarm definition metadata change message and update the alarm definition metadata in the multi-level cache.

[0052] Step 4: Monitor the remote signaling event change topic in Kafka and consume the remote signaling change messages of one device in that topic.

[0053] Step 5: Extract the KeyId attribute from the remote signaling change message, and retrieve the model information of the corresponding device from the multi-level cache based on the KeyId attribute.

[0054] Step 6: If the model information of the device corresponding to the current change message does not exist in the multi-level cache, then query the model information of the current device from the database based on the KeyId attribute.

[0055] Step 7: Cache the device model information retrieved from the database into a multi-level cache.

[0056] Step 8: Combine the remote signaling change message with the device model information according to the alarm interface specification to form an alarm message.

[0057] Step 9: Send an alert message to the Kafka alert topic.

[0058] Furthermore, the alarm definition metadata in step 1 refers to the data used in the power distribution cloud master station system to identify specific alarm types and alarm states. This data is partly built into the system and partly generated by the user. Alarm types are divided into parent alarm types and sub-alarm types. When setting a specific alarm type, if a sub-type exists, the sub-type is used; if the sub-type does not exist, the parent type is used. The parent alarm type is a built-in system type and does not support customization; it is stored in the alarm type definition table. The sub-alarm type supports customization and is stored in the sub-alarm type definition table.

[0059] Furthermore, the multi-level caching in step 1 includes a first-level cache and a second-level cache. The first-level cache uses Caffeine, and the second-level cache uses Redis. The Caffeine first-level cache is an application-level cache. When the service starts, it allocates a memory area locally. The first-level cache manages cached data with different lifecycles by configuring multiple instances and namespaces, including static areas, dynamic areas, and real-time areas. Data cached in the static area is not evicted or expired. It is loaded during the project initialization phase and does not change during runtime. The dynamic area caches alarm definition metadata. This area's data is not evicted or expired. It is loaded during the project initialization phase and dynamically updated locally during runtime by listening to alarm definition metadata change messages obtained from Redis. The real-time area caches data with a shorter lifecycle and has an eviction and expiration policy. It stores primary device model information.

[0060] Furthermore, in step 1, initializing the alarm definition metadata into the multi-level cache involves querying the alarm parent type definition table during the project startup phase, storing it in the multi-level cache with the event type as the key and the alarm parent type as the value; and querying the alarm subtype definition table, storing it in the multi-level cache with the event type@table number@domain number@remote signaling value as the key and the alarm subtype as the value.

[0061] Furthermore, the Redis in step 2 is a distributed cache and can also be used as a message middleware, supporting two modes of subscription and publication: channel-based publish / subscribe and mode-based publish / subscribe.

[0062] Furthermore, the alarm definition metadata change Topic in step 2 is a message session in Redis that receives alarm subtype change messages. When a user modifies / adds / deletes an alarm type on the alarm definition page, an alarm type change message is generated and sent to this Topic. All consumers consume alarm type change messages from this Topic.

[0063] Furthermore, in step 2, Redis is used as a message middleware, employing a channel-based publish / subscribe model. Its key feature is ensuring data consistency of alarm definition metadata across multiple instances running in a distributed environment. The original method used Kafka as a message middleware; in a distributed multi-instance scenario, when alarm definition metadata changes, only one instance can consume the changed message. Using Redis as a message middleware ensures that all instances can consume the changed message, such as... Figure 2 As shown in Figures 2.1-2.3.

[0064] Furthermore, in step 3, parsing the alarm definition metadata change message and updating the alarm definition metadata in the multi-level cache involves synchronously adding / modifying / deleting the corresponding alarm definition metadata in the multi-level cache based on the operation type in the alarm definition metadata change message, such as add / modify / delete.

[0065] Furthermore, in step 4, Kafka is an open-source stream processing platform and a high-throughput distributed publish-subscribe messaging system. A Topic is a session in Kafka and a unit for managing messages. Producers can publish messages to Kafka Topics, and consumers can consume messages published by producers by subscribing to Kafka Topics.

[0066] Furthermore, the event change topic in step 4 is a Kafka session specifically used to store remote signal change messages.

[0067] Furthermore, the remote signaling change message of the primary device in step 4 is a string message. This message is processed by the upstream service and sent to the event change topic. The message format is $id $feederId $termId $trArea $mainType $value $status $time $specialFlag $regionId, with fields separated by spaces. Here, $id is the device ID, $feederId is the feeder ID, $termId is the terminal ID, $trArea is the region ID, $mainType is the event type, $value is the remote signaling value, $status is the status setting, $time is the remote signaling change time, $specialFlag is the remote signaling change type, and $regionId is the device region.

[0068] Furthermore, in step 5, the KeyId attribute value is extracted from the remote signaling change message. This involves parsing the remote signaling change message in step 4 and obtaining the $id value, which is a Long type data. The $id value is composed of the table number, domain number, and record number.

[0069] Furthermore, based on the KeyId attribute, the model information of the corresponding device is retrieved from the multi-level cache. Specifically, the "current device" here exists in multiple specific device tables within the primary equipment scope of the power system. Different device tables require different model attribute information when generating alarms. This invention, for different device tables, specifies which fields of the device table need to be queried by configuring a list of model attribute names [i.e., table field names] during the project startup phase. This list of model attribute names does not change during runtime and is cached in the static area of ​​the first-level cache. When querying the current device model information, the table number and domain number of $id are first parsed. The list of model attribute names corresponding to that table number is retrieved from the first-level cache using the Key[table number]. The data names in the attribute list are looped through, and the model information is retrieved from the multi-level cache using the Key[KeyId@model attribute name]. When querying device model data from the multi-level cache, such as... Figure 2 As shown in sections 1.1-1.7, the specific process is as follows:

[0070] When a data query is triggered, device model data is retrieved from the first-level cache. If the data is found, it is returned. If the data is not found, device model data is retrieved from the second-level cache. If the data is found, the device model data is returned first.

[0071] Then, use a thread pool to asynchronously update the first-level cache; if a cache miss occurs, continue to query the device model data from the database. After the queried device model data is returned, use a thread pool to asynchronously update the device model data to the second-level cache first, and then update it to the first-level cache.

[0072] For example, most primary equipment simultaneously possesses equipment name, feeder to which it belongs, area of ​​responsibility to which it belongs, measurement type, and area attribute.

[0073] For example, id[3799912185620001363], table number

[13500] , the model attribute list corresponding to table number 13505 is [name, code, feeder_id, resp_area]. At this time, the multi-level cache has 4 data entries [3799912185620001363@name=value1;3799912185620001363@code=value2;3799912185620001363@feeder_id=value3;3799912185620001363@resp_area=value4].

[0074] Furthermore, in step 6, the model information of the current device is queried from the database based on the KeyId attribute. When the device model information is not found in the multi-level cache, the device model information is queried from the database using an SQL statement with the table number parsed from $id in step 5 as the table name and the list of model attribute names queried from the first-level cache using the table number in step 5 as the field name.

[0075] For example, if id[3799912185620001363] and table number

[13500] corresponds to the model attribute list [name, code, feeder_id, resp_area], the SQL statement would be: select name, code, feeder_id, resp_area from 13500[table_name] where id=3799912185620001363.

[0076] Furthermore, in step 7, the device model information queried from the database is cached in a multi-level cache. The model information is stored in the multi-level cache with KeyId@model attribute name as the key and the specific attribute value as the value.

[0077] Furthermore, the alarm interface specification in step 8 is used to define and describe the fields of the alarm entity, mainly including: alarm type, alarm time, alarm status, region, and other alarm fields. The detailed data format of the alarm interface is as follows:

[0078] {

[0079] "alarmTime": "2022-12-07",

[0080] "alarmType": 1234,

[0081] "otherColumn": {

[0082] "yx_value": 1,

[0083] "regionId": "420112",

[0084] "feeder_id": "3799912185620001363",

[0085] "event_time": 1670083200000,

[0086] ...[Other attributes]

[0087] },

[0088] "alarmContent": "December 7, 2022, 17:25:22 10kV Test Line 10kV Doumen Line 154 101 Test Switch Operation Change Time [December 4, 2022, 00:00:00]",

[0089] "alarmStatus": 90

[0090] }

[0091] Furthermore, in step 8, the alarm interface specification is used to assemble the remote signaling change message, alarm metadata, and model information into an alarm message.

[0092] The alarm time (alarmTime) is the time when the remote signaling event changes during step 4.

[0093] The alarm type (alarmType) is determined by querying the alarm type and subtype from the multi-level cache based on the KeyId and attribute name.

[0094] The caching, querying, and updating processes and methods for alarm status (alarmStatus) are consistent with those for alarm types.

[0095] The alarm regionId is the regionId parsed from the remote signaling change message.

[0096] The alarm remote signaling value yx_value is the value parsed from the remote signaling change message.

[0097] The alarm remote signal change time event_time is the time parsed from the remote signal change message.

[0098] The feeder_id of the alarm is the feeder_id parsed from the remote signaling change message.

[0099] The alarm's otherColumn field is defined as shown in the interface data format, including yx_value, regionId, feeder_id, event_time, and other attributes. These other attributes are fields in the primary device model attribute list cached in the first-level cache static area with the table number as the key. The values ​​corresponding to these fields are the model information corresponding to the model attribute list retrieved from the database based on the id and table number parsed from the remote signaling change message, as described in step 6.

[0100] The alarm content field, alarmContent, is composed of multiple fields: alarm time, feeder name, switch name, and alarm status change time. The alarm time is the current time when the remote signaling change message is received. The feeder name is the name obtained from the feeder_id parsed from the remote signaling change message using the method mentioned in step 4. The switch name is the name obtained from the id parsed from the remote signaling change message using the method mentioned in step 4. The alarm status and change time are taken from the alarmStatus and yx_value fields, respectively.

[0101] The regionId is parsed from the remote signaling change message to indicate the region to which it belongs, and the time is parsed to indicate the time of the alarm remote signaling change.

[0102] The alarm type is retrieved from the multi-level cache based on the KeyId and attribute name, and the subtype is populated with the alarm type. When retrieving the alarm type from the multi-level cache, the alarm subtype is first retrieved from the first-level cache. If the alarm subtype exists, it is taken as the alarm type. If the alarm subtype does not exist, the alarm parent type is retrieved from the first-level cache as the alarm type. The alarm parent type must exist.

[0103] Other alarm fields refer to the fields in the primary device model attribute list cached in the first-level cache static area. Different table numbers correspond to different attribute lists. These fields correspond to model information queries as in step 5, and then the retrieved model information is used as the other alarm fields to fill in the data.

[0104] This invention provides a method for processing real-time alarm data using a multi-level caching scheme based on a microservice architecture. It includes the architecture and operation process of multi-level caching, as well as the real-time alarm data processing process.

[0105] like Figure 1The multi-level cache shown includes a first-level cache (Caffeine) and a second-level cache (Redis), which are managed by a multi-level cache client. This multi-level cache client is an implementation of a subclass of the abstract class AbstractValueAdaptingCache in Spring. The three static areas, dynamic areas, and real-time areas in the first-level cache are three instances of the multi-level cache client.

[0106] The multi-level caching client is characterized by its ability to perform batch queries of primary equipment model information and real-time updates of alarm metadata in the first-level cache Caffeine. The batch query process for primary equipment model data is as follows: Figure 2 In sections 1.1-1.7, when querying model data based on a multi-level cache using KeyId, the system prioritizes querying the first-level cache. If the model data is found, it is returned. If the model data is not found, it then queries the second-level cache. If the model data is not found in the second-level cache, it then queries the database. When caching the retrieved device model information data into the multi-level cache, if the model data is retrieved from the database, it is first cached in the second-level cache, and then asynchronously cached in the first-level cache using a thread pool. This reduces database query operations in distributed multi-instance scenarios. If the model data is retrieved from the second-level cache, it is directly cached in the first-level cache asynchronously using a thread pool.

[0107] The real-time update process of alarm definition metadata in the first-level cache is as follows: Figure 2 As shown in Figures 2.1-2.3, when a user manipulates alarm definition metadata on the alarm definition page, the data is persisted to the database, and the alarm definition metadata in the second-level cache is modified asynchronously. An alarm definition metadata change message is also sent to the second-level cache message queue. In a distributed environment with multiple instances, a second-level cache message listener is implemented. When each instance hears an alarm definition metadata change message in the second-level cache message queue, it deletes or updates the alarm definition metadata in the first-level cache of the current instance, thereby ensuring the consistency and real-time performance of the alarm definition metadata stored in the first-level cache of each instance.

[0108] This invention provides a real-time alarm processing method that supports high concurrency through multi-level caching. Taking into full account the characteristic that distributed stream computing engines cannot cache large amounts of data, it combines a microservice architecture with multi-level caching technology, enabling local service instances to cache large amounts of hot data while ensuring the consistency of this important data. This solves the performance bottleneck problem caused by high-frequency database queries when alarms are generated from massive remote signaling and telemetry data processing, and greatly improves the throughput of massive real-time alarm processing.

[0109] The multi-level cache in this invention supports batch caching and batch querying of diverse data and multi-lifecycle data. It also supports real-time updates and synchronization of alarm metadata in dynamic areas of multi-instance first-level caches in a distributed environment. Based on a microservice architecture, this invention integrates a multi-level caching framework (Redis + Caffeine) to greatly improve the throughput of real-time processing of massive alarms and significantly reduce the access pressure on the database and distributed cache.

[0110] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A real-time alarm processing method supporting high concurrency with multi-level caching, characterized in that: Includes the following steps: Step 1: Query the alarm definition metadata from the database and initialize the alarm definition metadata into the multi-level cache; Step 2: Monitor the Alarm Definition Metadata Change Topic in Redis, and consume the Alarm Definition Metadata Change messages in the Alarm Definition Metadata Change Topic session; Step 3: Parse the alarm definition metadata change message and update the alarm definition metadata in the multi-level cache; Step 4: Monitor the remote signaling event change topic in Kafka, and consume the remote signaling event change messages of the primary device in the remote signaling event change topic; Step 5: Extract the KeyId attribute from the remote signaling change message, and obtain the device model information from the multi-level cache based on the KeyId attribute; Step 6: If the model information of the device corresponding to the current change message does not exist in the multi-level cache, then query the model information of the current device from the database based on the KeyId attribute; Step 7: Cache the device model information retrieved from the database into a multi-level cache; Step 8: Combine the remote signaling change message with the device model information according to the alarm interface specification to form an alarm message; The alarm definition metadata in step 1 refers to the alarm type and alarm status used in the power distribution cloud master station system. Alarm types are divided into alarm parent types and alarm subtypes. When setting alarm types, if a subtype exists, the subtype is used; if the subtype does not exist, the parent type is used. The alarm parent type is a built-in type of the system and does not support customization. It is stored in the alarm type definition table. Alarm subtypes support customization and are stored in the alarm subtype definition table. Step 3 includes: When alarm definition metadata is manipulated on the alarm definition page, the data is persisted to the database, the alarm definition metadata in the second-level cache is modified asynchronously, and an alarm definition metadata change message is sent to the second-level cache message queue. When Redis detects a change in alert definition metadata in the second-level cache message queue, it deletes or updates the alert definition metadata in the first-level cache of the current instance. Step 5 includes: Parse the remote signaling change message of the primary device to obtain the device's $id, which is composed of table number, domain number, and record number as the KeyId attribute. This is a Long type data. When querying the current device's model information from the multi-level cache, first parse the table number and domain number of $id. Then, use Key[table number] to query the list of model attribute names corresponding to that table number from the first-level cache. Loop through the data names in the attribute list and use Key[KeyId@model attribute name] to query the device model information from the multi-level cache. The querying of device model information from the multi-level cache using Key[KeyId@model attribute name] includes: When a data query is triggered, device model data is retrieved from the first-level cache. If the data is found, it is returned. If the data is not found, device model data is retrieved from the second-level cache. If the data is found, the model data is returned first. Then, use a thread pool to asynchronously update the first-level cache; if a cache miss occurs, continue to query the device model data from the database. After the queried device model data is returned, use a thread pool to asynchronously update the device model data to the second-level cache first, and then update it to the first-level cache.

2. The real-time alarm processing method supporting high concurrency with multi-level caching as described in claim 1, characterized in that: The multi-level cache in step 1 includes: a first-level cache and a second-level cache; the first-level cache uses Caffeine, and the second-level cache uses Redis.

3. The real-time alarm processing method supporting high concurrency with multi-level caching according to claim 2, characterized in that: The first-level cache includes: a static region, a dynamic region, and a real-time region; The static area caches model attribute information data. This data is not discarded or expired. It is loaded during the project initialization phase and does not change during runtime. The dynamic area caches alarm definition metadata. This data is not evicted or expired. It is loaded during the project initialization phase and dynamically updated during runtime by listening to alarm definition metadata change messages from Redis. Data cached in the real-time area has a short lifespan and is subject to an expiration policy. It stores the model information of the primary device.

4. The real-time alarm processing method supporting high concurrency with multi-level caching as described in claim 1, characterized in that: Step 1, which initializes the alarm definition metadata into the multi-level cache, includes: During the project startup phase, query the alarm parent type definition table, using the event type as the key and the alarm parent type as the value, and store it in a multi-level cache; query the alarm subtype definition table, using the event type@table number@domain number@remote signaling value as the key and the alarm subtype as the value, and store it in a multi-level cache.

5. The real-time alarm processing method supporting high concurrency with multi-level caching according to claim 1, characterized in that: Redis, as a message middleware, supports channel-based publish / subscribe and schema-based publish / subscribe, enabling all instances to consume alarm definition metadata change messages in distributed multi-instance scenarios.

6. The real-time alarm processing method supporting high concurrency with multi-level caching according to claim 1, characterized in that: In step 4, Kafka is a distributed publish-subscribe messaging system. The remote information event change topic is a Kafka session topic used to store remote information change messages. Producers publish messages to Kafka topics, and consumers consume messages published by producers by subscribing to topics in Kafka.

7. A real-time alarm processing method supporting high concurrency with multi-level caching as described in claim 1, characterized in that: In step 4, the remote signaling change message of a primary device is a string message. The format of the remote signaling change message of a primary device is $id $feederId $termId $trArea $mainType $value $status $time $specialFlag $regionId, with the fields separated by spaces. Among them, $id is the device ID, $feederId is the feeder ID, $termId is the communication terminal ID, $trArea is the region ID, $mainType is the event type, $value is the remote signaling value, $status is the status setting, $time is the remote signaling change time, $specialFlag is the remote signaling change type, and $regionId is the device region.

8. A real-time alarm processing method supporting high concurrency with multi-level caching as described in claim 2, characterized in that: Step 6 includes: when there is no device model information in the multi-level cache, query the model information from the database device using an SQL statement with the table number parsed from $id as the table name and the list of model attribute names retrieved from the first-level cache using the table number as the field name.

9. A real-time alarm processing method supporting high concurrency with multi-level caching as described in claim 1, characterized in that: Step 7 includes: The model information is stored in a multi-level cache with KeyId@model attribute name as the key and the specific attribute value as the value.

10. A real-time alarm processing method supporting high concurrency with multi-level caching according to claim 2, characterized in that: Step 8 includes: The regionId is parsed from the remote signaling change message to indicate the region to which it belongs, and the time is parsed to indicate the alarm remote signaling change time. The alarm type is retrieved from the multi-level cache based on the KeyId and attribute name, and the subtype is populated. When retrieving the alarm type from the multi-level cache, the alarm subtype is first retrieved from the first-level cache. If the alarm subtype exists, it is taken as the alarm type. If the alarm subtype does not exist, the alarm parent type is retrieved from the first-level cache as the alarm type. The alarm other fields are fields in the primary device model attribute list cached in the first-level cache static area. Different table numbers correspond to different attribute lists. By querying device model information from the multi-level cache, the retrieved device model information is used as the alarm other fields to populate.

Images