Change event processing method and device, electronic equipment and program product

Abstract

The invention discloses a distributed service change event processing method, which comprises the following steps: continuously acquiring change events from an upstream service, and generating a corresponding version number for each newly acquired change event; associating and storing the change event and the corresponding version number into a first data set, wherein the first data set adopts a key value pair structure; continuously monitoring the state of the downstream service processing change event; when the notification that the downstream service finishes processing the first change event is monitored, the version number of the first change event is recorded into a second data set, and the second data set adopts a key-value pair structure; and determining a to-be-processed second change event of the downstream service based on the first data set and the second data set at least under a preset condition. According to the embodiment of the invention, a high-availability change event processing scheme is provided, and the change event can be prevented from being lost under the condition of a short-time high-intensity change event.

Description

Technical Field

[0001] The present disclosure relates to the field of computer application technology, and in particular to a change event processing method, device, electronic device and program product. Background Art

[0002] Currently, many business application services in a distributed platform / cluster usually have certain business processing dependencies based on distributed coordination services. The distributed coordination service monitors event changes of upstream services and notifies downstream services for processing.

[0003] However, when faced with a short-term, high-intensity change event notification from upstream services, downstream services face a serious problem of missing change events due to the discontinuity of the existing distributed coordination service monitoring mechanism. In some scenarios, when downstream services crash abnormally, the current distributed coordination service cannot trace back the unprocessed change events during the downtime of the downstream service, causing abnormal processing of downstream services and consistency issues.

[0004] Therefore, a highly available change event processing solution is urgently needed to solve the problem of downstream service loss of change events in the above-mentioned high-intensity upstream event change notification scenario.

[0005] The content of this background technology description is only for facilitating understanding of the relevant technology in this field and is not regarded as an admission of the prior art. Summary of the invention

[0006] The embodiments of the present disclosure aim to provide a distributed service change event processing method and device, electronic device, and program product, which can alleviate or solve at least one of the technical problems mentioned above.

[0007] In a first aspect, an embodiment of the present disclosure provides a distributed service change event processing method, which may include:

[0008] Continuously obtain change events from upstream services and generate corresponding version numbers for each newly obtained change event;

[0009] The change event and the corresponding version number are associated and stored in a first data set, where the first data set adopts a key-value pair structure;

[0010] Continue to monitor the status of downstream services processing change events;

[0011] When a notification that the downstream service has completed processing the first change event is monitored, the version number of the first change event is recorded in a second data set, where the second data set adopts a key-value pair structure;

[0012] At least under a preset condition, based on the first data set and the second data set, a second change event to be processed by the downstream service is determined.

[0013] Optionally, the storing the change event and the corresponding version number in association with each other in the first data set includes:

[0014] Recording the version number and content of the change event in the value of the primary key corresponding to the change event in the first data set;

[0015] The recording the version number of the first change event into the second data set includes:

[0016] Record the version number of the first change event and the name of the downstream service that processes the change event in the value of the mapping key corresponding to the first change event in the second data set, where the mapping key corresponds to the primary key corresponding to the first change event in the first data set.

[0017] Optionally, the determining, based on the first data set and the second data set, a second change event to be processed by the downstream service includes:

[0018] Read the latest version number from the value of the primary key in the first data set;

[0019] Read the last processed version number from the value of the mapping key in the second data set;

[0020] Determining a version number range of a second change event to be processed according to the latest version number and the last processed version number;

[0021] sorting the version numbers within the version number range;

[0022] Based on the sorting, corresponding change events are sequentially acquired from the first data set as second change events to be processed by the downstream service.

[0023] Optionally, the determining, based on the first data set and the second data set, a second change event to be processed by the downstream service includes:

[0024] Comparing the value of the primary key in the first data set with the value of the mapping key in the second data set, thereby identifying a version number of a change event to be processed, where the version number of the change event to be processed exists in the first data set but does not exist in the second data set;

[0025] Determine the primary key corresponding to the identified version number;

[0026] Get the change event content according to the determined primary key value;

[0027] A second change event to be processed by the downstream service is determined according to the acquired change event content.

[0028] Optionally, the method further comprises:

[0029] Continuously monitoring the status of the first data set;

[0030] When an update of the primary key in the first data set is monitored, a change event to be processed by the downstream service is determined based on the version number recorded in the value of the updated primary key.

[0031] Optionally, the change event includes the upstream service creating a new configuration or updating a configuration;

[0032] Wherein, each of the configurations corresponds to one primary key, and the content of the updated configuration is recorded in the value of the primary key;

[0033] The downstream service uses one or more of the configurations when processing a change event.

[0034] Optionally, the preset condition includes at least one of a primary key in the first data set being updated, a mapping key in the second data set being updated, and a mapping key in the second data set not being updated within a predetermined time threshold.

[0035] In a third aspect, an embodiment of the present disclosure provides a distributed service change event processing device, which may include:

[0036] The acquisition unit is used to continuously obtain change events from upstream services;

[0037] A generation unit, used to generate a corresponding version number for each newly acquired change event;

[0038] A first storage unit, used to associate and store the change event and its version number into a first data set, wherein the first data set adopts a key-value pair structure;

[0039] The monitoring unit is used to continuously monitor the status of downstream service processing change events;

[0040] The second storage unit is used to record the version number of the current first change event into a second data set when monitoring the notification that the downstream service has completed processing the first change event, wherein the second data set adopts a key-value pair structure;

[0041] A determining unit is configured to determine, at least under a preset condition, a second change event to be processed by a downstream service based on the first data set and the second data set.

[0042] In a third aspect, an embodiment of the present disclosure provides an electronic device, which may include: a processor and a memory storing a computer program, wherein the processor is configured to implement the method described in the first aspect when running the computer program.

[0043] In a fourth aspect, an embodiment of the present disclosure provides a program product, including a computer program, wherein when the computer program is executed by a processor, the method described in the first aspect is implemented.

[0044] The distributed service change event processing method of the embodiment of the present disclosure can continuously obtain change events from upstream services, and generate a corresponding version number for each newly obtained change event; associate the change event and its version number and store it in a first data set, the first data set adopts a key-value pair structure; continuously monitor the status of the downstream service processing the change event; when the notification that the downstream service has completed processing the first change event is monitored, the version number of the first change event is recorded in a second data set, the second data set adopts a key-value pair structure; at least under preset conditions, based on the first data set and the second data set, determine the second change event to be processed by the downstream service. The above method of the embodiment of the present disclosure ensures the effective storage and processing of change events, avoids the loss of change events, ensures the correct acquisition of change event content, and ensures the uniqueness and sequentiality of events. At the same time, the method of the above further embodiment of the present disclosure also realizes that after the downstream service is shut down and restarted, it can accurately locate the pending events that were not processed during the downtime, and further ensures the effective processing of change events.

