An optimization method and system for frequent RPC pulling of non-real-time data

Abstract

This application discloses an optimization method and system for frequent RPC retrieval of non-real-time data, comprising: configuring a server-side cache version number for first data retrieved by the server based on a timestamp; when the client retrieves data from the server for the first time via RPC, obtaining the first data and the server-side cache version number and caching them locally on the client, and updating the interface call time; when the client subsequently requests the required data, and the interval between the interface call time and the current time exceeds a preset time interval, retrieving the server-side cache version number from the server via the RPC interface; when the server-side cache version number is inconsistent with the client-side cache version number, retrieving the required data from the server's first data via RPC; otherwise, retrieving the required data from the client's second data. This application can reduce the frequency of data retrieval from the server via RPC, reduce interface performance loss, and improve the efficiency of retrieving non-real-time data, and can be applied in the field of computer technology.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an optimization method and system for frequent RPC fetching of non-real-time data. Background Technology

[0002] With the rapid development of the internet and the explosive growth of data, both users and businesses prioritize data processing speed and performance. Slow websites or APIs negatively impact user experience. RPC (Remote Procedure Call) is a technology that allows a program to execute code on a remote server from its local machine. It's similar to a local procedure call, but the operation operates on a different computer. RPC achieves cross-network procedure calls by sending requests and receiving responses over the network, offering good versatility and flexibility. However, frequent and excessive RPC calls not only lead to performance degradation but also increase the load on services. Summary of the Invention

[0003] The main objective of this application is to propose an optimization method and system for frequent RPC retrieval of non-real-time data, aiming to optimize RPC retrieval calls, reduce interface performance loss, and lower service pressure.

[0004] To achieve the above objectives, one aspect of this application proposes an optimization method for frequent RPC fetching of non-real-time data, the method comprising:

[0005] When the server retrieves the first data for caching, it configures the server cache version number for the first data based on the timestamp.

[0006] When the client calls the Rpc interface for the first time to request the required data from the server, the required data is retrieved from the first data on the server through the Rpc interface.

[0007] Obtain the first data and the server-side cache version number, cache the first data and the server-side cache version number locally on the client, use them as the second data and the client-side cache version number, and update the interface call time;

[0008] When the client subsequently calls the RPC interface to request the required data from the server, and the time interval between the interface call and the current time exceeds a preset time interval, the client pulls the server cache version number from the server through the RPC interface.

[0009] When the server-side cache version number is inconsistent with the client-side cache version number, the required data is retrieved from the first data on the server through the RPC interface;

[0010] When the server-side cache version number is the same as the client-side cache version, or when the interval between the interface call time and the current time does not exceed a preset time interval, the required data is retrieved from the second data.

[0011] In some embodiments, before the step of fetching the server cache version number from the server via the RPC interface when the client subsequently calls the RPC interface to request the required data from the server, and the interval between the interface call time and the current time exceeds a preset time interval, the method further includes the following steps:

[0012] In the client's RPC interface configuration file, configure the first cache key-value pair based on the timestamp of the first data obtained from the server;

[0013] When the client calls the RPC interface for the first time to request the required data from the server, it obtains the first cache key value and caches it locally on the client, thus obtaining the second cache key value;

[0014] When the client subsequently calls the Rpc interface to request the required data from the server, it obtains the first cache key value in the configuration file and the second cache key value stored locally;

[0015] When the first cache key and the second cache key are inconsistent, the judgment on the interface call time is skipped, and the server cache version number is directly pulled from the server through the RPC interface.

[0016] In some embodiments, the method includes the following steps:

[0017] Update the first cache key-value pair based on the server-side data update status.

[0018] In some embodiments, after the step of retrieving the required data from the first data on the server via the RPC interface when the server-side cache version number is inconsistent with the client-side cache version number, the method further includes the following steps:

[0019] Update the second data and the client cache version number according to the first data and the server cache version number;

[0020] Update the API call time.

[0021] In some embodiments, when caching is performed on the client side, the caching mechanism of the Java Virtual Machine is used.

[0022] In some embodiments, the method further includes the following steps:

[0023] Configure preset time intervals based on the real-time requirements of the business scenario.

[0024] In some embodiments, the client is a web client.

[0025] To achieve the above objective, another aspect of this application proposes an optimization system for frequent RPC fetching of non-real-time data, the system comprising:

