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

这篇具有很好参考价值的文章主要介绍了[Etcd]分布式系统中如何使用乐观锁保证Mysql和Etcd数据最终一致性。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

问题描述

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

问题分析

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

服务A1更新db数据为{"key1":"valA", "key2":"val_old"}
服务A2读取db数据为{"key1":"valA", "key2":"val_old"}，并存入内存
服务B1更新db数据为{"key1":"valA", "key2":"valB"}
服务B2读取db数据为{"key1":"valA", "key2":"valB"}，并存入内存
服务B2将其内存数据发送到etcd，etcd中的数据为{"key1":"valA", "key2":"valB"}
服务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