Message management system for carbon sink management and carbon trading

Abstract

The present application discloses a message management system for carbon sink management and carbon trading, including: a carbon reduction regulator, which is used to issue carbon reduction indicators to carbon reduction implementers via a server; a carbon reduction implementer, which is used to receive the carbon reduction indicators issued by the carbon reduction regulator from the server, and settle the carbon reduction with the carbon reduction regulator through the server; an object tool corresponding to the carbon reduction implementer, which is used to provide work data to the server; an object user corresponding to the carbon reduction implementer, which is used to apply to the server for carbon credits / carbon reduction transfer; a server, which is used to calculate the carbon reduction based on the work data, upload the carbon reduction to a distributed ledger and obtain an upload certificate, and provide the newly added carbon credits / carbon reduction data to the object user of the carbon reduction implementer, receive the carbon credits / carbon reduction transfer application from the object user corresponding to the carbon reduction implementer, confirm the carbon credits / carbon reduction transfer with the object user corresponding to the carbon reduction implementer, and transfer the carbon credits / carbon reduction to the carbon reduction implementer.

Description

Technical Field

[0001] The present application relates to the field of green energy technology, and more specifically, to a message management system for carbon sink management and carbon trading. Background Art

[0002] Carbon sink refers to the process or activity of absorbing and storing carbon dioxide in the atmosphere through natural or artificial means. It can be natural ecosystems such as forests, oceans, and soil, or it can be human activities that increase carbon absorption through artificial planting of trees and improved land management. The main purpose of carbon sink management is to reduce the concentration of carbon dioxide in the atmosphere by increasing carbon absorption and storage, thereby alleviating global climate change. The process of carbon sink management mainly includes monitoring and reporting carbon absorption, ensuring the effectiveness and sustainability of carbon sinks, etc.

[0003] As an extension of carbon sink management, carbon trading is a market mechanism that encourages emission reduction activities by buying and selling carbon emission rights (carbon credits). Carbon trading allows companies to offset their own carbon emissions by purchasing carbon credits, thereby achieving emission reduction targets. Carbon sink management generates carbon credits by increasing carbon absorption, and carbon trading converts these carbon credits into economic value through market mechanisms, further stimulating the implementation and development of carbon sink projects.

[0004] However, considering that carbon sink management and carbon trading usually involve multiple parties, message management among them is of great importance to ensure the efficiency and security of information collection, transmission, storage, analysis and sharing, as well as the user-friendliness of interface design. Therefore, it is expected to provide an optimized message management system for carbon sink management and carbon trading. Summary of the invention

[0005] In order to solve the above technical problems, this application is proposed. The embodiment of this application provides a message management system solution for carbon sink management and carbon trading, which manages repeated requests from multiple parties by the server through a request cache management mechanism based on message commitment, thereby improving message management performance.

[0006] According to one aspect of the present application, a message management system for carbon sink management and carbon trading is provided, including: a carbon reduction regulator, for issuing carbon reduction indicators to carbon reduction implementers via a server; a carbon reduction implementer, for receiving the carbon reduction indicators issued by the carbon reduction regulator from the server, and settling carbon reductions with the carbon reduction regulator through the server; an object tool corresponding to the carbon reduction implementer, for providing work data to the server; an object user corresponding to the carbon reduction implementer, for applying to the server for a carbon credit / carbon reduction transfer; a server, for calculating the carbon reduction based on the work data, uploading the carbon reduction to a distributed ledger and obtaining an upload certificate, and providing newly added carbon credit / carbon reduction data to the object user of the carbon reduction implementer, receiving a carbon credit / carbon reduction transfer application from the object user corresponding to the carbon reduction implementer, confirming the carbon credit / carbon reduction transfer with the object user corresponding to the carbon reduction implementer, and transferring the carbon credit / carbon reduction to the carbon reduction implementer, so that the carbon reduction implementer can settle the carbon reduction with the carbon reduction regulator;

[0007] Among them, the message requests received by the server include constant message requests and variable message requests, and for the variable message requests, a message commitment for performing a callback of a response message is stored in the system memory, and the message commitment is used to process the callback of the response message based on the included states, sub-functions and methods; and the server further includes a request cache manager for performing repeated request management for the variable message request, using the identifier of the message initiator as the key and the message commitment corresponding to the message as the value.