[0045] Other optional features and technical effects of the embodiments of the present disclosure are partially described below, and partially can be understood by reading this document. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. The elements shown are not limited by the proportions shown in the accompanying drawings. The same or similar reference numerals in the accompanying drawings represent the same or similar elements, wherein:

[0047] Figure 1 A schematic diagram of the architecture of a business change event processing system based on distributed application coordination services is shown;

[0048] Figure 2 A schematic diagram of the processing flow of a business change event processing system based on a distributed application coordination service is shown;

[0049] Figure 3 A first flow chart of a distributed service change event processing method according to an embodiment of the present disclosure is shown;

[0050] Figure 4 A second flow chart of the distributed service change event processing method according to an embodiment of the present disclosure is shown;

[0051] Figure 5 A third flow chart of the distributed service change event processing method according to an embodiment of the present disclosure is shown;

[0052] Figure 6 A schematic diagram of a processing flow of a business change event processing system based on a distributed application coordination service according to an embodiment of the present disclosure is shown;

[0053] Figure 7 A fourth flow chart of the distributed service change event processing method according to an embodiment of the present disclosure is shown;

[0054] Figure 8 An exemplary structural diagram showing a distributed service change event processing device according to an embodiment of the present disclosure; and

[0055] Fig. 9 An exemplary structural diagram of an electronic device capable of implementing the distributed service change event processing method according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0056] In order to make the purpose, technical solution and advantages of the present disclosure more clear, the present disclosure is further described in detail below in conjunction with specific implementation methods and drawings. Here, the illustrative implementation methods and descriptions of the present disclosure are used to explain the present disclosure, but are not intended to limit the present disclosure.

[0057] As used herein, the term "including" and its variations mean open inclusion, i.e., "including but not limited to". Unless otherwise stated, the term "or" means "and / or". The term "based on" means "based at least in part on". The terms "an example embodiment" and "an embodiment" mean "at least one example embodiment". The term "another embodiment" means "at least one some embodiments". The terms "first", "second", etc. may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0058] In the embodiments of the present disclosure, the upstream service does not refer to certain fixed services. The upstream service can be dynamically determined according to the relationship between the change events between the distributed services. In other words, a service can be used as an upstream service or a downstream service when it is involved in different change events. In one example, service A is an upstream service when it is involved in a certain change event, and at the same time, service A is a downstream service when it is involved in another change event.

[0059] In current distributed application systems, multiple business application services usually have business processing dependencies based on distributed coordination services. Upstream business application services notify downstream business application services by writing distributed coordination service change events. However, since the monitoring mechanism of distributed coordination services is non-persistent, serious change event loss problems may occur in some scenarios.

[0060] refer to Figure 1, which shows a distributed application system based on Zookeeper, in which the upstream service can write the change event into Zookeeper, and the downstream service monitors the upstream service through Zookeeper. When the monitored upstream service has a change event, the upstream service sends a change event notification to the downstream service through Zookeeper. In response to the change event notification, the downstream service reads the change event in Zookeeper and performs corresponding processing.

[0061] However, in this distributed application system, when the monitored upstream service changes frequently in a short period of time and issues change event notifications, or the downstream service crashes and restarts abnormally, the downstream service may suffer from serious change event loss.

[0062] In a specific example, refer to Figure 2 , which shows a processing flow of a business change event processing system: the downstream service registers a listener (Watcher) in Zookeeper at time t1 to listen to the change events of the upstream service. The listener is one-time. When the change event e1 is listened to, the listener becomes invalid and triggers the read logic preset by the downstream service. Since there is a system processing delay from the triggering of the read logic preset by the downstream service to the actual execution of the read operation, the downstream service starts to read Zookeeper to obtain the change event at time t2. Since Zookeeper only saves the latest data status, only the change event e2 is saved in Zookeeper at time t2. At this time, the downstream service can only read the change event e2 for processing, and the change event e1 is lost.

[0063] After the downstream business application service re-registers a new listener at t3 and starts listening again, when it listens to the change event e3, the listener becomes invalid and triggers the preset reading logic of the downstream service. The downstream service starts reading Zookeeper to obtain the change event at t4. Since Zookeeper only saves the latest data status, only the change event e4 is saved in Zookeeper at t4. Then the new listener is re-registered at t5. Therefore, the downstream service cannot perceive the change event e5 generated between t4 and t5. Finally, the downstream service only reads the change event e4 for processing. Not only does it lose the change event e3, but it also fails to read the latest change event e5.

[0064] Continuing with the previous example, at time t6, the downstream service crashes abnormally. During the crash, when the listener registered in Zookeeper listens to the change event e6, the listener becomes invalid. However, the downstream service cannot read the event or re-register a new listener. When the downstream service restarts at time t7 and re-registers a new listener, the downstream business application service can only obtain the change event e8 after time t7 for processing, but loses the change events e6 and e7 during the crash.

[0065] It can be seen that in this processing flow, there are problems such as only obtaining the latest change event and losing some of the change events in the middle, obtaining a change event that is not the latest and losing some of the change events in the middle, and losing the change events during downtime. The root cause of the above problems is that the monitoring mechanism of the Zookeeper client is one-time and non-persistent. After the downstream business application service monitors the change event, it needs to reset the monitoring. This results in the downstream application service being unable to perceive these changes and causing the change event to be lost if a change event occurs between the end of the last monitoring and the start of the next monitoring.

[0066] In this regard, the embodiments of the present disclosure propose a high-availability solution, which can be combined with a distributed key-value storage system to at least partially solve the above-mentioned problems, ensuring that downstream business application services will not lose change events even in the case of frequent event notifications, and ultimately all change event content can be obtained and processed.

[0067] In some embodiments of the present disclosure, a distributed service change event processing method is provided, which can be applied to distributed application systems, such as Figure 3 As shown, the method may include at least the following 310~350.

[0068] 310: Continue to obtain change events from upstream services and generate a corresponding version number for each newly obtained change event.

[0069] In some embodiments of the present disclosure, an upstream service may register one or more configurations in a distributed key-value storage system, and the change operation of the upstream service on the configuration may be called a change event, wherein the change operation includes but is not limited to creating a new configuration or updating an existing configuration, and the downstream service may monitor at least one configuration through the distributed key-value storage system. In this embodiment, when the upstream service changes the configuration, such as creating a configuration or updating an existing configuration in the distributed key-value storage system, the distributed key-value storage system stores the content of the change event, and uses the version control mechanism to generate a unique change event version number for the change event, and at the same time notifies the downstream service that monitors the configuration to process the change event.

[0070] In this embodiment, when the downstream service monitors the change event, it can obtain the corresponding change event content and update its own data, wherein the change event content includes but is not limited to the change data identifier, the data before the change, the data after the change, and the change event timestamp, etc. It should be pointed out that in the above process, the specific operation logic of the upstream service generating the change event and the downstream service processing the change event is decoupled. In other words, the upstream service does not interfere with how the downstream service specifically processes the change event generated by the upstream service.

[0071] In the disclosed embodiment, the unique change event version number can be generated by the version control mechanism of the distributed key-value storage system according to the change operation request or notification from the upstream service. In one example, the distributed key-value storage system is ETCD (full name Etcd Extended Distributed Consistency), and the version control mechanism of ETCD can be used to generate a unique change event version number. In some other embodiments, a distributed key-value storage system such as Redis, MongoDB, Cassandra, etc. can also be used to generate a unique change event version number. In this embodiment, the change event version number is, for example, but not limited to, a sequentially increasing version number based on the timestamp of the change event. In a specific example, for change events A and B, ETCD can generate a unique change event version number "20000101T123456789Z" for change event A and a unique change event version number "20000101T123456799Z" for change event B. However, it can be understood that in other embodiments, the unique change event version number can also be generated based on other rules or combined with rules and random numbers.

[0072] In this embodiment, the version control mechanism can manage the version number based on a preset historical version retention policy, wherein the historical version retention policy can be defined and set based on at least one of time, number of version numbers, time and number of version numbers. In one example, the historical version retention policy can be defined and set based on time, including but not limited to retaining all versions within a specific time period. In a specific example, it can be set to retain all version numbers within the last 7 days. In another example, the historical version retention policy can be defined and set based on the number of version numbers, for example, retaining the latest N version numbers, where N is the version number threshold. In a specific example, the version number threshold can be set to 100, that is, retaining the latest 100 version numbers. In another example, the historical version retention policy can be defined and set based on time and number of version numbers, for example, retaining versions within the last specific time period, and the total number of version numbers does not exceed N. In a specific example, for example, it can be set to retain the latest 1000 version numbers within 7 days.

[0073] In some embodiments, it is possible to consider controlling the size of the version retention period to improve the efficiency of determining the change events to be processed. In this embodiment, in order to avoid the phenomenon that the change event corresponding to the version number is not processed when the version retention period is reached or the version number needs to be removed, in some embodiments of the present disclosure, when the retention period of any version number or some version numbers is about to arrive, it is also possible to check whether the change event corresponding to the version number has been processed downstream. If not, the change event corresponding to the version is sent to the downstream system, and the downstream system is notified to process it within a predetermined time. And after receiving feedback from the downstream system that the processing is completed within the predetermined time, the version number will be deleted or not retained. In some examples, the predetermined time can be determined according to the event processing time of the downstream system, for example, the predetermined time is one or more times the preset processing time of the target change event to be processed, such as the predetermined time is 1.0 times, 1.5 times or 2.0 times the preset processing time of the target change event. In one example, the preset processing time can be determined based on the processing time of historical change events that are the same as or of the same type as the target change event, such as the preset processing time is the average processing time for processing historical change events, or the weighted time of the average processing time, and the weighting coefficient can be 1.0-1.5. In a specific application, the sum of the time of issuing the target change event and the scheduled time should be earlier than the arrival time of the retention period of the target change event. For example, the time of issuing the target change event is 10:00:00:00 on January 1, 2000, the arrival time of the retention period is 10:10:00:00 on January 1, 2000, and the preset processing time is 1.0 minute, then the scheduled time should be not less than 1.0 minute and less than 10.0 minutes.

[0074] In other embodiments of the present disclosure, when the version control mechanism needs to remove a version number in the first data set according to the historical version retention policy, the version control mechanism may also check whether the version number exists in the second data set. In this embodiment, if the version number does not exist in the second data set, the downstream service may be notified again for processing, and the version number may be retained during a preset retention period, and the version number may be checked at preset time intervals to see whether it exists in the second data set; if the version number exists in the second data set, the version number may be removed. In this embodiment, when it is determined that the version number still does not exist in the second data set after the preset retention period, an alarm may be issued to remind the downstream service that the change event processing is abnormal.

[0075] Through the above method, the embodiment of the present disclosure can avoid as much as possible the phenomenon that the change event corresponding to the version number is not processed due to the expiration of the version retention period or the need to remove the version number, thereby avoiding the problem of change event loss as much as possible.

[0076] 320: Associate the change event and the corresponding version number and store them in a first data set, where the first data set adopts a key-value pair structure.

[0077] In the disclosed embodiment, the key-value pair is a data structure including a key and a corresponding value. In this embodiment, the change event and its version number are, for example, the change event obtained in 310 and the unique change event version number corresponding to the change event.

[0078] In some embodiments of the present disclosure, the change event and its corresponding version number are associated and stored in a first data set, and the first data set adopts a key-value pair structure, which may include: recording the version number and content of the change event in the value of the primary key corresponding to the change event in the first data set.

[0079] As previously described, the upstream service may have one or more configurations registered in the distributed key-value storage system. In some embodiments of the present disclosure, each of the configurations corresponds to a primary key, wherein the primary key can be used to uniquely identify a configuration maintained by the upstream service in the first data set. In one example, when the upstream service creates a new configuration, a corresponding new primary key may be created for the new configuration in the first data set. In some examples, if the new configuration is subsequently updated, the updated content may be recorded in the value of the primary key corresponding to the new configuration. In some embodiments of the present disclosure, when or after creating a new primary key in the first data set, a mapping key uniquely corresponding to the primary key may also be created in the second data set, which will be described in detail below.

[0080] In some embodiments of the present disclosure, the value of the primary key can be used to record the content of the change event that occurs when the upstream service updates the configuration. In one example, when the upstream service changes the configuration, the version number and content of the change event can be recorded in the value of the primary key of the configuration corresponding to the change event in the first data set. As described above, a mapping key that uniquely corresponds to the primary key can be created in the second data set. When the change event recorded in the value of the primary key corresponding to the mapping key is processed by the downstream service, the version number of the change event will be recorded in the value of the mapping key, which will be described in detail below.

[0081] In some embodiments of the present disclosure, after an upstream service registers one or more configurations in a distributed key-value storage system, the one or more configurations may be maintained by one or more upstream services, and the present disclosure does not limit this. In this embodiment, the one or more configurations may be monitored by one or more downstream services, wherein the downstream services may use one or more of the configurations when processing change events, and the present disclosure does not limit this either.

[0082] In this embodiment, the primary key may include unique identification information of the configuration and optionally the environment of the configuration (such as a production environment, a test environment, etc.), regional information of the configuration (such as a data center), etc., wherein the unique identification information is, for example, the configuration name of the configuration, the unique identification code of the configuration, or a combination of the configuration name of the configuration and the unique identification code, etc., and the present disclosure does not impose any restrictions on this.

[0083] In a specific example, the primary key used to uniquely identify configuration 1 in the first data set is " / production / dc-east-1 / config_1 / 123456", where "production" is the environment corresponding to configuration 1, "dc-east-1" is the data center corresponding to configuration 1, "config_1" is the name of configuration 1, and "123456" is the unique identification code corresponding to configuration 1. In this embodiment, the value of the corresponding change event A recorded in the value (Value) of the primary key " / production / dc-east-1 / config_1 / 123456" is: ""user_id": "1234", "old_score": "70", "new_score": "75", "timestamp":"2000-01-01T12:34:56:780Z","version":"20000101T123456780Z"", where ""user_id": "1234"" represents that the change object identifier is 1234, ""old_score": "70"" represents that the data before the change is 70, ""new_score": "75"" represents that the data after the change is 75, and "timestamp":"2000-01-01T12:34:56:780Z","version":"20000101T123456780Z"". "2000-01-01T12:34:56:780Z" represents that the change timestamp is 2000-01-01T12:34:56:780Z, and "version": "20000101T123456780Z" represents that the unique change event version number corresponding to the change event A is 20000101T123456780Z. It should be understood that in the above embodiment, only a part of the value of one of the primary keys included in the first data set is shown, and the first data set may include more primary keys. The value of any of the primary keys may include the version numbers and contents of multiple change events configured corresponding to the primary key, and can be managed using the historical version retention period as described in 310.

[0084] In the embodiments of the present disclosure, for example in the above 310~320, a key-value pair structure is used to store change events and their version numbers, allowing corresponding change events to be quickly retrieved by key. At the same time, the key-value pair storage structure supports multiple data types as values, and the stored data structure can be flexibly adjusted according to actual needs.

[0085] 330: Continue to monitor the status of downstream services processing change events.

[0086] In the disclosed embodiment, the status update information of the downstream service processing the change event can be continuously obtained, including the unique change event version number of the change event being processed by the downstream service and the processing result, etc. In one example, when the downstream service completes the processing of the change event, the downstream service can return the unique change event version number of the processed change event to the distributed key-value storage system, thereby enabling monitoring of the status of the downstream service processing the change event.

[0087] 340: When a notification that the downstream service has completed processing the first change event is monitored, the version number of the first change event is recorded in the second data set.

[0088] In an embodiment of the present disclosure, the unique change event version number of the first change event returned by the downstream service and processed can be recorded in the second data set. In this embodiment, the second data set adopts a key-value pair structure.

[0089] In some embodiments of the present disclosure, recording the version number of the first change event in the second data set may include: recording the version number of the first change event and the name of the downstream service that processes the change event in the value of the mapping key corresponding to the first change event in the second data set, wherein the mapping key corresponds to the primary key corresponding to the first change event in the first data set.

[0090] In this embodiment, the mapping key can be used to uniquely identify the configuration corresponding to the change event processed by the downstream service, and the value of the mapping key can be used to record the change event of the configuration processed by the downstream service, such as the version number of the processed change event and the name of the downstream service. In this embodiment, each change event processed by the downstream service corresponds to a mapping key, that is, corresponds to a configuration.

[0091] In this embodiment, the mapping key may include unique identification information of a configuration processed by the downstream service, etc. In this embodiment, the unique identification information is, for example, the primary key of the corresponding configuration in the first data set in the aforementioned 320 includes unique identification information, so that the primary key corresponding to the mapping key can be quickly retrieved in the aforementioned first data set based on the unique identification information. In this embodiment, by combining the primary key with the mapping key, even in the case of abnormal shutdown and restart of the downstream service, the version number of the change event to be processed can be quickly determined and the change event to be processed can be accurately located, thereby ensuring the continuity of upstream and downstream services, and quickly restoring normal change event processing, thereby ensuring the high availability of the entire system. Referring to the description of the relevant specific embodiment in the aforementioned 320, in a specific example, the mapping key used in the second data set to uniquely identify the configuration corresponding to the processed change event is " / config_1 / 123456 / ", where "config_1" is the configuration 1 corresponding to the processed change event, and "123456" is the unique identification code corresponding to configuration 1. In this embodiment, the value (Value) of the change event A processed by the corresponding downstream service B recorded in the mapping key " / config_1 / 123456 / " is: "version": "20000101T123456780Z", "service_name": "service_B", wherein "version": "20000101T123456780Z" represents that the unique change event version number corresponding to the processed change event A is 20000101T123456780Z, and "service_name": "service_B" represents that the name of the downstream service processing the change event A is service_B. It should be understood that in the above embodiment, only a part of the value of one of the mapping keys included in the second data set is shown, and the second data set may include more mapping keys, and the value of any of the mapping keys may include the version numbers of multiple processed change events of the configuration corresponding to the mapping key and the name of the downstream service processing the change event, and can be managed using the historical version retention period as described in 310.

[0092] 350: Determine, at least under a preset condition, based on the first data set and the second data set, a second change event to be processed by the downstream service.

[0093] In some embodiments of the present disclosure, for example, in the above 350, the preset condition may include the following sub-conditions: the primary key in the first data set is updated, the mapping key in the second data set is updated, and the mapping key in the second data set is not updated within a predetermined time threshold. It should be understood that in the embodiments of the present disclosure, the preset condition may include at least one of the above sub-conditions or a combination of at least two of the above sub-conditions, which falls within the protection scope of the present disclosure. In one example, the preset condition is, for example: the primary key in the first data set is updated, and the mapping key in the second data set is not updated within a predetermined time threshold.

[0094] As an explanation but not limitation, referring to the relevant description in the aforementioned 320, when the primary key in the first data set is updated, it means that a new change event from the upstream is obtained. At this time, the new second change event to be processed by the downstream service can be determined in time based on the first data set and the second data set. Referring to the relevant description in the aforementioned 340, when the mapping key in the second data set is updated, it means that the downstream service has completed processing a certain first change event. At this time, the second change event to be processed by the downstream service can be updated in time based on the first data set and the second data set. When the mapping key in the second data set is not updated within the predetermined time threshold, it means that the downstream service processes the change event abnormally, or the downstream service crashes and restarts. At this time, the second change event to be processed by the downstream service can be determined in time based on the first data set and the second data set. In other embodiments, the predetermined time threshold can be one or more, such as 0.5 seconds, 1 second, and 5 seconds. It should be understood that the time threshold can be set accordingly according to the processing capacity of the downstream service in the distributed application system, and the present disclosure does not limit the specific value of the time threshold.

[0095] In other embodiments of the present disclosure, the preset condition may also include: monitoring a notification of a restart of a downstream service. In this embodiment, the downstream service is configured to monitor its own running status, and when a restart is detected, a restart notification may be sent to the distributed application system, and the distributed application system may respond to the notification and determine a second change event to be processed by the downstream service based on the first data set and the second data set.

[0096] refer to Figure 4 In some embodiments of the present disclosure, for example, in the above 350, determining the second change event to be processed by the downstream service based on the first data set and the second data set may at least include the following 351~355.

[0097] 351: Read the latest version number from the value of the primary key in the first data set.

[0098] In the embodiment of the present disclosure, the version numbers of all change events stored in the first data set can be queried, and the latest version number can be determined therein. In one example, the first data set is, for example, the first data set in the aforementioned 320. In a specific example, the version numbers in the values ​​of all primary keys stored in the first data set can be queried using the ETCD API, and the latest generated version number can be found therein as the latest version number. Through the aforementioned 351, the latest version numbers of all change events can be read.

[0099] 352: Read the last processed version number from the value of the mapping key in the second data set.

[0100] In an embodiment of the present disclosure, the version numbers of all the change events processed by the downstream services stored in the second data set can be queried, and the last processed version number can be determined from the version numbers of the processed change events. In an example, the second data set is, for example, the second data set in 340 above.

[0101] 353: Determine a version number range of a second change event to be processed according to the latest version number and the last processed version number.

[0102] In the disclosed embodiment, the latest version number obtained can be compared with the version number last processed by the downstream service. In this embodiment, as described above, the version number generated by the version control mechanism of the distributed key-value storage system can be incremented in sequence, thereby determining that the upper limit of the version number range of the change event to be processed is the above-mentioned latest version number and the lower limit is the version number last processed by the above-mentioned downstream service. In a specific embodiment, the latest version number in the first data set obtained by ETCD query is 20000101T123456780Z, and the version number last processed by the downstream service obtained by query is 20000101T123456760Z, then the version number range of the change event to be processed is (20000101T123456760Z, 20000101T123456780Z).

[0103] 354: Sort version numbers within a version number range.

[0104] In some embodiments of the present disclosure, by way of explanation and not limitation, although the version number may be generated incrementally, and the version number range of the second change event to be processed may be determined based on the latest version number and the last processed version number. However, when actually querying and obtaining multiple version numbers from the first data set, it cannot be guaranteed that the version numbers are all returned in ascending order, and the order of the version numbers actually obtained may be out of order. In a specific example, when querying for version numbers within the version number range (20000101T123456760Z, 20000101T123456780Z), the multiple version numbers to be processed obtained are "20000101T123456770Z, 20000101T123456765Z, 20000101T123456772Z".

[0105] However, in some distributed application systems, there may be a time sequence relationship between the change events generated by the upstream services, and the change events need to be processed in order to avoid errors in business services. As an example and not a limitation, in a specific example, the downstream service is a transaction management service, and the change event content corresponding to the version number "20000101T123456765Z" of the change event to be processed by the downstream service is "The remaining amount of financial product A is modified to: 10000.00", and the change event content corresponding to the version number "20000101T123456770Z" is "The sales status of financial product A is modified to: Sold out". When the change events corresponding to the version numbers 20000101T123456765Z and 20000101T123456770Z are not processed in order, for example, when the change event corresponding to the version number 20000101T123456770Z is processed first, the user may be mistakenly prohibited from subscribing to financial products with a remaining balance.

[0106] Accordingly, in the embodiment of the present disclosure, for example, in the above 354, all version numbers within the determined version number range may be extracted and sorted, for example, in ascending order, etc. In a specific example, the obtained version numbers "20000101T123456770Z, 20000101T123456765Z, 20000101T123456772Z" are sorted in ascending order to obtain "20000101T123456765Z, 20000101T123456770Z, 20000101T123456772Z".

[0107] 355: Based on the sorting, corresponding change events are sequentially obtained from the first data set as second change events to be processed by the downstream service.

[0108] In the disclosed embodiment, the change event content corresponding to the version number can be obtained from the first data set according to the sorted version number sequence, and the downstream service can be notified in the sequence to process the change event. In a specific example, continuing with the above example, the downstream service can be notified in sequence according to the ascending version number to process the change events corresponding to the version numbers 20000101T123456765Z, 20000101T123456770Z, and 20000101T123456772Z.

[0109] In the embodiment of the present disclosure, by first determining the version number range of the second change event to be processed based on the latest version number and the last processed version number, and then sorting the version numbers within the version number range and notifying the downstream service in sequence to process the change events, it is possible to ensure that all change events are correctly processed according to the actual sequence of their occurrence, thereby ensuring the correct and stable operation of business services in the distributed application system.

[0110] In some embodiments of the present disclosure, after notifying the downstream service to process the change event, the status of the downstream service processing the change event can be continuously monitored, and the value in the mapping key in the aforementioned second data set can be updated in a timely manner. For the specific description of monitoring and updating the second data set, please refer to the aforementioned description of 330~340, which will not be repeated here.

[0111] In other embodiments of the present disclosure, for different business scenarios, the method of determining the second change event to be processed by the downstream service may be different. For example, in some business scenarios, there may be no time sequence relationship between the change events generated successively by the upstream service. Figure 5 The step of determining the change event to be processed by the downstream service based on the first data set and the second data set may also include at least the following 351'-354'.

[0112] 351': Compare the value of the primary key in the first data set with the value of the mapping key in the second data set to identify the version number of the second change event to be processed, which exists in the first data set but not in the second data set.

[0113] In the embodiment of the present disclosure, all primary key values ​​in the first data set may be traversed, the version number therein may be determined, and then it may be checked whether it exists in the value of the mapping key of the second data set.

[0114] 352': Determine the primary key corresponding to the identified version number.

[0115] In the embodiment of the present disclosure, the primary key corresponding to the version number of the second change event to be processed may be determined in the first data set, wherein the version number of the second change event to be processed is determined by the aforementioned 351 ′, for example.

[0116] 353': Get the change event content according to the determined primary key value.

[0117] In the embodiment of the present disclosure, the corresponding change event content may be read from the first data set according to the primary key corresponding to the version number of the change event to be processed.

