WO2012171349A1 - 一种分布式自增计数的实现方法、装置及系统 - Google Patents

一种分布式自增计数的实现方法、装置及系统 Download PDF

Info

Publication number
WO2012171349A1
WO2012171349A1 PCT/CN2012/070854 CN2012070854W WO2012171349A1 WO 2012171349 A1 WO2012171349 A1 WO 2012171349A1 CN 2012070854 W CN2012070854 W CN 2012070854W WO 2012171349 A1 WO2012171349 A1 WO 2012171349A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
auto
counting
result
increment
Prior art date
Application number
PCT/CN2012/070854
Other languages
English (en)
French (fr)
Inventor
陈典强
郭斌
韩银俊
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to EP12800793.7A priority Critical patent/EP2723017A4/en
Publication of WO2012171349A1 publication Critical patent/WO2012171349A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Definitions

  • the present invention relates to the field of cloud computing, and in particular, to a method, device and system for implementing distributed auto-increment counting. Background technique
  • Cloud Computing is Grid Computing, Distributed Computing, Parallel Computing, Utility Computing.
  • Cloud Computing aims to integrate multiple relatively low-cost computing entities into a system with powerful computing power through the network.
  • Distributed caching is an area in the field of cloud computing. Its role is to provide distributed storage services for massive data and high-speed read and write access.
  • the distributed cache system is composed of a plurality of server nodes and service terminals connected to each other; the server node is responsible for storing data, and the service terminal can perform operations such as writing, reading, updating, and deleting data to the server node, for example, in a store.
  • the monitor ie, the service terminal
  • the data written by the service terminal cannot be saved only on a single server node (hereinafter referred to as
  • Node On the “node"), a copy of the same data is saved on multiple nodes, which are backups of each other.
  • the stored data is composed of Key (Key) and Value (value), Key is equivalent to the index of the data, for example, Key is set to "the total number of customers entering the store, and Value is the data content represented by Key, for example, Value is "10203 person times", logically, Key and Value are one-to-one relationships, which are used to uniquely identify a form of data storage. This form of storage is also called distributed auto-increment counting. Device.
  • Distributed auto-increment counters are widely used to perform atomic addition and subtraction of values in a distributed environment. They can generate global unique serial numbers and implement global statistical counting functions. Based on distributed auto-increment counters, applications can implement many complex functions.
  • Requesting concurrency for example, when multiple auto-increment counts of the same value are sent to the server at the same time, only one request can be allowed to succeed, other requests will return failure, and the service terminal that failed the request must retry, which is also reduced to some extent.
  • the service efficiency of the distributed auto-increment counter further, the system that guarantees concurrency and availability cannot guarantee accuracy. For example, when multiple auto-incrementing requests are executed simultaneously, the counting results between the servers are not coordinated. , resulting in inconsistent counting results, affecting its counting accuracy.
  • the embodiments of the present invention provide a method and an apparatus for implementing distributed auto-increment counting, which are used to improve the execution efficiency of distributed auto-increment counting and improve the accuracy of the counting result.
  • a method for implementing distributed auto-increment counting includes:
  • the first server receives an auto-increment request message sent by the service terminal, where the auto-increment request message carries identifier information indicating the content of the operation;
  • the first server obtains, according to the identifier information, a count result corresponding to the storage of the identifier information, and obtains a count result corresponding to the identifier information stored on each second server, where the first server and the second server are backups of each other. ;
  • the first server performs an auto-incrementing operation according to the obtained counting result in which the update time is the smallest from the current time, and obtains the updated counting result;
  • the first server sends the updated counting result to each second server for backup, and determines that the current auto-incrementing operation succeeds when it is confirmed that the backup of the second server exceeds the set number.
  • a device for implementing distributed auto-increment counting comprising:
  • the first communication unit is configured to receive an auto-increment request message sent by the service terminal, where the auto-increment request message carries identifier information indicating the content of the operation;
  • the obtaining unit is configured to obtain, according to the identifier information, a counting result of the local corresponding identification information storage, and obtain a counting result of the corresponding identification information storage on each second server, where the device and the second server are backups of each other;
  • the execution unit is configured to perform an auto-incrementing operation according to the obtained counting result in which the update time is the smallest from the current time, and obtain the updated counting result;
  • the second communication unit is configured to send the updated counting result to each of the second servers for backup, and determine that the current self-incrementing operation is successful when it is confirmed that the backup of the second server exceeds the set number is successful.
  • a distributed auto-increment implementation system includes a first server and a second server that are mutually backed up, wherein
  • a first server configured to receive an auto-increment request message sent by the service terminal, where the auto-increment request message carries identifier information for indicating an operation content, and obtains, according to the identifier information, a local corresponding identifier information storage Counting results, and obtaining a count result corresponding to the storage of the identification information on each second server, and updating the time interval according to each obtained counting result
  • the counting result with the smallest duration of the current time performs an auto-incrementing operation, obtains the updated counting result, sends the updated counting result to each second server for backup, and confirms that the second server exceeds the set number.
  • the second server is configured to return, according to the identifier information sent by the first server, a count result stored locally corresponding to the identifier information, and back up the updated count result sent by the first server, and first The server returns the backup result.
  • an efficient distributed self-incrementing counting method is proposed for a distributed cache system in the cloud computing field, which is specifically: saving a copy of the counting result on multiple servers for an incrementing counter, Each time the auto-increment counting operation is performed, the latest counting result is selected in the counting result saved by the same auto-increment counter on each server to perform the auto-increment counting operation, thereby effectively ensuring the accuracy of the counting result, and at the same time, only confirming If the number of successful backup servers reaches the set threshold, it can be determined that the current auto-increment operation is successful, thereby improving the execution efficiency of the auto-increment operation to a certain extent, and only a normal working server when a server fails. The number of thresholds reached the set threshold will not affect the normal operation of the distributed cache system, thus effectively improving the stability, security and availability of the distributed cache system.
  • FIG. 1 is a schematic structural diagram of a distributed cache system according to an embodiment of the present invention
  • FIG. 2 is a schematic diagram of a functional architecture of a collaborative server according to an embodiment of the present invention.
  • FIG. 3 is a flowchart of an overview of implementing an auto-incrementing operation according to an embodiment of the present invention
  • FIG. 4 is a flowchart of an example of implementing an auto-increment counting operation according to an embodiment of the present invention. detailed description
  • An efficient distributed self-incrementing method is specifically: using a multi-copy mechanism on the server side, that is, saving a copy of the data on multiple servers for the same auto-increment counter, each time the auto-incrementing operation is performed, If the number of servers that successfully perform the self-incrementing operation reaches the preset threshold, it is considered that the system performs the self-incrementing operation successfully.
  • the advantage of the embodiment of the present invention is that when a server fails, it is normal. The number of working servers reaches the set threshold and does not affect the normal operation of the distributed cache system.
  • a plurality of servers serving each other are provided in a distributed cache system, where
  • the first server which is also referred to as a collaboration server, is configured to receive an auto-increment request message sent by the service terminal, where the auto-increment request message carries identifier information for indicating an operation content, and obtains a local corresponding according to the identifier information.
  • the second server which is also referred to as a replica server, is configured to return, to the collaborative server, a count result stored locally corresponding to the identifier information according to the identifier information sent by the collaborative server, and back up the updated count result sent by the collaborative server, and Returns the backup results to the companion server.
  • a connection is established between a service terminal and a plurality of servers (including a collaborative server and a replica server), and multiple servers are also connected to each other and operate normally, wherein when a certain key and a corresponding Value are saved,
  • a certain key and a corresponding Value are saved
  • the companion server and the replica server are mutually backups, that is, the servers have stored the same Key and corresponding Value, and the collaborative server and replica server selected by the service terminal for different Keys and Values.
  • the collaborative server and the replica server selected by the service terminal may be the same or different.
  • a collaborative server corresponding to a key (called Key A, referred to as KA) fails, the system can select a priority match in the corresponding replica server according to the order of priority from highest to lowest.
  • the required replica server is used as the new companion server.
  • the replica server with the highest priority/second highest/third highest/... is selected as the new companion server, and the other replica servers are still used as the replica server.
  • the new companion server and the replica server are still backed up each other, which effectively shortens the duration of troubleshooting and does not affect the execution result of subsequent auto-incrementing operations.
  • the collaborative server selected by the service terminal may be different, and when the collaborative server fails, the service terminal may be in the copy.
  • the server reselects one as the companion server. Therefore, based on this execution mode, the following may occur:
  • the value saved by the corresponding KA on the companion server is not the latest data, that is, the update time of the value corresponding to the KA saved on the companion server is the current time.
  • the duration of the update is greater than the duration of the update time of the value saved by the KA on a certain replica server. Therefore, when the companion server performs the auto-incrementing operation, it needs to comprehensively consider the correlation of the value corresponding to the KA saved on each replica server. Information, which will be further described in subsequent embodiments.
  • the first communication unit 20, the acquisition unit 21, the execution unit 22, and the second communication unit 23 are coordinated.
  • the first communication unit 20 is configured to receive an auto-increment request message sent by the service terminal, where the auto-increment request message carries identifier information indicating the content of the operation;
  • the obtaining unit 21 is configured to obtain, according to the identifier information, a counting result of the local corresponding identification information storage, and obtain a counting result of the corresponding identification information storage on each copy server; and an executing unit 22, configured to obtain, according to the obtained counting results The counting result with the smallest update time from the current time performs an auto-incrementing operation, and obtains the updated counting result;
  • the second communication unit 23 is configured to send the updated counting result to each replica server for backup, and determine that the current auto-incrementing operation succeeds when it is confirmed that the backup of the replica server exceeds the set number is successful.
  • Step 300 The service terminal initiates a counter auto-increment operation, and sends an auto-increment request message to the selected companion server, where the auto-increment request message carries the identifier information corresponding to the auto-increment operation, that is, Key, which is called Key A.
  • Key A the identifier information corresponding to the auto-increment operation
  • the service terminal may select a server node according to the self-incrementing operation content indicated by KA, and send an auto-increment request message to the selected server, and the selected server is referred to as the current operation.
  • the companion server, the server selected by the service terminal may be the same or different for different Keys.
  • the service terminal is a monitor of the store, and when the monitor determines that a new customer enters the store, sends an auto-increment request message to a selected collaborative server in the background, and the KA represented in the auto-increment request message is represented.
  • the current self-incrementing operation content is "the total number of customers entering the store”.
  • Step 310 The collaborative server obtains the count result of the local corresponding KA storage according to the obtained KA, that is, Value, hereinafter referred to as V, and acquires the V of the corresponding KA storage on each copy server.
  • the cooperative server When performing step 310, the cooperative server receives the auto-incrementing request message carrying the key sent by the service terminal, attempts to locally read the V corresponding to the key, and sends a copy read request to the server that also holds the key.
  • the server is called a replica server of the current operation, and specifically: the collaboration server sends a copy acquisition request message to each replica server corresponding to the KA, and the replica acquisition request message carries at least KA, so that some/all replica servers return to the local server.
  • the specific implementation includes but is not limited to the following two types:
  • the collaborative server sends a copy request message carrying the KA to each copy server corresponding to the KA.
  • each copy server After receiving the KA, each copy server returns the V saved by the KA and the local corresponding KA to the collaborative server (the copy server returns to the collaborative server) KA, is to make the co-server explicitly receive which key V).
  • mode A the most comprehensive data is available to perform the most accurate auto-increment operation.
  • the replica server notifies the cooperation server that the related data is not saved, and details are not described herein again.
  • the collaborative server sends a copy acquisition request message carrying the KA and the corresponding V (the V saved by the cooperative server) to each replica server corresponding to the KA.
  • each of the replica servers After each of the replica servers receives the KA and the V, it determines the local V corresponding to the KA. Whether the duration of the update time from the current time is less than the duration of the update time of the received V from the current time, and if so, returns the KA stored in the KA and the local corresponding KA to the collaborative server, otherwise, returns only the KA to the collaborative server.
  • network data traffic can be effectively reduced and network operation load can be reduced.
  • the auto-incrementing operation is interrupted.
  • the co-server sends the copy acquisition request message, it is not necessary. Wait until the feedback information of all replica servers is received, and then perform subsequent operations, but when it is determined that the number of replica servers returning KA and corresponding V or/and returning KA reaches the set threshold value (referred to as threshold value X) Then, the subsequent operations are started, that is, after the collaborative server sends the copy acquisition request message, it is determined that the number of replica servers that feed back the copy acquisition request message reaches the threshold value X, and then the steps are started. 320.
  • Step 320 The companion server performs an auto-incrementing operation according to the obtained V in which the update time is the smallest from the current time, and obtains the updated V.
  • the cooperative server determines the duration between the update time of the V and the current time, for example, determining the duration of the update time from the current time according to the time stamp of the corresponding V record. The later the time is recorded, the shorter the duration of the update time from the current time. For example, the length of the update time from the current time is determined according to the version number of the corresponding V record. The larger the version number, the update time interval. The shorter the duration of the current time; the two implementations are only examples, but are not limited to the two implementations, and are not described here.
  • the cooperative server performs the above-mentioned judgment operation when performing the self-incrementing operation, which can effectively ensure the data consistency of the system in the self-incrementing operation, thereby ensuring the accuracy of the updated V.
  • the plurality of service terminals send an auto-increment request message for the same auto-increment counter to the companion server, that is, the companion server receives the auto-increment counting from the plurality of service terminals carrying the same key.
  • the collaboration server needs to merge the number of increments indicated by the received multiple auto-increment request messages, and then perform subsequent operations; wherein the merge operation may be performed immediately after receiving the auto-increment request message, or After each V is obtained, it is executed before the auto-incrementing operation, and details are not described herein again.
  • the companion server receives the auto-increment request message carrying KA from 100 service terminals, and each auto-increment request message requests the self-increment number to be 1, the companion server merges the self-increment number into 100. Then, the up-counting operation of the latest V obtained is performed, that is, 100 is added as the updated V on the current latest V; correspondingly, the cooperative server only needs to subtract the updated V when feeding back to any one of the service terminals. The number of self-increment requests from other service terminals is sufficient. In this way, one hundred operations in the prior art can be solved in one embodiment, which greatly saves the operation time of the self-incrementing operation and improves the execution efficiency of the self-incrementing operation.
  • Step 330 The collaborative server sends the updated V to each replica server for backup, Preferably, the KA and the updated V- should be sent together, and when it is confirmed that the backup of the second server exceeding the set number is successful, it is confirmed that the current auto-increment operation is successful.
  • each replica server After receiving the updated V sent by the server, each replica server needs to determine whether the updated update time of the updated V is less than the current time, and is smaller than the local corresponding KA saved by the replica server. The update time of V is longer than the current time. If yes, the updated V is saved, and the collaborative server is notified that the backup is successful; otherwise, the data is not saved, and the collaborative server fails to be notified.
  • Each of the replica servers performs the above-mentioned judgment operations when performing backups, which can enhance the data consistency of the system in the self-incrementing operation, thereby ensuring the accuracy of the updated V.
  • the collaborative server does not have to wait until the feedback information of all the replica servers is received, and then determines that the auto-increment operation succeeds, but confirms that the number of replica servers successfully restored reaches the set threshold.
  • the threshold value Y it can be confirmed that the current auto-increment counting operation is successful, and the threshold value Y here may be the same as or different from the value of the previously described threshold value X.
  • the service terminal may select a replica server with the priority matching condition as the new collaborative server to perform the current self-increment according to the preset priority for each replica server.
  • the counting operation does not affect the final execution result, which effectively improves the stability and security of the distributed cache system.
  • a service terminal, a collaboration server, and two replica servers are respectively disposed in the distributed cache system, respectively, as a replica server 1 And the replica server 2, wherein the auto-increment-related data stored in the companion server is Key B _ Value 0, abbreviated as KB_VO, and the auto-increment-related data stored in the replica server 1 is Key B - Value 1 , abbreviated as KB - VI, and the auto-increment-related data stored in the replica server 2 is Key B - Value 2 , abbreviated as KB - V2 , KB means "the number of customers using the ATM terminal, and the value of V0 is "150", and the value of VI is The "148" and V2 values are "152", so the specific process of implementing the auto-increment operation is as follows:
  • Step 400 The service terminal sends an auto-increment request message carrying KB to the collaborative server, and assumes that the number of counts for requesting self-increment is 1.
  • Step 401 The collaborative server obtains the V0 saved by the local corresponding KB.
  • Step 402 The collaborative server sends a replica request message to the replica server 1 to carry at least a copy of the KB.
  • Step 403 The collaborative server sends a replica request message to the replica server 1 to carry at least a copy of the KB.
  • Step 404 The replica server 1 obtains the VI corresponding to the local KB.
  • Step 405 The replica server 1 obtains the V2 saved locally by the KB.
  • Step 406 Replica 2 returns V2 to the companion server.
  • Step 407 Replica 1 returns a VI to the companion server.
  • the step 402, the step 404, the step 407, and the step 403, the step 405, and the step 406 may be performed in parallel or sequentially, and the execution order is not limited herein.
  • Step 408 The companion server compares the update times of V0, VI, and V2, and determines that the latest count result is V2, that is, the value is "152".
  • Step 409 The companion server performs an auto-increment operation based on V2 and the number of increments requested to be incremented, and obtains the updated V3, which has a value of "153".
  • Step 410 The collaborative server sends a backup request message carrying V3 to the replica server 1.
  • Step 411 The collaborative server sends a backup request message carrying V3 to the replica server 2.
  • Step 412 The replica server 1 stores the latest V3 corresponding to the KB.
  • Step 413 Replica 1 returns an operation success response to the companion server.
  • Step 414 Replica 1 saves the latest V3 for KB.
  • Step 415 Replica 2 returns an operational success response to the companion server.
  • the step 410, the step 412, the step 413, and the step 411, the step 414, and the step 415 may be performed in parallel or sequentially, and the execution order is not limited herein.
  • Step 416 The co-server determines that the replica server that successfully returns the response reaches a preset threshold (for example, the threshold is 1).
  • step 416 when step 416 is performed, if the collaborative server determines that the replica server that successfully returns the response does not reach the preset threshold, it may return to step 401 to perform a failed retry and retry.
  • the current process is terminated and the service terminal is alerted.
  • Step 417 The collaborative server returns an auto-increment result to the service terminal, that is, V3.
  • an efficient distributed self-incrementing counting method is proposed for the distributed cache system in the cloud computing domain, which is specifically: storing an auto-increment counter on multiple servers A copy of the counting result, each time the self-incrementing operation is performed, the latest counting result is selected in the counting result saved by the same incrementing counter on each server to perform the self-incrementing operation, thereby effectively ensuring the accuracy of the counting result.
  • the normal operation of the distributed cache system will not be affected, thereby effectively improving the stability, security, and availability of the distributed cache system. Further, it is also possible to target Multiple self-increment counters The up-counting request is merged, thereby further improving the execution efficiency of the self-incrementing operation. In this way, the requirements of the distributed cache system for the availability, efficiency, concurrency and accuracy of distributed auto-increment counters are met.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明涉及云计算领域，公开了一种分布式自增计数的实现方法、装置及系统，用以提高分布式自增计数的执行效率，提升计数结果的准确性。该方法为：在云计算领域分布式缓存系统中，针对一个自增计数器在多个服务器上保存其计数结果的副本，每次执行自增计数操作时，在各服务器上针对同一自增计数器保存的计数结果中选取出最新的计数结果执行自增计数操作，从而有效保证了计数结果的准确性，同时，只需确认计数结果备份成功的服务器的数目达到设定阈值，便可确定当前自增计数操作成功，从而在一定程度上提高了自增计数操作的执行效率。

