在被测服务中，可能会遇到多个数据源的情况，例如同时存在数据库，消息队列，缓存数据，第三方API数据等 数据源。在之前的测试工作中，我遇到过过由于缓存数据更新逻辑异常，导致产品数据。

首先，我们需要先明确一下，数据一致性指的是什么，才能更好的讨论本章的主题“多数据源的情况下，如何保障被测服务中多数据源的数据一致性？”。

数据一致性，指的是在系统中进行查询，更新或者删除操作时，我们需要保证所有相关数据都应该同步更新。比如，当User 信息同时存在于数据库和Redis缓存中，当用户在界面中更新了用户名和头像时，我们需要确保数据库和缓存数据都被更新。如果代码逻辑中出现了漏洞，只更新了缓存数据，那么当缓存数据过期后，用户再次请求用户信息数据时，将从DB中读取未更新的旧数据。

前置准备

在测试数据一致性之前，我们需要了解被测服务中的数据源和数据流向。

- 在被测服务中涉及了哪些数据源。例如，Mysql，Redis，第三方API 等。

- 确定被测服务中涉及到多数据源下数据读取，更新，删除等操作的业务场景。

- 需要明确每个数据源的作用，比如Mysql 中的数据是原始数据，Redis中的数据是作为减轻DB压力的缓存数据。

保证数据一致性的方案和测试点

在这里我们将以Redis和Mysql 为例，来讨论数据一致性的问题。为了确保数据一致，那么我们可能有以下几种方案来确保数据一致。

1. 先更新缓存，再更新数据库

2. 先更新数据库，再更新缓存

3. 先清空缓存数据，再更新数据库。

以上三种是比较常见的多数据源情况下，确保数据一致的处理方式，由于这三种方案的测试中有很多相同点。因此，对于以上三种方案，我们可以提炼出一些公共的测试点，如下所示：

缓存更新测试点：

1. 基本功能测试：

- 分别对一条和多条数据进行更新，验证缓存和数据库是否都能正常更新数据。并且页面重新请求时能否显示最新数据。

- 分别对一条和多条数据进行删除，验证缓存和数据库下数据是否都能正常删除。并且通过客户端查询时不再回显该数据。

- 调用更新接口对数据进行修改，检查缓存是否被清理。

2. 异常情况测试：

- 模拟数据库连接失败的场景，当触发更新接口时，检查缓存是否按要求清空，以及在数据库连接恢复后，数据是否能够正确更新。

- 在调用更新接口时，模拟网络故障、服务器故障等导致更新操作失败的情况。检查缓存是否仍被清空，若更新失败后是否有重新尝试更新的retry逻辑。以及验证更新失败后是否有合理的处理机制（例如内部邮件通知，warning提示等）

3. 并发测试：

- 模拟多个并发请求同时更新同一条数据，检查缓存是否正确更新为最后一次更新的数据，且缓存更新结果也应该与数据库的最终更新结果一致。

- 模拟多个并发请求同时更新不同的数据，确保数据库中不同类型数据都能正确更新，缓存也能同步更新相应的数据，并且各个更新操作之间不会出现混乱或错误。

4. 数据上锁

确保在当前服务下同一条数据同一时间只允许一个事务在处理，如果有其他事务介入直接拒绝。

数据上锁测试点：

1. 正常加锁解锁测试：

- 启动一个接口处理数据，验证能否成功加锁。

- 事务完成后，验证锁是否正确释放，其他事务可以正常获取锁处理数据。

2. 并发测试：

- 同时启动多个接口尝试处理同一条数据。验证只有一个接口能处理数据并上锁，其他请求能正常被拒绝。

- 被拒绝的请求能有相应的异常处理机制，不会导致系统无响应或者报错等问题。

- 高并发情况下，验证加锁和解锁的响应能力，是否会遇到性能瓶颈等问题。

3. 锁超时测试：

-设置较短的锁超时时间，在请求中进行等待，并且等待时间超过锁的最长时间，验证数据锁是否能正常释放。

4. 异常情况测试：

- 在数据加锁后，模拟系统异常或者网络中断，再恢复系统/网络后检查数据锁能否正常释放。