[0026] The first module is used to configure the server-side cache version number for the first data based on the timestamp when the server obtains the first data for caching.

[0027] The second module is used to obtain the first data and the server cache version number when the client calls the RPC interface for the first time to request the required data from the server, and cache the first data and the server cache version number locally on the client as the second data and the client cache version number, and update the interface call time.

[0028] The third module is used to retrieve the server cache version number from the server through the RPC interface when the client subsequently calls the RPC interface to request the required data from the server, and the time interval between the interface call and the current time exceeds a preset time interval.

[0029] The fourth module is used to retrieve the required data from the first data on the server through the RPC interface when the server cache version number is inconsistent with the client cache version number.

[0030] The fifth module is used to retrieve the required data from the second data when the server-side cache version number is consistent with the client-side cache version, or when the interval between the interface call time and the current time does not exceed a preset time interval.

[0031] It should be noted that, in some embodiments, the system may further include at least one of the following modules:

[0032] The seventh module is used to configure a first cache key-value pair in the client's RPC interface configuration file based on the timestamp of the server obtaining the first data; when the client calls the RPC interface for the first time to request the required data from the server, it obtains the first cache key-value pair and caches it locally on the client to obtain a second cache key-value pair; when the client subsequently calls the RPC interface to request the required data from the server, it obtains the first cache key-value pair in the configuration file and the second cache key-value pair stored locally; when the first cache key-value pair and the second cache key-value pair are inconsistent, it skips the judgment on the interface call time and directly pulls the server cache version number from the server through the RPC interface.

[0033] The eighth module is used to update the second data and the client cache version number based on the first data and the server cache version number; and to update the interface call time.

[0034] The ninth module is used to configure preset time intervals based on the real-time requirements of business scenarios.

[0035] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0036] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0037] The embodiments of this application include at least the following beneficial effects: This application provides an optimization method and system for frequent RPC retrieval of non-real-time data. This solution, when the server obtains the first data for caching, configures the server cache version number for the first data according to the timestamp, and requests the data to be cached locally on the client by calling the interface. By verifying the cache version number and the interface call time, the frequency of calling data from the server via RPC can be reduced, the performance loss of the interface by RPC can be reduced, and the efficiency of obtaining non-real-time data in high-frequency access scenarios can be greatly improved. Attached Figure Description

[0038] The accompanying drawings are used to provide a further understanding of the technical solution 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 technical solution of the present application and do not constitute a limitation on the technical solution of the present application.

[0039] Figure 1 This is a flowchart illustrating the steps of an optimization method for frequent RPC fetching of non-real-time data provided in an embodiment of this application.

[0040] Figure 2 This is a flowchart illustrating an optimization method for frequently fetching non-real-time data using RPC, provided in an embodiment of this application.

[0041] Figure 3 This is a schematic diagram of a module of an optimized system for frequent RPC fetching of non-real-time data provided in an embodiment of this application;

[0042] Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0044] Although functional modules are divided in the system diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the system or the order in the flowchart. The terms "first / S100," "second / S200," etc., in the specification, claims, and the aforementioned figures are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0045] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0046] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0047] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0048] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0049] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0050] RPC fetch: RPC (Remote Procedure Call) is a technology that allows a program to execute code on a remote server locally. It is similar to a local procedure call, but the object of the operation resides on another computer. RPC fetch refers to remotely retrieving data.

[0051] In related technologies, since data is often stored in the corresponding service, when the client wants to display the data, it needs to obtain the data from the server through RPC. However, too many RPC requests may cause interface performance loss, resulting in reduced data processing performance and increased service pressure.

[0052] In view of this, this application provides an optimization method and system for frequent RPC retrieval of non-real-time data. This solution, when caching first data on the server side, configures a server-side cache version number based on the timestamp for the first data, and requests local caching of the data via an interface call on the client side. Verification is performed using the cache version number and the interface call time. This reduces the frequency of RPC calls to the server, minimizing the performance overhead of RPC on the interface and significantly improving the efficiency of acquiring non-real-time data in high-frequency access scenarios. Furthermore, a cache key can be configured. When data is updated, the cache key in the configuration file can be directly changed, and the current cache version number will be retrieved directly via RPC, skipping the interface call time verification and reducing the impact of data errors caused by accessing the data within a preset timeframe without retrieving it via RPC.

[0053] This application provides an optimization method for frequent RPC retrieval of non-real-time data, relating to the field of computer technology. This optimization method can be applied to terminals, servers, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing an optimization method for frequent RPC retrieval of non-real-time data, but is not limited to the above forms.

[0054] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0055] Figure 1 This is an optional flowchart of an optimization method for frequent RPC fetching of non-real-time data provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S100 to S600.

[0056] Step S100: When the server obtains the first data for caching, it configures the server cache version number for the first data according to the timestamp.

[0057] Step S200: When the client calls the Rpc interface for the first time to request the required data from the server, the required data is retrieved from the first data on the server through the Rpc interface.

[0058] Step S300: Obtain the first data and the server-side cache version number, cache the first data and the server-side cache version number locally on the client as the second data and the client-side cache version number, and update the interface call time.

[0059] Step S400: When the client subsequently calls the Rpc interface to request the required data from the server, and the time interval between the interface call and the current time exceeds a preset time interval, the client retrieves the server cache version number from the server through the Rpc interface.

[0060] Step S500: When the server-side cache version number is inconsistent with the client-side cache version number, the required data is retrieved from the first data on the server through the RPC interface.

[0061] Step S600: When the server-side cache version number is consistent with the client-side cache version, or the interval between the interface call time and the current time does not exceed a preset time interval, the required data is retrieved from the second data.

[0062] Steps S100 to S600 as shown in the embodiments of this application, by configuring a server-side cache version number for the first data based on the timestamp when the server obtains the first data for caching, and by calling the interface on the client to request local caching of the data, and verifying the cache version number and the interface call time, can reduce the frequency of calling data from the server via RPC, reduce the performance loss of the interface caused by RPC, and greatly improve the efficiency of obtaining non-real-time data in high-frequency access scenarios.

[0063] In some embodiments, before step S400, the following steps S710 to S720 may also be included:

[0064] Step S710: In the configuration file of the client's RPC interface, configure the first cache key-value pair according to the timestamp of the first data obtained by the server;

[0065] Step S720: When the client calls the Rpc interface for the first time to request the required data from the server, it obtains the first cache key value and caches it locally on the client to obtain the second cache key value.

[0066] Step S730: When the client subsequently calls the Rpc interface to request the required data from the server, it obtains the first cache key value in the configuration file and the second cache key value stored locally.

[0067] Step S740: When the first cache key value and the second cache key value are inconsistent, skip the judgment on the interface call time and directly pull the server cache version number from the server through the RPC interface.

[0068] In some embodiments, step S400 is preceded by step S750:

[0069] Step S750: Update the first cache key value according to the server-side data update status.

[0070] Following step S500 in some embodiments, the method further includes the following steps S810 to S820:

[0071] Step S810: Update the second data and the client cache version number according to the first data and the server cache version number;

[0072] Step S820: Update the interface call time.

[0073] In some embodiments, when caching is performed on the client side, the caching mechanism of the Java Virtual Machine is used.

[0074] In some embodiments, the method further includes the step of configuring a preset time interval according to the real-time requirements of the business scenario.

[0075] The following is a detailed description and explanation of the solution in this application embodiment, using specific examples of clients retrieving data from servers:

[0076] This application provides an optimization method for frequent RPC fetching of non-real-time data. This method can be applied to situations where non-real-time data is being acquired, optimizing the client's fetching of data from the server via the RPC interface, reducing the frequency of RPC fetching, minimizing the performance overhead of RPC on the interface, and improving the efficiency of acquiring non-real-time data in high-frequency access scenarios. (Refer to...) Figure 2 Taking a web-based client as an example, the specific steps can be as follows:

[0077] a. Set up a data acquisition server, which can be used in conjunction with Redis (remote dictionary service) as a cache storage database to cache the data.

[0078] b. The server adds a server cache version number before the data is cached. When data is modified, the server cache version number needs to be changed.

[0079] c. Add a cache key to the configuration file of the client RPC interface to determine whether to directly obtain the server cache version number through RPC when accessing the interface.

[0080] d. When the interface is accessed, check if the time since the last read of the current interface from the web cache has exceeded a preset time interval (e.g., 30 seconds). If not, directly return the data cached on the web. The preset time interval can be adjusted according to the real-time data requirements of the business scenario.

[0081] e. If the preset time interval has elapsed since the last access to the current interface, the server cache version number is obtained through RPC. If the cache version number on the web side is the same as the cache version number on the server side, it proves that there is no data change and the data can be returned directly.

