CN109600323A - 一种拜占庭共识机制 - Google Patents
一种拜占庭共识机制 Download PDFInfo
- Publication number
- CN109600323A CN109600323A CN201811340715.6A CN201811340715A CN109600323A CN 109600323 A CN109600323 A CN 109600323A CN 201811340715 A CN201811340715 A CN 201811340715A CN 109600323 A CN109600323 A CN 109600323A
- Authority
- CN
- China
- Prior art keywords
- message
- request
- node
- commit
- diff
- 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
- 230000007246 mechanism Effects 0.000 title claims abstract description 62
- 230000008263 repair mechanism Effects 0.000 claims description 20
- 230000004044 response Effects 0.000 claims description 20
- 230000008439 repair process Effects 0.000 claims description 16
- 238000004891 communication Methods 0.000 abstract description 7
- 230000008901 benefit Effects 0.000 abstract description 5
- 230000001934 delay Effects 0.000 abstract description 3
- 230000007850 degeneration Effects 0.000 abstract description 2
- 238000012545 processing Methods 0.000 description 8
- 238000000034 method Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/56—Queue scheduling implementing delay-aware scheduling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/56—Queue scheduling implementing delay-aware scheduling
- H04L47/564—Attaching a deadline to packets, e.g. earliest due date first
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/622—Queue service order
-
- 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/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Hardware Redundancy (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种拜占庭共识机制，本发明结合Primary节点‑based机制和Quorum‑based机制的优势，在良好的集群环境和低并发的场景下，实现了低延迟和高吞吐的目标。本发明完成一个请求只需要三个通信延迟，实现了低延迟。而吞吐量和扩展性方面，本发明在稳定的网络环境下，不需要节点之间相互广播，减少了不必要通信开销，有利于提高吞吐量和扩展性。在高并发场景下，本发明能以更低的延迟巧妙退化为PBFT，实现平滑降级。
Description
技术领域
本发明涉及分布式系统领域，更具体的，涉及一种拜占庭共识机制。
背景技术
在分布式系统中，由于需要避免单点故障而导致服务不可用，因此需要通过多节点同步复制数据来达到容错和高可用的目的。现有技术主要采用共识机制/共识协议来保证多节点数据完全一致，共识机制可以分为两大类：非拜占庭共识机制和拜占庭共识机制，这两类的区别在于其错误模型不一样。其中拜占庭共识机制：假设节点的行为可以是任意的，甚至不受程序约束，比如某个节点被黑客入侵，其就有可能表现出拜占庭行为。拜占庭共识机制分为两类：Primary节点-based共识机制和Quorum-based共识机制。下面详细介绍这两种共识机制中的代表机制以及它们存在的优缺点。
PBFT共识机制，是Primary节点-based拜占庭共识机制的一种，它要求集群的数目至少为3f + 1（f为可以容纳出错的节点数目），集群中的节点有两种角色，分别为Primary节点和backup。如图1所示，PBFT机制完成共识过程需要经过三个通信阶段。
pre-prepare阶段：Primary节点汇总用户请求，给请求分配序号，然后构造Pre-prepare消息，并广播给所有的backup节点。
pepare阶段：Backup节点接收Pre-prepare消息，进行相关验证，然后构造Prepare消息，广播给所有其他节点。当Backup节点接收超过2f + 1个有效匹配的Prepare消息，则进入Commit阶段。
commit阶段：Backup节点构造Commit消息，广播给所有节点。当节点接收2f + 1个Commit消息，则可以认为其对应的请求被提交了，然后执行请求，返回响应给用户。
PBFT共识机制的优缺点如下：
PBFT共识机制要求的集群节点数比较少（比如3f+1），在高并发场景下具有稳定的性能和较高的吞吐量。但是PBFT共识机制的延迟比较高，需要经过三个阶段来使节点达成共识。PBFT共识机制还存在扩展性差，其要求节点之间相互广播消息，当随着集群节点数n的增加，其消息数目将呈n^2 增多，使其扩展性受到了一定的限制。
Q/U共识机制，是Quorum-based共识机制中的一种。该机制中所有节点的角色是相等，没有Primary节点和backup角色之分，是否达成共识是由client端来判断。Q/U机制主要向外暴露两个功能：Query和Update，它要求集群的数目至少为5f + 1。如图2所示，Update操作分为两步：Retrieve State和Propose Request。
Retrieve State：Client端向所有节点发送请求，获取节点当前最新的逻辑时间戳。Client端获取4f + 1个响应后，如果当中有3f + 1个一致的逻辑时间戳，就可以进入Propose Request阶段。如果没有3f + 1个一致的时间戳，此时说明有冲突发生，则需要进行冲突解决。
Propose Request：Client把Retrieve State阶段获取到的逻辑时间戳分配给Request，然后广播给所有节点。节点接收到Request后，如果该Request上的逻辑时间戳大于等于当前自身维护的逻辑时间戳，该节点就接收该Request，执行它，并把结果返回给Client端，否则，会返回拒绝响应。Client端获取4f + 1个响应后，如果当中有3f + 1个一致的结果，则可以认为该Request执行成功，否则说明有冲突发生，需要进行冲突解决。
Q/U共识机制的优缺点如下：
Q/U共识机制具有很好的扩展性，随着集群节点数目增加，其消息数目呈线性增加。另外，在低并发的场景下，其延迟比较低，最优情况下两个通信延迟就能完成响应。但是Q/U共识机制要求的集群节点数比较多（5f + 1）。而且，Q/U机制在高并发场景下，该类机制很容易出现性能退化，最严重可能呈现指数级别的性能下降。
发明内容
本发明为了解决现有技术中拜占庭共识机制不能同时兼顾低延迟、吞吐量高、扩展性高、高并发场景下性能平滑降级的问题，提供了一种拜占庭共识机制，其能同时兼顾低延迟、吞吐量高、扩展性高、高并发场景下性能平滑降级的特点。
为实现上述本发明目的，采用的技术方案如下：一种拜占庭共识机制，该拜占庭共识机制包括Simple-Order-Match机制、Repair机制；
所述Simple-Order-Match机制的实现步骤如下：
S1：通过client端向所有节点发送请求，接收到请求后，Primary节点和Backup节点都会为该请求分配序列号，并且分别构造Remote-request消息和Local-request消息；
S2：Backup节点在构造完Local-request消息后，会启动一个定时器diff-timer；若在定时器定时器diff-timer超时前，Backup节点没有收到来自Primary节点的Remote-request的匹配消息，则Backup节点会触发Repair机制；若在定时器diff-timer超时前，backup节点收到来自Primary节点的Remote-request的匹配消息，则该节点会对请求进行预执行，然后返回响应Fast-reply消息给客户端；
S3：当客户端接收到2f + 1个匹配的Fast-reply消息，则该请求执行完成。
所述Repair机制的实现步骤如下：
T1：触发Repair机制的backup节点广播Diff消息，表明当前节点接收到的请求与Primary节点接收到的请求不一样；
T2：当其他节点接收到Diff消息后，若该节点已经完成预执行，该节点广播Repair消息给所有节点，若该节点未完成预执行，则该节点保存好Diff消息；
T3：当节点接收到2f + 1个匹配的Diff消息或者2f + 1个匹配的Repair消息后，该节点将进行commit阶段，并请求进行提交操作；
T4：在commit阶段，节点广播Commit消息，并且等待其他节点发送Commit消息；
T5：当节点接收到2f + 1个Commit消息，说明该请求已经提交，该请求返回响应Commit-reply消息给client端；
T6：当client端接收到f + 1个Commit-reply消息后，则该请求执行完成。
优选地，所述在Simple-Order-Match机制中，对于backup节点收到来自Primary节点的Remote-request的不匹配消息，backup节点直接触发Repair机制。
优选地，对于存在[0, f)个backup节点的请求队列与Primary节点的请求队列不一致，不匹配的请求通过backup节点触发Repair机制，最终被所有节点提交，并返回响应Commit-reply给client端。
进一步地，对于存在[f,2f)个backup节点的请求队列与Primary节点的请求队列不一致，此时所有节点无法收到2f + 1个Diff消息或者Repair消息，从而无法进入commit阶段，同时client端也无法接收到2f + 1个Fast-reply消息或者f+1个Commit-reply消息完成响应；每个节点等待自身维护的vtimer定时器超时，然后选择新的Primary节点进行处理。
进一步地，对于存在[2f,3f]个backup节点的请求队列与Primary节点的请求队列不一致，请求不匹配的backup节点触发Repair机制，广播Diff消息；所有节点收到2f + 1个Diff消息后提交请求，并返回响应Commit-reply消息给client端。
本发明的有益效果如下：本发明结合Primary节点-based机制和Quorum-based机制的优势，在良好的集群环境和低并发的场景下，实现了低延迟和高吞吐的目标。本发明完成一个请求只需要三个通信延迟，实现了低延迟。而吞吐量和扩展性方面，本发明在稳定的网络环境下，不需要节点之间相互广播，减少了不必要通信开销，有利于提高吞吐量和扩展性。在高并发场景下，本发明能以更低的延迟巧妙退化为PBFT，实现平滑降级。
附图说明
图1是现有技术PBFT共识机制的详细流程图。
图2是现有技术Q/U共识机制的详细流程图。
图3是本发明执行Simple-Order-Match机制的流程图。
图4是存在[0, f)个backup节点的请求队列与Primary节点的请求队列不一致时的流程图。
图5是存在[f,2f)个backup节点的请求队列与Primary节点的请求队列不一致时的流程图。
图6是存在[2f,3f]个backup节点的请求队列与Primary节点的请求队列不一致时的流程图。
图7是 Primary节点处理的流程图。
图8是Backup节点处理的流程图。
具体实施方式
下面结合附图和具体实施方式对本发明做详细描述。
实施例1
一种拜占庭共识机制，其结合了Quorum-based机制特性的Primary节点-based的共识机制，即要求集群节点有Primary节点和Backup角色之分。本实施例所述拜占庭共识机制包括Simple-Order-Match机制、Repair机制；
所述Simple-Order-Match机制的实现步骤如下：
S1：通过client端向所有节点发送请求，接收到请求后，Primary节点和Backup节点都会为该请求分配序列号，并且分别构造Remote-request消息和Local-request消息；
S2：Backup节点在构造完Local-request消息后，会启动一个定时器diff-timer；若在定时器定时器diff-timer超时前，Backup节点没有收到来自Primary节点的Remote-request的匹配消息，则Backup节点会触发Repair机制；若在定时器diff-timer超时前，backup节点收到来自Primary节点的Remote-request的匹配消息，则该节点会对请求进行预执行，然后返回响应Fast-reply消息给客户端；
S3：当客户端接收到2f + 1个匹配的Fast-reply消息，则该请求执行完成。
所述Repair机制的实现步骤如下：
T1：触发Repair机制的backup节点广播Diff消息，表明当前节点接收到的请求与Primary节点接收到的请求不一样；
T2：当其他节点接收到Diff消息后，若该节点已经完成预执行，该节点广播Repair消息给所有节点，若该节点未完成预执行，则该节点保存好Diff消息后什么也不做；
T3：当节点接收到2f + 1个匹配的Diff消息或者2f + 1个匹配的Repair消息后，该节点将进行commit阶段，并请求进行提交操作；
T4：在commit阶段，节点广播Commit消息，并且等待其他节点发送Commit消息；
T5：当节点接收到2f + 1个Commit消息，说明该请求已经提交，该请求返回响应Commit-reply消息给client端；
T6：当client端接收到f + 1个Commit-reply消息后，则该请求执行完成。
如图3所示，当所有backup节点的请求队列与Primary节点的请求队列一致，此时所有节点都会顺利执行Simple-Order-Match机制，不会触发Repair机制，此时只需要三个通信延迟，client端即可获取响应。
所述在Simple-Order-Match机制中，对于backup节点收到来自Primary节点的Remote-request的不匹配消息，backup节点直接触发Repair机制。
如图4所示，对于存在[0, f)个backup节点的请求队列与Primary节点的请求队列不一致，不匹配的请求会通过backup节点触发Repair机制最终被所有节点提交此时节点最终会收到2f + 1个Repair消息，进入commit阶段，并返回响应Commit-reply给client端。而这些不匹配被提交的过程实际就是重新执行了一个类似PBFT的三阶段共识机制。而与Primary节点匹配的那部分请求则会顺序执行Simple-Order-Match机制，并且在三个通信延迟后将响应Fast-reply返回给client端。
如图5所示，对于存在[f,2f)个backup节点的请求队列与Primary节点的请求队列不一致，此时所有节点无法收到2f + 1个Diff消息或者Repair消息从而进入commit阶段，而client端也无法接收到2f + 1个Fast-reply消息或者f+1个Commit-reply消息完成响应。这种情况下，每个节点等待自身维护的vtimer定时器超时，然后进行重新选主。当新的Primary节点选出来后，机制就会继续顺利执行。
如图6所示，对于存在[2f,3f]个backup节点的请求队列与Primary节点的请求队列不一致，请求不匹配的backup节点触发Repair机制，广播Diff消息。最终，所有节点收到2f + 1个Diff消息从而提交请求，并返回响应Commit-reply消息给client端。
如图7所示，本实施例中所述的Primary节点处理流程如下：给请求分配序列号，进行预执行；返回Fast-reply消息给client端；client端判断是否接收到Diff消息，若client端接收到Diff消息，则向所有节点广播Repair消息，若client端没有接收到Diff消息，则返回继续判断；client端向所有节点广播Repair消息后，若能成功进入Commit阶段，返回Commit-reply消息client端，结束Primary节点处理；若不能进入Commit阶段，先client端触发View-change协议，后返回Commit-reply消息client端，结束Primary节点处理。
如图8所示，本实施例中所述的Backup节点处理流程如下：给请求分配序列号，等待Remote-request；判断是否成功SOM机制，若成功，client端向所有节点广播Repair消息，若不成功，进行预执行，并返回Fast-reply消息给client端；Backup节点判断是否接收Different或Repair消息，若不接收，则继续判断；若接收判断是否成功进入Commit阶段；若能成功进入Commit阶段，返回Commit-reply消息client端，结束Primary节点处理；若不能进入Commit阶段，先client端触发View-change协议，后返回Commit-reply消息client端，结束Primary节点处理。
显然，本发明的上述实施例仅仅是为清楚地说明本发明所作的举例，而并非是对本发明的实施方式的限定。凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明权利要求的保护范围之内。
Claims (5)
1.一种拜占庭共识机制，其特征在于：该拜占庭共识机制包括Simple-Order-Match机制、Repair机制；
所述Simple-Order-Match机制的实现步骤如下：
S1：通过client端向所有节点发送请求，接收到请求后，Primary节点和Backup节点都会为该请求分配序列号，并且分别构造Remote-request消息和Local-request消息；
S2：Backup节点在构造完Local-request消息后，会启动一个定时器diff-timer；若在定时器定时器diff-timer超时前，Backup节点没有收到来自Primary节点的Remote-request的匹配消息，则Backup节点会触发Repair机制；若在定时器diff-timer超时前，backup节点收到来自Primary节点的Remote-request的匹配消息，则该节点会对请求进行预执行，然后返回响应Fast-reply消息给客户端；
S3：当客户端接收到2f + 1个匹配的Fast-reply消息，则该请求执行完成；
所述Repair机制的实现步骤如下：
T1：触发Repair机制的backup节点广播Diff消息，表明当前节点接收到的请求与Primary节点接收到的请求不一样；
T2：当其他节点接收到Diff消息后，若该节点已经完成预执行，该节点广播Repair消息给所有节点，若该节点未完成预执行，则该节点保存好Diff消息；
T3：当节点接收到2f + 1个匹配的Diff消息或者2f + 1个匹配的Repair消息后，该节点将进行commit阶段，并请求进行提交操作；
T4：在commit阶段，节点广播Commit消息，并且等待其他节点发送Commit消息；
T5：当节点接收到2f + 1个Commit消息，说明该请求已经提交，该请求返回响应Commit-reply消息给client端；
T6：当client端接收到f + 1个Commit-reply消息后，则该请求执行完成。
2.根据权利要求1所述的拜占庭共识机制，其特征在于：所述在Simple-Order-Match机制中，对于backup节点收到来自Primary节点的Remote-request的不匹配消息，backup节点直接触发Repair机制。
3.根据权利要求1所述的拜占庭共识机制，其特征在于：对于存在[0, f)个backup节点的请求队列与Primary节点的请求队列不一致，不匹配的请求通过backup节点触发Repair机制，最终被所有节点提交，并返回响应Commit-reply给client端。
4.根据权利要求3所述的拜占庭共识机制，其特征在于：对于存在[f,2f)个backup节点的请求队列与Primary节点的请求队列不一致，此时所有节点无法收到2f + 1个Diff消息或者Repair消息，从而无法进入commit阶段，同时client端也无法接收到2f + 1个Fast-reply消息或者f+1个Commit-reply消息完成响应；每个节点等待自身维护的vtimer定时器超时，然后选择新的Primary节点进行处理。
5.根据权利要求4所述的拜占庭共识机制，其特征在于：对于存在[2f,3f]个backup节点的请求队列与Primary节点的请求队列不一致，请求不匹配的backup节点触发Repair机制，广播Diff消息；所有节点收到2f + 1个Diff消息后提交请求，并返回响应Commit-reply消息给client端。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811340715.6A CN109600323B (zh) | 2018-11-12 | 2018-11-12 | 一种拜占庭共识机制 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811340715.6A CN109600323B (zh) | 2018-11-12 | 2018-11-12 | 一种拜占庭共识机制 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109600323A true CN109600323A (zh) | 2019-04-09 |
| CN109600323B CN109600323B (zh) | 2021-10-01 |
Family
ID=65958346
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811340715.6A Active CN109600323B (zh) | 2018-11-12 | 2018-11-12 | 一种拜占庭共识机制 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109600323B (zh) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110166364A (zh) * | 2019-05-15 | 2019-08-23 | 武汉理工大学 | 一种基于实用拜占庭容错算法的软件定义机会网络流表更新方法 |
| CN110535680A (zh) * | 2019-07-12 | 2019-12-03 | 中山大学 | 一种拜占庭容错方法 |
| CN111342971A (zh) * | 2020-02-07 | 2020-06-26 | 数据通信科学技术研究所 | 一种拜占庭共识方法和系统 |
| CN112068978A (zh) * | 2020-08-27 | 2020-12-11 | 恒宝股份有限公司 | View-change二次启动定时器的定时期限延长方法 |
| CN112929354A (zh) * | 2021-01-28 | 2021-06-08 | 恒宝股份有限公司 | 一种实用型拜占庭容错抗攻击死锁的方法及装置 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106445711A (zh) * | 2016-08-28 | 2017-02-22 | 杭州云象网络技术有限公司 | 一种应用于区块链的拜占庭容错共识方法 |
| CN107360206A (zh) * | 2017-03-29 | 2017-11-17 | 阿里巴巴集团控股有限公司 | 一种区块链共识方法、设备及系统 |
-
2018
- 2018-11-12 CN CN201811340715.6A patent/CN109600323B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106445711A (zh) * | 2016-08-28 | 2017-02-22 | 杭州云象网络技术有限公司 | 一种应用于区块链的拜占庭容错共识方法 |
| CN107360206A (zh) * | 2017-03-29 | 2017-11-17 | 阿里巴巴集团控股有限公司 | 一种区块链共识方法、设备及系统 |
Non-Patent Citations (2)
| Title |
|---|
| GIULIANA SANTOS VERONESE: "Efficient Byzantine Fault-Tolerance", 《IEEE TRANSACTIONS ON COMPUTERS》 * |
| 朱腾: "基于可信计数器的拜占庭容错技术研究", 《中国优秀硕士学位论文全文数据库 信息科技辑》 * |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110166364A (zh) * | 2019-05-15 | 2019-08-23 | 武汉理工大学 | 一种基于实用拜占庭容错算法的软件定义机会网络流表更新方法 |
| CN110535680A (zh) * | 2019-07-12 | 2019-12-03 | 中山大学 | 一种拜占庭容错方法 |
| CN111342971A (zh) * | 2020-02-07 | 2020-06-26 | 数据通信科学技术研究所 | 一种拜占庭共识方法和系统 |
| CN111342971B (zh) * | 2020-02-07 | 2023-08-08 | 数据通信科学技术研究所 | 一种拜占庭共识方法和系统 |
| CN112068978A (zh) * | 2020-08-27 | 2020-12-11 | 恒宝股份有限公司 | View-change二次启动定时器的定时期限延长方法 |
| CN112929354A (zh) * | 2021-01-28 | 2021-06-08 | 恒宝股份有限公司 | 一种实用型拜占庭容错抗攻击死锁的方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109600323B (zh) | 2021-10-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109600323A (zh) | 一种拜占庭共识机制 | |
| US10990609B2 (en) | Data replication framework | |
| US6718173B1 (en) | Location information recovery and management for mobile networks | |
| US8468132B1 (en) | Data replication framework | |
| JP5498594B2 (ja) | フェデレーションインフラストラクチャ内の一貫性 | |
| EP3340054A1 (en) | Maintaining coherency in distributed operating systems for network devices | |
| US10545993B2 (en) | Methods and systems of CRDT arrays in a datanet | |
| EP2317450A1 (en) | Method and apparatus for distributed data management in a switching network | |
| US7984127B2 (en) | Data matrix method and system for distribution of data | |
| US10198492B1 (en) | Data replication framework | |
| US20090077036A1 (en) | Propagating a query in a federated database | |
| CN106713391B (zh) | 一种session信息的共享方法和共享系统 | |
| CN109639773B (zh) | 一种动态构建的分布式数据集群控制系统及其方法 | |
| WO2012041404A1 (en) | Distributed database | |
| WO2009100636A1 (zh) | 电信网络用户数据存储管理的方法及装置 | |
| Eischer et al. | Resilient cloud-based replication with low latency | |
| US20030182444A1 (en) | Distributed system with an efficient atomic broadcast mechanism | |
| US20060136454A1 (en) | Method for managing a hybrid distributed database in a communication network | |
| Serrano et al. | An autonomic approach for replication of internet-based services | |
| Hayashi et al. | Updated data dissemination methods for updating old replicas in ad hoc networks | |
| Anastasi et al. | Group multicast in distributed mobile systems with unreliable wireless network | |
| US20170004196A1 (en) | Data replication framework | |
| Meiklejohn et al. | Loquat: A framework for large-scale actor communication on edge networks | |
| EP3393092B1 (en) | Controller coordination system for software defined networking in a wireless network with partitions | |
| Rane et al. | Overview of Data Replication Strategies in Various Mobile Environment |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |