[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. 1  get revision of key from etcd
2. 2  if revision is null:
3. 3    create key1
4. 4    goto line 1
5. 5  get val from db
6. 6  start etcd transaction
7. 7  if mod_revision of key equal revision:
8. 8    put val
9. 9  else:
10. 10   goto line 1
11. 11 commit etcd transaction
12.        

复制代码

至于具体的实现方式，可以参考etcd-cli的mutex实现，这篇分布式锁之 etcd（分布式锁原理、etcd特点、分布式锁实现方案）也有较为具体的先容。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。