A cross-unit parameter sharing method, server and client

Abstract

This article belongs to the field of distributed systems, and in particular, relates to a cross-unit parameter sharing method, a server, and a client. When applied to the server, the method includes: after receiving a business parameter change request, generating a change notification, grouping the clients to be changed, and sending the change notification to each group of clients to be changed one by one, wherein the change notification includes the version number of the version to be changed; receiving a data pull request initiated by each client to be changed in response to the change notification; and sending the version to be changed and the effective time of the version to be changed to the client to be changed according to the data pull request. This article solves the problems of inconsistent parameter synchronization and large access traffic to a single node when cross-unit parameter sharing in distributed systems occurs.

Description

Technical Field

[0001] The present invention relates to the field of distributed systems, and in particular to a cross-unit parameter sharing method, a server, and a client. Background Art

[0002] In distributed systems, especially financial distributed systems, in order to maintain stable service operation, clients are deployed redundantly and run in different computer rooms and logical units. Therefore, when services change, it is necessary to ensure that clients that maintain common parameters are synchronized and used across units and computer rooms.

[0003] In the prior art, the business parameters of clients in different computer rooms / units are cached by the configuration center. When the business parameters change, the server sends the changed parameters to each configuration center. Since the configuration centers are relatively independent, when the clients obtain the changed parameters from their respective configuration centers, the configuration centers may obtain the business parameters at different times or the configuration centers may fail, resulting in inconsistency in the changed parameters cached by the configuration centers. As a result, the parameters of clients maintaining the same business may also be inconsistent. In addition, when the business parameters change, the clients may simultaneously access a single configuration center in a short period of time to obtain the changed parameters, resulting in excessive access traffic to the configuration center and a single point of failure. Summary of the invention

[0004] The present invention provides a cross-unit parameter sharing method, a server and a client, which are used to solve the problems of inconsistent parameter synchronization and large single-node access traffic during cross-unit parameter sharing in an existing distributed system.

[0005] In order to solve the above technical problems, a first aspect of this document provides a cross-unit parameter sharing method, which is applied to a server, and the method includes:

[0006] After receiving the service parameter change request, a change notification is generated, the clients to be changed are grouped, and the change notification is sent to each group of clients to be changed one by one, wherein the change notification includes the version number of the version to be changed;

[0007] Receiving a data pull request initiated by each of the to-be-changed clients in response to the change notification;

[0008] According to the data pull request, the version to be changed and the effective time of the version to be changed are sent to the client to be changed.

[0009] Furthermore, the cross-unit parameter sharing method, applied to the server, further includes:

[0010] Establishing a service relationship between the server and the client;

[0011] Receiving a start query request sent by the client;

[0012] Determine a list of versions to be pushed according to the startup query request, where the versions in the list of versions to be pushed are versions whose effective time is greater than the current time;

[0013] Send the versions in the list of versions to be pushed to the client.

[0014] Furthermore, the change notification includes:

[0015] Update the main version number table according to the business parameter change request;

[0016] Determine the version of the non-pushed version number first written in the updated main version number table as the version to be changed;

[0017] According to the version to be changed, the change notification is generated and sent one by one in groups to the client to be changed.

[0018] Furthermore, after receiving the service parameter change request, the method further includes:

[0019] Adjust the status of each version to be pushed in the updated main version number table to a locked state;

[0020] After receiving confirmation information of successful change from each client, the locked state of the version to be changed is cancelled.

[0021] Furthermore, after sending the change notification, the method further includes: updating the notification status of the change notification;

[0022] The method further comprises:

[0023] The notification status of the change notification is polled, and an alarm is issued if an abnormality is found. The abnormality includes: the notification status is not notified and timed out, the notification status is parameter effective and timed out, and the notification status is notification completed and timed out.

[0024] Furthermore, the clients to be changed are grouped as follows:

[0025] Obtaining response characteristic information of the client to be changed;

[0026] The clients to be changed are grouped according to the response characteristic information of the clients to be changed and the performance information of the server.

[0027] A second aspect of the present invention provides a cross-unit parameter sharing method, which is applied to a client, and the method includes:

[0028] Receive a change notification sent by the server, wherein the change notification includes a version number of the version to be changed;

[0029] Sending a data pull request to the server according to the change notification;

[0030] Receive and store the version to be changed and the effective time of the version to be changed, and send confirmation information to the server.

