复制数据库环境下保持数据一致性的方法和系统技术方案

本发明专利技术公开了一种复制数据库环境下保持数据一致性的方法和系统。该方法包括：协调者向复制数据库环境中的参与者发送事务请求，所述参与者根据所述事务请求在本地执行复制事务；参与者根据本地复制事务执行结果向协调者投票，协调者根据参与者返回的投票结果做出全局决定，其中如果至少有一个参与者投票已准备好，则协调者做出全局提交的全局决定，否则协调者做出全局夭折的全局决定；参与者执行所述全局决定。该系统包括协调者和复制数据库环境中的参与者。应用本发明专利技术，通过对做出全局决定的条件进行改变，在保证数据一致性的基础上，既节约了资源，又提高了系统的可用性。

【技术实现步骤摘要】

本专利技术涉及数据库
，特别是涉及一种在复制数据库环境下保持数据一致性的方 法和系统。肖驗*为了支持各种数据无关(data-less)应用，即数据库层和应用层分离，通常需要提供具 有高可用性服务的可靠架构，如三层架构。三层架构包括应用客户端(AC)、数据库前端(DB-FE)和数据库后端(DB-BE)。客户端 用于向数据库前端发起请求。为了负载均衡和冗余性考虑，客户端可以连接到一个或者多个 数据库前端。数据库前端接收来自于客户端的请求，将该请求路由到数据库后端，并接收由 数据库后端返回的请求结果，然后将请求结果再回传给用客户端，其中请求结果既可以是成 功的请求结果，也可以是失败的请求结果。数据库后端用于保存用户数据，执行来自于数据 库前端的操作请求，并且将执行结果/响应返回到数据库前端。同样，为了冗余性考虑，多个 数据库后端可以组成集群(cluster)。组成集群的目的是为了保证系统的高可用性。一个集 群中所有数据库后端保持数据相互复制的关系，这样可保证一个数据库后端发生故陣时，该 集群中的其它数据库后端仍能提供服务。集群中各数据库后端之间的协同由复制管理器负责， 以协调集群内数据的一致性。 一个集群的数据库后端既可以放置在一起，也可以在地理上间 隔较远。由于硬件节点故障、软件故障或连接错误等失败原因，上述架构中的组成元件可能会出 现故障。为了保证某个数据库后端出现故障时数据库前端仍然能够存取一致性数据，位于同 一集群中各个数据库后端中的数据应严格保持同步复制。即只要某一数据库后端中的数据产 生了更新，那么该集群中所有数据库后端中的相应数据也应同时更新，从而保证数据一致性。 广而言之，同步复制的目的就是保证集群中的所有单元具有相同的数据值。在现有技术中，如果某一个单元的数据不能成功更新，那么为了保证集群中所有单元的 数据一致性，该更新请求将会被拒绝。如果这种更新失败较为频繁，则对系统的高可用性会带来负面的影响。为了保证数据一致性，现有技术中有一种两阶段提交(2PC)协议。2PC协议是保证分布 式数据库一致性和原子性的标准协议。2PC协议是一种在事务管理器和所有加入到事务中的 资源之间的协议，确保了要么所有的资源管理器都提交了事务，要么所有的资源管理器都撤 销了事务。在这个协议中，当应用程序请求提交事务时，事务管理器向所有涉及的资源管理 器发出准备请求。每个资源都会依次发送一个应答，指出是否准备好提交它的操作。只有当 所有的资源管理器都准备好提交以后，事务管理器才会向所有的资源管理器发出提交命令。 否则，事务管理器会发出一个回退命令，从而回退事务。在2PC协议中，只有当收到所有参与者投票"已准备好(ready)",才能决定全局事务"提 交(commit)",并且只要收到一个参与者投票"夭折(abort)",则决定全局事务"夭折"。 实际上，对于复制数据库环境下的复制事务来说，由于需要所有的参与者都能在响应前完成 更新，因此做出全局事务"提交"的条件非常苛刻，这就造成很多实际上能完成复制事务的 参与者却不能正常提交复制事务。另外，当一个参与者失败时，大量的复制事务都会随之"夭 折"，因此现有技术中做出全局事务"夭折"的条件又过于宽松，从而造成大量的资源浪费。 不仅于此，如果有某一个参与者始终不能成功更新，那么整个更新事务就都不能够获得"提 交"，而这显然不合乎复制数据库环境下的高可用性要求。因此，现有2PC协议做出全局决定的条件并不能有效地应用到复制数据库环境，这一方 面会带来资源浪费，另一方面又会导致一些正常事务无法提交。M醇本专利技术提供一种复制数据库环境下保持数据一致性的方法和系统，从而克服现有技术中 资源浪费，又不能保证正常事务实现提交的缺点。为了达到上述目的，本专利技术的技术方案是这样实现的 一种复制数据库环境下保持数据一致性的方法，包括协调者向复制数据库环境中的参与者发送事务请求，所述参与者根据所述事务请求在本 地执行复制事务参与者根据本地复制事务执行结果向协调者投票，协调者根据参与者返回的投票结果做 出全局决定，其中如果至少有一个参与者投票已准备好，则协调者做出全局提交的全局决定， 否则协调者做出全局夭折的全局决定参与者执行所述全局决定。较佳地,该方法包括当至少有一个参与者投票己准备好时，协调者进一步向投票夭折的 参与者发送重试命令投票夭折的参与者收到所述重试命令后，重新在本地执行复制事务。 较佳地，所述投票夭折的参与者重新在本地执行复制事务后，进一步重新再向协调者投西较佳地,协调者做出全局提交的命令后，该方法进一步包括设置重新在本地执行复制事 务后投票结果为夭折的参与者状态为"不可用"，和/或设置协调者未能收到其投票的参与者 状态为"不可用"。本专利技术还公开了一种复制数据库环境下保持数据一致性的系统，包括协调者，用于向复制数据库环境中的参与者发送事务请求，并根据参与者返回的投票结 果做出全局决定，其中如果至少有一个参与者投票已准备好，则做出"全局提交"的全局决 定，否则做出"全局夭折"的全局决定；复制数据库环境中的参与者，用于根据本地复制事务执行结果向协调者投票，并执行由 协调者做出的所述全局决定。较佳地,所述协调者，进一步用于当至少有一个参与者投票己"准备好"时，向投票夭折 的参与者发送重试命令投票夭折的参与者，用于在收到所述重试命令后，重新在本地执行复制事务。可选地,投票夭折的参与者，进一步用于在本地重新执行复制事务后重新再向协调者"投票"。可选地,协调者，进一步用于设置重新在本地执行复制事务后投票结果为"夭折"的参与 者状态为"不可用"，和/或设置协调者未能收到其投票的参与者状态为"不可用"。 此外，本专利技术还公开了一种数据库系统，包括 应用客户端，用于向数据库前端发送事务请求；数据库前端，用于向数据库后端转发所述事务请求，并根据数据库后端返回的投票结果 做出全局决定，其中如果至少有一个数据库后端投票已准备好，则数据库前端做出全局提交 的全局决定，否则数据库前端做出全局夭折的全局决定；数据库后端，用于根据所述事务请求在本地执行复制事务，并根据本地复制事务执行结果向数据库前端投票，并执行由数据库前端做出的所述全局决定。可选地,数据库前端，进一步用于当至少有一个数据库后端投票"己准备好"时，向投 票"夭折"的数据库后端发送重试命令；投票夭折的数据库后端，用于在收到所述重试命令后，重新在本地执行复制事务。可选地,投票夭折的数据库后端，进一步用于在重新在本地执行复制事务后重新再向数据库前端投票。可选地,数据库前端，进一步用于设置重新在本地执行复制事务后投票结果为夭折的数据 库后端状态为"不可用"，和/或设置数据库前端未能收到其投票的数据库后端状态为"不可 用"。可选地,所述数据库后端集成在一起，或者在地理上相互隔开。另外，本专利技术还公开了一种采用三层结构的无线通信系统，包括信号层、应用层和数据 库后端，数据库后端包括至少一个复制路径服务器；其中信号层，用于接收路径存取请求， 并将所述路径存取请求转发到应用层应用层，用于向数据库后端转发所述路径存取请求， 并根据数据库后端返回的投票结果做出全局决定，其中如果至少有一个复制路径服务器投票 己准备好，则应用层做出全局提交的全局决定，否则应本文档来自技高网...

【技术保护点】
一种复制数据库环境下保持数据一致性的方法，包括：　协调者向复制数据库环境中的参与者发送事务请求，所述参与者根据所述事务请求在本地执行复制事务；　参与者根据本地复制事务执行结果向协调者投票，协调者根据参与者返回的投票结果做出全局决定，其中如果至少有一个参与者投票已准备好，则协调者做出全局提交的全局决定；否则协调者做出全局夭折的全局决定；　参与者执行所述全局决定。

【技术特征摘要】

【专利技术属性】
技术研发人员：廖国琼，周雷，
申请(专利权)人：诺基亚西门子通信公司，
类型：发明
国别省市：FI[芬兰]