Description

一种分布式自增计数的实现方法、 装置及系统 技术领域
本发明涉及云计算领域， 特别涉及一种分布式自增计数的实现方法、 装置及系统。 背景技术
Cloud Computing (云计算）是 Grid Computing (网格计算）、 Distributed Computing (分布式计算 )、 Parallel Computing (并行计算 )、 Utility Computing
(效用计算）、 Network Storage Technologies (网络存储）、 Virtualization (虚 拟化）、 Load Balance (负载均衡）等传统计算机技术和网络技术发展融合 的产物。 Cloud Computing旨在通过网络把多个成本相对较低的计算实体整 合成一个具有强大计算能力的系统。
分布式緩存是云计算范畴中的一个领域， 其作用是提供海量数据的分 布式存储服务以及高速读写访问的能力。 分布式緩存系统是由若干服务器 节点和服务终端互相连接构成的； 服务器节点负责数据的存储， 服务终端 可以对服务器节点做数据的写入、 读取、 更新、 删除等操作， 例如， 商店 里的监视器（即服务终端）针对每一个进入商店的顾客进行计数统计， 并 将统计结果上报至后台的服务节点进行存储。 一般来说， 为了保证数据的 安全性， 服务终端写入的数据不可能只保存在单个服务器节点 （以下简称
"节点"）上， 而是在多台节点上保存同一个数据的副本， 互为备份。 而存 储的数据由 Key (键）和 Value (值）构成， Key相当于数据的索引， 例如， Key设置为 "进入商店的顾客总数目， 而 Value是 Key所代表的数据内容， 例如， Value为 "10203人次"， 在逻辑上， Key和 Value是一对一的关系， 用于唯一标识某一形式的数据存储， 这种存储形式又称为分布式自增计数 器。
分布式自增计数器用途很广泛， 可以实现在分布式环境中进行数值的 原子加减运算， 可以实现全局唯一序列号的生成， 可以实现全局的统计计 数功能等。 基于分布式自增计数器， 应用可以实现许多复杂的功能。
目前， 分布式自增计数器的准确性、 并发性、 可用性和效率是难以兼 顾的关键问题。 现有技术下， 通常保证了并发性和准确性的系统， 无法实 现高可用性， 如， 在有任意一节点故障时， 整体服务会间断， 将故障节点 的任务全部转到其他节点上执行后， 再恢复整体服务， 这就往往要花费很 长时间， 从而在一定程度上降低了分布式自增计数器的服务效率； 进一步 地， 现有技术下， 保证了准确性和可用性的系统， 无法实现多请求并发， 如， 同一个数值的多个自增计数同时发到服务端时， 只能允许一个请求成 功， 其他请求将返回失败， 请求失败的服务终端必须重试， 这在一定程度 上也降低了分布式自增计数器的服务效率； 再进一步地， 保证了并发性和 可用性的系统， 无法保证准确性， 如， 多个自增计数请求同时执行时， 各 服务器之间的计数结果未经协调， 从而导致计数结果不一致， 影响其计数 准确性。
鉴于上述现有技术的局限性， 需要提供一种新的分布式自增计数的实 现方法， 以克服上述技术缺陷。 发明内容
有鉴于此， 本发明实施例提供一种分布式自增计数的实现方法及装置， 用以提高分布式自增计数的执行效率， 提升计数结果的准确性。
本发明实施例提供的具体技术方案如下：
一种分布式自增计数的实现方法， 包括：
第一服务器接收服务终端发送的自增计数请求消息， 所述自增计数请 求消息中携带用于指示操作内容的标识信息； 第一服务器根据所述标识信息， 获取本地对应所述标识信息存储的计 数结果， 以及获取各第二服务器上对应所述标识信息存储的计数结果， 其 中， 第一服务器和第二服务器互为备份；
第一服务器根据获得的各计数结果中更新时间距当前时间的时长最小 的计数结果执行自增计数操作， 获得更新后的计数结果；
第一服务器将所述更新后的计数结果发往各第二服务器进行备份， 并 在确认超过设定数目的第二服务器备份成功时， 确定当前自增计数操作成 功。
一种分布式自增计数的实现装置， 包括：
第一通信单元， 设置为接收服务终端发送的自增计数请求消息， 该自 增计数请求消息中携带用于指示操作内容的标识信息；
获取单元， 设置为根据所述标识信息， 获取本地对应该标识信息存储 的计数结果， 以及获取各第二服务器上对应该标识信息存储的计数结果， 其中， 本装置和第二服务器互为备份；
执行单元， 设置为根据获得的各计数结果中更新时间距当前时间的时 长最小的计数结果执行自增计数操作 , 获得更新后的计数结果；
第二通信单元， 设置为将所述更新后的计数结果发往各第二服务器进 行备份， 并在确认超过设定数目的第二服务器备份成功时， 确定当前自增 计数操作成功。
一种分布式自增计数的实现系统， 包括互为备份的第一服务器和第二 服务器， 其中，
第一服务器， 设置为接收服务终端发送的自增计数请求消息， 所述自 增计数请求消息中携带用于指示操作内容的标识信息， 根据所述标识信息， 获取本地对应所述标识信息存储的计数结果， 以及获取各第二服务器上对 应所述标识信息存储的计数结果， 并根据获得的各计数结果中更新时间距 当前时间的时长最小的计数结果执行自增计数操作， 获得更新后的计数结 果， 再将所述更新后的计数结果发往各第二服务器进行备份， 并在确认超 过设定数目的第二服务器备份成功时， 确定当前自增计数操作成功；
第二服务器， 设置为根据第一服务器发送的标识信息， 向第一服务器 返回本地对应所述标识信息保存的计数结果， 以及对第一服务器发送的更 新后的计数结果进行备份， 并向第一服务器返回备份结果。
本发明实施例中， 针对云计算领域分布式緩存系统， 提出了一种高效 的分布式自增计数的实现方法， 具体为： 针对一个自增计数器在多个服务 器上保存其计数结果的副本， 每次执行自增计数操作时， 在各服务器上针 对同一自增计数器保存的计数结果中选取出最新的计数结果执行自增计数 操作， 从而有效保证了计数结果的准确性， 同时， 只需确认计数结果备份 成功的服务器的数目达到设定阈值， 便可确定当前自增计数操作成功， 从 而在一定程度上提高了自增计数操作的执行效率， 并且当某服务器出现故 障时只要正常工作的服务器的数目达到设置的门限值， 就不会影响分布式 緩存系统的正常工作， 进而有效提高了分布式緩存系统的稳定性、 安全性 及可用性。 附图说明
图 1为本发明实施例中分布式緩存系统体系架构图；
图 2为本发明实施例中协同服务器功能架构示意图；
图 3为本发明实施例中实现自增计数操作概述流程图；
图 4为本发明实施例中实现自增计数操作举例流程图。 具体实施方式
在分布式緩存系统中， 为了提供可用的高效的自增计数服务， 令某服 务器发生临时故障时不影响系统的整体服务性能， 本发明实施例中， 提供 了一种高效的分布式自增计数的方法， 具体为： 在服务器端采用多副本机 制， 即针对同一个自增计数器在多个服务器上保存其数据副本， 每次执行 自增计数操作时， 执行自增计数操作成功的服务器的数目达到预设门限值， 则视为系统整体执行自增操作成功； 与现在技术相比， 本发明实施例的优 势在于， 当某服务器出现故障时只要正常工作的服务器的数目达到设置的 门限值， 就不会影响分布式緩存系统的正常工作。
下面结合附图对本发明优选的实施方式进行详细介绍。
如图 1 所示， 本发明实施例中， 分布式緩存系统中设置有多个互为备 份的服务器， 其中，
第一服务器， 又称为协同服务器， 用于接收服务终端发送的自增计数 请求消息， 该自增计数请求消息中携带用于指示操作内容的标识信息， 根 据所述标识信息， 获取本地对应该标识信息存储的计数结果， 以及获取各 副本服务器上对应该标识信息存储的计数结果， 并根据获得的各计数结果 中更新时间距当前时间的时长最小的计数结果执行自增计数操作， 获得更 新后的计数结果， 再将所述更新后的计数结果发往各副本服务器进行备份， 并在确认超过设定数目的副本服务器备份成功时， 确定当前自增计数操作 成功；
第二服务器， 又称为副本服务器， 用于根据协同服务器发送的标识信 息， 向协同服务器返回本地对应所述标识信息保存的计数结果， 以及对协 同服务器发送的更新后的计数结果进行备份， 并向协同服务器返回备份结 果。
如图 1所示， 服务终端和多个服务器（包括协同服务器和副本服务器） 之间建立连接， 多个服务器之间同样互相建立连接并且运行正常， 其中， 当某一个 Key及相应的 Value被保存在多个服务器上后， 其中一个服务器 将在后续的自增计数操作中被服务终端选定为协同服务器， 其余的服务器 则称为副本服务器， 协同服务器和副本服务器互为备份， 即这些服务器上 有存储有保存有相同的一个 Key和对应的 Value,针对不同的 Key及 Value, 服务终端选定的协同服务器和副本服务器可以相同， 也可以不同， 而针对 同一个 Key及 Value, 在不同的自增计数操作流程中， 服务终端选定的协同 服务器和副本服务器可以相同， 也可以不相同。
在实际应用中， 若某一个 Key (称为 Key A, 下面简称 KA )对应的协 同服务器发生了故障， 则系统可以在相应的副本服务器中按照优先级从高 到低的顺序选择一个优先级符合要求的副本服务器作为新的协同服务器， 如， 选取优先级最高 /次高 /第三高 / ... ...的副本服务器作为新的协同服务器， 其他副本服务器则仍然作为副本服务器， 这样， 新的协同服务器和副本服 务器之间仍然互为备份， 从而有效缩短了故障排除的历时时长， 也不会影 响后续自增计数操作的执行结果。
通过上述技术方案可以获知， 本实施例中， 针对同一个 Key, 在不同 的自增操作流程中， 服务终端选择的协同服务器可能不相同， 以及， 在协 同服务器发生故障时， 服务终端可以在副本服务器中重新选择一个作为协 同服务器， 因此， 基于这种执行方式， 有可能出现以下情况： 协同服务器 上对应 KA保存的 Value不是最新数据， 即协同服务器上对应 KA保存的 Value的更新时间距当前时间的时长， 大于某一副本服务器上对应 KA保存 的 Value的更新时间距当前时间的时长， 因此，协同服务器在执行自增计数 操作时，便需要综合考虑各副本服务器上对应 KA保存的 Value的相关信息， 这一点将在后续实施例中进行进一步介绍。
如图 2所示， 本发明实施例中， 协同服务器第一通信单元 20、 获取单 元 21、 执行单元 22和第二通信单元 23 , 其中，
第一通信单元 20, 用于接收服务终端发送的自增计数请求消息， 该自 增计数请求消息中携带用于指示操作内容的标识信息； 获取单元 21 , 用于根据所述标识信息， 获取本地对应该标识信息存储 的计数结果， 以及获取各副本服务器上对应该标识信息存储的计数结果； 执行单元 22, 用于根据获得的各计数结果中更新时间距当前时间的时 长最小的计数结果执行自增计数操作 , 获得更新后的计数结果；
第二通信单元 23 , 用于将所述更新后的计数结果发往各副本服务器进 行备份， 并在确认超过设定数目的副本服务器备份成功时， 确定当前自增 计数操作成功。
基于上述技术方案， 如图 3 所示， 本发明实施例中， 在分布式緩存系 统内， 实现自增计数操作的详细流程如下：
步驟 300: 服务终端发起计数器自增操作， 向选定的协同服务器发送自 增计数请求消息， 该自增计数请求消息中携带有自增计数操作对应的标识 信息， 即 Key, 称为 Key A, 下面简称 KA。
本发明实施例中， 服务终端可以根据 KA表示的自增计数操作内容选 择一台服务器节点， 并将自增计数请求消息发送至选定的服务器， 该选定 的服务器被称作本次操作的协同服务器， 对于不同的 Key, 服务终端选定 的协同服务器可能相同， 也可能不同。
例如， 服务终端为商店的监视器， 当该监视器确定有新的顾客进入商 店时， 向后台选定的一台协同服务器发送自增计数请求消息， 该自增计数 请求消息中携带的 KA表示当前自增计数操作内容为 "进入商店的顾客总 数目"。
步驟 310: 协同服务器根据获得的 KA, 获取本地对应 KA存储的计数 结果， 即 Value, 下面简称 V, 以及获取各副本服务器上对应 KA存储的 V。
在执行步驟 310时， 协同服务器接收到服务终端发送的携带有 Key的 自增计数请求消息后， 尝试从本地读取该 Key对应的 V, 并向同样保存有 该 Key的服务器发送副本读取请求消息， 其中， 同样保存有上述 Key的服 务器在称为本次操作的副本服务器， 具体为： 协同服务器向 KA对应的各 副本服务器发送副本获取请求消息， 该副本获取请求消息中至少携带有 KA, 令部分 /全部副本服务器返回其本地对应 KA保存的 V, 具体实现方式 包含但不限于以下两种：
A、协同服务器向 KA对应的各副本服务器发送携带 KA的副本获取请 求消息，每一个副本服务器接收到 KA后， 均将 KA及本地对应 KA保存的 V返回至协同服务器（副本服务器向协同服务器返回 KA, 是为了令协同服 务器明确接收的是哪个 Key的 V )。 通过执行方式 A, 可以获得最全面的数 据， 从而执行最为准确的自增计数操作。
另一方面， 若接收到携带上述 Key的副本获取请求消息的副本服务器 上未保存有对应该 Key的 V, 则副本服务器向协同服务器通知未保存有相 关数据即可， 在此不再赘述。
B、 协同服务器向 KA对应的各副本服务器发送携带 KA及相应 V (协 同服务器保存的 V ) 的副本获取请求消息， 每一个副本服务器接收到 KA 和 V后， 均判断本地对应 KA保存的 V的更新时间距当前时间的时长是否 小于接收的 V的更新时间距当前时间的时长， 若是， 则向协同服务器返回 KA及本地对应 KA保存的 V, 否则， 仅向协同服务器返回 KA。 通过执行 方式 B, 可以有效降低网络数据流量， 减轻网络运行负荷。
实际应用中， 无论执行方式 A还是方式 B , 为了提高处理效率， 同时 为了避免因某些副本服务器出现临时故障而导致自增计数操作中断， 较佳 的， 协同服务器发送副本获取请求消息后， 不必等到接收到全部副本服务 器的反馈信息后再执行后续操作， 而是在确定返回 KA及相应 V或 /和返回 KA的副本服务器的数目达到设定的门限值（称为门限值 X )时， 便开始执 行后续操作， 即协同服务器发送副本获取请求消息后， 确定针对该副本获 取请求消息进行反馈的副本服务器的数目达到门限值 X， 则开始执行步驟 320。
步驟 320: 协同服务器根据获得的各 V中更新时间距当前时间的时长 最小的 V执行自增计数操作， 获得更新后的 V。
本发明实施例中， 在步驟 320中， 协同服务器判断 V的更新时间与当 前时间之间的时长的方式有多种， 例如， 根据对应 V记录的时间戳来确定 其更新时间距当前时间的时长， 时间截记录的时间越晚， 表示更新时间距 当前时间的时长越短； 又例如， 据对应 V记录的版本号来确定其更新时间 距当前时间的时长， 版本号越大， 表示更新时间距当前时间的时长越短； 这两种实现方式仅为举例， 但并不局限于这两种实现方式， 在此不再赘述。 协同服务器在进行自增计数操作时均执行上述判断操作， 可以有效保证自 增计数操作中系统的数据一致性， 从而保证更新后的 V的准确性。
另一方面， 若在步驟 300 中， 多个服务终端向协同服务器发送针对同 一自增计数器的自增计数请求消息， 即协同服务器接收到来自于多个服务 终端的携带有相同 Key的自增计数请求消息， 则协同服务器需要先将接收 的多个自增计数请求消息指示的自增数目进行合并， 再执行后续操作； 其 中， 合并操作可以在接收到自增计数请求消息后立即执行， 也可以在获得 各 V后， 在进行自增计数操作之前执行， 在此不再赘述。 例如， 若协同服 务器接收到来自于 100个服务终端的携带 KA的自增计数请求消息， 每条 自增计数请求消息均请求自增数目为 1 , 则协同服务器将自增数目合并为 100后， 再对当前获取的最新的 V进行自增计数操作， 即在当前最新的 V 上添加 100作为更新后的 V； 相应的， 协同服务器在向任意一服务终端反 馈更新的 V时， 只需要减去其他服务终端请求的自增数目即可。 这样， 现 有技术下需要进行一百次的操作在本实施例中可以一次性解决， 大大节省 了自增计数操作的操作时间， 提高了自增计数操作的执行效率。
步驟 330: 协同服务器将更新后的 V发往各副本服务器进行备份， 较 佳的， 应当将 KA和更新后的 V—同发送， 并在确认超过设定数目的第二 服务器备份成功时， 确认当前自增计数操作成功。
在执行步驟 330 的过程中， 每一个副本服务器在接收到服务器发送的 更新后的 V后， 需判断接收的更新后的 V的更新时间距当前时间的时长， 是否小于副本服务器本地对应 KA保存的 V的更新时间距当前时间的时长， 若是， 则保存更新后的 V, 并通知协同服务器备份成功； 否则， 不保存数 据， 并通知协同服务器备份失败。 每一个副本服务器在进行备份时均执行 上述判断操作， 可以加强自增计数操作中系统的数据一致性， 从而保证更 新后的 V的准确性。 较佳的， 为了提高系统的执行效率， 协同服务器不必 等到接收到全部副本服务器的反馈信息后再确定自增计数操作成功， 而是 在确认备份成功的副本服务器的数目达到设定的门限值（称为门限值 Y ) 时， 便可确认当前自增计数操作成功， 此处的门限值 Y与之前记载的门限 值 X的取值可以相同， 也可以不同。
在上述实施例中， 若选定的协同服务器发生故障， 则服务终端可以根 据针对各副本服务器预设的优先级， 选择优先级符合条件的一个副本服务 器作为新的协同服务器来执行当前的自增计数操作， 不会影响最后的执行 结果， 这样， 有效提高了分布式緩存系统的稳定性和安全性。 而若各副本 服务器中的某些副本服务器发生故障， 则只要未发生故障的副本服务器的 数目达到门限值 X或 /和门限值 Y, 便不会影响自增计数操作的整体流程， 即只要不影响协同服务器向各副本服务器获取其保存的 V, 以及不影响协 同服务器接收备份服务器返回的表示自增计数操作成功的响应， 则备份服 务器的故障不会影响分布式緩存系统中的自增计数器的工作性能。 这样， 便进一步有效提高了分布式緩存系统的稳定性和安全性。
基于上述实施例， 如图 4所示， 假设分布式緩存系统中设置有一个服 务终端， 一个协同服务器， 以及两个副本服务器， 分别称为副本服务器 1 和副本服务器 2, 其中， 协同服务器中保存的自增计数相关数据为 Key B _ Value 0, 简称 KB— VO, 副本服务器 1中保存的自增计数相关数据为 Key B - Value 1 , 简称 KB— VI , 而副本服务器 2中保存的自增计数相关数据为 Key B - Value 2 , 简称 KB— V2 , KB表示 "使用 ATM终端的顾客数目，， , V0取值为 "150"、 VI取值为 "148"、 V2取值为 "152" , 则实现自增计数 操作的具体流程如下：
步驟 400: 服务终端向协同服务器发送携带 KB的自增计数请求消息， 假设请求自增的计数数目为 1。
步驟 401 : 协同服务器获取本地对应 KB保存的 V0。
步驟 402: 协同服务器向副本服务器 1发送至少携带 KB的副本获取请 求消息。
步驟 403:协同服务器向副本服务器 1发送至少携带 KB的副本获取请 求消息。
步驟 404: 副本服务器 1获取本地对应 KB保存的 VI。
步驟 405： 副本服务器 1获取本地对应 KB保存的 V2。
步驟 406: 副本服务器 2向协同服务器返回 V2。
步驟 407: 副本服务器 1向协同服务器返回 VI。
如图 4所示，本实施例中， 步驟 402、步驟 404、步驟 407,和步驟 403、 步驟 405、 步驟 406可以是并行执行或先后执行的关系， 在此并不限制其执 行顺序。
步驟 408: 协同服务器比较 V0、 VI和 V2的更新时间， 确定最新的计 数结果为 V2, 即取值为 "152"。
步驟 409: 协同服务器基于 V2以及请求自增的计数数目执行自增计数 操作， 获得更新后的 V3 , 其取值为 "153"。
步驟 410: 协同服务器向副本服务器 1发送携带 V3的备份请求消息。 步驟 411 : 协同服务器向副本服务器 2发送携带 V3的备份请求消息。 步驟 412: 副本服务器 1对应 KB保存最新的 V3。
步驟 413 : 副本服务器 1向协同服务器返回操作成功响应。
步驟 414: 副本服务器 1对应 KB保存最新的 V3。
步驟 415: 副本服务器 2向协同服务器返回操作成功响应。
如图 4所示，本实施例中， 步驟 410、步驟 412、步驟 413 ,和步驟 411、 步驟 414、 步驟 415可以是并行执行或先后执行的关系，在此并不限制其执 行顺序。
步驟 416:协同服务器确定返回操作成功响应的副本服务器达到预设门 限值（如， 门限值为 1 )。
如图 4所示， 本实施例中， 在执行步驟 416时， 若协同服务器确定返 回操作成功响应的副本服务器未达到预设门限值， 则可以返回步驟 401 进 行失败重试， 并在重试次数达到设定阈值且仍未成功执行自增计数操作时， 结束当前流程并对服务终端进行告警， 在此不再赘述。
步驟 417: 协同服务器向服务终端返回自增计数结果， 即 V3。
综上所述， 本发明实施例中， 针对云计算领域分布式緩存系统， 提出 了一种高效的分布式自增计数的实现方法， 具体为： 针对一个自增计数器 在多个服务器上保存其计数结果的副本， 每次执行自增计数操作时， 在各 服务器上针对同一自增计数器保存的计数结果中选取出最新的计数结果执 行自增计数操作， 从而有效保证了计数结果的准确性， 同时， 只需确认计 数结果备份成功的服务器的数目达到设定阈值， 便可确定当前自增计数操 作成功， 从而在一定程度上提高了自增计数操作的执行效率， 并且当某服 务器出现故障时只要正常工作的服务器的数目达到设置的门限值， 就不会 影响分布式緩存系统的正常工作， 进而有效提高了分布式緩存系统的稳定 性、 安全性及可用性； 进一步地， 还可以对针对同一自增计数器的多个自 增计数请求进行合并处理， 从而进一步提高了自增计数操作的执行效率。 这样， 便满足了分布式緩存系统对分布式自增计数器的可用性、 高效性、 并发性和准确性的要求。
显然， 本领域的技术人员可以对本发明进行各种改动和变型而不脱离 本发明的精神和范围。 这样， 倘若本发明的这些修改和变型属于本发明权 利要求及其等同技术的范围之内， 则本发明也意图包含这些改动和变型在 内。

Claims

权利要求书
1、 一种分布式自增计数的实现方法， 其中， 包括：
第一服务器接收服务终端发送的自增计数请求消息， 所述自增计数请 求消息中携带用于指示操作内容的标识信息；
第一服务器根据所述标识信息， 获取本地对应所述标识信息存储的计 数结果， 以及获取各第二服务器上对应所述标识信息存储的计数结果， 其 中， 第一服务器和第二服务器互为备份；
第一服务器根据获得的各计数结果中更新时间距当前时间的时长最小 的计数结果执行自增计数操作， 获得更新后的计数结果；
第一服务器将所述更新后的计数结果发往各第二服务器进行备份， 并 在确认超过设定数目的第二服务器备份成功时， 确定当前自增计数操作成 功。
2、 如权利要求 1所述的方法， 其中， 该方法还包括： 第一服务器接收 到至少两个服务终端发送的携带同一标识信息的自增计数请求消息时， 第 一服务器将所述至少两个自增计数请求消息指示的自增数目进行合并后， 再进行后续操作。
3、 如权利要求 1所述的方法， 其中， 所述第一服务器根据所述标识信 息， 获取各第二服务器上对应该标识信息存储的计数结果为：
第一服务器向所述标识信息对应的各第二服务器， 发送携带所述标识 信息的副本获取请求消息 , 令每一个接收到所述标识信息的第二服务器 , 向第一服务器返回所述标识信息及第二服务器本地对应该标识信息保存的 或， 第一服务器向所述标识信息对应的各第二服务器， 发送携带所述 标识信息及第一服务器对应所述标识信息保存的计数结果的副本获取请求 消息， 令每一个接收到所述标识信息和计数结果的第二服务器， 在确定第 二服务器本地对应所述标识信息保存的计数结果的更新时间距当前时间的 时长， 小于接收的计数结果的更新时间距当前时间的时长时， 向第一服务 器返回所述标识信息及第二服务器本地对应该标识信息保存的计数结果。
4、 如权利要求 3所述的方法， 其中， 该方法还包括： 第一服务器发送 副本获取请求消息后， 确定针对所述副本获取请求消息进行反馈的副本服 务器的数目达到预设门限值时， 根据获得的各计数结果中更新时间距当前 时间的时长最小的计数结果执行自增计数操作。
5、 如权利要求 1至 4任一项所述的方法， 其中， 所述第一服务器根据 获得的各计数结果中更新时间距当前时间的时长最小的计数结果执行自增 计数操作为：
第一服务器根据获得的各计数结果中 , 时间截指示时间最晚的计数结 果执行自增计数操作；
或， 第一服务器根据获得的各计数结果中， 版本号最大的计数结果执 行自增计数操作。
6、 如权利要求 5所述的方法， 其中， 该方法还包括： 服务终端确定协 同服务器发生故障时， 根据针对各副本服务器预设的优先级， 选择优先级 符合条件的一个副本服务器作为新的协同服务器。
7、 一种分布式自增计数的实现装置， 其中， 包括：
第一通信单元， 设置为接收服务终端发送的自增计数请求消息， 该自 增计数请求消息中携带用于指示操作内容的标识信息；
获取单元， 设置为根据所述标识信息， 获取本地对应该标识信息存储 的计数结果， 以及获取各第二服务器上对应该标识信息存储的计数结果， 其中， 本装置和第二服务器互为备份；
执行单元， 设置为根据获得的各计数结果中更新时间距当前时间的时 长最小的计数结果执行自增计数操作， 获得更新后的计数结果； 第二通信单元， 设置为将所述更新后的计数结果发往各第二服务器进 行备份， 并在确认超过设定数目的第二服务器备份成功时， 确定当前自增 计数操作成功。
8、 如权利要求 7所述的装置， 其中， 所述第一通信单元接收到至少两 个服务终端发送的携带同一标识信息的自增计数请求消息时， 所述第一通 信单元将所述至少两个自增计数请求消息指示的自增数目进行合并后， 再 进行后续操作。
9、如权利要求 7所述的装置， 其中， 所述获取单元根据所述标识信息， 获取各第二服务器上对应该标识信息存储的计数结果为：
所述获取单元通过所述第二通信单元向所述标识信息对应的各第二服 务器， 发送携带所述标识信息的副本获取请求消息， 令每一个接收到所述 标识信息的第二服务器， 向本装置返回所述标识信息及第二服务器本地对 应该标识信息保存的计数结果；
或， 所述获取单元通过所述第二通信单元向所述标识信息对应的各第 二服务器 , 发送携带所述标识信息及本装置对应所述标识信息保存的计数 结果的副本获取请求消息， 令每一个接收到所述标识信息和计数结果的第 二服务器， 在确定第二服务器本地对应所述标识信息保存的计数结果的更 新时间距当前时间的时长， 小于接收的计数结果的更新时间距当前时间的 时长时， 向本装置返回所述标识信息及第二服务器本地对应该标识信息保 存的计数结果。
10、 如权利要求 9所述的装置， 其中， 所述获取单元通过所述第二通 信单元发送副本获取请求消息后， 所述执行单元确定针对所述副本获取请 求消息进行反馈的副本服务器的数目达到预设门限值时， 根据获得的各计 数结果中更新时间距当前时间的时长最小的计数结果执行自增计数操作。
11、 如权利要求 7至 10任一项所述的装置， 其中， 所述执行单元根据 获得的各计数结果中更新时间距当前时间的时长最小的计数结果执行自增 计数操作为：
所述执行单元根据获得的各计数结果中， 时间截指示时间最晚的计数 结果执行自增计数操作；
或， 所述执行单元根据获得的各计数结果中， 版本号最大的计数结果 执行自增计数操作。
12、 一种分布式自增计数的实现系统， 其中， 包括互为备份的第一服 务器和第二服务器， 其中，
第一服务器， 设置为接收服务终端发送的自增计数请求消息， 所述自 增计数请求消息中携带用于指示操作内容的标识信息， 根据所述标识信息， 获取本地对应所述标识信息存储的计数结果， 以及获取各第二服务器上对 应所述标识信息存储的计数结果， 并根据获得的各计数结果中更新时间距 当前时间的时长最小的计数结果执行自增计数操作， 获得更新后的计数结 果， 再将所述更新后的计数结果发往各第二服务器进行备份， 并在确认超 过设定数目的第二服务器备份成功时， 确定当前自增计数操作成功；
第二服务器， 设置为根据第一服务器发送的标识信息， 向第一服务器 返回本地对应所述标识信息保存的计数结果， 以及对第一服务器发送的更 新后的计数结果进行备份， 并向第一服务器返回备份结果。
PCT/CN2012/070854 2011-06-15 2012-02-02 一种分布式自增计数的实现方法、装置及系统 WO2012171349A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP12800793.7A EP2723017A4 (en) 2011-06-15 2012-02-02 METHOD, DEVICE AND SYSTEM FOR IMPLEMENTING A DISTRIBUTED AUTO INCREMENT COUNT

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110160425.5A CN102833281B (zh) 2011-06-15 2011-06-15 一种分布式自增计数的实现方法、装置及系统
CN201110160425.5 2011-06-15

Publications (1)

Publication Number Publication Date
WO2012171349A1 true WO2012171349A1 (zh) 2012-12-20

Family

ID=47336251

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/070854 WO2012171349A1 (zh) 2011-06-15 2012-02-02 一种分布式自增计数的实现方法、装置及系统

Country Status (3)

Country Link
EP (1) EP2723017A4 (zh)
CN (1) CN102833281B (zh)
WO (1) WO2012171349A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108363708A (zh) * 2017-06-08 2018-08-03 国云科技股份有限公司 一种业务订单号生成方法

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104794172B (zh) * 2015-03-31 2018-09-11 北京奇艺世纪科技有限公司 一种数据处理方法和装置
CN107040558A (zh) * 2016-02-03 2017-08-11 阿里巴巴集团控股有限公司 一种任务监控方法及装置
CN106022747B (zh) * 2016-05-12 2019-09-27 苏州朗动网络科技有限公司 一种基于分布式高并发条件下的计费方法
CN106066894A (zh) * 2016-06-23 2016-11-02 广州市百果园网络科技有限公司 数据全缓存方法和数据全缓存装置
CN108804442B (zh) * 2017-04-27 2022-06-07 北京京东尚科信息技术有限公司 序列号生成方法和装置
CN109005217B (zh) * 2018-07-05 2019-10-25 山东九州信泰信息科技股份有限公司 云计算环境下利用只读变量解决并发冲突的方法
CN109471154B (zh) * 2018-11-09 2020-03-17 中国核动力研究设计院 一种小型gm计数管宽量程监测仪表
CN112783924B (zh) * 2019-11-07 2024-07-16 北京沃东天骏信息技术有限公司 一种脏数据识别方法、装置和系统
CN112131267B (zh) * 2020-08-14 2023-10-03 北京达佳互联信息技术有限公司 计数处理方法、装置、服务器和计数处理系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1602618A (zh) * 2001-12-13 2005-03-30 诺基亚公司 在网络单元中收集计数器数据的方法和系统
US20090222684A1 (en) * 2008-02-28 2009-09-03 Serebrin Benjamin C Fast, Automatically Scaled Processor Time Stamp Counter
CN101710907A (zh) * 2009-11-06 2010-05-19 惠州Tcl移动通信有限公司 一种采用弹性泡棉的卡扣装置
CN101877650A (zh) * 2010-05-20 2010-11-03 中兴通讯股份有限公司 一种自动更新软件版本的方法及系统
CN101478422B (zh) * 2008-12-01 2010-12-22 北京星网锐捷网络技术有限公司 一种软件版本自协商方法及系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7716180B2 (en) * 2005-12-29 2010-05-11 Amazon Technologies, Inc. Distributed storage system with web services client interface
US7962697B2 (en) * 2006-10-05 2011-06-14 Waratek Pty Limited Contention detection

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1602618A (zh) * 2001-12-13 2005-03-30 诺基亚公司 在网络单元中收集计数器数据的方法和系统
US20090222684A1 (en) * 2008-02-28 2009-09-03 Serebrin Benjamin C Fast, Automatically Scaled Processor Time Stamp Counter
CN101478422B (zh) * 2008-12-01 2010-12-22 北京星网锐捷网络技术有限公司 一种软件版本自协商方法及系统
CN101710907A (zh) * 2009-11-06 2010-05-19 惠州Tcl移动通信有限公司 一种采用弹性泡棉的卡扣装置
CN101877650A (zh) * 2010-05-20 2010-11-03 中兴通讯股份有限公司 一种自动更新软件版本的方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2723017A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108363708A (zh) * 2017-06-08 2018-08-03 国云科技股份有限公司 一种业务订单号生成方法

Also Published As

Publication number Publication date
CN102833281A (zh) 2012-12-19
EP2723017A4 (en) 2014-11-19
CN102833281B (zh) 2018-01-09
EP2723017A1 (en) 2014-04-23

Similar Documents

Publication Publication Date Title
WO2012171349A1 (zh) 一种分布式自增计数的实现方法、装置及系统
WO2020238365A1 (zh) 消息消费方法、装置、设备及计算机存储介质
US10701177B2 (en) Automatic data request recovery after session failure
US9799017B1 (en) Cross-data-store operations in log-coordinated storage systems
WO2021128915A1 (zh) 智能设备的监控方法及装置
CN112039970B (zh) 一种分布式业务锁服务方法、服务端、系统及存储介质
CN106034137A (zh) 用于分布式系统的智能调度方法及分布式服务系统
WO2013163864A1 (zh) 数据持久化处理方法、装置及数据库系统
WO2020134199A1 (zh) 实现数据一致性的方法和装置、服务器和终端
CN112463437B (zh) 存储集群系统离线节点的业务恢复方法、系统及相关组件
WO2017181430A1 (zh) 分布式系统的数据库复制方法及装置
CN108512753B (zh) 一种集群文件系统中消息传输的方法及装置
CN107135097A (zh) 基于簿记建档的容灾系统及容灾方法
JP5065259B2 (ja) 企業情報システムとクライアントとの間の通信に役立つ装置、システム、方法、およびコンピュータプログラム（企業情報システムとクライアントとの間の通信に役立つ装置、システム、および方法）
WO2023147716A1 (zh) 一种流控计费方法、装置、系统、电子设备、介质及产品
TWI429232B (zh) 備用伺服器、恢復用戶端在主用伺服器註冊的系統及方法
CN105471616A (zh) 缓存系统管理方法和系统
US8359601B2 (en) Data processing method, cluster system, and data processing program
CN112650629B (zh) 区块链索引数据恢复方法、装置、设备和计算机存储介质
US9043274B1 (en) Updating local database and central database
CN106951341A (zh) 一种实现分布式架构的数据库备份方法
CN111404737B (zh) 一种容灾处理方法以及相关装置
CN104463014A (zh) 一种基于快照的oracle数据库保护方法
CN116384993A (zh) 基于云支付中心实现订单支付状态高一致性的方法与系统
JP2015114952A (ja) ネットワークシステム、監視制御装置およびソフトウェア検証方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12800793

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE