多主复制的适用场景-需离线操作的客户端和协作编辑

Posted JavaEdge.

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了多主复制的适用场景-需离线操作的客户端和协作编辑相关的知识,希望对你有一定的参考价值。

3.1.2 需离线操作的客户端

应用在断网后仍需继续工作。

如手机、PC和其他设备上的日历应用。无论设备当前是否连网,都需随时查看:

  • 当前会议日程(读请求)
  • 添加新会议(写请求)

离线状态下进行的任何更改,会在设备下次上线时,与服务器和其他设备同步。

此时,每个设备都有一个充当M的本地DB(接受写请求),并在所有设备之间采用异步方式同步这些多M上的副本,同步滞后可能是几h或数天,具体时间取决于设备何时再联网。

架构上,这种设置类似IDC之间的多主复制,只不过每个设备都是个“IDC”,而它们之间的网络连接极不可靠。从日历同步功能的这些破烂实现也能看出,多主可以得到结果,但中间依旧很多未知数。

有一些工具就是为了使多主配置更容易,如CouchDB。

3.1.3 协作编辑

实时协作编辑应用程序允许多人同时编辑文档。如Google Docs。通常不会将协作式编辑完全等价于数据库复制问题,但与前面提到的离线编辑案例类似。

当一个用户编辑文档时,所做更改将立即应用到本地副本(Web浏览器或客户端应用程序中的文档状态),并异步复制到服务器和编辑同一文档的任何其他用户。

若要保证不发生编辑冲突,则应用程序必须先锁定文档,然后才能编辑。若另一用户想编辑同一文档,必须等到第一个用户提交修改并释放锁。这种协作模式类似主从复制模型下在主节点执行事务。

为加速协作效率,期望将可编辑粒度设置很小,如一个按键甚至全程无锁。但同时也带来多主复制都有的挑战:解决冲突。

以上是关于多主复制的适用场景-需离线操作的客户端和协作编辑的主要内容,如果未能解决你的问题,请参考以下文章

mysql多主双向+级联复制(高可用强稳定)

MySQL实战应用案例:单主/多主模式详解

mysql多源复制(多主一从)配置

mysql多源复制(多主一从)配置

多主复制下处理写冲突-同步与异步冲突检测及避免冲突

深入理解CAP理论和适用场景