[0118] 354': Determine a second change event to be processed by the downstream service according to the acquired change event content.

[0119] In the disclosed embodiment, the acquired change event content can be combined with the corresponding unique change event version number of the change event as the change event to be processed by the downstream service. In this embodiment, the determined change events to be processed can be optionally sorted, and the downstream service is notified to process the change event in the order of the sorting.

[0120] In some specific embodiments of the present disclosure, reference Figure 6 , which shows a processing flow of a business change event according to an embodiment of the present disclosure: the downstream business application service crashes at time t1 and restarts monitoring the upstream service at time t2. At this time, the distributed key-value storage system queries and obtains the second data set, and determines the version number of the latest recorded change event in the value of the mapping key in the second data set (the last processed version number), and compares it with all version numbers in the value of the primary key corresponding to the mapping key in the first data set. It is found that the version numbers corresponding to the change events e4, e5, and e6 exist in the value of the primary key in the first data set, but do not exist in the value of the mapping key in the second data set. Therefore, e4, e5, and e6 are determined to be change events to be processed, and the notification is sorted according to the version number. The downstream business application service processes the change events e4, e5, and e6 in turn.

[0121] In some embodiments of the present disclosure, for example, in the above 350, reference Figure 7 The distributed service change event processing method may also include at least the following steps 360~370.

[0122] 360: Continue to monitor the status of the first data set.

[0123] In an embodiment of the present disclosure, the change of the value of the primary key in the first data set can be continuously monitored. In one example, the change of the value of the primary key in the first data set can be continuously monitored using a monitoring mechanism of the distributed key-value storage system.

[0124] 370: When an update of the primary key in the first data set is monitored, a second change event to be processed by the downstream service is determined based on the version number recorded in the value of the updated primary key.

[0125] In an embodiment of the present disclosure, when a change in the value of the primary key in the first data set is monitored, the downstream service may be notified to process the change event based on the version number and content of the change event recorded in the updated primary key value.

[0126] The distributed service change event processing method of the embodiment of the present disclosure can continuously obtain change events from upstream services, and generate a corresponding version number for each newly obtained change event; the change event and the corresponding version number are associated and stored in a first data set, and the first data set adopts a key-value pair structure; the status of the downstream service processing the change event is continuously monitored; when the notification that the downstream service has completed the processing of the current change event is monitored, the version number of the current change event is recorded in a second data set, and the second data set adopts a key-value pair structure; at least under preset conditions, based on the first data set and the second data set, the change event to be processed by the downstream service is determined. The above method of the embodiment of the present disclosure ensures the effective storage and processing of change events, avoids the loss of change events, and ensures the uniqueness and sequentiality of events. At the same time, the method of the above further embodiment of the present disclosure can further accurately locate the unprocessed pending events during the downtime after the downstream service is restarted, effectively avoiding the loss of change events.

[0127] The following will further describe the distributed service change event processing method disclosed in the present invention in combination with several specific embodiments:

[0128] In a specific embodiment of the present disclosure, the distributed service change event processing method of the embodiment of the present disclosure can be used in a scenario where risk assessment is performed based on user behavior parameters. In this scenario, the behavior data recording service in the distributed system will update the behavior data of the account in real time based on the account's behavior, such as consumption behavior and financial behavior. Whenever the behavior data of the account changes, a change event related to the behavior data will be generated. The risk decision service can obtain the change event and perform risk assessment on the account in a timely manner based on the change in the account behavior data, such as adjusting the risk level of the account. In this embodiment, the behavior data recording service is an upstream service of the risk assessment service, and the risk assessment service is a downstream service of the behavior data recording service. The risk assessment service uses ETCD to monitor the change events of the behavior data recording service.

[0129] In this embodiment, the behavior data recording service maintains configuration 1 in ETCD. ETCD monitors that the behavior data recording service changes configuration 1 at time "2000 / 01 / 01 / 12:34:56:780". The content of change event A is: ""user_id": "1234", "old_score": "70", "new_score": "75", "timestamp": "2000-01-01T12:34:56:780Z"". At this time, ETCD generates a unique change event version number "20000101T123456780Z" for it according to its event timestamp. This step can refer to the aforementioned description of 310.

[0130] At the same time, the specific content of the change event A is stored in the first data set in the form of a key-value pair, where the primary key is " / production / dc-east-1 / config_1 / 123456", and the value corresponding to the primary key is the content of the change event A and the unique change event version number of the change event ""user_id": "1234", "old_score": "70", "new_score": "75", "timestamp": "2000-01-01T12:34:56:780Z", "version": "20000101T123456780Z"". As a result, the change event A from the upstream behavior data recording service is persistently stored in the first data set. This step can refer to the aforementioned description of 320.

[0131] In the above process, ETCD continuously monitors the status of the risk assessment service processing change events. When the risk assessment service completes processing of change event A, ETCD can receive the version number "20000101T1234Z" of the processed change event A returned by the risk assessment service. At this time, ETCD adds a record "version": "20000101T123456780Z", "service_name":" service_C" to the value of the mapping key " / config_1 / 123456 / " corresponding to the change event A in the second data set. For this step, please refer to the above description of 330-340.

[0132] During this process, ETCD also continues to monitor the value changes of the primary key " / production / dc-east-1 / config_1 / 123456" in the first data set. When the value of the primary key is updated, it determines the change event to be processed by the risk assessment service based on the version number recorded in the updated primary key value. For this step, refer to the above description of 360~370.

[0133] In this embodiment, the above steps ensure that the change event of the behavior data recording service can be timely included in the risk decision, thereby improving the accuracy and timeliness of risk control.

[0134] In another specific embodiment of the present disclosure, the distributed cluster includes a transaction execution service, an account limit update service, and a transaction report generation service, wherein the transaction execution service generates transaction execution events in real time according to the user's financial behavior, and each time a new transaction is executed, a change event related to the transaction execution is generated, and the account limit update service and the transaction report generation service can obtain the change event and perform corresponding processing in a timely manner according to the transaction information, such as updating the user account limit and generating a transaction report. In this embodiment, the transaction execution service is an upstream service of the account limit update service and the transaction report generation service, and the account limit update service and the transaction report generation service are downstream services of the transaction execution service, and the account limit update service and the transaction report generation service use ETCD to monitor the change event of the transaction execution service.