[0031] Furthermore, the cross-unit parameter sharing method, applied to the client, further includes:

[0032] Establishing a service relationship between the client and the server;

[0033] Sending a start query request to the server;

[0034] Receiving and storing the push version of the server;

[0035] The pushed version is effective according to the effective time of the pushed version.

[0036] Furthermore, the cross-unit parameter sharing method, applied to the client, further includes:

[0037] Determine whether the effective time of the version to be changed has been reached;

[0038] If the judgment is yes, the version to be changed will take effect.

[0039] A second aspect of the present invention provides a server, the server comprising:

[0040] A change notification module is used to generate a change notification after receiving a service parameter change request, group the clients to be changed, and send the change notification to each group of clients to be changed one by one, wherein the change notification includes the version number of the version to be changed;

[0041] A first interaction module is used to receive a data pull request initiated by each of the to-be-changed clients in response to the change notification;

[0042] The second interaction module is used to send the version to be changed and the effective time of the version to be changed to the client to be changed according to the data pull request.

[0043] A third aspect of the present invention provides a client, the client comprising:

[0044] A third interaction module is used to receive a change notification sent by the server, wherein the change notification includes a version number of the version to be changed;

[0045] A fourth interaction module, configured to send a data pull request to the server according to the change notification;

[0046] The fifth interaction module is used to receive and store the version to be changed and the effective time of the version to be changed, and send confirmation information to the server.

[0047] A fourth aspect of the present invention provides a computer device, comprising a memory, a processor, and a computer program stored in the memory, wherein when the computer program is executed by the processor, the computer program executes instructions of the cross-unit parameter sharing method described in any of the aforementioned embodiments.

[0048] A fifth aspect of the present invention provides a computer storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor of a computer device, the computer program executes instructions of the cross-unit parameter sharing method described in any of the aforementioned embodiments.

[0049] A sixth aspect of the present invention provides a computer program product, which includes a computer program. When the computer program is executed by a processor of a computer device, the computer program executes instructions of the cross-unit parameter sharing method described in any of the above embodiments.

[0050] The cross-unit parameter sharing method, server, and client provided in this article communicate directly between the server and the client without going through the configuration center, thus avoiding the parameter inconsistency problem caused by multiple configuration centers. The server actively sends change notifications, and the client responds to the change notifications and then initiates a data pull request, which reduces the system pressure faced by the server when receiving too much access traffic in a short period of time. By sending the version effective time, the client takes effect according to the effective time, ensuring the consistency of the version maintained by each client during the statistical time.

[0051] In order to make the above and other purposes, features and advantages of this article more obvious and easy to understand, the following specifically cites preferred embodiments and describes them in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the technical solutions in the embodiments of this article or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of this article. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0053] Figure 1 A first flow chart of the cross-unit parameter sharing method applied to a server in an embodiment of the present invention is shown;

[0054] Figure 2 A second flow chart of the cross-unit parameter sharing method applied to the server side according to the embodiment of this document is shown;

[0055] Figure 3A flow chart of a method for generating and sending a change notification according to an embodiment of the present invention is shown;

[0056] Figure 4 A flow chart of the method after receiving a service parameter change request in an embodiment of this invention is shown;

[0057] Figure 5 A flow chart showing the sending of change notifications by group one by one in the embodiment of this article is shown;

[0058] Figure 6 A first flow chart of a method for cross-unit parameter sharing applied to a client according to an embodiment of the present invention is shown;

[0059] Figure 7 A second flow chart of the cross-unit parameter sharing method applied to a client according to an embodiment of the present invention is shown;

[0060] Figure 8 A third flow chart of the cross-unit parameter sharing method applied to a client according to an embodiment of the present invention is shown;

[0061] Fig. 9 The structure diagram of the server in the embodiment of this article is shown;

[0062] Fig.10 The structure diagram of the client of the embodiment of this article is shown;

[0063] Fig.11 A structural diagram of a computer device according to an embodiment of this invention is shown.

[0064] Description of the accompanying symbols:

[0065] 910. Change notification module;

[0066] 920, first interaction module;

[0067] 930, second interaction module;

[0068] 1010. third interaction module;

[0069] 1020, fourth interaction module;

[0070] 1030, fifth interaction module;

[0071] 1102. Computer equipment;

[0072] 1104. Processor;

[0073] 1106. Memory;

[0074] 1108. Driving mechanism;

[0075] 1110, input / output module;

[0076] 1112. Input device;

[0077] 1114. Output device;

[0078] 1116. Presentation equipment;

[0079] 1118. Graphical user interface;

[0080] 1120. Network interface;

[0081] 1122. Communication link;

[0082] 1124. Communication bus. DETAILED DESCRIPTION

[0083] The following will be combined with the drawings in the embodiments of this article to clearly and completely describe the technical solutions in the embodiments of this article. Obviously, the described embodiments are only part of the embodiments of this article, not all of the embodiments. Based on the embodiments of this article, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this article.

[0084] It should be noted that the terms "first", "second", etc. in the specification and claims of this article and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of this article described here can be implemented in an order other than those illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, device, product or equipment that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0085] This specification provides method operation steps as described in the embodiments or flow charts, but more or fewer operation steps may be included based on routine or non-creative work. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the system or device product is executed in practice, it can be executed in the order of the method shown in the embodiments or the drawings or in parallel.

[0086] It should be noted that the acquisition, storage, use, and processing of data in the technical solutions of the embodiments of this specification comply with the relevant provisions of national laws and regulations.

[0087] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0088] In the embodiment of this article, the server maintains a main version number table, a parameter table, a change record table, a history record table, a service subscription table, a notification table, a registration center module and a data table. The main version number table is used to maintain the version number, the parameter table is used to maintain various parameters in the version, such as version identification, version parameter value, version effective time and expiration time, etc., the change record table is used to maintain the change records of the data table corresponding to each version, the history record table is used to maintain the data table of the historical version, the service subscription table is used to maintain the microservice information, the notification table is used to maintain the notification status of the version, the registration center module is used to query the client corresponding to the microservice, and the data table contains specific business parameter data.

[0089] In one embodiment of the present invention, a cross-unit parameter sharing method is provided, which is applied to a server to solve the problems of inconsistent parameter synchronization and large access traffic to a single node when sharing parameters across units in a distributed system.

[0090] Specifically, Figure 1 As shown, the cross-unit parameter sharing method applied to the server includes:

[0091] Step 110, after receiving the service parameter change request, generating a change notification, grouping the clients to be changed, and sending the change notification to each group of clients to be changed one by one, wherein the change notification includes the version number of the version to be changed;

[0092] Step 120, receiving a data pull request initiated by each of the to-be-changed clients in response to the change notification;

[0093] Step 130: Send the version to be changed and the effective time of the version to be changed to the client to be changed according to the data pull request.

[0094] In this embodiment, the server no longer goes through the configuration center, but directly sends change notifications to the client, avoiding the parameter inconsistency problem caused by multiple configuration centers; the server sends change notifications one by one by groups, and the client initiates a data pull request after responding to the change notification, alleviating the pressure of the server receiving too much access traffic in a short time; the server sends the version effective time, so that the client takes effect according to the unified effective time, ensuring the consistency of the maintenance version of each client.

[0095] In some embodiments of the present invention, after receiving a business parameter change request, the server obtains the newly added data table and the effective time of the newly added data table. The effective time is pre-set by the management personnel and is used to launch the version at the scheduled time. Afterwards, the version number and version push identifier of the data table are inserted into the main version number table, a change record is generated in the change record table, the version identifier, version parameter value, version effective time and expiration time are added to the parameter table, the newly added data table is inserted into the history record table, the microservice name corresponding to the data table to be pushed is queried in the service subscription table, all client information associated with the microservice is obtained in the registration center module according to the microservice name, and a change notification is sent to the client. The change notification includes the version number of the data table to be pushed, and at the same time, the notification status corresponding to the change notification is inserted in the notification table.

[0096] In some embodiments of the present invention, after receiving a data pull request initiated by the client in response to a change notification, the server queries the service subscription table and the change record table according to the version number request and the microservice name in the data pull request, locates the data table that needs to be pulled, and queries the data table data required by the client in the history record table, and sends the new version data and effective time of the data table to the client.

[0097] In one embodiment of this invention, Figure 2 As shown, the cross-unit parameter sharing method applied to the server also includes:

[0098] Step 210, establishing a service relationship between the server and the client;

[0099] Step 220, receiving a start query request sent by the client;

[0100] Step 230, determining a list of versions to be pushed according to the startup query request, wherein the versions in the list of versions to be pushed are versions whose effective time is greater than the current time;

[0101] Step 240: Send the versions in the list of versions to be pushed to the client.

[0102] In this embodiment, when the server and the client establish an initial service relationship, the server receives the startup query request sent by the client and pushes all versions that have not yet taken effect to the client, so that the client keeps the updated version synchronously with other clients that have already run the service.

[0103] In one embodiment of this invention, Figure 3 As shown, the generating change notification includes:

[0104] Step 310, updating the main version number table according to the service parameter change request;

[0105] Step 320, determining the version of the non-pushed version number first written in the updated main version number table as the version to be changed;

[0106] Step 330: Generate and send the change notification to the client to be changed one by one in groups according to the version to be changed.

[0107] This embodiment uses the first written version in the non-pushing state as the version to be changed, so as to push the version number of the mature version to the client first, thereby ensuring the stability of the client when running the new version.

[0108] In some embodiments of the present invention, after receiving a business parameter change request, the server obtains the newly added data table and the effective time of the newly added data table, inserts the version number and version push identifier of the data table into the main version number table, and sets the version push identifier of the data table to 0, indicating that it has not been pushed, and uses the first non-pushed version written as the version to be changed, and then sends change notifications to all clients to be changed one by one in groups.

[0109] In one embodiment of this invention, Figure 4 As shown, after receiving the service parameter change request, it also includes:

[0110] Step 410, adjusting the status of each version to be pushed in the updated main version number table to a locked state;

[0111] Step 420: After receiving confirmation information of successful change from each client, cancel the locked state of the version to be changed.

[0112] After receiving the service parameter change request, this embodiment adjusts the status of each version to be pushed in the updated main version number table to a locked state, thereby ensuring that no other versions are pushed by mistake when the version is pushed.

[0113] In some embodiments of this document, after receiving a business parameter change request, the status of each version to be pushed in the updated main version number table is adjusted to -1, indicating that the version is locked. After receiving confirmation information that the change is successful from each client, the status of the version to be changed is adjusted to the corresponding version number, and its push flag is set to 1, indicating that it has been pushed. The locked status and push flag can also be represented by other values ​​or symbols, which are not limited in this document.

[0114] In some embodiments of the present invention, after sending the change notification, the notification status of the change notification is also updated, and the notification status includes 0: not notified, 1: notified, 2: notification completed, 3: parameters have taken effect, -1: alarmed; among which, not notified means that the change notification has not been sent, notified means that the change notification is sent successfully, notification completed means that the client confirms receipt of the notification, parameters have taken effect means that the client has updated the version data, and alarmed means that an alarm has been given for the abnormal notification situation.

[0115] In some embodiments of the present invention, when a change notification is generated, the notification status of the change notification will be polled. When the notification status timeout is always 0, it means that the change notification has not been sent within the scheduled time, and an alarm mechanism will be triggered to remind the staff to troubleshoot the problem; when the notification status timeout is always 1, it means that the change notification has been sent but the client's confirmation information has not been received within the scheduled time, thereby triggering the alarm mechanism; when the notification status timeout is always 2, it means that the server has not received the notification of successful change from the client within the time limit, thereby triggering the alarm mechanism; when the notification status is 3, it means that the client has completed the parameter change; when the notification status is -1, it means that the abnormal situation has been alarmed and no alarm will be given.

[0116] In some embodiments of the present invention, if the notification status is always 0, that is, the unnotified state, before triggering the alarm mechanism, the server will query whether the previous version of the version to be notified has missed notification. Only when the previous version has been successfully notified, will the current version be notified; when the server has multiple versions that need to be notified in a short period of time, multiple versions to be notified may be sent. Therefore, the server also needs to query whether multiple consecutive versions before the version to be notified are normally notified; for versions that are not notified normally, the server will query the change record table and compare the data in the notification table and the registration center module. After that, the server will trigger the alarm mechanism and help the staff locate the problem when the alarm mechanism is triggered.

[0117] In one embodiment of this invention, Figure 5 As shown, the groups of clients to be changed include:

[0118] Step 510, obtaining the response characteristic information of the client to be changed;

[0119] Step 520: grouping the clients to be changed according to the response characteristic information of the clients to be changed and the performance information of the server.

[0120] This embodiment considers dividing the clients to be changed into multiple groups according to the response characteristic information of the clients to be changed and the performance information of the server, so as to ensure that the server will not receive access requests from all the clients to be changed in a short time, thereby alleviating the system pressure on the server.

