程序员，你懂查询分离业务场景：千万工单表如何实现快速查询吗？

最新推荐文章于 2024-04-19 17:41:32 发布

程序员小英

最新推荐文章于 2024-04-19 17:41:32 发布

阅读量708

点赞数 12

文章标签：查询分离业务场景

本文链接：https://blog.csdn.net/2401_83384536/article/details/137919351

版权

文章讲述了客服系统中千万工单查询速度慢的问题，探讨了从冷热分离到读写分离再到最终采用查询分离的解决方案过程。查询分离在数据量大、查询复杂且写操作响应尚可的情况下尤为适用，避免了与业务深度耦合，提升了查询效率。

摘要由CSDN通过智能技术生成

前言

承接上文：
https://www.toutiao.com/article/7119685174979265057/

查询分离

上一场景使用的冷热分离解决方案性价比高，可以快速交付，但它却不是一个最优的方案，仍然存在诸多不足。比如，业务功能上要求不能再修改冷数据，查询冷数据速度慢，无法承受复杂的查询和统计。后来，笔者负责了另一个客服系统项目，刚好就用了不同的方案。

先介绍一下这个项目的业务场景吧。

业务场景：千万工单表如何实现快速查询

本场景中的客服系统承接的是集团的所有业务，每条业务线的客服又分为多个渠道，有电话、在线聊天、微信、微博等。

它的业务流程是这样的：当客户接线进来以后，不管是通过什么渠道，客服都会登记一个客服工单，而后再根据业务线、工单的类型来登记不同的信息；工单创建后，会按需创建其他的单据，比如退款单、投诉单、充值单等，针对每个该工单的处理动作或工单关联单据的处理动作，也会自动添加工单处理记录和更新处理时间。

系统已经运作了5年左右，已有数据量大，而且随着集团业务的扩大，业务线增加，客服增多，工单数量的增长也越来越快，在系统中查询工单，以及打开工单详情的时候，就会出现响应速度很慢的情况。

一开始客服只是偶尔抱怨，后来抱怨的次数慢慢增多。但是之前客服这个板块的优先级不高，所以那些抱怨基本都被忽略了。

在一次集团战略会议上，客服的负责人又提到了这个问题，称其已经影响了客服的工作效率。会后，集团领导意识到了问题的急迫性，启动了客服系统的整改项目。

项目组调研了查询慢和工单详情打开慢的问题，具体情况如下。

1）查询慢。当时工单数据库里面有1000万左右的客服工单时，每次查询时需要关联其他近10个表，一次查询平均花费13秒左右。

2）打开工单慢。工单打开以后需要调用多个接口，分别将用户信息、订单信息以及其他客服创建的单据信息列出来（如退款、赔偿、充值、投诉等）。打开工单详情页需要近5秒。

因为以前做过冷热分离，所以项目组人员脑海中第一个思路就是，能不能把不常用的工单数据移到其他数据库？

但是这次不一样了，因为向客服调研的时候发现，有些工单的处理会涉及诉讼，所以周期很长，比如一个3年前建的工单最近还在处理。项目组问客服，这是不是个例，客服说不是，这种工单还不少。又问客服，是不是只有涉及诉讼的工单才会拖这么久？客服说，基本是这样。

项目组就有了一种思路：针对投诉类型的工单，不做冷热分离，其他类型的工单处理后归档冷数据库。

但是进一步调研以后才发现，还有个工单类型转换的场景，即原本客户只是咨询，沟通中发现了问题，然后就转投诉了，但是系统设计的功能中，是不能修改工单类型的。也就是说，有些客服工单表面上只是咨询，其实是投诉。

这样冷热分离的方案就不合适了，因为再继续下去，这个方案会跟业务耦合很深，对业务代码的影响面会变得很大。

还有个思路：读写分离。

这个思路是这样的：MySQL有个主从架构，可以将所有对工单表的写操作转入MySQL的主库，所有对工单表的查询操作连接到MySQL的从库。读写分离的好处就是，读的请求和写的请求针对不同的数据库，彼此不会抢占数据库资源。而且，主库用InnoDB的存储引擎，从库用MyISM，MyISM不支持事务，但是性能更好。

但是，使用这个方案得到的工单查询速度提升有限，所以最终没有采用。

它主要还是用在数据库高并发的场景中。

最终采用的是查询分离的解决方案，即将更新的数据放在主数据库里，而查询的数据放在另外一个专门针对搜索的存储系统里。

对于主数据库，因为数据的更新都是单表更新，不需要关联也没有外键，而且不会被查询操作占用数据库资源，所以写的性能就没有问题了。数据的查询则通过一个专门处理大数据量的查询引擎来解决，它的优点就是能够实现快速查询。

接下来详细介绍一下这个方案。