[0135] In this embodiment, the transaction execution service maintains configuration 2 in ETCD. ETCD monitors that the transaction execution service changes configuration 2 at time "2020 / 02 / 02 / 14:45:56:780". The content of change event B is: ""order_id": "O78901", "user_id": "U111", "items": [{"product_id": "P1", "quantity": 2}, {"product_id": "P2", "quantity": 1}], "total_amount": 159.99, "timestamp": "2024-02-02T14:45:56:780Z"". At this time, ETCD generates a unique change event version number "20000202T144556780Z" for it according to its event timestamp. This step can refer to the aforementioned description of 310.

[0136] At the same time, the specific content of the change event B is stored in the first data set in the form of a key-value pair, where the primary key is " / production / dc-east-2 / config_2 / 234567 / ", and the value corresponding to the primary key is the content of the change event B and the unique change event version number of the change event ""order_id": "O78901", "user_id": "U111","items": [{"product_id": "P1", "quantity": 2}, {"product_id": "P2", "quantity": 1}], "total_amount": 150, "timestamp": "2000-02-02T14:45:56:780Z", "version": "20000202T144556780Z"". As a result, the change event B from the upstream transaction execution service is persistently stored in the first data set. For this step, refer to the aforementioned description of 320.

[0137] In the above process, ETCD continuously monitors the status of the account limit update service and the transaction report generation service processing change events. When the account limit update service completes processing of change event B, ETCD receives the processed change event B version number "20000202T144556780Z" returned by the account limit update service at 2020 / 02 / 02 / 14:45:56:800. At this time, ETCD adds a record ""version": "20000202T144556780Z", "service_name": "inventory_service"" to the value of the mapping key " / config_2 / 234567 / " corresponding to the change event B in the second data set. Similarly, when the transaction report generation service completes processing of change event B, ETCD can receive the processed change event B version number "20000202T144556780Z" returned by the account limit update service. At this time, ETCD adds "version": "20000202T144556780Z" and "service_name": "logistics_service"" to the value of the mapping key " / config_2 / 234567 / " in the second data set. For the above steps, please refer to the description of 330-340 above.

[0138] After processing the above change event B, the account limit update service crashed due to an abnormality. During the crash, ETCD monitored that the transaction execution service changed configuration 2 at time "2020 / 02 / 02 / 14:45:56:900". The content of the change event C is: ""order_id": "O78902", "user_id": "U222", "items": [{"product_id": "P2","quantity": 3}, {"product_id": "P3", "quantity": 2}], "total_amount": 200, "timestamp": "2024-02-02T14:45:56:900Z"". At this time, ETCD generated a unique change event version number 20000202T144556900Z for it according to its event timestamp. For this step, please refer to the above description of 310.

[0139] Similarly, the specific content of the change event C is stored in the first data set in the form of a key-value pair, where the primary key is " / production / dc-east-2 / config_2 / 234567 / ", and the value corresponding to the primary key is the content of the change event C and the unique change event version number of the change event.

[0140] During this process, the transaction report generation service processes the change event normally. The steps of processing the change event C are similar to those in the above embodiment and will not be repeated here.

[0141] When the Account Limit Update Service restarts monitoring the Transaction Execution Service, ETCD detects that the mapping key in the second data set has not been updated for 1.0 second since it was updated at 2020 / 02 / 02 / 14:45:56:800. ETCD reads the value of the primary key " / production / dc-east-2 / config_2 / 234567 / " in the first data set at 2020 / 02 / 02 / 14:45:57:800, and reads the mapping key " / config_2 / 234567 / " in the second data set. 567 / ", confirming that the version number "20000202T144556900Z" only exists in the value of the above primary key of the first data set, and does not exist in the value of the mapping key corresponding to the account limit update service in the second data set, thereby determining that "20000202T144556900Z" is a pending change event for the account limit update service, and the version number "20000202T144556900Z" in the primary key value of the first data set and the change event content corresponding to the version number are changed to the content of event C: ""order_id": "O78902", "user_id": "U222", "items": [{"product_id": "P2", "quantity":3}, {"product_id": "P3", "quantity": 2}], "total_amount": 200, "timestamp": "2024-02-02T14:45:56:900Z"” to notify the account limit update service for processing.

[0142] In this embodiment, the above method ensures that the transaction execution event is delivered to the relevant downstream services in a timely manner, and monitors the processing progress of multiple downstream services at the same time. Even after the downstream service is restarted, the transaction execution event that is not processed by the downstream service can be accurately found, ensuring that no transaction execution event processing steps are missed, thereby improving the efficiency and reliability of transaction execution event processing.

[0143] In some embodiments of the present disclosure, a distributed service change event processing device 800 is also provided, including an acquisition unit 810, a generation unit 820, a first storage unit 830, a monitoring unit 840, a second storage unit 850, and a determination unit 860. Among them:

[0144] The acquisition unit 810 is configured to continuously acquire change events from upstream services.

[0145] The generating unit 820 is configured to generate a corresponding version number for each newly acquired change event.

[0146] The first storage unit 830 is configured to associate and store the change event and the corresponding version number in a first data set, and the first data set adopts a key-value pair structure.

[0147] The monitoring unit 840 is configured to continuously monitor the status of downstream service processing change events.

[0148] The second storage unit 850 is configured to record the version number of the first change event into a second data set when monitoring the notification that the downstream service has completed processing the first change event. The second data set adopts a key-value pair structure.

[0149] The determining unit 860 is configured to determine, at least under a preset condition, a second change event to be processed by a downstream service based on the first data set and the second data set.

[0150] In some embodiments of the present disclosure, Fig. 9 As shown, a schematic diagram of an electronic device 900 that can implement the method of the disclosed embodiment is provided, and in some embodiments, more or fewer electronic devices than shown may be included. In some embodiments, it can be implemented using a single or multiple electronic devices. In some embodiments, it can be implemented using cloud or distributed electronic devices.

[0151] like Fig. 9 As shown, the electronic device 900 includes a processor 901, which can perform various appropriate operations and processes according to the programs and / or data stored in the read-only memory (ROM) 902 or the programs and / or data loaded from the storage part 908 to the random access memory (RAM) 903. CPU 901 can be a multi-core processor or can include multiple processors. In some embodiments, the processor 901 can include a general main processor and one or more special coprocessors, such as a graphics processing unit (GPU), a neural network processor (NPU), a digital signal processor (DSP), etc. In RAM903, various programs and data required for the operation of the electronic device 900 are also stored. CPU 901, ROM 902 and RAM 903 are connected to each other via a bus 904. Input / output (I / O) interface 905 is also connected to bus 904.

[0152] The processor and the memory are used together to execute the program stored in the memory. When the program is executed by the computer, the steps or functions of the file transmission method described in the above embodiments can be implemented.