[0121] In some implementations of this document, the response characteristic information includes the speed at which the client to be changed receives the change notification, and the time it takes for the changed client to initiate a pull request in response to the change notification. The performance information includes the amount of traffic that the server can simultaneously receive for access. Based on the performance information of the server and the response characteristic information of the client to be changed, the number of clients in each client group and the order in which the change notification is sent to each client group are jointly determined, thereby maximizing the notification efficiency of the change notification and the stable operation of the server.

[0122] In one embodiment of the present invention, a cross-unit parameter sharing method is also provided, which is applied to a client to solve the problems of inconsistent parameter synchronization and large access traffic to a single node when sharing parameters across units in a distributed system.

[0123] Specifically, Figure 6 As shown, the cross-unit parameter sharing method applied to the client includes:

[0124] Step 610, receiving a change notification sent by the server, wherein the change notification includes a version number of the version to be changed;

[0125] Step 620, sending a data pull request to the server according to the change notification;

[0126] Step 630, receiving and storing the version to be changed and the effective time of the version to be changed, and sending confirmation information to the server.

[0127] In this embodiment, the client no longer goes through the configuration center, but directly receives the change notification sent by the server, and then pulls data from the server, avoiding the parameter inconsistency problem caused by multiple configuration centers; at the same time, after receiving the change version, the change version and the effective time of the change version are stored to ensure that each client has a unified change version effective time. When the version is effective according to the effective time, the parameter inconsistency problem caused by inconsistent pulling time of each client can be guaranteed; a confirmation message is sent to the server to ensure that the server performs the next step of processing.

[0128] In some embodiments of this document, after the client receives the change notification sent by the server, it sends a confirmation message of receiving the notification to the server, and sends a data pull request to the server at a preset time. The data pull request includes the version number of the version to be changed and the microservice name corresponding to the client. The preset time is determined according to the actual arrangement of the client and is not limited in this document.

[0129] In some embodiments of this invention, the client receives the version to be changed and the effective time of the version to be changed and stores them in the memory to facilitate the client to query the information of each version, thereby reducing the query time. When the effective time is reached, the client takes effect on the corresponding version and sends confirmation information of successful version change to the server.

[0130] In one embodiment of this invention, Figure 7 As shown, the cross-unit parameter sharing method applied to the client also includes:

[0131] Step 710, establishing a service relationship between the client and the server;

[0132] Step 720, sending a start query request to the server;

[0133] Step 730, receiving and storing the push version of the server;

[0134] Step 740: Validate the pushed version according to the effective time of the pushed version.

[0135] In this embodiment, when the client and the server establish an initial service relationship, the client actively initiates a startup query request to the server to pull all ineffective version data to ensure that the client keeps a synchronized update version with other clients that have already run the service.

[0136] In one embodiment of this invention, Figure 8 As shown, the cross-unit parameter sharing method applied to the client also includes:

[0137] Step 810, determine whether the effective time of the version to be changed has arrived, if so, execute step 820;

[0138] Step 820: Validate the version to be changed.

[0139] In this embodiment, when the effective time is reached, the corresponding version stored in the client is effective, and the version consistency of each client is ensured by a unified effective time.

[0140] In some embodiments of the present invention, when initiating a query, the client may receive and store multiple versions to be changed, and make each version effective in sequence according to the effective time, and send confirmation information of the successful version change to the server. When the version to be changed corresponding to the change notification is subsequently pulled, the version will be stored, and the version will be effective when the effective time is reached, and confirmation information of the successful version change will be sent to the server.

[0141] Based on the same inventive concept, this document also provides a server, as described in the following embodiments. Since the principle of solving the problem by the server is similar to the cross-unit parameter sharing method applied to the server, the implementation of the server can refer to the cross-unit parameter sharing method applied to the server, and the repeated parts will not be repeated.

[0142] Specifically, Fig. 9 As shown, the server includes:

[0143] The change notification module 910 is used to generate a change notification after receiving a service parameter change request, group the clients to be changed, and send the change notification to each group of clients to be changed one by one, wherein the change notification includes the version number of the version to be changed;

[0144] The first interaction module 920 is used to receive a data pull request initiated by each of the to-be-changed clients in response to the change notification;

