多主复制下处理写冲突(1)-同步与异步冲突检测及避免冲突
【摘要】 多主复制最大问题:可能发生写冲突,必须解决之。如两个用户同时编辑wiki,如图-7。用户1将页面标题从A-》B,且用户2同时将标题从A-》C。每个用户的更改都成功提交到本地主节点。但当异步复制到对方时,发现存在冲突。正常的主从复制则不会出现此问题。 3.2.1 同步与异步冲突检测若为主从复制数据库,第二个写请求将:被阻塞直到第一个写完成或被中止,强制用户必须重试多主节点的复制模型下,这两个写...
多主复制最大问题:可能发生写冲突,必须解决之。
如两个用户同时编辑wiki,如图-7。用户1将页面标题从A-》B,且用户2同时将标题从A-》C。每个用户的更改都成功提交到本地主节点。但当异步复制到对方时,发现存在冲突。正常的主从复制则不会出现此问题。
3.2.1 同步与异步冲突检测
若为主从复制数据库,第二个写请求将:
- 被阻塞直到第一个写完成
- 或被中止,强制用户必须重试
多主节点的复制模型下,这两个写都是成功的,且只能在稍后时间点才能异步检测到冲突,那时再要求用户解决冲突为时已晚。
理论上能做到同步冲突检测,即等待写请求完成对所有副本的同步,再通知用户写成功。但这样会失去多主的优点:允许每个主节点独立接受写请求。所以,若确实需要同步冲突检测,应考虑使用单主节点的主从复制!
3.2.2 避免冲突
处理冲突的最理想策略:避免它们,若应用层能保证对特定记录的所有写请求都通过同一主节点,就不会冲突。实践中,由于很多主节点复制模型所实现的冲突解决方案很不好,因此直接避免冲突是推荐首选方案。
如用户需编辑自己的数据,可确保特定用户的请求始终路由到特定IDC,并使用该IDC的主节点读/写。不同用户可能对应不同主数据中心(如根据用户地理位置选择),但从用户角度看,这基本等价于主从复制模型。
但有时可能需更改事先指定的主节点,可能因为:
- IDC故障,需将流量重新路由到另一个IDC
- 或可能因为用户已漫游到另一个位置,接近了不同的IDC
此时,冲突避免方式不再有效,必须要有方案应对不同主节点同时写入的可能。
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)