[0008] In the above-mentioned message management system for carbon sink management and carbon trading, the constant message request includes user information and / or configuration data of the carbon reduction regulator, the carbon reduction implementer, the object tool corresponding to the carbon reduction implementer, and the object user corresponding to the carbon reduction implementer.

[0009] In the above-mentioned message management system for carbon sink management and carbon trading, the response message is pre-cached for the constant message request, so that when the constant message request corresponding to the request for the same request object is received next time, the response message is directly read from the cache.

[0010] In the above-mentioned message management system for carbon sink management and carbon trading, the variable message request includes the work data provided by the object tool corresponding to the carbon reduction implementer to the server, the new carbon credits / carbon reduction data provided by the server to the object user of the carbon reduction implementer, the carbon credits / carbon reduction transfer applied for by the object user corresponding to the carbon reduction implementer, and the carbon reduction settled by the carbon reduction implementer and the carbon reduction regulator.

[0011] In the above-mentioned message management system for carbon sink management and carbon trading, the commitment object includes three states: an ongoing state as an initial state, which is neither success nor failure; a successful state indicating that the operation is successfully completed; and a failed state indicating that the operation fails; the commitment object includes two sub-functions, respectively used to call and pass success information when the operation is successful, and a rejection sub-function used to call and pass error information when the operation fails; the commitment object includes three methods: a callback function for registration success and failure, including a callback function for success whose parameter is the value passed by the resolution sub-function, and a callback function for failure whose parameter is the value passed by the rejection sub-function; a callback function registered as empty that does not return a value; and a callback function that will be executed regardless of success or failure.

[0012] In the above-mentioned message management system for carbon sink management and carbon trading, for the variable message request, repeated request management is performed using the identifier of the message initiator as the key and the message commitment corresponding to the message as the value, including: creating a request management class for managing repeated requests for repeated requests, and initializing the class object container of the request management class as a storage container to store repeated requests and their corresponding message commitments; generating the identifier of the message initiator of the variable message request as the key of the request management class, and generating the value of the request management class with the message commitment corresponding to the variable message request; and, for requests with the same key, confirming whether it is a repeated request by returning the message commitment in the memory, directly returning the message commitment in the memory for caching, and further confirming the success or failure of the request through the commitment object status of the message commitment.

[0013] In the above-mentioned message management system for carbon sink management and carbon trading, the identifier of the message initiator of the variable message request is generated as the key of the request management class, and the value of the request management class is generated with the message commitment corresponding to the variable message request, including: generating the key of the request management class by calling the key generation function with the identifier of the message initiator of the variable message request, and for the initial empty option of the request for the request management class, extracting the commitment object method from the message commitment corresponding to the variable message request as the value.

[0014] In the above-mentioned message management system for carbon sink management and carbon trading, it further includes: when the request is successful, the message commitment of the request is deleted from the cache and the data is returned; when the request fails, the message commitment of the request is also deleted from the cache and an error is returned; only when there is a new request or a new message commitment is returned, the new message commitment is cached and returned as response data.

[0015] In the above-mentioned message management system for carbon sink management and carbon trading, the value of the request management class includes parameters related to the cache expiration time, error handling strategy and cache size limit promised by the message.

[0016] In the above-mentioned message management system for carbon sink management and carbon trading, the cache expiration time and cache size limit promised by the cached message are calculated by setting the product of the cache time and the cache size to a constant and the product of the probability value of the cache expiration time or the cache size limit corresponding to the constant; wherein the probability value is set to: based on experience, the cache expiration time and the cache size limit are calculated. After normalizing the maximum value of each sampling value, the cache expiration time or cache size limit is divided by the sum of the cache expiration time and the cache size limit to obtain the corresponding probability value. , and calculate the benchmark binary similarity, the benchmark binary similarity is used to represent the similarity between the interaction between the binary variables of the cache expiration time and the cache size limit and the normalized constant value; the interaction between the binary variables of the cache expiration time and the cache size at each sampling is regarded as an interactive cycle for the expansion of the normalized constant value, based on the sampling number is the cycle depth, obtaining a cross-cycle extension form of the benchmark binary similarity; and performing cross-reduction on the cross-cycle extension form of each cycle, and calculating the average to obtain the probability value.

