经常使用查问分别后从20s优化到500ms

冷热分别诚然是一共性价比高的处置方案，但也并不是银弹，依然有诸多限度，比如：

此时假设须要处置以上疑问，可以驳回另外一种方案：经常使用优化业务主表数据大查问缓慢的疑问

查问分别从字面过去说十分容易了解，其实就是在写数据时保留一个备份数据到另外的存储系统，在查问时间接从另外的存储系统中失掉数据，如下图：

以上只是繁难的架构图，其中有些细节还是须要深究，如下：

当你在实践业务中遇到以上情景，则可以思考经常使用查问分别处置方案。

曾做过 SaaS 客服系统的架构优化，系统里有一个工单查问配置，工单表中寄存了几千万条数据，且查问工单表数据时须要关联十几个子表，每个子表的数据也是超亿条。

面对如此宏大的数据量，跟前面的冷热分别一样，每次客户查问数据时几十秒能力前往结果，即使我们经常使用了索引、SQL 等数据库优化技巧，成果依然不显著。

工单表中有些数据是几年前的，客户说这些数据触及诉讼疑问，须要继续坚持降级，因此我们不可将这些旧数据封存到别的中央，也就没法经过前面的冷热分别方案来处置。

最终我们驳回了查问分别的处置方案，才得以将这个疑问顺利处置：将降级的数据放在一个数据库里，而查问的数据放在另外一个系统里。由于数据的降级都是单表降级，不须要关联也没有外键，所以降级速度立马失掉优化，每次客户查问数据时，500ms 内就可失掉前往结果。

什么时刻触发查问分别？

繁难的来说就是什么时刻应该保留一份数据到查问数据库中，其实也就是数据异构的环节。

修正业务代码：在写入惯例数据后，同步建设查问数据。

该种方案优缺陷也十分显著：

：查问数据的分歧性和实时性失掉了保障

：业务代码侵入比拟强；减缓写操作的效率

修正业务代码：写入数据后，异步建设查问数据

该种方案的优缺陷如下：

：不影响干流程

：数据分歧性存在疑问

该种方案也是业界罕用的一种方案，关于代码是无侵入的，经过监听数据库日志的模式建设查问数据，如下：

该种方案的优缺陷如下：

：不影响干流程；代码侵入为0

：数据分歧性存在疑问；架构相对复杂

关于上述三种方案都算是比拟经常出现的方案，关于第一种同步的模式比拟繁难，这里不再引见；

这篇文章来引见一下异步的模式，异步的模式有很多，可以放在内存中启动操作，然而这有些弊病：

因此最终我们可以决定的模式，那么此时就触及到了MQ的技术选型，这里给两个倡导：

当然一旦引入了MQ还须要思考的疑问很多，如下：

MQ宕机象征着查问数据不能继续建设了，我们可以在写入数据的同时给该条数据加一个标记字段（已搬运、未搬运），当MQ启动后，查问一切未搬运的数据，继续建设查问数据

这里的方案很多，依照业务虚际状况考量

信息的幂等生产必定要保障，防止数据重复建设，比如：主数据的订单 A 降级后，我们在查问数据中拔出了 A，可是此时系统出疑问了，系统误认为查问数据没降级，又把订单 A 拔出降级了一次性。

比如某个订单 A 降级了 1 次数据变成 A1，线程甲将 A1 的数据搬到查问数据中。不一会儿，后盾订单 A 又降级了 1 次数据变成 A2，线程乙也启动上班，将 A2 的数据搬到查问数据中。

所谓的时序性就是假设线程甲启动比乙早，但搬运数据举措比线程乙还晚成功，就有或者出现查问数据最终变成过时的 A1

查问数据的存储系统选型？

既然为了处置表数据量大查问缓慢的疑问，必需是不能决定相关型数据库了，那么还有其余决定吗？

内存数据库只管性能十分高，比如Redis，然而不适宜海量数据，太费钱了

那么这里比拟实用的有如下三种：

这里选型还是要依据自己公司业务决定，假设曾经有在用的，则间接用即可；另外就是决定自己相熟的，比如现在我们设计架构方案时，为什么决定用 Elasticsearch，除 ES 对查问的裁减性支持外，最关键的一点是我们团队对 Elasticsearch 很相熟。

查问数据很繁难，每个数据库都有对应的API，间接调用查问

然而，这里有一个疑问： 数据查问降级完前，查问数据不分歧怎样办？ ，给出两种方案：

本篇文章引见了表数据量大查问缓慢的一种处置方案：查问分别，但这也不是银弹，依然是存在一些无余，比如表数据量大，写入缓慢怎样办？

当然查问分别还有一个关键的疑问：历史数据如何迁徙？这个处置也是十分繁难，然而也有许多须要思考的点，