面试官:为什么在系统中不推荐双写?

引言

某日，面试阿雄跑去面试！什系于是统中有如下情形

面试官:"阿雄是吧，做做自我介绍!"

阿  雄:"我叫阿雄，不推来自某a国际电商公司！荐双"

面试官:"我看你项目里用了elasticsearch，面试你是什系怎么同步数据的呢?"

阿  雄:"在代码里写入数据库的时候，同时再写入elasticsearch！统中"

面试官:"那你如何保证写入数据库，不推和写入elasticsearch原子性问题呢？荐双万一写入数据库成功了，写入elasticsearch失败了怎么处理？面试"

阿  雄:"我还是回去等通知吧！"

OK，什系以上情形纯属虚构，统中如有雷同，不推绝对巧合！荐双

其实这篇文章所探讨的数据同步策略并不限于某两种固定的存储系统之间，而想去探讨一种通用的数据同步策略。主要分为以下三个部分

 (1)背景介绍  (2)双写缺点  (3)改良方案

正文

背景介绍

话说阿雄在加入某a国际电商公司的时候，业务系统十分简单，一个database就能搞定一切！

可是某a国际电商公司在产品韩的领导下，业务增长迅速，高防服务器阿雄发现了数据库越来越慢，于是乎阿雄加入了一些缓存，如redis来缓存一些数据，提高系统的响应能力。

又过了一段时间，产品韩发现搜索的速度灰常慢，让阿雄去改。阿雄在网上发现，现在业内都用一些elasticsearch做一些全文检索的操作，于是乎阿雄将一些需要全文检索的数据放入elasticsearch,提高了系统的搜索能力！

随着数据的膨胀，阿雄慢慢的发现了，对数据库做一些数据分析操作，性能明显的跟不上了。于是乎阿雄将数据库里的数据，导入hadoop，然后进行数据分析。

(省略一万字….)

最后，阿雄和产品韩幸福的在一起了。

OK，亿华云计算好，现在分析上面的场景！思考第一个问题

1、在database，redis,elasticsearch，hadoop中的数据是有关系的，还是彼此独立的?

显然是有关系的，在这几个数据源中的数据都是相关的。只是格式不一样而已！例如，对于一条Product数据，在数据库里是

在redis里就是key为 product:pId:1，value是 

{          "pId": "1",      "productName": "macbook"  }

如上所示，只是数据格式不一样而已！

那好，现在思考第二个问题

2、既然这些数据源之间数据是香港云服务器相关的，如何保证这几个数据源之间数据一致性！

一种比较简单且容易想到的方案是，hardcode在程序中

例如现在有两个数据源DataSouce1和DataSource2，我们往里头写数据,代码如下 

ProductService{       \\省略      public void syncData(){           x1. writeDataSource1();          x2. writeDataSource2();      }  } 

这就是我们标题中所提到的双写！那么，双写会带来什么坏处呢？OK，继续往下看！

双写缺点

一致性问题

打个比方我们现在有两个client，同时往两个DataSouce写数据。

 一个client往里头入X为1  一个client往里头入X为5

那么会有如下情形出现

如图所示，两个DataSouce的数据就不一致了，一个为1，一个为5。除非接下来有一个新的请求，对x数据发生了变更，才能修正这种现象！否则，你可能永远都发现不了。

原子性问题

因为我们需要同时往DataSource1和DataSource2一起写数据，你需要保证 

x1. writeDataSource1();  x2. writeDataSource2(); 

这两个操作一起成功，或者一起失败！如果采用双写的方法，是避不开这个问题的！

那么有没有通用的办法来解决这些问题呢？

有的，只要能按顺序记录数据的变更即可！那具体怎么做呢，我们继续往下看!

改良方案

假设，如果我们能将数据按顺序记录，写入某个消息队列，然后其他系统按消息顺序恢复数据，看看what happen?

此时架构图如下

在该架构下，所有的数据变更写入一个消息队列里去。其他各数据源从消息队列里恢复数据即可！

那么，此时还有一致性问题，和原子性问题么？

一致性问题

OK，这种情况下，各个数据源之间数据肯定是一致的。因为写入顺序已经在消息队列中定义好，各数据源按照消息队列中的消息顺序，恢复数据即可，并不存在竞争现象。因此，不会出现不一致的问题！

原子性问题

OK,这种情况下，如果写入DataSource失败会怎么样？例如出现了网络问题，这条消息恢复失败了。这个问题其实好解决，一般我们在顺序根据消息恢复数据的时候，会记录下坐标。如果写入失败，停止恢复数据。下次从该坐标处恢复数据即可。

但是在上面那张图中，写入DataBase是异步写入的。这样就不符合很多业务场景的"写后即读"的要求，因此，在实际落地中，做了一些变更!通用做法是去提取数据库的变化！

如下图所示

在该图中的中间件，例如oracle中的oracle golden gate可以提取数据变化。mysql中的canal能提取数据的变化。至于消息队列，可以选用kafka。直接提取数据变化到kafka中，其他数据源从kafka中获取数据，避免了直接双写从而导致一致性和原子性问题。

总结

本问讨论了在项目中常见的数据同步问题，希望大家有所收获。