[0017] Therefore, the message management system solution for carbon sink management and carbon trading provided in the embodiment of the present application can manage repeated requests from the server to multiple parties through a request cache management mechanism based on message commitment, thereby improving message management performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] By describing the embodiments of the present application in more detail in conjunction with the accompanying drawings, the above and other purposes, features and advantages of the present application will become more apparent. The accompanying drawings are used to provide a further understanding of the embodiments of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the present application and do not constitute a limitation of the present application. In the accompanying drawings, the same reference numerals generally represent the same components or steps.

[0019] Figure 1 The diagram illustrates a time flow diagram of an example of a message management system for carbon sink management and carbon trading according to an embodiment of the present application.

[0020] Figure 2 The diagram illustrates a working diagram of a request cache manager of a message management system for carbon sink management and carbon trading according to an embodiment of the present application. DETAILED DESCRIPTION

[0021] Figure 1 The diagram shows a time flow diagram of an example of a message management system for carbon sink management and carbon trading according to an embodiment of the present application. Figure 1 As shown, the carbon sink management system for cargo transportation includes multiple roles and links such as the supervisor, carbon reduction implementer, driver, server, heavy truck and distributed ledger. Among them, the carbon reduction supervisor is responsible for sending the carbon reduction index to the carbon reduction implementer via the server, and the carbon reduction implementer receives the carbon reduction index issued by the supervisor from the server, and settles the carbon reduction with the supervisor through the server. The object tool of the carbon reduction implementer, such as a truck, directly provides work data to the server, such as mileage, hydrogen consumption data, etc. After the server calculates the carbon reduction, on the one hand, it is uploaded to the distributed ledger and obtains the upload certificate, and on the other hand, the newly added carbon credits / carbon reduction data are provided to the object user of the carbon reduction implementer, such as the truck driver. When the object user, such as a truck driver, wants to apply for a carbon credit / carbon reduction transfer to the carbon reduction implementer, he will also apply for a carbon credit / carbon reduction transfer to the server. On the one hand, the server confirms the carbon credit / carbon reduction transfer to the driver, and on the other hand, it transfers the carbon credit / carbon reduction to the carbon reduction implementer, so that the carbon reduction implementer can settle the carbon reduction with the supervisor.

[0022] That is, the message management system for carbon sink management and carbon trading according to the embodiment of the present application includes: a carbon reduction regulator, which is used to issue carbon reduction indicators to carbon reduction implementers via a server; a carbon reduction implementer, which is used to receive the carbon reduction indicators issued by the carbon reduction regulator from the server, and settle the carbon reduction with the carbon reduction regulator through the server; an object tool corresponding to the carbon reduction implementer, which is used to provide work data to the server; a tool user corresponding to the carbon reduction implementer, which is used to apply to the server for carbon credits / carbon reduction transfer; a server, which is used to calculate the carbon reduction based on the work data, upload the carbon reduction to the distributed ledger and obtain the upload certificate, and provide the newly added carbon credits / carbon reduction data to the tool user of the carbon reduction implementer, receive the carbon credits / carbon reduction transfer application from the tool user corresponding to the carbon reduction implementer, confirm the carbon credits / carbon reduction transfer with the tool user corresponding to the carbon reduction implementer, and transfer the carbon credits / carbon reduction to the carbon reduction implementer, so that the carbon reduction implementer can settle the carbon reduction with the carbon reduction regulator.

[0023] It can be seen that in the above process, the server, as a message management intermediary for carbon sink management and carbon trading, is responsible for the management of messages from all parties. In the actual management process, the server does not manage all parties, such as carbon reduction implementers, drivers and heavy trucks, one-to-one, but needs to manage messages between multiple carbon reduction implementers, and more heavy trucks and drivers at the same time. In this process, even if multiplexing is used to reduce the impact of message requests and responses between multiple entities on message management performance, if the scale of the management project is expanded, there may still be too much network concurrency, especially when the same request message is loaded multiple times, resulting in message management IO (input and output) congestion, thereby affecting message management performance.

[0024] In order to solve this problem, in the message management system for carbon sink management and carbon trading according to the embodiment of the present application, various message requests are first divided into constant message requests and variable message requests, wherein, for constant message requests, that is, message requests involving some data that do not change frequently, such as user information and configuration data of each party, the response message as the request result can be pre-cached by the system, and the response message contains the response data, for example, the query request message for user information corresponds to the response message containing the user identity data. In this way, when the same data is requested next time, the response message can be directly read from the cache.

[0025] That is, in the message management system for carbon sink management and carbon trading according to the embodiment of the present application, the response message is pre-cached for the constant message request, so that when the constant message request corresponding to the request for the same request object is received next time, the response message is directly read from the cache.

[0026] Of course, in the embodiment of the present application, for the cache response message involved in the constant message request, its response data can also be further compared with the latest response data. If the response data has not changed, it means that the cache is valid and the response message can be directly read from the cache. On the contrary, if the response data has changed, it means that the cache is invalid and the constant message request needs to be processed as a variable message request.

[0027] On the other hand, in an embodiment of the present application, for variable message requests, that is, message requests involving data that often changes, such as the various numerical data involved above, including mileage and hydrogen consumption data sent by the truck, new carbon credits / carbon reduction data provided by the server to the driver, carbon credits / carbon reduction transfers applied by the driver to the carbon reduction implementer, and carbon reduction applied for settlement by the carbon reduction implementer to the regulator, etc., the corresponding data will change after each message request as a reporting request. Therefore, both subsequent query requests and new reporting requests involve updated data, and thus the response message will also change. In this case, in an embodiment of the present application, the system cache is not used to directly cache the response message, but a corresponding message promise is stored in the system memory for the variable message request to perform a callback of the corresponding response message, thereby improving the request-based response message return call.

[0028] That is, in the message management system for carbon sink management and carbon trading according to the embodiment of the present application, the message requests received by the server include constant message requests and variable message requests, and a message commitment for performing a callback of a response message is stored in the system memory for the variable message request, and the message commitment is used to process the callback of the response message based on the included states, sub-functions and methods.

[0029] Specifically, message promises are used in asynchronous programming to use promise objects to handle the results of asynchronous operations, which can better handle the problem of nested callback functions. Here, the promise object represents an asynchronous operation that will eventually complete (or fail) and its results. Among them, the promise object contains three states, namely Pending: the initial state, neither success nor failure; Fulfilled: the operation is successfully completed; Rejected: the operation failed. In addition, the promise object also contains two sub-functions, resolve and reject, which are used to indicate the success and failure of the operation respectively. If the operation is successful, resolve is called and the success information is passed, and if the operation fails, reject is called and the error information is passed. In addition, the promise object usually contains three methods, which are the processing methods of the callback function, for example, they are expressed as: then(onFulfilled, onRejected): register the callback functions for success and failure, where onFulfilled is the callback function for success, and the parameter is the value passed by resolve, and onRejected is the callback function for failure, and the parameter is the value passed by reject; catch(onRejected): register a callback function as empty, which is equivalent to then(null, onRejected), that is, no value is returned; finally(onFinally): a callback function that will be executed regardless of success or failure.

[0030] That is, by using message promises to handle asynchronous message sending operations, the results of asynchronous operations can be better managed and processed through message promises rather than directly through response messages. The message promise object provides richer response options through its states, sub-functions, and methods to handle different stages of asynchronous operations, which can make asynchronous message processing more efficient in server management and operation.

[0031] Based on this, in the embodiment of the present application, repeated request management can also be performed through message commitment. That is, in the network communication environment between the carbon reduction implementer and the driver, and the heavy truck and the server, the problem of repeated requests may be caused by poor communication. According to the carbon sink management system for cargo transportation in the embodiment of the present application, repeated requests can be managed by setting a request cache manager, that is, if there is the same request, that is, the same message initiator, the same commitment object state and the same commitment object method, only one system memory call is initiated, and then the results can be distributed to all waiting repeated requests, or sent to the request closest in time.

[0032] Specifically, the request cache manager may exist as a key-value object for repeated requests, where the object uses a unique identifier of the request, such as an initiator ID, as a key and a corresponding message commitment as a value.

[0033] That is, in the message management system for carbon sink management and carbon trading according to the embodiment of the present application, the server further includes a request cache manager, which is used to manage repeated requests for the variable message request, using the identifier of the message initiator as the key and the message commitment corresponding to the message as the value.

