CN113157812A - Method and system for synchronizing distributed multi-cluster state class data - Google Patents
Method and system for synchronizing distributed multi-cluster state class data Download PDFInfo
- Publication number
- CN113157812A CN113157812A CN202110556863.7A CN202110556863A CN113157812A CN 113157812 A CN113157812 A CN 113157812A CN 202110556863 A CN202110556863 A CN 202110556863A CN 113157812 A CN113157812 A CN 113157812A
- Authority
- CN
- China
- Prior art keywords
- cluster
- login
- identifier
- login state
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 45
- 238000012217 deletion Methods 0.000 claims description 17
- 230000037430 deletion Effects 0.000 claims description 17
- 238000012795 verification Methods 0.000 claims description 9
- 230000001360 synchronised effect Effects 0.000 claims description 8
- 238000012546 transfer Methods 0.000 claims description 6
- 238000010586 diagram Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 2
- 238000013524 data verification Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- OEMCLQLAWYKPRK-OQLLNIDSSA-N N-[(E)-(5-bromo-2-hydroxyphenyl)methylideneamino]benzenesulfonamide Chemical compound Oc1ccc(Br)cc1\C=N\NS(=O)(=O)c2ccccc2 OEMCLQLAWYKPRK-OQLLNIDSSA-N 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/178—Techniques for file synchronisation in file systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The invention discloses a method and a system for synchronizing distributed multi-cluster state data, wherein when a login state identifier sent by a client is determined not to be stored in a local database of a current cluster, whether the login state identifier is created by the current cluster is determined by judging whether a target cluster identifier in the login state identifier is the same as the cluster identifier of the current cluster, if not, the login state identifier is used as a synchronization request parameter and sent to a target cluster corresponding to the target cluster identifier through an HTTP protocol, target user login state data corresponding to the login state identifier is requested to be obtained, and target user login state data returned by the target cluster are obtained and stored in the local database of the current cluster. The invention decentralizes all clusters, each cluster can independently serve, and when one cluster fails to provide service for users, other clusters can directly bear the service capability of the failed cluster according to the existing user login state data.
Description
Technical Field
The invention relates to the technical field of distributed systems, in particular to a method and a system for synchronizing distributed multi-cluster state class data.
Background
Currently, state class data (e.g., login state, authentication code state, etc.) of all clusters in a distributed multi-cluster needs to be kept synchronized. The existing solutions for implementing the synchronization of distributed cluster state class data mainly include two kinds: the first is centralized storage, wherein one cluster is designated as a master cluster from all the clusters, the master cluster is connected with a database master library, the rest clusters are used as slave clusters, and each cluster is connected with a database slave library. All the state class data are generated in the master cluster, and then the master cluster issues the generated state class data to the slave cluster. The second is to use message middleware in multiple clusters, after each cluster generates respective state class data, the state class data is distributed to the rest clusters in a message mode through the message middleware, and finally the state class data of all the clusters are consistent.
For the first solution, when the generation amount of the state class data at the same time is increased sharply, the server of the master cluster will face a huge pressure, and when the master cluster fails or a network failure occurs, the state class data and the distribution of the state class data cannot be generated, so that the service cannot be provided for the user. For the second solution, because a third-party message middleware is introduced, if a message is missing or blocked, additional processing is required for the return source of the state class data, and the introduction of the message middleware can increase additional research and development costs and operation and maintenance costs.
Disclosure of Invention
In view of the above, the present invention discloses a method and a system for synchronizing distributed multi-cluster state class data, so as to implement that non-existent data is compensated by a remote cluster in an active manner, and finally implement consistency of stored data of all clusters, so that a user can provide corresponding services for the user no matter which cluster the user accesses, when one of the clusters fails to provide services for the user, other clusters can directly bear the service capability of the failed cluster according to existing user login state data, and no message middleware needs to be introduced, thereby solving the problems in the prior art.
A synchronization method for distributed multi-cluster state class data comprises the following steps:
acquiring a login state identifier sent by a client, wherein the login state identifier is used for representing that a user is in a successful login state in a multi-cluster;
judging whether the local database of the current cluster stores the login state identification or not;
if not, judging whether the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster;
if not, the login state identification is used as a synchronous request parameter and is sent to a target cluster corresponding to the target cluster identification through a hypertext transfer protocol (HTTP) protocol, and target user login state data corresponding to the login state identification is requested to be obtained;
acquiring the target user login state data returned by the target cluster responding to the synchronous request parameter;
and storing the target user login state data to a local database of the current cluster.
Optionally, when the local database of the current cluster stores the login status identifier, the method further includes:
when the target cluster identifier in the login state identifier is the same as the cluster identifier of the current cluster, judging whether the login state identifier is invalid according to a preset service rule;
if so, deleting the login state identification from the local database of the current cluster;
and sending a deletion request of the login state identifier to the clusters except the current cluster through an HTTP protocol, so that the clusters except the current cluster delete the login state identifier from the corresponding local database.
Optionally, the method further includes:
when the target cluster identifier in the login state identifier is different from the cluster identifier of the current cluster, judging whether the login state identifier is invalid according to the preset service rule;
and if so, deleting the login state identification from the local database of the current cluster.
Optionally, the method further includes:
judging whether the local data of the current cluster stores the failed user login state data or not;
and if so, deleting the login state data of the failed user.
Optionally, when the user logs in the current cluster for the first time, the method further includes:
acquiring a user login request sent by the client, wherein the user login request carries login information of the current cluster;
comparing the login information with pre-stored reference login information, and performing validity check on the login information;
after the login information passes validity verification, creating a login state identifier in the current cluster, wherein the login state identifier has the cluster identifier of the current cluster;
assembling the login state identification, the user related attribute information and the preset validity period into a complete user login state data;
and storing the user login state data to a local database of the current cluster, and immediately responding to the successful login of the user.
Optionally, the method further includes:
and asynchronously distributing the user login state data to each target cluster except the current cluster through an HTTP (hyper text transport protocol), so that each target cluster stores the received user login state data to a corresponding local database.
A system for synchronizing distributed multi-cluster state class data, comprising:
the system comprises an identification acquisition unit, a login state identification and a login control unit, wherein the identification acquisition unit is used for acquiring the login state identification sent by a client, and the login state identification is used for representing that a user is in a successful login state in a multi-cluster;
the first judging unit is used for judging whether the login state identification is stored in a local database of the current cluster;
a second judging unit, configured to, if the first judging unit judges that the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster, judge whether the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster;
a first sending unit, configured to, when the second determining unit determines that the target user is not logged in, send the login status identifier as a synchronization request parameter to a target cluster corresponding to the target cluster identifier through a hypertext transfer protocol HTTP protocol, and request to obtain target user login status data corresponding to the login status identifier;
a data obtaining unit, configured to obtain the target user login status data returned by the target cluster in response to the synchronization request parameter;
and the first storage unit is used for storing the login state data of the target user to a local database of the current cluster.
Optionally, the method further includes:
a third judging unit, configured to, when the first judging unit judges that the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster, judge, according to a preset service rule, whether the login status identifier has failed;
a first deleting unit, configured to delete the login status identifier from the local database of the current cluster if the third determining unit determines that the current cluster is the current cluster;
and a second sending unit, configured to send a deletion request of the login status identifier to a cluster other than the current cluster through an HTTP protocol, so that the cluster other than the current cluster deletes the login status identifier from a corresponding local database.
Optionally, the method further includes:
a fourth judging unit, configured to, when a target cluster identifier in the login status identifier is different from the cluster identifier of the current cluster, judge whether the login status identifier has failed according to the preset service rule;
and a second deleting unit, configured to delete the login status identifier from the local database of the current cluster if the fourth determining unit determines that the current cluster is a cluster.
Optionally, the method further includes:
a fifth judging unit, configured to judge whether the local data of the current cluster stores failed user login status data;
and a third deleting unit configured to delete the failed user login status data when the fifth determining unit determines that the user login status data is valid.
Optionally, the method further includes:
the request acquisition unit is used for acquiring a user login request sent by the client when a user logs in the current cluster for the first time, wherein the user login request carries login information of the current cluster;
the comparison unit is used for comparing the login information with pre-stored reference login information and carrying out validity check on the login information;
the identification creating unit is used for creating a login state identification in the current cluster after the login information passes validity verification, wherein the login state identification has the cluster identification of the current cluster;
the assembling unit is used for assembling the login state identifier, the user related attribute information and the preset validity period into a complete user login state data;
and the second storage unit is used for storing the user login state data to a local database of the current cluster and immediately responding to the successful login of the user.
Optionally, the method further includes:
and the distribution unit is used for asynchronously distributing the user login state data to each target cluster except the current cluster through an HTTP (hyper text transport protocol), so that each target cluster stores the received user login state data to a corresponding local database.
According to the technical scheme, when the login status identifier sent by the client is determined not to be stored in the local database of the current cluster, whether the login status identifier is created by the current cluster is determined by judging whether the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster, if not, the login status identifier is used as a synchronization request parameter and sent to the target cluster corresponding to the target cluster identifier through an HTTP protocol, target user login status data corresponding to the login status identifier is requested to be obtained, target user login status data returned by the target cluster are obtained, and the target user login status data are stored in the local database of the current cluster. The invention decentralizes each cluster, each cluster can independently serve to realize the read-write function of state data, each cluster preferentially uses the data source of the cluster in a data reading scene, and when the user login state data is not stored in the cluster, the user login state data is obtained from the corresponding cluster according to the login state identification mark to compensate the user login state data missing from the cluster. Therefore, the remote cluster in the invention can actively acquire the user login state data which does not exist in the cluster from the cluster created by the login state identifier and store the user login state data in the local database, so that the remote cluster can compensate the nonexistent data in an active mode, and finally the consistency of the stored data of all clusters is realized, so that a user can provide corresponding service for the user no matter which cluster the user accesses, when one cluster fails to provide service for the user, other clusters can directly bear the service capability of the failed cluster according to the existing user login state data, and message middleware is not required to be introduced, thereby solving the problems in the prior art.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the disclosed drawings without creative efforts.
FIG. 1 is a flowchart of a method for synchronizing distributed multi-cluster state class data according to an embodiment of the present invention;
FIG. 2 is a timing diagram illustrating a cross-cluster data synchronization disclosed in an embodiment of the present invention;
FIG. 3 is a timing diagram illustrating a cross-cluster data deletion disclosed in an embodiment of the present invention;
FIG. 4 is a timing diagram illustrating a cross-cluster data distribution according to an embodiment of the present invention;
fig. 5 is a schematic structural diagram of a distributed multi-cluster state class data synchronization system disclosed in the embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The embodiment of the invention discloses a method and a system for synchronizing distributed multi-cluster state class data, wherein when the fact that a login state identifier sent by a client is not stored in a local database of a current cluster is determined, whether the login state identifier is created by the current cluster is determined by judging whether a target cluster identifier in the login state identifier is the same as a cluster identifier of the current cluster, if not, the login state identifier is used as a synchronization request parameter and sent to a target cluster corresponding to the target cluster identifier through an HTTP protocol, target user login state data corresponding to the login state identifier is requested to be obtained, target user login state data returned by the target cluster are obtained, and the target user login state data are stored in the local database of the current cluster. The invention decentralizes each cluster, each cluster can independently serve to realize the read-write function of state data, each cluster preferentially uses the data source of the cluster in a data reading scene, and when the user login state data is not stored in the cluster, the user login state data is obtained from the corresponding cluster according to the login state identification mark to compensate the user login state data missing from the cluster. Therefore, the remote cluster in the invention can actively acquire the user login state data which does not exist in the cluster from the cluster created by the login state identifier and store the user login state data in the local database, so that the remote cluster can compensate the nonexistent data in an active mode, and finally the consistency of the stored data of all clusters is realized, so that a user can provide corresponding service for the user no matter which cluster the user accesses, when one cluster fails to provide service for the user, other clusters can directly bear the service capability of the failed cluster according to the existing user login state data, and message middleware is not required to be introduced, thereby solving the problems in the prior art.
Referring to fig. 1, a flowchart of a synchronization method for distributed multi-cluster state class data disclosed in the embodiment of the present invention includes:
step S101, obtaining a login state identifier sent by a client;
and the login state identifier is used for representing that the user is in a successful login state in the multi-cluster.
When a user successfully logs in a certain cluster in a plurality of clusters before, login information including a user name and a password does not need to be input again when the user starts an application next time, and a login state identifier is created after the user successfully logs in for the first time and is used as a login-free ticket of the user within a preset validity period (such as three months).
In practical application, the multiple clusters at least comprise two clusters, and each cluster is configured with an intranet domain name on an operation and maintenance side for the clusters to call each other. The intranet domain name back end of the cluster is in load balance corresponding to corresponding services, a rear specific server address is not concerned, any server at the back end can process the request of the intranet domain name, and has idempotent for repeated data, wherein the idempotent refers to that one more request is processed repeatedly, and the returned results are the same. Taking the example that the multiple clusters include cluster one, cluster two, and cluster three, the intranet domain name of cluster one may be hx (h denotes a cluster, and x denotes a cluster number), the intranet domain name of cluster two may be hy (h denotes a cluster, and y denotes a cluster number), and the intranet domain name of cluster three may be hz (h denotes a cluster, and z denotes a cluster number).
Regarding the login status identifier, for example, when the user logs in the first cluster (hx), after the login information (user name and password) of the user passes the verification of the current cluster, a login status identifier is generated in the current cluster, and the login status identifier may be a character string, the character string data starts with the cluster identifier shx1, where the first character s identifies the Server, the second and third characters are the identifiers of the clusters, hx represents the first cluster, hy represents the second cluster, hz represents the third cluster, the fourth character is the cluster number, 1 represents the first cluster, the value increases in order, and 2 represents the second cluster. In the login status identifier, the shx1 identifies a first service cluster in the first cluster, the shx2 identifies a second service cluster in the first cluster, the corresponding shy1 corresponds to the first cluster in the second cluster, the shz1 corresponds to the first cluster in the third cluster, the cluster number means that multiple sets of logical clusters can be independently deployed in the same physical cluster, and data between each set of logical clusters is completely independent.
Step S102, judging whether the local database of the current cluster stores the login state identification, if not, executing step S103;
under normal conditions, most users drifting to another cluster can search the user login state data in the local database of the current cluster. When the user is identified in the created login state of the first cluster, the access point is shifted to the second cluster for login, and then the local database of the second cluster is preferentially inquired.
Step S103, judging whether the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster, if not, executing step S104;
if the local database of the current cluster does not inquire the login state identifier, whether the login state identifier of the user is created in the current cluster is firstly checked, for example, the cluster identifier of the second cluster is shy1, and the cluster identifier in the login state identifier is shx1, which means that the login state identifier is created in the first cluster, at this time, the login state identifier shx1xxxx is used as a synchronization request parameter and is sent to the first cluster through an HTTP protocol, and the login state data of the target user corresponding to the login state identifier is obtained by calling the intranet domain name of the first cluster.
Step S104, sending the login state identification as a synchronous request parameter to a target cluster corresponding to the target cluster identification through an HTTP (hyper text transport protocol), and requesting to acquire target user login state data corresponding to the login state identification;
HTTP (HyperText Transfer Protocol) is a simple request-response Protocol that typically runs over TCP (Transmission Control Protocol) and specifies what messages a client may send to a server and what responses it gets.
The method comprises the steps of storing login state data in the cluster at different places, after the cluster at different places (such as the cluster two (hy) and the cluster three (hz)) receives a data distribution request of the cluster one (hx), firstly checking whether a login state identifier in the request exists, if so, repeatedly initiating the request belonging to the cluster one (hx), and ignoring the current request without any operation. If the login state identification does not exist, the login state identification is asynchronously stored in a database of the cluster, and the redundant storage of the login state data of the remote cluster is completed.
Step S105, obtaining the target user login state data returned by the target cluster responding to the synchronous request parameter;
when the target cluster does not return target user login state data corresponding to the login state identifier, it is determined that acquisition of the target user login state data fails, and at this time, the user needs to log in again manually, that is, the user needs to input login information again in the current cluster.
And step S106, storing the target user login state data to a local database of the current cluster.
In practical application, in order to avoid repeated storage of target user login state data in a local database of a current cluster, the current cluster also verifies whether the target user login state data is already stored in the local database before the target user login state data is stored, and the target user login state data is stored in the local database of the current cluster only when the target user login state data is determined not to be stored in the local database; otherwise, the target user login state data is not stored in the local database of the current cluster.
To sum up, the invention discloses a synchronization method of distributed multi-cluster state class data, when it is determined that a login state identifier sent by a client is not stored in a local database of a current cluster, whether the login state identifier is created by the current cluster is determined by judging whether a target cluster identifier in the login state identifier is the same as a cluster identifier of the current cluster, if not, the login state identifier is used as a synchronization request parameter and sent to a target cluster corresponding to the target cluster identifier through an HTTP protocol, target user login state data corresponding to the login state identifier is requested to be obtained, target user login state data returned by the target cluster are obtained, and the target user login state data are stored in the local database of the current cluster. The invention decentralizes each cluster, each cluster can independently serve to realize the read-write function of state data, each cluster preferentially uses the data source of the cluster in a data reading scene, and when the user login state data is not stored in the cluster, the user login state data is obtained from the corresponding cluster according to the login state identification mark to compensate the user login state data missing from the cluster. Therefore, the remote cluster in the invention can actively acquire the user login state data which does not exist in the cluster from the cluster created by the login state identifier and store the user login state data in the local database, so that the remote cluster can compensate the nonexistent data in an active mode, finally the consistency of all cluster stored data is realized, corresponding services can be provided for users no matter which cluster the users access, and no message middleware is required to be introduced, thereby solving the problems in the prior art.
In addition, when one cluster fails and cannot provide service for the user, other clusters can directly bear the service capacity of the failed cluster according to the existing user login state data.
To further optimize the above embodiment, after step S106, the method may further include:
judging whether the login state and the validity period of the user are valid or not according to a preset service rule;
and if so, returning the user login state to the client as valid.
To facilitate understanding of the synchronization process of distributed multi-cluster state class data, see the cross-cluster data synchronization timing diagram shown in fig. 2, comprising in multiple clusters: taking the first cluster (hx), the second cluster (hy), and the third cluster (hz) as examples, when the client needs to automatically log in the second cluster, the client sends a login state identifier shx1xxxx to the second cluster, and the second cluster queries whether the local database stores the login state identifier shx1 xxxx. In a normal scenario, the database of the cluster (i.e., cluster two) has redundant data of a remote cluster, and in order to completely describe the whole process of cross-cluster data compensation (i.e., synchronization), it is assumed that the database of the cluster (i.e., cluster two) does not store the login state identifier shx1 xxxx. The cluster II judges the attribution of the login state identifier shx1xxxx by judging whether a target cluster identifier in the login state identifiers is the same as the cluster identifier of the current cluster, when the cluster identifier of the cluster II is shy1 and the target cluster identifier in the login state identifiers is shx1, the login state identifier shx1xxxx is established in one cluster, at the moment, the cluster II sends the login state identifier shx1xxxx to the cluster II through an HTTP protocol as a synchronous request parameter to request to acquire login state data corresponding to the login state identifier shx1xxxx (namely, complete login state data is acquired through an HTTP request attribution area), the cluster II acquires login state data corresponding to the login state identifier shx1xxxx by responding to the login state identifier shx1xxxx by the cluster I, when the cluster II determines that the login state data is not stored in the local database, the login state data is stored in the local database, after the services such as validity and validity period of the login state data are passed, and returning prompt information that the user login state is valid to the client.
It should be noted that, when receiving data requests of other clusters, the internal cluster communication interface in the present invention performs corresponding addition, update, and deletion operations according to the interface action identifier, where the internal cluster communication interface performs validity check in MD5 signature manner, and is in JSON format.
In order to further optimize the above embodiments, the present invention may also perform a cross-cluster data deletion operation.
Specifically, when the determination in step S102 is yes, that is, when it is determined that the login status identifier is stored in the local database of the current cluster, it is further checked whether the login status identifier is invalid, and when it is determined that the login status identifier is invalid, different deletion operations are performed according to the difference in creating the login status identifier cluster.
Therefore, when the local database of the current cluster stores the login state identifier, the method for synchronizing the distributed multi-cluster state class data may further include:
1) when the target cluster identifier in the login state identifier is the same as the cluster identifier of the current cluster, judging whether the login state identifier is invalid according to a preset service rule;
2) if so, deleting the login state identification from the local database of the current cluster;
2) and sending a deletion request of the login state identifier to the clusters except the current cluster through an HTTP protocol, so that the clusters except the current cluster delete the login state identifier from the corresponding local database.
The current cluster actively informs other clusters of deleting the failed login state identifier, so that the current cluster informs other clusters of deleting the failed login state identifier in an active mode. If the interface call fails, the current cluster can be actively deleted during data verification, and the failed login state identifier can be deleted during the execution of the timing task, and the consistency of the stored data in all the clusters is ensured.
Specifically, referring to the cross-cluster data deletion timing diagram shown in fig. 3, the client sends the login status identifier shx1xxxx to the first cluster, when the cluster one query local database stores the login state identifier shx1xxxx, and the target cluster identifier shx1 in the login state identifier shx1xxxx is the same as the cluster identifier of cluster one, determining that the login state identifier shx1xxxx is created by a first cluster, verifying whether the login state identifier shx1xxxx fails by the first cluster, when determining that the login state identifier shx1xxxx has failed, deleting the login state identifier shx1xxxx from the local database of the first cluster, outputting prompt information that the automatic login is invalid to the client, sending a deletion request of the login state identifier to the second cluster and the third cluster through an HTTP protocol by the first cluster, enabling the second cluster and the third cluster to delete the login state identifier from the corresponding local database and send the deletion request, or, the first cluster sends an HTTP request to notify the second cluster and the third cluster to delete the locally stored login state identifiers shx1xxxx respectively.
It should be noted that, when the target cluster identifier in the login status identifier is different from the cluster identifier of the current cluster, whether the login status identifier is invalid is judged according to a preset service rule;
and if so, deleting the login state identification from the local database of the current cluster.
The preset business rule is determined according to actual needs, and the invention is not limited herein.
That is, if the login status identifier created by the first cluster is sent to the second cluster by the client, when the second cluster determines that the login status identifier is invalid, the second cluster only deletes the login status identifier from the local database of the second cluster, and because the login status identifier is not created by the second cluster, the second cluster does not initiate notification of other clusters to delete the login status identifier from each database.
In the invention, each cluster is provided with a timing task for clearing the logging state data of the failed user, and assisting to ensure data accuracy and reduce invalid data volume under the scene when the intranet among the clusters notifies that the deletion and calling are failed.
Therefore, the synchronization method for distributed multi-cluster state class data may further include:
judging whether the local data of the current cluster stores the failed user login state data or not;
and if so, deleting the login state data of the failed user.
It should be noted that, deletion of part of the user login state data is not triggered when the verification fails, and according to the service requirement, the client may be notified to execute a logic of replacing a new login state when the user login state data is close to a week, at this time, the old data is deleted, the old data is distributed and deleted, the new data is created, and the new data is distributed and created, where the specific logic is determined by an actual service scenario.
When a user logs in a cluster by using login information including a user name and a password for the first time, after the service passes the validity check of the account and the password of the user center, generating a login state identifier of shx1xxxx of a cluster I for the user; the login state identifier is a certificate which can be used in a short period (for example, three months) to prove the validity of the user, and does not mean that the sessionId and the like are used by the user in a single session, and the login state identifier is a service category identifier and is not described herein.
When the user logs in the current cluster for the first time, referring to the cross-cluster data distribution timing diagram shown in fig. 4, the synchronization method may further include:
1) acquiring a user login request sent by a client, wherein the user login request carries login information of the current cluster;
2) comparing the login information with pre-stored reference login information, and performing validity check on the login information;
in practical application, the login information carried in the user login request sent by the client may be compared with a reference login prestored in the user center, and the user center may be presented in a database or an application platform.
3) After the login information passes validity verification, creating a login state identifier in the current cluster, wherein the login state identifier has the cluster identifier of the current cluster;
4) assembling the login state identification, the user related attribute information and the preset validity period into a complete user login state data;
wherein the user-related attribute information includes a user ID.
5) And storing the user login state data to a local database of the current cluster, and immediately responding to the successful login of the user.
6) And asynchronously distributing the user login state data to each target cluster except the current cluster through an HTTP (hyper text transport protocol), so that each target cluster stores the received user login state data to a corresponding local database.
Specifically, referring to fig. 4, in this embodiment, the first cluster acquires a user login request sent by the client, performs validity check on the login request and reference login information pre-stored in the user center, after the verification is passed, the first cluster creates a login state identifier, assembles the login state identifier, the user-related attribute information, and the preset validity period into a complete user login state data, stores the complete user login state data in the local database, and responds to the client that the user successfully logs in. And the first cluster asynchronously distributes the user login state data to the second cluster and the third cluster through an HTTP (hyper text transport protocol), and the second cluster and the third cluster store the user login state data to each corresponding local database.
Wherein, the whole data distribution process is completed by an asynchronous thread.
In summary, the invention discloses a synchronization method of distributed multi-cluster state class data, centralizing each cluster, enabling each cluster to independently serve to realize the read-write function of the state class data, preferentially using a data source of the cluster by each cluster in a data reading scene, and acquiring user login state data from a corresponding cluster according to a login state identification mark when the user login state data is not stored in the cluster, so as to compensate the user login state data missing from the cluster. In a data writing scene, after the data source of the cluster is synchronously written, the data is distributed to other clusters in an asynchronous mode, so that the other clusters have redundant data of the cluster, and full authentication service can be provided for the state data of the cluster at any time. The remote cluster can actively acquire user login state data which does not exist in the cluster from the cluster created by the login state identification and store the user login state data in the local database, so that the remote cluster can compensate the nonexistent data in an active mode, the consistency of all cluster stored data is finally realized, corresponding services can be provided for users no matter which cluster the users access, and no message middleware is required to be introduced, so that the problems in the prior art are solved.
In addition, when one cluster fails and cannot provide service for the user, other clusters can directly bear the service capacity of the failed cluster according to the existing user login state data.
Corresponding to the embodiment of the method, the invention also discloses a synchronization system of the distributed multi-cluster state class data.
Referring to fig. 5, a schematic structural diagram of a synchronization system for distributed multi-cluster state class data disclosed in the embodiment of the present invention includes:
an identifier obtaining unit 201, configured to obtain a login status identifier sent by a client, where the login status identifier is used to represent that a user has successfully logged in a multi-cluster;
when a user successfully logs in a certain cluster in a plurality of clusters before, login information including a user name and a password does not need to be input again when the user starts an application next time, and a login state identifier is created after the user successfully logs in for the first time and is used as a login-free ticket of the user within a preset validity period (such as three months).
A first determining unit 202, configured to determine whether the login status identifier is stored in a local database of the current cluster;
under normal conditions, most users drifting to another cluster can search the user login state data in the local database of the current cluster. When the user is identified in the created login state of the first cluster, the access point is shifted to the second cluster for login, and then the local database of the second cluster is preferentially inquired.
A second judging unit 203, configured to, if the first judging unit judges that the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster, judge whether the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster;
if the local database of the current cluster does not inquire the login state identifier, whether the login state identifier of the user is created in the current cluster is firstly checked, for example, the cluster identifier of the second cluster is shy1, and the cluster identifier in the login state identifier is shx1, which means that the login state identifier is created in the first cluster, at this time, the login state identifier shx1xxxx is used as a synchronization request parameter and is sent to the first cluster through an HTTP protocol, and the login state data of the target user corresponding to the login state identifier is obtained by calling the intranet domain name of the first cluster.
A first sending unit 204, configured to, when the second determining unit determines that the target user login status data corresponds to the login status identifier, send the login status identifier as a synchronization request parameter to a target cluster corresponding to the target cluster identifier through a hypertext transfer protocol HTTP protocol, and request to obtain target user login status data corresponding to the login status identifier;
the method comprises the steps of storing login state data in the cluster at different places, after the cluster at different places (such as the cluster two (hy) and the cluster three (hz)) receives a data distribution request of the cluster one (hx), firstly checking whether a login state identifier in the request exists, if so, repeatedly initiating the request belonging to the cluster one (hx), and ignoring the current request without any operation. If the login state identification does not exist, the login state identification is asynchronously stored in a database of the cluster, and the redundant storage of the login state data of the remote cluster is completed.
A data obtaining unit 205, configured to obtain the target user login status data returned by the target cluster in response to the synchronization request parameter;
when the target cluster does not return target user login state data corresponding to the login state identifier, it is determined that acquisition of the target user login state data fails, and at this time, the user needs to log in again manually, that is, the user needs to input login information again in the current cluster.
A first storage unit 206, configured to store the login status data of the target user to a local database of the current cluster.
In practical application, in order to avoid repeated storage of target user login state data in a local database of a current cluster, the current cluster also verifies whether the target user login state data is already stored in the local database before the target user login state data is stored, and the target user login state data is stored in the local database of the current cluster only when the target user login state data is determined not to be stored in the local database; otherwise, the target user login state data is not stored in the local database of the current cluster.
To sum up, the invention discloses a distributed multi-cluster state data synchronization system, when it is determined that a login state identifier sent by a client is not stored in a local database of a current cluster, whether the login state identifier is created by the current cluster is determined by judging whether a target cluster identifier in the login state identifier is the same as a cluster identifier of the current cluster, if not, the login state identifier is used as a synchronization request parameter and sent to a target cluster corresponding to the target cluster identifier through an HTTP protocol, target user login state data corresponding to the login state identifier is requested to be obtained, target user login state data returned by the target cluster are obtained, and the target user login state data are stored in the local database of the current cluster. The invention decentralizes each cluster, each cluster can independently serve to realize the read-write function of state data, each cluster preferentially uses the data source of the cluster in a data reading scene, and when the user login state data is not stored in the cluster, the user login state data is obtained from the corresponding cluster according to the login state identification mark to compensate the user login state data missing from the cluster. Therefore, the remote cluster in the invention can actively acquire the user login state data which does not exist in the cluster from the cluster created by the login state identifier and store the user login state data in the local database, so that the remote cluster can compensate the nonexistent data in an active mode, finally the consistency of all cluster stored data is realized, corresponding services can be provided for users no matter which cluster the users access, and no message middleware is required to be introduced, thereby solving the problems in the prior art.
In addition, when one cluster fails and cannot provide service for the user, other clusters can directly bear the service capacity of the failed cluster according to the existing user login state data.
In order to further optimize the above embodiments, the present invention may also perform a cross-cluster data deletion operation.
Specifically, when the first determining unit 202 determines that the cluster is a cluster, that is, when it is determined that the local database of the current cluster stores the login status identifier, it is further determined whether the login status identifier is invalid, and when it is determined that the login status identifier is invalid, different deleting operations are performed according to the difference in creating the login status identifier cluster.
Therefore, the synchronization system of the distributed multi-cluster state class data may further include:
a third determining unit, configured to, when the first determining unit 202 determines that the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster, determine whether the login status identifier has failed according to a preset service rule;
a first deleting unit, configured to delete the login status identifier from the local database of the current cluster if the third determining unit determines that the current cluster is the current cluster;
and a second sending unit, configured to send a deletion request of the login status identifier to a cluster other than the current cluster through an HTTP protocol, so that the cluster other than the current cluster deletes the login status identifier from a corresponding local database.
The current cluster actively informs other clusters of deleting the failed login state identifier, so that the current cluster informs other clusters of deleting the failed login state identifier in an active mode. If the interface call fails, the current cluster can be actively deleted during data verification, and the failed login state identifier can be deleted during the execution of the timing task, and the consistency of the stored data in all the clusters is ensured.
To further optimize the above embodiment, the synchronization system may further include:
a fourth judging unit, configured to, when a target cluster identifier in the login status identifier is different from the cluster identifier of the current cluster, judge whether the login status identifier has failed according to the preset service rule;
and a second deleting unit, configured to delete the login status identifier from the local database of the current cluster if the fourth determining unit determines that the current cluster is a cluster.
The preset business rule is determined according to actual needs, and the invention is not limited herein.
In the invention, each cluster is provided with a timing task for clearing the logging state data of the failed user, and assisting to ensure data accuracy and reduce invalid data volume under the scene when the intranet among the clusters notifies that the deletion and calling are failed.
Therefore, the synchronization system may further include:
a fifth judging unit, configured to judge whether the local data of the current cluster stores failed user login status data;
and a third deleting unit configured to delete the failed user login status data when the fifth determining unit determines that the user login status data is valid.
When a user logs in a cluster by using login information including a user name and a password for the first time, after the service passes the validity check of the account and the password of the user center, generating a login state identifier of shx1xxxx of a cluster I for the user; the login state identifier is a certificate which can be used in a short period (for example, three months) to prove the validity of the user, and does not mean that the sessionId and the like are used by the user in a single session, and the login state identifier is a service category identifier and is not described herein.
Therefore, the synchronization system may further include:
the request acquisition unit is used for acquiring a user login request sent by the client when a user logs in the current cluster for the first time, wherein the user login request carries login information of the current cluster;
the comparison unit is used for comparing the login information with pre-stored reference login information and carrying out validity check on the login information;
the identification creating unit is used for creating a login state identification in the current cluster after the login information passes validity verification, wherein the login state identification has the cluster identification of the current cluster;
the assembling unit is used for assembling the login state identifier, the user related attribute information and the preset validity period into a complete user login state data;
and the second storage unit is used for storing the user login state data to a local database of the current cluster and immediately responding to the successful login of the user.
And the distribution unit is used for asynchronously distributing the user login state data to each target cluster except the current cluster through an HTTP (hyper text transport protocol), so that each target cluster stores the received user login state data to a corresponding local database.
In summary, the invention discloses a distributed multi-cluster state data synchronization system, which is used for decentralizing each cluster, each cluster can independently serve to realize the read-write function of state data, each cluster preferentially uses a data source of the cluster in a data reading scene, and when the user login state data is not stored in the cluster, the user login state data is obtained from the corresponding cluster according to a login state identification, and the missing user login state data of the cluster is compensated. In a data writing scene, after the data source of the cluster is synchronously written, the data is distributed to other clusters in an asynchronous mode, so that the other clusters have redundant data of the cluster, and full authentication service can be provided for the state data of the cluster at any time. The remote cluster can actively acquire user login state data which does not exist in the cluster from the cluster created by the login state identification and store the user login state data in the local database, so that the remote cluster can compensate the nonexistent data in an active mode, the consistency of all cluster stored data is finally realized, corresponding services can be provided for users no matter which cluster the users access, and no message middleware is required to be introduced, so that the problems in the prior art are solved.
In addition, when one cluster fails and cannot provide service for the user, other clusters can directly bear the service capacity of the failed cluster according to the existing user login state data.
It should be noted that, for the specific working principle of each component in the system embodiment, please refer to the corresponding part of the method embodiment, which is not described herein again.
Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The embodiments in the present description are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (12)
1. A method for synchronizing distributed multi-cluster state class data is characterized by comprising the following steps:
acquiring a login state identifier sent by a client, wherein the login state identifier is used for representing that a user is in a successful login state in a multi-cluster;
judging whether the local database of the current cluster stores the login state identification or not;
if not, judging whether the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster;
if not, the login state identification is used as a synchronous request parameter and is sent to a target cluster corresponding to the target cluster identification through a hypertext transfer protocol (HTTP) protocol, and target user login state data corresponding to the login state identification is requested to be obtained;
acquiring the target user login state data returned by the target cluster responding to the synchronous request parameter;
and storing the target user login state data to a local database of the current cluster.
2. The synchronization method according to claim 1, when the login status identifier is stored in the local database of the current cluster, further comprising:
when the target cluster identifier in the login state identifier is the same as the cluster identifier of the current cluster, judging whether the login state identifier is invalid according to a preset service rule;
if so, deleting the login state identification from the local database of the current cluster;
and sending a deletion request of the login state identifier to the clusters except the current cluster through an HTTP protocol, so that the clusters except the current cluster delete the login state identifier from the corresponding local database.
3. The synchronization method of claim 2, further comprising:
when the target cluster identifier in the login state identifier is different from the cluster identifier of the current cluster, judging whether the login state identifier is invalid according to the preset service rule;
and if so, deleting the login state identification from the local database of the current cluster.
4. The synchronization method of claim 1, further comprising:
judging whether the local data of the current cluster stores the failed user login state data or not;
and if so, deleting the login state data of the failed user.
5. The synchronization method of claim 1, further comprising, when a user first logs into the current cluster:
acquiring a user login request sent by the client, wherein the user login request carries login information of the current cluster;
comparing the login information with pre-stored reference login information, and performing validity check on the login information;
after the login information passes validity verification, creating a login state identifier in the current cluster, wherein the login state identifier has the cluster identifier of the current cluster;
assembling the login state identification, the user related attribute information and the preset validity period into a complete user login state data;
and storing the user login state data to a local database of the current cluster, and immediately responding to the successful login of the user.
6. The synchronization method of claim 5, further comprising:
and asynchronously distributing the user login state data to each target cluster except the current cluster through an HTTP (hyper text transport protocol), so that each target cluster stores the received user login state data to a corresponding local database.
7. A system for synchronizing distributed multi-cluster state class data, comprising:
the system comprises an identification acquisition unit, a login state identification and a login control unit, wherein the identification acquisition unit is used for acquiring the login state identification sent by a client, and the login state identification is used for representing that a user is in a successful login state in a multi-cluster;
the first judging unit is used for judging whether the login state identification is stored in a local database of the current cluster;
a second judging unit, configured to, if the first judging unit judges that the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster, judge whether the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster;
a first sending unit, configured to, when the second determining unit determines that the target user is not logged in, send the login status identifier as a synchronization request parameter to a target cluster corresponding to the target cluster identifier through a hypertext transfer protocol HTTP protocol, and request to obtain target user login status data corresponding to the login status identifier;
a data obtaining unit, configured to obtain the target user login status data returned by the target cluster in response to the synchronization request parameter;
and the first storage unit is used for storing the login state data of the target user to a local database of the current cluster.
8. The synchronization system of claim 7, further comprising:
a third judging unit, configured to, when the first judging unit judges that the target cluster identifier in the login status identifier is the same as the cluster identifier of the current cluster, judge, according to a preset service rule, whether the login status identifier has failed;
a first deleting unit, configured to delete the login status identifier from the local database of the current cluster if the third determining unit determines that the current cluster is the current cluster;
and a second sending unit, configured to send a deletion request of the login status identifier to a cluster other than the current cluster through an HTTP protocol, so that the cluster other than the current cluster deletes the login status identifier from a corresponding local database.
9. The synchronization system of claim 8, further comprising:
a fourth judging unit, configured to, when a target cluster identifier in the login status identifier is different from the cluster identifier of the current cluster, judge whether the login status identifier has failed according to the preset service rule;
and a second deleting unit, configured to delete the login status identifier from the local database of the current cluster if the fourth determining unit determines that the current cluster is a cluster.
10. The synchronization system of claim 7, further comprising:
a fifth judging unit, configured to judge whether the local data of the current cluster stores failed user login status data;
and a third deleting unit configured to delete the failed user login status data when the fifth determining unit determines that the user login status data is valid.
11. The synchronization system of claim 7, further comprising:
the request acquisition unit is used for acquiring a user login request sent by the client when a user logs in the current cluster for the first time, wherein the user login request carries login information of the current cluster;
the comparison unit is used for comparing the login information with pre-stored reference login information and carrying out validity check on the login information;
the identification creating unit is used for creating a login state identification in the current cluster after the login information passes validity verification, wherein the login state identification has the cluster identification of the current cluster;
the assembling unit is used for assembling the login state identifier, the user related attribute information and the preset validity period into a complete user login state data;
and the second storage unit is used for storing the user login state data to a local database of the current cluster and immediately responding to the successful login of the user.
12. The synchronization system of claim 11, further comprising:
and the distribution unit is used for asynchronously distributing the user login state data to each target cluster except the current cluster through an HTTP (hyper text transport protocol), so that each target cluster stores the received user login state data to a corresponding local database.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110556863.7A CN113157812A (en) | 2021-05-21 | 2021-05-21 | Method and system for synchronizing distributed multi-cluster state class data |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110556863.7A CN113157812A (en) | 2021-05-21 | 2021-05-21 | Method and system for synchronizing distributed multi-cluster state class data |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113157812A true CN113157812A (en) | 2021-07-23 |
Family
ID=76876985
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110556863.7A Pending CN113157812A (en) | 2021-05-21 | 2021-05-21 | Method and system for synchronizing distributed multi-cluster state class data |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113157812A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113949704A (en) * | 2021-10-15 | 2022-01-18 | 北京奇艺世纪科技有限公司 | User information processing method and server cluster |
| CN113986135A (en) * | 2021-10-27 | 2022-01-28 | 北京百度网讯科技有限公司 | Method, device, equipment and storage medium for processing request |
| CN114124508A (en) * | 2021-11-16 | 2022-03-01 | 上海浦东发展银行股份有限公司 | Application login method and system |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109067785A (en) * | 2018-09-19 | 2018-12-21 | 新华三大数据技术有限公司 | Cluster authentication method, device |
| CN109150862A (en) * | 2018-08-03 | 2019-01-04 | 福建天泉教育科技有限公司 | A kind of method and server-side for realizing token roaming |
| CN109413096A (en) * | 2018-11-30 | 2019-03-01 | 北京海泰方圆科技股份有限公司 | A kind of login method and device more applied |
| CN110781485A (en) * | 2019-11-07 | 2020-02-11 | 北京推想科技有限公司 | Single sign-on method and device |
| CN111107073A (en) * | 2019-12-11 | 2020-05-05 | 数字广东网络建设有限公司 | Application automatic login method and device, computer equipment and storage medium |
| CN111405019A (en) * | 2020-03-10 | 2020-07-10 | 腾讯科技（深圳）有限公司 | Data processing method, data processing device, computer equipment and storage medium |
| CN111628965A (en) * | 2020-04-03 | 2020-09-04 | 北京奇艺世纪科技有限公司 | Cross-domain name login method and device |
| CN111651747A (en) * | 2020-05-11 | 2020-09-11 | 腾讯科技（深圳）有限公司 | Login bill synchronization system and method and related equipment |
-
2021
- 2021-05-21 CN CN202110556863.7A patent/CN113157812A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109150862A (en) * | 2018-08-03 | 2019-01-04 | 福建天泉教育科技有限公司 | A kind of method and server-side for realizing token roaming |
| CN109067785A (en) * | 2018-09-19 | 2018-12-21 | 新华三大数据技术有限公司 | Cluster authentication method, device |
| CN109413096A (en) * | 2018-11-30 | 2019-03-01 | 北京海泰方圆科技股份有限公司 | A kind of login method and device more applied |
| CN110781485A (en) * | 2019-11-07 | 2020-02-11 | 北京推想科技有限公司 | Single sign-on method and device |
| CN111107073A (en) * | 2019-12-11 | 2020-05-05 | 数字广东网络建设有限公司 | Application automatic login method and device, computer equipment and storage medium |
| CN111405019A (en) * | 2020-03-10 | 2020-07-10 | 腾讯科技（深圳）有限公司 | Data processing method, data processing device, computer equipment and storage medium |
| CN111628965A (en) * | 2020-04-03 | 2020-09-04 | 北京奇艺世纪科技有限公司 | Cross-domain name login method and device |
| CN111651747A (en) * | 2020-05-11 | 2020-09-11 | 腾讯科技（深圳）有限公司 | Login bill synchronization system and method and related equipment |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113949704A (en) * | 2021-10-15 | 2022-01-18 | 北京奇艺世纪科技有限公司 | User information processing method and server cluster |
| CN113949704B (en) * | 2021-10-15 | 2024-03-08 | 北京奇艺世纪科技有限公司 | User information processing method and server cluster |
| CN113986135A (en) * | 2021-10-27 | 2022-01-28 | 北京百度网讯科技有限公司 | Method, device, equipment and storage medium for processing request |
| CN113986135B (en) * | 2021-10-27 | 2023-08-15 | 北京百度网讯科技有限公司 | Method, device, equipment and storage medium for processing request |
| CN114124508A (en) * | 2021-11-16 | 2022-03-01 | 上海浦东发展银行股份有限公司 | Application login method and system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113157812A (en) | Method and system for synchronizing distributed multi-cluster state class data | |
| US11868944B2 (en) | Container image management system for distributed clusters | |
| CN108470298B (en) | Method, device and system for transferring resource numerical value | |
| EP2706719B1 (en) | File synchronization method and device | |
| CN109787976B (en) | Information updating method and device, computer equipment and storage medium | |
| US8719386B2 (en) | System and method for providing configuration synchronicity | |
| CN106933548B (en) | Global information obtaining, processing and updating method, device and system | |
| CN106933550B (en) | Global information obtaining, processing and updating method, device and system | |
| CN106713391B (en) | Session information sharing method and sharing system | |
| CN100512158C (en) | Network measuring system structure and realizing method thereof | |
| CN110545207B (en) | Synchronous automatic intelligent DNS system and configuration method | |
| CN112883119B (en) | Data synchronization method and device, computer equipment and computer readable storage medium | |
| CN109120616A (en) | A kind of identity identifying method, device, agency service end and storage medium | |
| CN109933486B (en) | Logistics data monitoring processing method, device and system | |
| CN107547512B (en) | User authentication method and device in multi-level cloud platform | |
| EP4050850A1 (en) | Service upgrading method, device and system | |
| CN101841425A (en) | Network backup method, device and system without proxy | |
| CN113064732A (en) | Distributed system and management method thereof | |
| CN110928911A (en) | System, method and device for processing checking request and computer readable storage medium | |
| CN116414628A (en) | Transaction request processing method and device in new and old system switching process | |
| JP3802977B2 (en) | Information contradiction judgment, correction apparatus and method, and information contradiction judgment and correction program in storage exchange type electronic conference system | |
| CN115757552A (en) | Bank historical data management system based on distributed micro-service | |
| CN113919821A (en) | Service transfer method, device, computer equipment and storage medium | |
| US11582345B2 (en) | Context data management interface for contact center | |
| CN102904742A (en) | Operational method and system for executable nodes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210723 |
|
| RJ01 | Rejection of invention patent application after publication |