[0082] f. If the cache version numbers on the web client and the server are different, an RPC needs to be initiated to retrieve the data from the server again.

[0083] Furthermore, after obtaining server-side data for the first time via RPC, the JVM (Java Virtual Machine) caching mechanism can be used to create a non-expiring cache on the web side containing the server-side cache version number, data, and the current interface reading time (interface call time). When a new request arrives, the web-side cache can be used to determine whether it is necessary to obtain the data again via RPC, thus reducing the number of times data needs to be obtained via RPC.

[0084] Furthermore, normally, the data will not be checked for changes within the preset time interval. If there is a relatively large data update, a cache key can be configured in the configuration file as shown in step c. When there is a data update, the cache key in the configuration file can be manually changed. In this way, the web client can directly pull the current cache version number through RPC, which can reduce the impact of dirty data errors caused by accessing the cache through RPC within the preset time interval when there is a clear data update.

[0085] Furthermore, the timestamp of data retrieval can be used as the server-side cache version number, and also as a prefix for the data cache key. When data changes, the server-side cache version number is updated. Using the timestamp as the version number also makes it easier to compare the validity of the data.

[0086] Furthermore, after retrieving the data in step e, the version number and data of the local cache on the web side are updated according to the latest server-side cache version number and data, and the interface call time is updated.

[0087] In summary, the embodiments of this application have at least the following beneficial effects:

[0088] 1. By caching the first data obtained on the server side, configuring the server-side cache version number for the first data based on the timestamp, and calling the interface on the client side to request local caching of the data, and verifying the cache version number and the interface call time, the frequency of calling data from the server via RPC can be reduced, reducing the performance loss of the interface caused by RPC, and greatly improving the efficiency of obtaining non-real-time data in high-frequency access scenarios.

[0089] 2. By configuring a cache key in the configuration file and modifying the cache key when data is updated, the impact of errors caused by accessing data that is no longer processed through RPC within a preset time interval can be reduced when there is a clear data update.

[0090] Please see Figure 3 This application also provides an optimization system for frequent RPC fetching of non-real-time data, which can implement the above-mentioned optimization method for frequent RPC fetching of non-real-time data. The system includes:

[0091] The first module 101 is used to configure a server-side cache version number for the first data based on the timestamp when the server obtains the first data for caching.

[0092] The second module 102 is used to retrieve the required data from the first data on the server through the Rpc interface when the client calls the Rpc interface for the first time to request the required data from the server.

[0093] The third module 103 is used to obtain the first data and the server-side cache version number, cache the first data and the server-side cache version number locally on the client as the second data and the client-side cache version number, and update the interface call time.

[0094] The fourth module 104 is used to retrieve the server cache version number from the server through the Rpc interface when the client subsequently calls the Rpc interface to request the required data from the server, and the time interval between the interface call time and the current time exceeds a preset time interval.

[0095] The fifth module 105 is used to retrieve the required data from the first data on the server through the RPC interface when the server cache version number is inconsistent with the client cache version number;

[0096] The sixth module 106 is used to retrieve the required data from the second data when the server cache version number is consistent with the client cache version, or when the interval between the interface call time and the current time does not exceed a preset time interval.

[0097] It should be noted that, in some embodiments, the system may further include at least one of the following modules:

[0098] The seventh module is used to configure a first cache key-value pair in the client's RPC interface configuration file based on the timestamp of the server obtaining the first data; when the client calls the RPC interface for the first time to request the required data from the server, it obtains the first cache key-value pair and caches it locally on the client to obtain a second cache key-value pair; when the client subsequently calls the RPC interface to request the required data from the server, it obtains the first cache key-value pair in the configuration file and the second cache key-value pair stored locally; when the first cache key-value pair and the second cache key-value pair are inconsistent, it skips the judgment on the interface call time and directly pulls the server cache version number from the server through the RPC interface.

[0099] The eighth module is used to update the second data and the client cache version number based on the first data and the server cache version number; and to update the interface call time.

[0100] The ninth module is used to configure preset time intervals based on the real-time requirements of business scenarios.

[0101] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0102] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned optimization method for frequent RPC fetching of non-real-time data. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0103] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0104] Please see Figure 4 , Figure 4 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0105] The processor 201 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0106] The memory 202 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 202 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 202 and is called and executed by the processor 201 to execute an optimization method for frequent RPC fetching of non-real-time data according to an embodiment of this application.

[0107] Input / output interface 203 is used to implement information input and output;

[0108] The communication interface 204 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0109] Bus 205 transmits information between various components of the device (e.g., processor 201, memory 202, input / output interface 203, and communication interface 204);

[0110] The processor 201, memory 202, input / output interface 203 and communication interface 204 are connected to each other within the device via bus 205.

[0111] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned optimization method for frequent RPC fetching of non-real-time data.

[0112] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0113] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0114] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0115] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0116] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0117] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0118] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0119] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0120] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, apparatuses, or units, and may be electrical, mechanical, or other forms.

[0121] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0122] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0123] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0124] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. An optimization method for frequent RPC fetching of non-real-time data, characterized in that, Includes the following steps: When the server retrieves the first data for caching, it configures the server cache version number for the first data based on the timestamp. When the client calls the Rpc interface for the first time to request the required data from the server, the required data is retrieved from the first data on the server through the Rpc interface. Obtain the first data and the server-side cache version number, cache the first data and the server-side cache version number locally on the client, use them as the second data and the client-side cache version number, and update the interface call time; When the client subsequently calls the RPC interface to request the required data from the server, and the time interval between the interface call and the current time exceeds a preset time interval, the client pulls the server cache version number from the server through the RPC interface. When the server-side cache version number is inconsistent with the client-side cache version number, the required data is retrieved from the first data on the server through the RPC interface; When the server-side cache version number is the same as the client-side cache version, or when the interval between the interface call time and the current time does not exceed a preset time interval, the required data is retrieved from the second data. Before the step of the client subsequently calling the RPC interface to request the required data from the server, and the interval between the interface call time and the current time exceeds a preset time interval, and before the step of pulling the server cache version number from the server through the RPC interface, the method further includes the following steps: In the client's RPC interface configuration file, configure the first cache key-value pair based on the timestamp of the first data obtained from the server; When the client calls the RPC interface for the first time to request the required data from the server, it obtains the first cache key value and caches it locally on the client, thus obtaining the second cache key value; When the client subsequently calls the Rpc interface to request the required data from the server, it obtains the first cache key value in the configuration file and the second cache key value stored locally; When the first cache key and the second cache key are inconsistent, the judgment on the interface call time is skipped, and the server cache version number is directly pulled from the server through the RPC interface.

2. The method according to claim 1, characterized in that, The method includes the following steps: Update the first cache key-value pair based on the server-side data update status.

3. The method according to claim 1, characterized in that, After the step of retrieving the required data from the first data on the server via the RPC interface when the server-side cache version number is inconsistent with the client-side cache version number, the method further includes the following steps: Update the second data and the client cache version number according to the first data and the server cache version number; Update the API call time.

4. The method according to claim 1, characterized in that, When caching is performed on the client side, the caching mechanism of the Java Virtual Machine is used.

5. The method according to claim 1, characterized in that, The method further includes the following steps: Configure preset time intervals based on the real-time requirements of the business scenario.

6. The method according to claim 1, characterized in that, The client is a web client.

7. A system for implementing the optimization method for frequent RPC fetching of non-real-time data as described in any one of claims 1-6, characterized in that, include: The first module is used to configure the server-side cache version number for the first data based on the timestamp when the server obtains the first data for caching. The second module is used to retrieve the required data from the first data on the server through the Rpc interface when the client calls the Rpc interface for the first time to request the required data from the server. The third module is used to obtain the first data and the server-side cache version number, cache the first data and the server-side cache version number locally on the client as the second data and the client-side cache version number, and update the interface call time; The fourth module is used to retrieve the server's cached version number from the server through the RPC interface when the client subsequently calls the RPC interface to request the required data from the server, and the time interval between the interface call and the current time exceeds a preset time interval. The fifth module is used to retrieve the required data from the first data on the server through the RPC interface when the server cache version number is inconsistent with the client cache version number; The sixth module is used to retrieve the required data from the second data when the server-side cache version number is consistent with the client-side cache version, or when the interval between the interface call time and the current time does not exceed a preset time interval.

8. An electronic device, characterized in that, Including the processor and memory; The memory is used to store programs; The processor executes the program to implement the method as described in any one of claims 1 to 6.

9. A computer storage medium storing a processor-executable program, characterized in that, The processor-executable program, when executed by the processor, is used to implement the method as described in any one of claims 1 to 6.

Images