[0034] In one example, a request management class is first created for repeated requests to manage repeated requests and avoid unnecessary repeated requests. In addition, a class object container is initialized as a storage container to store requests and their corresponding message commitments.

[0035] Then, a unique identifier of the request is generated as the key of the request management class, and the value of the request management class is generated based on the corresponding message commitment, including the message commitment state and the message commitment method. Of course, in actual applications, it may also be necessary to consider distinguishing different message types to set other parameters. For example, the key of the request management class is generated by calling the key generation function with the ID of the message initiator, and for the initial empty option of the request management class for the request, the commitment object method is extracted from the request commitment corresponding to the request as the value.

[0036] For requests with the same key, the existing message promise in memory can be returned to confirm whether it is a duplicate request, and the message promise in memory can be directly returned for caching, and the request success or failure can be further confirmed through the promise object status. If the request is successful, the message promise of the request is deleted from the cache and the data is returned. If the request fails, the message promise of the request also needs to be deleted from the cache and an error is returned. Only when there is a new request or a new message promise is returned, the new message promise is cached and returned as the response data.

[0037] That is, in the message management system for carbon sink management and carbon trading according to the embodiment of the present application, for the variable message request, repeated request management is performed with the identifier of the message initiator as the key and the message commitment corresponding to the message as the value, including: creating a request management class for managing repeated requests for repeated requests, and initializing the class object container of the request management class as a storage container to store repeated requests and their corresponding message commitments; generating the identifier of the message initiator of the variable message request as the key of the request management class, and generating the value of the request management class with the message commitment corresponding to the variable message request; and, for requests with the same key, confirming whether it is a repeated request by returning the message commitment in the memory, directly returning the message commitment in the memory for caching, and further confirming the success or failure of the request through the commitment object status of the message commitment.

[0038] Furthermore, in the above-mentioned message management system for carbon sink management and carbon trading, the identifier of the message initiator of the variable message request is generated as the key of the request management class, and the value of the request management class is generated with the message commitment corresponding to the variable message request, including: generating the key of the request management class by calling the key generation function with the identifier of the message initiator of the variable message request, and for the initial empty option of the request for the request management class, extracting the commitment object method from the message commitment corresponding to the variable message request as the value.

[0039] In addition, the above-mentioned message management system for carbon sink management and carbon trading further includes: when the request is successful, the message commitment of the request is deleted from the cache and the data is returned; when the request fails, the message commitment of the request is also deleted from the cache and an error is returned; and, only when there is a new request or a new message commitment is returned, the new message commitment is cached and returned as response data.

[0040] In this way, for example, when there are multiple repeated requests, only the first request will generate a request management class and cache the message promise, and the subsequent requests will be directly obtained by the request management class from the cache to return data, and no new message promise call will be initiated. In addition, by setting the message promise in the cache to be deleted when the request succeeds or fails, the effective use of the system cache can also be ensured.

[0041] That is, the request management class caches message commitments corresponding to repeated requests, avoiding unnecessary repeated requests and improving performance and user experience, that is, by generating a unique identifier as the key of the request management class, it ensures that the same request reuses message commitments.

[0042] Of course, those skilled in the art will also understand that the above only gives an example of performing repeated request management through internal object mapping via a request management class. In actual applications, for example, for different request message types, the corresponding parameters of the request management class can be set as needed. For example, the cache expiration time promised by the message, error handling strategy, cache size limit, etc. can be set.

[0043] Among them, cache expiration time and cache size limit are a pair of contradictory parameters, that is, a larger cache size limit requires a shorter cache expiration time, while a larger cache size limit allows a longer cache expiration time.

[0044] Therefore, in the embodiment of the present application, the product of the cache time and the cache size can be set to a constant, and the cache time and the cache size can be calculated by multiplying the constant with a probability value greater than zero and less than one. In addition, considering that the dimensions of the cache time and the cache size are different, when performing the calculation, the cache time and the cache size are also converted to the interval [0,1], for example, by using the maximum value normalization method, then the constant is also normalized to one accordingly.

[0045] In this way, by empirically adjusting the cache time and cache size, times sampling, where the The sampling needs to be targeted at different request types and corresponding promised cache conditions. In this way, the corresponding probability value can be calculated for each sampling. , and calculate the baseline binary similarity, expressed as:

