[Etcd]分布式系统中如何使用乐观锁保证Mysql和Etcd数据最终一致性

问题描述

在写业务代码时，很多时候需要保证数据存储在不同中间件中的一致性。以笔者为例，就遇到了需要将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特点、分布式锁实现方案）也有较为详细的介绍。