[0153] The following components are connected to the I / O interface 905: an input section 906 including a keyboard, a mouse, a touch screen, etc.; an output section 907 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, a modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the I / O interface 905 as needed. A removable medium 911, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 910 as needed, so that a computer program read therefrom is installed into the storage section 908 as needed. Fig. 9 Only some components are schematically shown in the figure, which does not mean that the computer system 900 only includes Fig. 9 Components shown.

[0154] In some embodiments, the electronic device 900 refers to a mobile terminal or a computer, including a mobile phone, a car terminal, a smart TV, etc. Taking a mobile phone as an example, the electronic device 900 also includes a display screen with a touch function, an external speaker, a gyroscope, a camera, a 4G / 5G antenna and other device modules.

[0155] The systems, devices, modules or units described in the above embodiments may be implemented by a computer or its associated components. The computer may be, for example, a mobile terminal, a smart phone, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a personal digital assistant, a media player, a navigation device, a game console, a tablet computer, a wearable device, a smart TV, an Internet of Things system, a smart home, an industrial computer, a server or a combination thereof.

[0156] Although not shown, in an embodiment of the present disclosure, a program product is provided, including a computer program, and when the computer program is executed by a processor, the method of any one of the embodiments of the present disclosure is implemented.

[0157] Although not shown, in an embodiment of the present disclosure, a storage medium is provided, the storage medium storing a computer program, the computer program being configured to implement any method of the embodiments of the present disclosure when executed.

[0158] The storage media in the embodiments of the present disclosure include permanent and non-permanent, removable and non-removable items that can be implemented by any method or technology to store information. Examples of storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0159] The methods, programs, systems, devices, etc. of the embodiments of the present disclosure may be executed or implemented in a single or multiple networked computers, or may be practiced in a distributed computing environment. In the embodiments of the present specification, in these distributed computing environments, tasks may be performed by remote processing devices connected via a communication network.

[0160] Those skilled in the art should understand that the embodiments of the present specification may be provided as methods, systems or computer program products. Therefore, those skilled in the art may imagine that the functional modules / units or controllers and related method steps described in the above embodiments may be implemented in software, hardware or a combination of software / hardware.

[0161] Unless explicitly stated, the actions or steps of the methods, programs, and embodiments of the present disclosure do not have to be performed in a specific order and can still achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0162] In this article, multiple embodiments of the present disclosure are described, but for the sake of brevity, the description of each embodiment is not exhaustive, and the same or similar features or parts between the embodiments may be omitted. In this article, "one embodiment", "some embodiments", "example", "specific example", or "some examples" are intended to be applicable to at least one embodiment or example according to the present disclosure, rather than all embodiments. The above terms do not necessarily mean to refer to the same embodiment or example. In the absence of contradiction, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples.

[0163] The exemplary systems and methods of the present disclosure have been specifically shown and described with reference to the above embodiments, which are merely examples of the best modes for implementing the present systems and methods. It will be appreciated by those skilled in the art that various changes may be made to the embodiments of the systems and methods described herein when implementing the present systems and / or methods without departing from the spirit and scope of the present disclosure as defined in the appended claims.

Claims

1. A distributed service change event processing method, characterized in that: include: Continuously obtain change events from upstream services and generate corresponding version numbers for each change event obtained; The change event and the corresponding version number are associated and stored in a first data set, where the first data set adopts a key-value pair structure; Continue to monitor the status of downstream services processing change events; When a notification that the downstream service has completed processing the first change event is monitored, the version number of the first change event is recorded in a second data set, where the second data set adopts a key-value pair structure; At least under a preset condition, based on the first data set and the second data set, a second change event to be processed by the downstream service is determined.

2. The distributed service change event processing method according to claim 1, characterized in that: The storing the change event and the corresponding version number in association with each other in the first data set includes: Recording the version number and content of the change event in the value of the primary key corresponding to the change event in the first data set; The recording the version number of the first change event into the second data set includes: Record the version number of the first change event and the name of the downstream service that processes the change event in the value of the mapping key corresponding to the first change event in the second data set, where the mapping key corresponds to the primary key corresponding to the first change event in the first data set.

3. The distributed service change event processing method according to claim 2, characterized in that: The determining, based on the first data set and the second data set, a second change event to be processed by the downstream service includes: Read the latest version number from the value of the primary key in the first data set; Read the last processed version number from the value of the mapping key in the second data set; Determining a version number range of a second change event to be processed according to the latest version number and the last processed version number; sorting the version numbers within the version number range; Based on the sorting, corresponding change events are sequentially acquired from the first data set as second change events to be processed by the downstream service.

4. The distributed service change event processing method according to claim 2 is characterized in that The determining, based on the first data set and the second data set, a second change event to be processed by the downstream service includes: comparing the value of the primary key in the first data set with the value of the mapping key in the second data set, thereby identifying a version number of a second change event to be processed, where the version number of the second change event to be processed exists in the first data set but does not exist in the second data set; Determine the primary key corresponding to the identified version number; Get the change event content according to the determined primary key value; A second change event to be processed by the downstream service is determined according to the acquired change event content.

5. The distributed service change event processing method according to claim 2, characterized in that: The method further comprises: Continuously monitoring the status of the first data set; When an update of the primary key in the first data set is monitored, a second change event to be processed by the downstream service is determined based on the version number recorded in the value of the updated primary key.

6. The distributed service change event processing method according to claim 2, characterized in that: The preset condition includes at least one of a primary key in the first data set being updated, a mapping key in the second data set being updated, and a mapping key in the second data set not being updated within a predetermined time threshold.

7. The distributed service change event processing method according to claim 2, characterized in that: The change event includes the upstream service creating a new configuration or updating a configuration; Wherein, each of the configurations corresponds to one primary key, and the content of the updated configuration is recorded in the value of the primary key; The downstream service uses one or more of the configurations when processing a change event.

8. A distributed service change event processing device, characterized in that: include: The acquisition unit is used to continuously obtain change events from upstream services; A generation unit, used to generate a corresponding version number for each newly acquired change event; A first storage unit, used to associate and store the change event and the corresponding version number into a first data set, wherein the first data set adopts a key-value pair structure; The monitoring unit is used to continuously monitor the status of downstream service processing change events; A second storage unit is configured to record the version number of the first change event into a second data set when a notification that the downstream service has completed processing the first change event is monitored, wherein the second data set adopts a key-value pair structure; A determining unit is configured to determine, at least under a preset condition, a second change event to be processed by a downstream service based on the first data set and the second data set.

9. An electronic device, characterized in that: include: A processor and a memory storing a computer program, wherein the processor is configured to implement the method according to any one of claims 1 to 7 when running the computer program.

10. A program product comprising a computer program, wherein: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images