数据库仿真回放策略的思考

背景

为了满足客户日益增长的上云需求，华为云提供的各类云上数据库，但是始终无法消除用户的一个疑虑：以我们目前的业务量，华为云的RDS到底能不能稳定的支持住呢？这不仅是客户需要考虑的问题，更是我们数据库从业者应该深思的问题。除了不断优化我们的内核产品外，我们还应当提供一个可以验证的工具来消除这种疑虑，给用户以信心。

实施

那到底什么样的手段才是可信的呢？那我们思考在哪一步才能获得全部的SQL量，我们选择在网络路由层，通过旁路监听的方式，无损无干扰的将数据收集下来，然后通过回放程序进行回放，那就引入我们的正题了，到底什么样的策略才是更好的策略？

策略

策略一.线程模拟session

***说明（S 代表 Sleep | E 代表 Execute SQL）***

>线程1 S-E-E-S-E-S-S-E

>线程2 E-S-S-S-S-E-E-E-E-E-S

>线程3 S-S-S-S-S-S-E-E-E-E-S-S-S-E-E

这个策略就是将同一个session所有的sql放到同一个线程中执行，并且做了相同的时间间隔做等待，这里的主要实现就是一个线程模拟一个人。

**优势：** 可以很好的模拟一个用户在APP或者系统上的操作行为

**劣势：** 一台机器的CPU 内存资源是有限的，当服务负载高时，客户侧可能是10台机器执行的结果，而我们没有分布式的能力来模拟，导致当前机器CPU调度来不及或者内存溢出

策略二.最合适时间执行

> 当前每秒SQL    线程池

>|--------------|    |-------|

>|---- SQLs----| ---> |  E  |

>|--------------|    |-------|

这个策略是把数据库当前这1s内同时要执行的sql全部取出来，然后丢给一个线程池并发执行，使得他们尽最大努力把SQL执行完

**优势：** 不会造成SQL的延迟，不会因为某一条或者某一类SQL执行过慢导致整个执行序延迟，同时可以很好的控制和利用单机资源。

**劣势：** 我们在这个策略下就变成零散的看到业务SQL，对于业务依赖强的场景，就很难模拟出正确负载场合。

策略三.只回放select

***说明（P 代表暂停|E代表执行）***

> P -->| SELECT SQLS |-->E-->P-->|SELECT SQLS|-->E

每次回放只把Select语句拿来执行，不管线程模型采用何种，都不会破坏我目标数据库，可以很好的验证select的性能，并且一直保持住现场。

**优势：** 可以一直重复的验证select语句的执行效能，不会破坏数据的完整性。

**劣势：** 这个回放方案就没法用业务的思维来衡量了，并且验证的时间序也没法保证，对于事务比较多比较大的业务，这个内存压力就小了很多。

---

以上就是现阶段对于回放策略的总结，虽然有很多不完美的地方，但是已经能够帮助有特殊业务场景需求的客户完成数据库可信验证，并且我们还在持续输出的路上。

我们相信**道路是曲折的，前途是光明的。**