CN101329670A - 复制数据库环境下保持数据一致性的方法和系统 - Google Patents
复制数据库环境下保持数据一致性的方法和系统 Download PDFInfo
- Publication number
- CN101329670A CN101329670A CNA2007101119662A CN200710111966A CN101329670A CN 101329670 A CN101329670 A CN 101329670A CN A2007101119662 A CNA2007101119662 A CN A2007101119662A CN 200710111966 A CN200710111966 A CN 200710111966A CN 101329670 A CN101329670 A CN 101329670A
- Authority
- CN
- China
- Prior art keywords
- participant
- database
- overall situation
- ballot
- coordinator
- 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.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种复制数据库环境下保持数据一致性的方法和系统。该方法包括：协调者向复制数据库环境中的参与者发送事务请求，所述参与者根据所述事务请求在本地执行复制事务；参与者根据本地复制事务执行结果向协调者投票，协调者根据参与者返回的投票结果做出全局决定，其中如果至少有一个参与者投票已准备好，则协调者做出全局提交的全局决定，否则协调者做出全局夭折的全局决定；参与者执行所述全局决定。该系统包括协调者和复制数据库环境中的参与者。应用本发明，通过对做出全局决定的条件进行改变，在保证数据一致性的基础上，既节约了资源，又提高了系统的可用性。
Description
技术领域
本发明涉及数据库技术领域，特别是涉及一种在复制数据库环境下保持数据一致性的方法和系统。
背景技术
为了支持各种数据无关(data-less)应用，即数据库层和应用层分离，通常需要提供具有高可用性服务的可靠架构，如三层架构。
三层架构包括应用客户端(AC)、数据库前端(DB-FE)和数据库后端(DB-BE)。客户端用于向数据库前端发起请求。为了负载均衡和冗余性考虑，客户端可以连接到一个或者多个数据库前端。数据库前端接收来自于客户端的请求，将该请求路由到数据库后端，并接收由数据库后端返回的请求结果，然后将请求结果再回传给用客户端，其中请求结果既可以是成功的请求结果，也可以是失败的请求结果。数据库后端用于保存用户数据，执行来自于数据库前端的操作请求，并且将执行结果/响应返回到数据库前端。同样，为了冗余性考虑，多个数据库后端可以组成集群(cluster)。组成集群的目的是为了保证系统的高可用性。一个集群中所有数据库后端保持数据相互复制的关系，这样可保证一个数据库后端发生故障时，该集群中的其它数据库后端仍能提供服务。集群中各数据库后端之间的协同由复制管理器负责，以协调集群内数据的一致性。一个集群的数据库后端既可以放置在一起，也可以在地理上间隔较远。
由于硬件节点故障、软件故障或连接错误等失败原因，上述架构中的组成元件可能会出现故障。为了保证某个数据库后端出现故障时数据库前端仍然能够存取一致性数据，位于同一集群中各个数据库后端中的数据应严格保持同步复制。即只要某一数据库后端中的数据产生了更新，那么该集群中所有数据库后端中的相应数据也应同时更新，从而保证数据一致性。广而言之，同步复制的目的就是保证集群中的所有单元具有相同的数据值。
在现有技术中，如果某一个单元的数据不能成功更新，那么为了保证集群中所有单元的数据一致性，该更新请求将会被拒绝。如果这种更新失败较为频繁，则对系统的高可用性会带来负面的影响。
为了保证数据一致性，现有技术中有一种两阶段提交(2PC)协议。2PC协议是保证分布式数据库一致性和原子性的标准协议。2PC协议是一种在事务管理器和所有加入到事务中的资源之间的协议，确保了要么所有的资源管理器都提交了事务，要么所有的资源管理器都撤销了事务。在这个协议中，当应用程序请求提交事务时，事务管理器向所有涉及的资源管理器发出准备请求。每个资源都会依次发送一个应答，指出是否准备好提交它的操作。只有当所有的资源管理器都准备好提交以后，事务管理器才会向所有的资源管理器发出提交命令。否则，事务管理器会发出一个回退命令，从而回退事务。
在2PC协议中，只有当收到所有参与者投票“已准备好(ready)”，才能决定全局事务“提交(commit)”，并且只要收到一个参与者投票“夭折(abort)”，则决定全局事务“夭折”。实际上，对于复制数据库环境下的复制事务来说，由于需要所有的参与者都能在响应前完成更新，因此做出全局事务“提交”的条件非常苛刻，这就造成很多实际上能完成复制事务的参与者却不能正常提交复制事务。另外，当一个参与者失败时，大量的复制事务都会随之“夭折”，因此现有技术中做出全局事务“夭折”的条件又过于宽松，从而造成大量的资源浪费。不仅于此，如果有某一个参与者始终不能成功更新，那么整个更新事务就都不能够获得“提交”，而这显然不合乎复制数据库环境下的高可用性要求。
因此，现有2PC协议做出全局决定的条件并不能有效地应用到复制数据库环境，这一方面会带来资源浪费，另一方面又会导致一些正常事务无法提交。
发明内容
本发明提供一种复制数据库环境下保持数据一致性的方法和系统，从而克服现有技术中资源浪费，又不能保证正常事务实现提交的缺点。
为了达到上述目的，本发明的技术方案是这样实现的：
一种复制数据库环境下保持数据一致性的方法，包括：
协调者向复制数据库环境中的参与者发送事务请求，所述参与者根据所述事务请求在本地执行复制事务；
参与者根据本地复制事务执行结果向协调者投票，协调者根据参与者返回的投票结果做出全局决定，其中如果至少有一个参与者投票已准备好，则协调者做出全局提交的全局决定，否则协调者做出全局夭折的全局决定；
参与者执行所述全局决定。
较佳地，该方法包括：当至少有一个参与者投票已准备好时，协调者进一步向投票夭折的参与者发送重试命令；投票夭折的参与者收到所述重试命令后，重新在本地执行复制事务。
较佳地，所述投票夭折的参与者重新在本地执行复制事务后，进一步重新再向协调者投票。
较佳地，协调者做出全局提交的命令后，该方法进一步包括：设置重新在本地执行复制事务后投票结果为夭折的参与者状态为“不可用”，和/或设置协调者未能收到其投票的参与者状态为“不可用”。
本发明还公开了一种复制数据库环境下保持数据一致性的系统，包括：
协调者，用于向复制数据库环境中的参与者发送事务请求，并根据参与者返回的投票结果做出全局决定，其中如果至少有一个参与者投票已准备好，则做出“全局提交”的全局决定，否则做出“全局夭折”的全局决定；
复制数据库环境中的参与者，用于根据本地复制事务执行结果向协调者投票，并执行由协调者做出的所述全局决定。
较佳地，所述协调者，进一步用于当至少有一个参与者投票已“准备好”时，向投票夭折的参与者发送重试命令；
投票夭折的参与者，用于在收到所述重试命令后，重新在本地执行复制事务。
可选地，投票夭折的参与者，进一步用于在本地重新执行复制事务后重新再向协调者“投票”。
可选地，协调者，进一步用于设置重新在本地执行复制事务后投票结果为“夭折”的参与者状态为“不可用”，和/或设置协调者未能收到其投票的参与者状态为“不可用”。
此外，本发明还公开了一种数据库系统，包括：
应用客户端，用于向数据库前端发送事务请求；
数据库前端，用于向数据库后端转发所述事务请求，并根据数据库后端返回的投票结果做出全局决定，其中如果至少有一个数据库后端投票已准备好，则数据库前端做出全局提交的全局决定，否则数据库前端做出全局夭折的全局决定；
数据库后端，用于根据所述事务请求在本地执行复制事务，并根据本地复制事务执行结果向数据库前端投票，并执行由数据库前端做出的所述全局决定。
可选地，数据库前端，进一步用于当至少有一个数据库后端投票“已准备好”时，向投票“夭折”的数据库后端发送重试命令；
投票夭折的数据库后端，用于在收到所述重试命令后，重新在本地执行复制事务。
可选地，投票夭折的数据库后端，进一步用于在重新在本地执行复制事务后重新再向数据库前端投票。
可选地，数据库前端，进一步用于设置重新在本地执行复制事务后投票结果为夭折的数据库后端状态为“不可用”，和/或设置数据库前端未能收到其投票的数据库后端状态为“不可用”。
可选地，所述数据库后端集成在一起，或者在地理上相互隔开。
另外，本发明还公开了一种采用三层结构的无线通信系统，包括信号层、应用层和数据库后端，数据库后端包括至少一个复制路径服务器；其中信号层，用于接收路径存取请求，并将所述路径存取请求转发到应用层；应用层，用于向数据库后端转发所述路径存取请求，并根据数据库后端返回的投票结果做出全局决定，其中如果至少有一个复制路径服务器投票已准备好，则应用层做出全局提交的全局决定，否则应用层做出全局夭折的全局决定；复制路径服务器，用于根据所述路径存取请求在本地执行复制事务，根据本地复制事务执行结果向应用层投票，并执行由应用层做出的所述全局决定。
由此可见，本发明中协调者做出全局决定的条件为：至少有一个参与者投票已准备好，则协调者做出全局提交的全局决定；如果任何一个参与者都没有向协调者发出“准备好”的投票，则协调者做出全局夭折的全局决定。应用本发明以后，即使某些参与者投票夭折，本发明也可以实现对已准备好的参与者做出提交的决定，从而保证复制事务能够正常提交。因此个别参与者的失败不会影响复制事务的正常提交，从而避免了资源浪费，并提高了系统的可用性。
除此之外，当至少有一个参与者投票已准备好时，可以向投票夭折的参与者发送重试请求，投票夭折的参与者收到重试请求时，重新执行事务后再投票。因此在本发明中，参与者投票夭折后，不能单方面决定夭折，还需要等待协调者决定。而且，本发明可以对重新在本地执行复制事务后投票结果仍为夭折的参与者、或未能投票的参与者的状态设置为“不可用”，协调者将不再向“不可用”状态的参与者发送请求，所以本发明做出全局决定的逻辑判断更加符合实际需求。
附图说明
下面将通过参照附图详细描述本发明的示例性实施例，使本领域的普通技术人员更清楚本发明的上述及其它特征和优点，附图中：
图1是本发明复制数据库环境下保持数据一致性的示范性方法流程示意图；
图2是本发明复制数据库环境下保持数据一致性的示范性系统结构示意图；
图3是应用本发明在三层结构中保持数据一致性的系统示范性系统结构示意图；
图4是三层结构中参与者状态转换示意图；
图5是在本发明第一实施例中保持数据一致性的示范性方法流程图；
图6是在本发明第二实施例中保持数据一致性的示范性方法流程图；
图7是在本发明第三实施例中保持数据一致性的示范性方法流程图；
图8是根据本发明在通信系统中保持数据一致性的示范性结构示意图。
具体实施方式
本发明提出了一种复制数据库环境下保持数据一致性的。在该方法中，协调者将做出全局决定的条件设置为：如果至少有一个参与者投票“已准备好“，则协调者做出“全局提交”的全局决定，否则协调者做出“全局夭折”的全局决定。
本发明提出了一种复制数据库环境下保持数据一致性的。在该方法中，协调者将做出全局决定的条件设置为：如果至少有一个参与者投票“已准备好“，则协调者做出“全局提交”的全局决定，否则协调者做出“全局夭折”的全局决定。
图1是本发明复制数据库环境下保持数据一致性的示范性流程示意图。
如图1所示，该方法包括：
步骤101：协调者向复制数据库环境中的参与者发送事务请求，参与者根据事务请求在本地执行复制事务。
在这里，协调者可以通过多种方式获取事务请求，比如通过网络连接从客户端获取事务请求。
步骤102：参与者根据本地复制事务执行结果向协调者投票，协调者根据参与者返回的投票结果做出全局决定，其中如果至少有一个参与者投票“已准备好”，则协调者做出“全局提交”的全局决定；否则，如果没有任何参与者投票“已准备好”时，协调者做出“全局夭折”的全局决定。
参与者如果本地复制事务执行成功，则向协调者投票“准备好”，否则向协调者投票“夭折”。参与者可以在超时或收到全部参与者返回投票时做出“全局决定”。具体地：
1)如果全部参与者投票“准备好”，则协调者决定“全局提交”；
2)如果全部参与者投票夭折或未收到任何“准备好”投票，则协调者决定全局夭折；
也就是，决定全局提交的条件是：至少有一个参与者投票“准备好”。
步骤103：参与者执行所述“全局决定”。
在这里，如果参与者收到提交命令，则提交本地复制事务；如果参与者收到夭折命令，则夭折本地复制事务。
优选地，在步骤102中，如果至少有一个参与者投票“夭折”，则向其发送重试(retry)命令，并等待重试结果。无论重试结果如何，协调者都决定全局提交。投票夭折的参与者收到重试命令后，重新在本地执行复制事务，并根据事务执行结果重新投票，然后再等待全局决定来提交或夭折本地复制事务。此时，可以预先设置重试次数N，如果重试N次以后还是不能成功更新本地数据，则向协调者投票夭折。
另外，可以对重新在本地执行复制事务后投票结果仍为夭折的参与者、或未能投票的参与者的状态设置为“不可用”，协调者将不再向设置为“不可用”的参与者发送请求。
本发明还提出了一种复制数据库环境下保持数据一致性的系统。
图2是本发明复制数据库环境下保持数据一致性的系统示范性结构示意图。
如图2所示，该系统包括：
协调者201，用于向复制数据库环境中的参与者202发送事务请求，并根据参与者202返回的投票结果做出全局决定，其中如果至少有一个参与者投票“已准备好”，则做出“全局提交”的全局决定，否则做出“全局夭折”的全局决定；
复制数据库环境中的参与者202，用于根据本地复制事务执行结果向协调者投票，并执行由协调者201做出的所述全局决定。
优选地，协调者201，进一步用于当至少有一个参与者投票“已准备好”时，向投票夭折的参与者发送重试命令；
投票夭折的参与者，用于在收到所述重试命令后，重新在本地执行复制事务。
更优选地，投票夭折的参与者，还可以进一步在重新在本地执行复制事务后重新再向协调者投票。无论重试结果如何，协调者201都决定全局提交。投票夭折的参与者收到重试命令后，重新在本地执行复制事务，并根据事务执行结果重新投票，然后再等待全局决定来提交或夭折本地复制事务。
协调者201，可以进一步设置重新在本地执行复制事务后投票结果为夭折的参与者状态为“不可用”，和/或设置协调者未能收到其投票的参与者状态为“不可用”。
本领域技术人员可以意识到，图2只是给出了本发明系统的基本结构，这只用于对本发明进行阐述，而不用于对本发明进行限制。
实质上，当本发明系统中的各功能单元具体化时，本发明系统可以存在多种具体的结构。在实际应用中，可以将多本发明应用到多种的具体复制数据库环境下。比如，可以将本发明应用到一个三层通信系统的结构中。
图3是应用本发明在三层结构中保持数据一致性的系统示范性结构示意图。此处，数据库前端对应为前述的协调者，数据库后端对应为前述的参与者。数据库前端和数据库后端通过总线连接，若干个数据库后端组成集群。
如图3所示，该系统包括：
应用客户端，用于向数据库前端发送事务请求；
所述的数据库前端，用于向数据库后端转发所述事务请求，并根据数据库后端返回的投票结果做出全局决定，其中如果至少有一个数据库后端投票已准备好，则数据库前端做出全局提交的全局决定，否则数据库前端做出全局夭折的全局决定；
所述的数据库后端，用于根据所述事务请求在本地执行复制事务，根据本地复制事务执行结果向数据库前端投票，并执行由数据库前端做出的所述全局决定。
优选地，所述的数据库前端，被进一步用于当至少有一个数据库后端投票已准备好时，向投票夭折的数据库后端发送重试命令；
投票夭折的数据库后端，用于在收到所述重试命令后，重新在本地执行复制事务。
其中，投票夭折的数据库后端，可以进一步用于在重新在本地执行复制事务后重新再向数据库前端投票。无论重试结果如何，数据库前端都决定“全局提交”。投票夭折的数据库后端收到重试命令后，重新在本地执行复制事务，并根据事务执行结果重新投票，然后再等待全局决定来提交或夭折本地复制事务。
数据库前端，进一步用于设置重新在本地执行复制事务后投票结果为夭折的数据库后端状态为“不可用”，和/或设置数据库前端未能收到其投票的数据库后端状态为“不可用”。
图3中的数据库后端既可以集成在一起，也可以在地理上相互隔开。
基于图3所示系统结构，图4是三层结构中参与者状态转换示意图。此处的参与者即为数据库后端。如图4所示，数据库后端状态分为“不可用(down)”、“不同步(out-of-sync)”和“可用(avai lable)”。
每个数据库前端可以通过心跳信息(Heartbeat Message)了解每个数据库后端的最新状态。心跳信息是用于探测机器之间网络连接是否保持的信息。数据库后端“不可用”表示数据库后端和数据库前端之间的连接断开。数据库后端“不同步”表示数据库后端和数据库前端之间已经连接上，但其数据不一致。数据库后端“可用”表示数据库后端中的数据是同步的。
数据库前端接收到来自应用客户端的更新请求后，数据库前端确定将该请求发送到哪个数据库后端集群，并且仅向该数据库后端集群中的所有可用数据库后端发送该请求。当同一数据库后端集群中的不同数据库后端处于不同步状态时，需要通过重新同步(resync)过程来获取所有的丢失更新，并且该状态被相应地转换为可用。当同一数据库后端集群中的不同数据库后端处于“不可用”状态时，需要通过保持心跳来使之处于“可用”状态，然后再通过重新同步(resync)过程来获取所有的丢失更新，并且该状态被相应地转换为可用。类似地，当处于“可用”状态的数据库后端丢失心跳后，状态被相应地转换为“不可用”。当处于“可用”状态的数据库后端重试失败后，状态被相应地转换为“不同步”。
下面结合图5对应用本发明于三层结构中的第一实施例进行说明。
第一实施例：
图5是在本发明第一实施例中保持数据一致性的示范性方法流程图。在该实施例中，投票夭折的协调者重试成功。
如图5所示，该方法包括：
步骤501：客户端向协调者发送事务请求。
步骤502：协调者分别向各参与者转发该事务请求。
此处，为了简化描述，仅示出向参与者a和参与者b转发事务请求。对于参与者数量大于两个的情形，可以据此类推。
步骤503：各参与者接收到事务请求后，在本地执行数据更新，并向协调者投票。
此处，参与者a本地数据更新成功，向协调者投票准备好；参与者b本地数据更新不成功，向协调者投票夭折。
步骤504～步骤505：协调者根据参与者的投票结果做出决定。
此时，由于参与者a向协调者投票准备好，协调者可以向参与者a做出提交的决定。优选地，协调者向参与者b发出重试命令。参与者b在收到所述重试命令后，重新在本地执行复制事务，并重新再向协调者投票准备好。
步骤506～步骤507：协调者向客户端返回响应，并且向参与者a和参与者b发出全局提交命令。
实质上，协调者还可以将未能收到其投票的参与者的状态设置为“不可用”。
第二实施例：
图6是在本发明第二实施例中保持数据一致性的示范性方法流程图。在该实施例中，投票夭折的协调者重试失败。
如图6所示，该方法包括：
步骤601：客户端向协调者发送事务请求。
步骤602：协调者分别向各参与者转发该事务请求。
此处，为了简化描述，仅示出向参与者a和参与者b转发事务请求。对于参与者数量大于两个的情形，可以据此类推。
步骤603：各参与者接收到事务请求后，在本地执行数据更新，并向协调者投票。
此处，参与者a本地数据更新成功，向协调者投票准备好；参与者b本地数据更新不成功，向协调者投票夭折。
步骤604～步骤605：协调者根据参与者的投票结果做出决定。
此时，由于参与者a向协调者投票准备好，协调者可以向参与者a做出提交的决定。优选地，协调者向参与者b发出重试命令。参与者b在收到所述重试命令后，重新在本地执行复制事务，但是由于重新在本地执行复制事务的结果仍然失败，则再向协调者投票夭折。
步骤606～步骤607：协调者向客户端返回响应，并且向参与者a发出全局提交命令，由于参与者b重试失败，则设置参与者b状态为“不可用”，并向参与者b发出重新同步命令。
实质上，协调者也可以将未能收到其投票的参与者状态设置“不可用”。
第三实施例：
图7是在本发明第三实施例中保持数据一致性的示范性方法流程图。在该实施例中，处于“不可用”状态的参与者将被放弃(discard)。
如图7所示，该方法包括：
步骤701：客户端向协调者发送事务请求。
步骤702：协调者分别向各参与者转发该事务请求。
此处，为了简化描述，仅示出向参与者a和参与者b转发事务请求。对于参与者数量大于两个的情形，可以据此类推。
步骤703：各参与者接收到事务请求后，在本地执行数据更新，并向协调者投票。
此处，参与者a本地数据更新成功，向协调者投票准备好；参与者b状态“不可用”。造成参与者b状态为不可用的原因可能是与协调者的连接断开。
步骤704～步骤705：协调者向客户端返回响应，并根据参与者a的投票结果做出决定。
此时，由于参与者a向协调者投票准备好，协调者可以向参与者a做出提交的决定。同时，协调者根据心跳信息判断参与者b状态不可用，则丢弃参与者b，也不用再向参与者b发送重试命令。
综上所述，本发明通过对协调者将做出全局决定的条件进行了优化，对现有的2PC协议进行了改进，克服了现有技术中资源浪费，又不能保证正常事务实现提交的缺点。
可以将本发明应用到各种具体的数据库环境下，比如可以应用到任意的三层数据库结构中。进一步地，可以将本发明应用到采用了三层数据库结构的无线通信系统中。
图8是根据本发明在采用了三层数据库结构无线通信系统中保持数据一致性的示范性结构示意图。
如图8所示，该系统包括信令层、应用层和数据库层。其中信号层用于接受网络访问信号，并将网络访问信号转发到应用层中的不同应用前端。
应用层包括各种应用前端，根据网络访问信号，例如通过X.500/轻量级目录访问协议(LDAP)访问数据库层中的路径服务器(DS)；数据库层包括若干数据库后端，每个数据库后端包括若干个路径服务器。路径服务器存放路径数据并提供路径存取服务。
为提供高可靠性服务，一个数据库后端可以由多个路径服务器组成。如图8所示范性描述，一个数据库后端由三个路径服务器组成。
信号层例如可以具体为7号信令网络或者会话初始化协议(SIP)网络，用于接收路径存取请求，并将所述路径存取请求转发到应用层。
应用层具体可以包括归属位置寄存器(HLR)应用前端和/或归属签约用户服务器(HSS)。应用层可以用于向数据库后端转发所述路径存取请求，并根据数据库后端返回的投票结果做出全局决定，其中如果至少有一个复制路径服务器投票已准备好，则应用层做出全局提交的全局决定，否则应用层做出全局夭折的全局决定。所述的复制路径服务器用于根据所述路径存取请求在本地执行复制事务，根据本地复制事务执行结果向应用层投票，并执行由应用层做出的所述全局决定。
以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (14)
1.一种复制数据库环境下保持数据一致性的方法，包括：
协调者向复制数据库环境中的参与者发送事务请求，所述参与者根据所述事务请求在本地执行复制事务；
参与者根据本地复制事务执行结果向协调者投票，协调者根据参与者返回的投票结果做出全局决定，其中如果至少有一个参与者投票已准备好，则协调者做出全局提交的全局决定；否则协调者做出全局夭折的全局决定；
参与者执行所述全局决定。
2.根据权利要求1所述的方法，其特征在于，该方法包括：当至少有一个参与者投票已准备好时，协调者进一步向投票夭折的参与者发送重试命令；投票夭折的参与者收到所述重试命令后，重新在本地执行复制事务。
3.根据权利要求2所述的方法，其特征在于，所述投票夭折的参与者重新在本地执行复制事务后，重新再向所述协调者投票。
4.根据权利要求2所述的方法，其特征在于，协调者做出全局提交的命令后，该方法进一步包括：设置重新在本地执行复制事务后投票结果为夭折的参与者状态为不可用，和/或设置协调者未能收到其投票的参与者状态为不可用。
5.一种复制数据库环境下保持数据一致性的系统，所述复制数据库环境包括至少一个参与者，其特征在于，包括：
协调者，用于向参与者发送事务请求，并根据参与者返回的投票结果做出全局决定，其中如果至少有一个参与者投票已准备好，则做出全局提交的全局决定，否则做出全局夭折的全局决定；
参与者，位于复制数据库环境中，用于根据本地复制事务执行结果向协调者投票，并执行由协调者做出的所述全局决定。
6.根据权利要求5所述的复制数据库环境下保持数据一致性的系统，其特征在于，
所述协调者，进一步用于当至少有一个参与者投票已准备好时，向投票夭折的参与者发送重试命令；
投票夭折的参与者，用于在收到所述重试命令后，重新在本地执行复制事务。
7.根据权利要求6所述的复制数据库环境下保持数据一致性的系统，其特征在于，
投票夭折的参与者，进一步用于在重新在本地执行复制事务后重新再向协调者投票。
8.根据权利要求6所述的复制数据库环境下保持数据一致性的系统，其特征在于，
协调者，进一步用于设置重新在本地执行复制事务后投票结果为夭折的参与者状态为不可用，和/或设置未能收到其投票的参与者状态为不可用。
9.一种数据库系统，其特征在于，包括：
应用客户端，用于向数据库前端发送事务请求；
数据库前端，用于向数据库后端转发所述事务请求，并根据数据库后端返回的投票结果做出全局决定，其中如果至少有一个数据库后端投票已准备好，则数据库前端做出全局提交的全局决定，否则数据库前端做出全局夭折的全局决定；
数据库后端，用于根据所述事务请求在本地执行复制事务，根据本地复制事务执行结果向数据库前端投票，并执行由数据库前端做出的所述全局决定。
10.根据权利要求9所述的数据库系统，其特征在于，
数据库前端，进一步用于当至少有一个数据库后端投票已准备好时，向投票夭折的数据库后端发送重试命令；
投票夭折的数据库后端，用于在收到所述重试命令后，重新在本地执行复制事务。
11.根据权利要求10所述的数据库系统，其特征在于，
投票夭折的数据库后端，进一步用于在重新在本地执行复制事务后重新再向数据库前端投票。
12.根据权利要求10所述的数据库系统，其特征在于，
数据库前端，进一步用于设置重新在本地执行复制事务后投票结果为夭折的数据库后端状态为不可用，和/或设置数据库前端未能收到其投票的数据库后端状态为不可用。
13.根据权利要求9-12中任一项所述的数据库系统，其特征在于，
所述数据库后端集成在一起，或者在地理上相互隔开。
14.一种采用三层结构的无线通信系统，包括信号层、应用层和数据库后端，数据库后端包括至少一个复制路径服务器，其特征在于，信号层，用于接收路径存取请求，并将所述路径存取请求转发到应用层；应用层，用于向数据库后端转发所述路径存取请求，并根据数据库后端返回的投票结果做出全局决定，其中如果至少有一个复制路径服务器投票已准备好，则应用层做出全局提交的全局决定，否则应用层做出全局夭折的全局决定；复制路径服务器，用于根据所述路径存取请求在本地执行复制事务，根据本地复制事务执行结果向应用层投票，并执行由应用层做出的所述全局决定。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2007101119662A CN101329670B (zh) | 2007-06-20 | 2007-06-20 | 复制数据库环境下保持数据一致性的方法和系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2007101119662A CN101329670B (zh) | 2007-06-20 | 2007-06-20 | 复制数据库环境下保持数据一致性的方法和系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101329670A true CN101329670A (zh) | 2008-12-24 |
| CN101329670B CN101329670B (zh) | 2011-03-23 |
Family
ID=40205483
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2007101119662A Expired - Fee Related CN101329670B (zh) | 2007-06-20 | 2007-06-20 | 复制数据库环境下保持数据一致性的方法和系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101329670B (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102203779A (zh) * | 2011-05-03 | 2011-09-28 | 华为技术有限公司 | 更新数据的方法和控制装置 |
| CN102571850A (zh) * | 2010-12-24 | 2012-07-11 | 中国移动通信集团山东有限公司 | 事务提交系统、方法及设备 |
| CN103677968A (zh) * | 2012-09-07 | 2014-03-26 | 腾讯科技（深圳）有限公司 | 事务处理方法、事务协调器装置、事务参与者装置及系统 |
| CN106547610A (zh) * | 2016-10-11 | 2017-03-29 | 北京国电通网络技术有限公司 | 一种分布式事务提交的方法及系统 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI105870B (fi) * | 1997-03-21 | 2000-10-13 | Nokia Networks Oy | Menetelmä masterkeskuksen ja varakeskuksen datan epäkonsistenttiuden estämiseksi |
| CN100561920C (zh) * | 2004-12-27 | 2009-11-18 | 北京航空航天大学 | Web服务事务处理系统及处理方法 |
| CN100391161C (zh) * | 2005-03-18 | 2008-05-28 | 华为技术有限公司 | 网络管理系统中模板数据的全局管理方法 |
-
2007
- 2007-06-20 CN CN2007101119662A patent/CN101329670B/zh not_active Expired - Fee Related
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102571850A (zh) * | 2010-12-24 | 2012-07-11 | 中国移动通信集团山东有限公司 | 事务提交系统、方法及设备 |
| CN102571850B (zh) * | 2010-12-24 | 2014-08-06 | 中国移动通信集团山东有限公司 | 事务提交系统、方法及设备 |
| CN102203779A (zh) * | 2011-05-03 | 2011-09-28 | 华为技术有限公司 | 更新数据的方法和控制装置 |
| WO2011120452A2 (zh) * | 2011-05-03 | 2011-10-06 | 华为技术有限公司 | 更新数据的方法和控制装置 |
| WO2011120452A3 (zh) * | 2011-05-03 | 2012-03-08 | 华为技术有限公司 | 更新数据的方法和控制装置 |
| CN102203779B (zh) * | 2011-05-03 | 2013-04-17 | 华为技术有限公司 | 更新数据的方法和控制装置 |
| CN103677968A (zh) * | 2012-09-07 | 2014-03-26 | 腾讯科技（深圳）有限公司 | 事务处理方法、事务协调器装置、事务参与者装置及系统 |
| CN103677968B (zh) * | 2012-09-07 | 2017-11-10 | 腾讯科技（深圳）有限公司 | 事务处理方法、事务协调器装置、事务参与者装置及系统 |
| CN106547610A (zh) * | 2016-10-11 | 2017-03-29 | 北京国电通网络技术有限公司 | 一种分布式事务提交的方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101329670B (zh) | 2011-03-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8140623B2 (en) | Non-blocking commit protocol systems and methods | |
| CN111258822B (zh) | 数据处理方法、服务器和计算机可读存储介质 | |
| JP6382454B2 (ja) | 分散ストレージ及びレプリケーションシステム、並びに方法 | |
| CN105512266A (zh) | 一种实现分布式数据库操作一致性的方法及装置 | |
| WO2012071920A1 (zh) | 分布式内存数据库的实现方法、系统、令牌控制器及内存数据库 | |
| JP2014116968A (ja) | フェデレーションインフラストラクチャ内の一貫性 | |
| CN113268471B (zh) | 处理分布式事务的方法、代理连接池、系统、设备及介质 | |
| CN108989391B (zh) | 一种一致性处理的方法及系统 | |
| CN109600323B (zh) | 一种拜占庭共识机制 | |
| CN115794499B (zh) | 一种用于分布式块存储集群间双活复制数据的方法和系统 | |
| CN101329670B (zh) | 复制数据库环境下保持数据一致性的方法和系统 | |
| CN108228581B (zh) | Zookeeper兼容通信方法、服务器及系统 | |
| CN100388225C (zh) | 具有远程数据镜像的集群数据库 | |
| CN114363350A (zh) | 一种服务治理系统及方法 | |
| CN110417882A (zh) | 主节点的确定方法、装置和存储介质 | |
| CN112000444B (zh) | 数据库事务处理方法、装置、存储介质和电子设备 | |
| US8230444B2 (en) | Global attribute uniqueness (GAU) using an ordered message service (OMS) | |
| JP5416490B2 (ja) | 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム | |
| US20090106781A1 (en) | Remote call handling methods and systems | |
| CN116107706A (zh) | 分布式数据库的事务处理方法、装置、电子设备及存储介质 | |
| CN111130896A (zh) | 一种nfs故障的切换方法、系统及双控存储系统 | |
| CN115967611B (zh) | 跨域的切换处理方法、装置、设备和存储介质 | |
| CN110716827A (zh) | 适用于分布式系统的热备份方法及分布式系统 | |
| CN107153594B (zh) | 分布式数据库系统的ha组件选主方法及其系统 | |
| WO2023125412A1 (en) | Method and system for synchronous data replication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C56 | Change in the name or address of the patentee | ||
| CP01 | Change in the name or title of a patent holder |
Address after: Espoo, Finland Patentee after: Nokia Siemens Networks OY Address before: Espoo, Finland Patentee before: Nokia Siemens Networks OY |
|
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110323 Termination date: 20150620 |
|
| EXPY | Termination of patent right or utility model |