冷热分离解决方案的性价比高，但它并不是一个最优的方案，仍然存在诸多不足，比如：查询冷数据慢、业务无法再修改冷数据、冷数据多到一定程度系统依旧扛不住，我们如果想把这些问题一一解决掉，可以用另外一种解决方案——查询分离。（注意：查询分离与读写分离还是有区别的）
业务场景
SaaS 客服系统的架构优化，系统里有一个工单查询功能，工单表中存放了几千万条数据，且查询工单表数据时需要关联十几个子表，每个子表的数据也是超亿条。面对如此庞大的数据量，跟冷热分离一样，每次客户查询数据时几十秒才能返回结果，即便我们使用了索引、SQL 等数据库优化技巧，效果依然不明显。加上工单表中有些数据是几年前的，客户说这些数据涉及诉讼问题，需要继续保持更新，因此我们无法将这些旧数据封存到别的地方，也就没法通过前面的冷热分离方案来解决
最终采用了查询分离的解决方案，才得以将这个问题顺利解决：将更新的数据放在一个数据库里，而查询的数据放在另外一个系统里。因为数据的更新都是单表更新，不需要关联也没有外键，所以更新速度立马得到提升，数据的查询则通过一个专门处理大数据量的查询引擎来解决，也快速地满足了客户的需求，通过这种解决方案处理后，每次客户查询数据时，500ms 内就可得到返回结果，客户再也不抱怨了
什么是查询分离？
查询分离的概念，从简单的字面意思上也好理解，即每次写数据时保存一份数据到另外的存储系统里，用户查询数据时直接从另外的存储系统里获取数据，示意图如下
什么场景下使用查询分离？
当你在实际业务中遇到以下情形，则可以考虑使用查询分离解决方案
- 数据量大；
- 所有写数据的请求效率尚可；
- 查询数据的请求效率很低；
- 所有的数据任何时候都可能被修改；
- 业务希望我们优化查询数据的功能
查询分离实现思路
在实际工作中，如果业务要求必须使用查询分离的解决方案，我们就务必掌握查询分离的实现思路。也只有这样，真正遇到问题时才能有条不紊地开展工作
查询分离解决方案的实现思路如下
- 如何触发查询分离？
- 如何实现查询分离？
- 查询数据如何存储？
- 查询数据如何使用？
（一）如何触发查询分离？
这个问题说明的是应该在什么时候保存一份数据到查询数据中，即什么时候触发查询分离这个动作，一般来说，查询分离的触发逻辑分为 3 种
- (1) 修改业务代码：在写入常规数据后，同步建立查询数据
- (2) 修改业务代码：在写入常规数据后，异步建立查询数据
- (3) 监控数据库日志：如有数据变更，更新查询数据
3 种触发逻辑的优缺点对比表如下
| 修改业务代码，同步建立查询数据 | 修改业务代码，异步建立查询数据 | 监控数据库日志 | |
|---|---|---|---|
| 优点 | 1、保证查询数据的实时性和一致性 2、业务逻辑灵活可控 |
不影响主流程 | 1、不影响主流程 2、业务代码0侵入 |
| 缺点 | 1、浸入业务代码 2、减缓写操作速度 |
查询数据更新前，用户可能会查询到过时的数据 | 1、查询数据更新前，用户可能会查询到过时的数据 2、架构相对复杂一些 |
什么叫业务逻辑灵活可控？
举个例子：一般来说，写业务代码的人能从业务逻辑中快速判断出何种情况下更新查询数据，而监控数据库日志的人并不能将全部的数据库变更分支穷举，再把所有的可能性关联到对应的更新查询数据逻辑中，最终导致任何数据的变更都需要重新建立查询数据
什么叫减缓写操作速度？
建立查询数据的一个动作能减缓多少写操作速度？很多。举个例子：当你只是简单更新了订单的一个标识，本来查询数据时间只需要 2ms，而在查询数据时可能会涉及重建（比如使用 ES 查询数据时会涉及索引、分片、主从备份，其中每个动作又细分为很多子动作），这时建立查询数据的过程可能就需要 1s 了，从 2ms 变成 1s
查询数据更新前，用户可能查询到过时数据
这里结合第 2 种触发逻辑来讲，比如某个操作正处于订单更新状态，状态更新时会通过异步更新查询数据，更新完后订单才从“待审核”状态变为“已审核”状态。假设查询数据的更新时间需要 1 秒，这 1 秒中如果用户正在查询订单状态，这时主数据虽然已变为“已审核”状态，但最终查询的结果还是显示“待审核”状态
每种触发逻辑的适用场景如下
| 触发逻辑 | 适用场景 |
|---|---|
| 修改业务代码，同步建立查询数据 | 业务代码比较简单且对写操作的响应速度要求不高 |
| 修改业务代码，异步建立查询数据 | 业务代码比较简单且对写操作响应速度有要求 |
| 监控数据库日志 | 业务代码比较复杂或者改动代价太大 |
在一个真实业务场景中，虽然我们对业务的代码比较熟悉，但是业务要求每次修改工单请求时响应速度快，我们最终就选择了修改业务代码异步建立查询数据这种触发逻辑
（二）如何实现查询分离？
关于第 2 种触发方案：修改业务代码异步建立查询数据，最基本的实现方式是单独起一个线程建立查询数据，不过这种做法会出现如下情况
- 写操作较多且线程太多，最终撑爆 JVM；
- 建查询数据的线程出错了，如何自动重试；
- 多线程并发时，很多并发场景需要解决
面对以上三种情况，我们该如何处理？此时使用 MQ 管理这些线程即可解决
MQ 的具体操作思路为每次主数据写操作请求处理时，都会发一个通知给 MQ，MQ 收到通知后唤醒一个线程更新查询数据，示意图如下
了解了 MQ 的具体操作思路后，还应该考虑以下 5 大问题
问题一：MQ 如何选型？
如果公司已使用 MQ，那选型问题也就不存在了，毕竟技术部门不会同时维护 2 套 MQ 中间件，而如果公司还没使用 MQ，这就需要考虑选型问题了
（1）召集技术中心所有能做技术决策的人共同投票选型
（2）不管我们选择哪个 MQ ，最终都能实现想要的功能，只不过是易用不易用、多写少写业务代码的问题，因此从易用性和代码工作量角度考量即可
问题二：MQ 宕机了怎么办？
如果 MQ 宕机了，我们只需要保证主流程正常进行，且 MQ 恢复后数据正常处理即可，具体方案分为三大步骤
- 每次写操作时，在主数据中加个标识：NeedUpdateQueryData=true，这样发到 MQ 的消息就很简单，只是一个简单的信号告知更新数据，并不包含更新的数据 id
- MQ 的消费者获取信号后，先批量查询待更新的主数据，然后批量更新查询数据，更新完后查询数据的主数据标识 NeedUpdateQueryData 就更新成 false 了
- 当然还存在多个消费者同时搬运动作的情况，这就涉及并发性的问题，一般是需要加锁处理
问题三：更新查询数据的线程失败了怎么办？
如果更新的线程失败了，NeedUpdateQueryData 的标识就不会更新，后面的消费者会再次将有 NeedUpdateQueryData 标识的数据拿出来处理。但如果一直失败，我们可以在主数据中多添加一个尝试搬运次数，比如每次尝试搬运时 +1，成功后就清零，以此监控那些尝试搬运次数过多的数据
问题四：消息的幂等消费
在编程中，一个幂等操作的特点是多次执行某个操作均与执行一次操作的影响相同
举个例子，比如主数据的订单 A 更新后，我们在查询数据中插入了 A，可是此时系统出问题了，系统误以为查询数据没更新，又把订单 A 插入更新了一次
所谓幂等，就是不管更新查询数据的逻辑执行几次，结果都是我们想要的结果。因此，考虑消费端并发性的问题时，我们需要保证更新查询数据幂等
问题五：消息的时序性问题
比如某个订单 A 更新了 1 次数据变成 A1，线程甲将 A1 的数据搬到查询数据中。不一会儿，后台订单 A 又更新了 1 次数据变成 A2，线程乙也启动工作，将 A2 的数据搬到查询数据中
所谓的时序性就是如果线程甲启动比乙早，但搬运数据动作比线程乙还晚完成，就有可能出现查询数据最终变成过期的 A1，如下图（动作前面的序号代表实际动作的先后顺序）
此时解决方案为主数据每次更新时，都更新上次更新时间 last_update_time，然后每个线程更新查询数据后，检查当前订单 A 的 last_update_time 是否跟线程刚开始获得的时间一样，且 NeedUpdateQueryData 是否等于 false，如果都满足的话，我们就将 NeedUpdateQueryData 改为 true，然后再做一次搬运
简单说下MQ 的作用
服务的解耦： 这样主业务逻辑就不会依赖更新查询数据这个服务了
控制更新查询数据服务的并发量： 如果我们直接调用更新查询数据服务，因写操作速度快，更新查询数据速度慢，写操作一旦并发量高，会给更新查询数据服务造成超负荷压力。如果通过消息触发更新查询数据服务，我们就可以通过控制消息消费者的线程数来控制负载
（三）查询数据如何存储？
我们应该使用什么技术存储查询数据呢？目前，市面上主要使用 Elasticsearch 实现大数据量的搜索查询，当然还可能会使用到 MongoDB、HBase 这些技术，这就需要我们对各种技术的特性了如指掌，再进行技术选型
关于技术选型这个问题，我觉得很多时候不能单单只考虑业务功能的需求，还需要考虑组织结构。比如当初我们设计架构方案时，为什么选择用 Elasticsearch，除 ES 对查询的扩展性支持外，最关键的一点是我们团队对 Elasticsearch 很熟悉
（四）查询数据如何使用？
因 ES 自带 API，所以使用查询数据时，我们在查询业务代码中直接调用 ES 的 API 就行，不过，这个办法会出现一个问题：数据查询更新完前，查询数据不一致怎么办？这里分享 2 种解决思路
- 在查询数据更新到最新前，不允许用户查询。（我们没用过这种设计，但确实见过市面上有这样的设计）
- 给用户提示：您目前查询到的数据可能是 1 秒前的数据，如果发现数据不准确，可以尝试刷新一下，这种提示用户一般比较容易接受
整体方案
历史数据迁移
新的架构方案上线后，旧的数据如何适用新的架构方案？这是实际业务中需要我们考虑的问题，在这个方案里，只需要把所有的历史数据加上这个标识：NeedUpdateQueryData=true，程序就会自动处理了
查询分离解决方案的不足
查询分离这个解决方案虽然能解决一些问题，但也要清醒地认识到它的不足
不足一： 使用 Elasticsearch 存储查询数据时，注意事项有什么
不足二： 主数据量越来越大后，写操作还是慢，到时还是会出问题
不足三： 主数据和查询数据不一致时，假设业务逻辑需要查询数据保持一致性呢？