[0145] The second interaction module 930 is used to send the version to be changed and the effective time of the version to be changed to the client to be changed according to the data pull request.

[0146] In this embodiment, the server no longer goes through the configuration center, but directly sends change notifications to the client, avoiding the parameter inconsistency problem caused by multiple configuration centers; the server sends change notifications one by one by groups, and the client initiates a data pull request after responding to the change notification, alleviating the pressure of the server receiving too much access traffic in a short time; the server sends the version effective time, so that the client takes effect according to the unified effective time, ensuring the consistency of the maintenance version of each client.

[0147] Based on the same inventive concept, this document also provides a client, as described in the following embodiments. Since the principle of the client to solve the problem is similar to the cross-unit parameter sharing method applied to the client, the implementation of the client can refer to the cross-unit parameter sharing method applied to the client, and the repeated parts will not be repeated.

[0148] Specifically, Fig.10 As shown, the client includes:

[0149] The third interaction module 1010 is used to receive a change notification sent by the server, where the change notification includes a version number of the version to be changed;

[0150] A fourth interaction module 1020, configured to send a data pull request to the server according to the change notification;

[0151] The fifth interaction module 1030 is used to receive and store the version to be changed and the effective time of the version to be changed, and send confirmation information to the server.

[0152] In this embodiment, the client no longer goes through the configuration center, but directly receives the change notification sent by the server, and then pulls data from the server, avoiding the parameter inconsistency problem caused by multiple configuration centers; at the same time, after receiving the change version, the change version and the effective time of the change version are stored to ensure that each client has a unified change version effective time. When the version is effective according to the effective time, the parameter inconsistency problem caused by inconsistent pulling time of each client can be guaranteed; a confirmation message is sent to the server to ensure that the server performs the next step of processing.

[0153] The cross-unit parameter sharing method, server, and client provided in this article communicate directly between the server and the client without going through the configuration center, thus avoiding the parameter inconsistency problem caused by multiple configuration centers. The server actively sends change notifications, and the client responds to the change notifications and then initiates a data pull request, which reduces the system pressure faced by the server when receiving too much access traffic in a short period of time. By sending the version effective time, the client takes effect according to the effective time, ensuring the consistency of the maintenance versions of each client.

[0154] In one embodiment of the present invention, a computer device is also provided for implementing the method described in any of the above embodiments, such as Fig.11 The schematic diagram of the structure of the node of the embodiment of this article is shown. In this embodiment, the structure of the node in the side chain network and the node in the main chain network is described, which may include a relay node, a decision maker node or other functional nodes. The node is referred to as a computer device in this embodiment. The computer device 1102 may include one or more processors 1104, such as one or more central processing units (CPUs), and each processing unit may implement one or more hardware threads. The computer device 1102 may also include any memory 1106, which is used to store any kind of information such as code, settings, data, etc. Non-limiting, for example, the memory 1106 may include any one or more combinations of the following: any type of RAM, any type of ROM, flash memory device, hard disk, optical disk, etc. More generally, any memory can use any technology to store information. Further, any memory can provide volatile or non-volatile retention of information. Further, any memory can represent a fixed or removable component of the computer device 1102. In one case, when the processor 1104 executes an associated instruction stored in any memory or a combination of memories, the computer device 1102 can perform any operation of the associated instruction. The computer device 1102 also includes one or more drive mechanisms 1108 for interacting with any storage, such as a hard disk drive mechanism, an optical disk drive mechanism, etc.

[0155] The computer device 1102 may also include an input / output module 1110 (I / O) for receiving various inputs (via input devices 1112) and for providing various outputs (via output devices 1114). A specific output mechanism may include a presentation device 1116 and an associated graphical user interface (GUI) 1118. In other embodiments, the input / output module 1110 (I / O), input device 1111, and output device 1114 may not be included, and the computer device 1102 may be used as a computer device in a network. The computer device 1102 may also include one or more network interfaces 1120 for exchanging data with other devices via one or more communication links 1122. One or more communication buses 1124 couple the components described above together.

[0156] The communication link 1122 may be implemented in any manner, for example, through a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication link 1122 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc. governed by any protocol or combination of protocols.

[0157] Corresponds to Figure 1-Figure 8 The method in this article also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above method are executed.

[0158] The embodiment of the present invention also provides a computer readable instruction, wherein when the processor executes the instruction, the program therein causes the processor to execute the following Figures 1 to 8 The method shown.

