数据冗余(数据冗余举例)

今天看了58沈剑的文章《如何保证冗余数据的一致性？我觉得很好，就做了一些实验，然后分享内容。什么情况下我们需要数据冗余？我们在设计一个数据库的时候，往往会因为一些数据库的数据量巨大而选择对数据库进行切割，而横向切割就是这类数据的一种常用方式。

当使用水平切割时，我们通常选择一个切割尺寸，即一个PationKey。现在在做B2B平台，每天都会有大量的订单。作为店铺，会有一个ShopId，作为买家，会有一个UserId。

当我们查询店铺订单时，如果ShopId是我们的PationKey，那么查询就相对简单了。但是，如果我们想查询买家的订单，我们需要查询多个数据库。相反，如果UserId是PationKey，买家查询方便，但店家查询麻烦。

针对这种情况，我们可以对相同的数据做两个备份，一个使用UserId子数据库，另一个使用ShopId子数据库。

如何有效的进行数据冗余呢？

1)服务同步双写

如果我们需要数据冗余，我们可以在执行服务时同时将数据写入两个数据库。

这种解决方案的优点是:

简单，代码中直接向两个数据库插入数据就行了；数据一致性相对较高，因为两次插入完成后才回返回。

当然，缺点是显而易见的:

需要同时进行两次写操作，时间花费多。（实际测试中，其实人多一次写还是两次写的时间上并不敏感）；可能存在数据不一致，例如第一次写成功后，服务断开。

假设我们需要增加处理时间，我们可以使用下面的解决方案，这也是一个常见的解决方案。

2)服务异步双写

在该方案中，通过引入消息总线和数据同步中心，数据不再通过服务重复写入。服务会异步向消息总线发送消息，然后通知数据同步中心完成冗余数据的写入。

我们已经说过这个方案的优点，即:

处理时间快。由于只请求一次数据库，其他都异步的完成。

当然，缺点也随之产生了:

系统复杂性增加了。因为多了一个消息总线和数据同步中心服务。（对于已经使用消息总线的小伙伴就相对简单许多）；数据极短时间内无法一致。由于第二次写入是异步的，可能在请求返回时，异步数据写入还没有完成，因此，会有短暂的数据不一致。（绝大多数业务场景中，这一点点时间的不一致大多都可以忽略）；消息总线可能丢失消息，那么数据就会出现不一致。（这种情况极少出现）。

当然，沈剑还介绍了第三种方案，我没试过，说是可以实现冗余数据的解耦。

3)离线异步双写

这种方法类似于数据库的订阅同步。冗余数据的写入不再通过服务来完成，而是通过离线服务或任务来完成。

离线服务或任务通过读取日志记录来完成冗余数据的写入。

这种方法的优点:

将冗余数据的写入和业务完全解耦，怎么去写冗余数据和业务服务以及无关了；处理时间快。（原因同第二种方式）。

当然，也有一些缺点:

数据不一致性，和第二种方式一样，这也是异步插入冗余数据，那就会有短暂的时间出现数据不一直；线下服务必须可靠，不然数据一致性难保证。

无论我们用哪种方式，系统中总会出现某种异常，尤其是在高并发的情况下。当这些异常发生时，我们需要一种手段来最终实现不一致数据的一致性。

所以必须完成:异步检测，异步修复。

如何保证数据的最终一致性

沈剑在文章中介绍了三种方法。在这里，我将这三种方法分享给大家。

1)离线全数据扫描

离线启动一个离线扫描工具，不断扫描对比T1表和T2表的数据，一旦发现数据不一致就进行修复。

这样做的好处是:

简单，开发的方便；无需修改线上服务，离线扫描工具与线上业务完全解耦。

缺点也很明显:

扫描效率低，大部分时间，都在扫描已经一致的数据；扫描量大，因此同步数据的时间周期比较长。

有什么办法不是每次都扫描所有的数据，而是有针对性的扫描？

2)离线增量数据扫描

我们修改了在线服务，以便在每次写入数据时都写一个日志。然后，我们还需要一个离线扫描工具，但是这个扫描工具每次只对日志进行增量扫描。如果发现日志数据不一致，将进行修复。

完成此操作后:

虽然增加了一些步骤，但依旧非常简单，开发的难度不高；数据扫描效率提高了，只需要扫描增量数据。

但是:

我们需要对线上服务进行调整（只是多写两次日志，非常简单）；虽然扫描效率提高了，但是实时性还是不高，主要是取决于扫描增量数据的周期时间。

有办法实时监控吗？

3)在线实时监控的“消息对”方法

这一次，我们将服务改为向总线发送消息，而不是写日志。数据成功写入后，发送一条消息，两次写入后，发送两条消息。这个时候，我们不再需要扫描工具，而是需要实时订阅服务，不断接收这些消息。如果我们在收到第一条成功消息后的一定时间内没有收到第二条消息，我们会检查数据的一致性，如果发现不一致就修复。

完成此操作后:

实时性高；效率高。

但是也有缺点:

方案比较复杂，需要使用到消息总线；需要一个订阅总线的检测服务。

我们需要使用哪种解决方案取决于我们的实际业务需求。技术没有绝对的方法。我们需要考虑投入和产出。所以，有明显缺点的方案不是好方案。