[0046]

[0047] It is used to represent the similarity between the interaction between the binary variables of cache time and cache size and the ideal output, that is, the normalized constant value.

[0048] Furthermore, if the interaction between the binary variables of cache time and cache size at each sampling is considered as an unrolled interaction loop for the ideal output, then As the loop depth, we can get the cross-loop expansion form of the base binary similarity:

[0049]

[0050] Finally, for each cycle of the cross-loop expansion form, the cross-reduction idea is used, that is, multiplying the cross-probability difference, normalizing it with the maximum value, and then calculating the average, the required probability value can be obtained, for example, expressed as:

[0051]

[0052] That is, considering the diversity of request and commitment states in each experience sampling, and the high relative error in the absence of a benchmark, each cycle sampling is treated as a subsystem with poor correlation with each other to consider dynamic cyclic changes based on the existing global irrelevance, thereby approximating a strongly correlated state through cross-interaction.

[0053] Of course, those skilled in the art can understand that if the results of each sampling are not much different, that is, the system itself is in a strong correlation state, the average of the sampling results can be directly taken.

[0054] In general, the request cache manager of the message management system for carbon sink management and carbon trading according to the embodiment of the present application is similar to Figure 2 If Figure 2 As shown, for multiple repeated requests, based on the message commitment mechanism, the request cache manager is used to merge the repeated requests to send a call request for response data to the server, and respond to the multiple requests through the cached message commitment. Figure 2 The diagram illustrates a working diagram of a request cache manager of a message management system for carbon sink management and carbon trading according to an embodiment of the present application.

[0055] The basic principles of the present application are described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, effects, etc. mentioned in the present application are only examples and not limitations, and it cannot be considered that these advantages, strengths, effects, etc. are required by each embodiment of the present application. In addition, the specific details disclosed above are only for the purpose of illustration and ease of understanding, not for limitation, and the above details do not limit the present application to being implemented by adopting the above specific details.

[0056] The block diagrams of the devices, apparatuses, equipment, and systems involved in this application are only illustrative examples and are not intended to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagram. As will be appreciated by those skilled in the art, these devices, apparatuses, equipment, and systems can be connected, arranged, and configured in any manner. Words such as "including", "comprising", "having", etc. are open words, referring to "including but not limited to", and can be used interchangeably with them. The words "or" and "and" used here refer to the words "and / or" and can be used interchangeably with them, unless the context clearly indicates otherwise. The words "such as" used here refer to the phrase "such as but not limited to", and can be used interchangeably with them.

[0057] It should also be noted that in the apparatus, device and method of the present application, each component or each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present application.

[0058] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the present application. Therefore, the present application is not intended to be limited to the aspects shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

[0059] The above description has been given for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present application to the forms disclosed herein. Although multiple example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, changes, additions and sub-combinations thereof.

Claims

1. A message management system for carbon sink management and carbon trading, characterized in that: include: Carbon reduction supervisors are used to send carbon reduction indicators to carbon reduction implementers via the server; The carbon reduction implementer receives the carbon reduction indicators issued by the carbon reduction regulator from the server and settles the carbon reduction with the carbon reduction regulator through the server; The object tool corresponding to the carbon reduction implementer is used to provide work data to the server; The target user corresponding to the carbon reduction implementer is used to apply for carbon credits / carbon reduction transfer from the server; A server is used to calculate the carbon reduction amount based on the work data, upload the carbon reduction amount to the distributed ledger and obtain the upload certificate, and provide the newly added carbon credits / carbon reduction amount data to the target user of the carbon reduction implementer, receive the carbon credits / carbon reduction amount transfer application from the target user corresponding to the carbon reduction implementer, confirm the carbon credits / carbon reduction amount transfer with the target user corresponding to the carbon reduction implementer, and transfer the carbon credits / carbon reduction amount to the carbon reduction implementer, so that the carbon reduction implementer can settle the carbon reduction amount with the carbon reduction regulator; The message request received by the server includes a constant message request and a variable message request, and a message commitment for performing a callback of a response message is stored in a system memory for the variable message request, wherein the message commitment is used to process the callback of the response message based on the included state, sub-function and method; and The server further comprises a request cache manager for managing repeated requests for the variable message request using the identifier of the message initiator as a key and the message commitment corresponding to the message as a value; Wherein, for the variable message request, using the identifier of the message initiator as a key and the message commitment corresponding to the message as a value to perform repeated request management includes: Creating a request management class for managing repeated requests for repeated requests, and initializing a class object container of the request management class as a storage container to store repeated requests and their corresponding message commitments; generating an identifier of a message initiator of the variable message request as a key of the request management class, and generating a value of the request management class with a message commitment corresponding to the variable message request; and For requests with the same key, confirm whether it is a duplicate request by returning the message promise in memory, directly return the message promise in memory for caching, and further confirm the success or failure of the request through the promise object status of the message promise; The value of the request management class includes parameters related to the cache expiration time, error handling strategy and cache size limit promised by the message; The cache expiration time and cache size limit promised for the cached message are calculated by setting the product of the cache time and the cache size to a constant and the product of the probability value of the cache expiration time or the cache size limit corresponding to the constant. Wherein, the probability value is set as: Based on experience, the cache expiration time and the cache size limit are limited. After normalizing the maximum value of each sampling value, the cache expiration time or cache size limit is divided by the sum of the cache expiration time and the cache size limit to obtain the corresponding probability value. , and calculating a benchmark binary similarity, the benchmark binary similarity being used to represent the similarity between the interaction between the binary variables of the cache expiration time and the cache size limit and a normalized constant value; The interaction between the binary variables of cache expiration time and cache size at each sampling is regarded as an interactive loop unfolded for the normalized constant value, based on the number of sampling times is the loop depth, obtaining a cross-loop expansion form of the benchmark binary similarity; and A cross-reduction is performed on the cross-cycle expansion form of each cycle, and the average is calculated to obtain the probability value.

2. The message management system for carbon sink management and carbon trading according to claim 1, characterized in that: The constant message request includes user information and / or configuration data of the carbon reduction supervisor, the carbon reduction implementer, the object tool corresponding to the carbon reduction implementer, and the object user corresponding to the carbon reduction implementer.

3. The message management system for carbon sink management and carbon trading according to claim 2, characterized in that: The response message is pre-cached for the constant message request, so that when a constant message request corresponding to a request for the same request object is received next time, the response message is directly read from the cache.

4. The message management system for carbon sink management and carbon trading according to claim 1, characterized in that: The variable message request includes the work data provided by the object tool corresponding to the carbon reduction implementer to the server, the newly added carbon credits / carbon reduction data provided by the server to the object user of the carbon reduction implementer, the carbon credits / carbon reduction transfer applied for by the object user corresponding to the carbon reduction implementer, and the carbon reduction settled by the carbon reduction implementer to the carbon reduction supervisor.

5. The message management system for carbon sink management and carbon trading according to claim 1, characterized in that: The message promise is used in asynchronous programming to use a promise object to process the result of an asynchronous operation. The promise object includes three states: an ongoing state as an initial state, which is neither a success nor a failure; a successful state indicating that the operation is successfully completed; and a failed state indicating that the operation fails. The promise object includes two sub-functions, a resolution sub-function for calling and transmitting success information when the operation is successful, and a rejection sub-function for calling and transmitting error information when the operation fails; The promise object contains three methods: callback functions for registration success and failure, including a callback function whose parameter is a success callback function that resolves the value passed by the child function, and a callback function whose parameter is a failure callback function that rejects the value passed by the child function; a callback function that is registered as empty if no value is returned; and a callback function that will be executed regardless of success or failure.

6. The message management system for carbon sink management and carbon trading according to claim 1, characterized in that: Generating the identifier of the message initiator of the variable message request as the key of the request management class, and generating the value of the request management class with the message commitment corresponding to the variable message request includes: The key of the request management class is generated by calling a key generation function with the identifier of the message initiator of the variable message request, and for the initial empty option of the request management class for the request, the commitment object method is extracted from the message commitment corresponding to the variable message request as the value.

7. The message management system for carbon sink management and carbon trading according to claim 1, characterized in that: Further including: When the request succeeds, the message promise of the request is deleted from the cache and the data is returned; When the request fails, the message promise of the request is also deleted from the cache and an error is returned; Only when there is a new request or a new message promise is returned, the new message promise is cached and returned as response data.

Images