[0159] It should be understood that in the various embodiments of this document, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this document.

[0160] It should also be understood that in the embodiments of this article, the term "and / or" is only a description of the association relationship of the associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0161] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this article.

[0162] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0163] In the several embodiments provided herein, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of the units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, or can be electrical, mechanical or other forms of connection.

[0164] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of this article.

[0165] In addition, each functional unit in each embodiment of this invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit may be implemented in the form of hardware or in the form of software functional unit.

[0166] If the integrated unit is implemented in the form of 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 article is essentially 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, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of this article. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0167] Specific embodiments are used in this article to illustrate the principles and implementation methods of this article. The description of the above embodiments is only used to help understand the methods and core ideas of this article. At the same time, for general technicians in this field, according to the ideas of this article, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as a limitation on this article.

Claims

1. A cross-unit parameter sharing method, characterized in that: Applied to the server, the method includes: After receiving the service parameter change request, a change notification is generated, the clients to be changed are grouped, and the change notification is sent to each group of clients to be changed one by one, wherein the change notification includes the version number of the version to be changed; Receiving a data pull request initiated by each of the to-be-changed clients in response to the change notification; According to the data pull request, the version to be changed and the effective time of the version to be changed are sent to the client to be changed.

2. The method according to claim 1, characterized in that Also includes: Establishing a service relationship between the server and the client; Receiving a start query request sent by the client; Determine a list of versions to be pushed according to the startup query request, where the versions in the list of versions to be pushed are versions whose effective time is greater than the current time; Send the versions in the list of versions to be pushed to the client.

3. The method according to claim 1, characterized in that The generating change notification includes: Update the main version number table according to the business parameter change request; Determine the version of the non-pushed version number first written in the updated main version number table as the version to be changed; According to the version to be changed, the change notification is generated and sent one by one in groups to the client to be changed.

4. The method according to claim 3, characterized in that After receiving a business parameter change request, it also includes: Adjust the status of each version to be pushed in the updated main version number table to a locked state; After receiving confirmation information of successful change from each client, the locked state of the version to be changed is cancelled.

5. The method according to claim 1, characterized in that After sending the change notification, the method further includes: updating the notification status of the change notification; The method further comprises: The notification status of the change notification is polled, and an alarm is issued if an abnormality is found, wherein the abnormality includes: the notification status is not notified and timed out, the notification status is notified and timed out, and the notification status is notification completed and timed out.

6. The method according to claim 1, characterized in that The client groups to be changed include: Obtaining response characteristic information of the client to be changed; The clients to be changed are grouped according to the response characteristic information of the clients to be changed and the performance information of the server.

7. A cross-unit parameter sharing method, characterized in that: Applied to a client, the method comprises: Receive a change notification sent by the server, wherein the change notification includes a version number of the version to be changed; Sending a data pull request to the server according to the change notification; Receive and store the version to be changed and the effective time of the version to be changed, and send confirmation information to the server.

8. The method according to claim 7, characterized in that The method further comprises: Establishing a service relationship between the client and the server; Sending a start query request to the server; Receiving and storing the push version of the server; The pushed version is effective according to the effective time of the pushed version.

9. The method according to claim 8, characterized in that Also includes: Determine whether the effective time of the version to be changed has been reached; If the judgment is yes, the version to be changed will take effect.

10. A server, characterized in that: The server includes: A change notification module is used to generate a change notification after receiving a service parameter change request, group the clients to be changed, and send the change notification to each group of clients to be changed one by one, wherein the change notification includes the version number of the version to be changed; A first interaction module is used to receive a data pull request initiated by each of the to-be-changed clients in response to the change notification; The second interaction module is used to send the version to be changed and the effective time of the version to be changed to the client to be changed according to the data pull request.

11. A client, characterized in that: The client comprises: A third interaction module is used to receive a change notification sent by the server, wherein the change notification includes a version number of the version to be changed; A fourth interaction module, configured to send a data pull request to the server according to the change notification; The fifth interaction module is used to receive and store the version to be changed and the effective time of the version to be changed, and send confirmation information to the server.

12. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 9 is implemented.

13. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor of a computer device, the method according to any one of claims 1 to 9 is implemented.

14. A computer program product, comprising a computer program, characterized in that: When the computer program is executed by a processor of a computer device, the method according to any one of claims 1 to 9 is implemented.

Images