问题描述

在写业务代码时,很多时候需要保证数据存储在不同中间件中的一致性。以笔者为例,就遇到了需要将mysql中已存储的数据转存到etcd中,同时还要考虑到并发场景下如何保证数据最终一致性的问题。

问题分析

该问题形象地表示的话,可以将时间线展开如下

  1. 服务A1更新db数据为{"key1":"valA", "key2":"val_old"}
  2. 服务A2读取db数据为{"key1":"valA", "key2":"val_old"},并存入内存
  3. 服务B1更新db数据为{"key1":"valA", "key2":"valB"}
  4. 服务B2读取db数据为{"key1":"valA", "key2":"valB"},并存入内存
  5. 服务B2将其内存数据发送到etcd,etcd中的数据为{"key1":"valA", "key2":"valB"}
  6. 服务A2将其内存数据发送到etcd,etcd中的数据为{"key1":"valA", "key2":"val_old"}

最终db中的数据为{"key1":"valA", "key2":"valB"},而etcd中的数据为{"key1":"valA", "key2":"val_old"}。从中我们可以分析出,产生这个问题的本质原因是因为服务A1、A2、B1和B2没有共用一块物理内存,这也是微服务拆分的必然结果。

解决思路

要想解决本问题,可以考虑几种方案:

  • 方案1:db添加读写锁,将1、2、6和3、4、5分别串行执行,缺点是db开销变大、并发性能下降
  • 方案2:使用db事务,将写etcd的操作保护起来,缺点是这种方法很不规范,不应在db的事务中添加外部调用,可能带来严重的故障
  • 方案3:基于etcd的revision和事务机制设计乐观锁,首先获取etcd中key的revision,从而在服务2查询db时保证etcd中的key没有被其他服务修改,确保最终一致性,缺点是在高并发修改的情况下可能需要多次重试。

方案3详解

不了解etcd中的各种version可以看Etcd 中 Revision, CreateRevision, ModRevision, Version 的含义

方案3伪代码如下:

1  get revision of key from etcd
2  if revision is null:
3    create key1
4    goto line 1
5  get val from db
6  start etcd transaction
7  if mod_revision of key equal revision:
8    put val
9  else:
10   goto line 1
11 commit etcd transaction
	

至于具体的实现方式,可以参考etcd-cli的mutex实现,这篇分布式锁之 etcd(分布式锁原理、etcd特点、分布式锁实现方案)也有较为详细的介绍。

转载版权:乐易云香港服务器 乐易云美国服务器

转载标题:【Etcd】分布式系统中如何使用乐观锁来保证Mysql和Etcd数据的最终一致性 转载地址:https://www.123yun.com/article/1949.html

香港二区用什么服务器 移动宽带打开香港服务器慢 香港cn2低价服务器 多ip香港服务器哪家好

内容来源于网络如有侵权请私信删除