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

系统简介

• 系统名：客服系统

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

• 主要功能：

  • 当客户接线进来以后，不管是通过什么渠道，客服都会登记一个客服工单，而后再根据业务线、工单的类型来登记不同的信息；

  • 工单创建后，会按需创建其他的单据，比如退款单、投诉单、充值单等，针对每个该工单的处理动作或工单关联单据的处理动作，也会自动添加工单处理记录和更新处理时间。

• 数据量：工单数据库里面有1000万左右的客服工单。

• 问题描述：

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

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

解决思路

• 冷热分离方案（业务限制）：

  • 有些工单的处理会涉及诉讼，所以周期很长，比如一个3年前建的工单最近还在处理。

  • 这种工单还不少。

• 针对投诉类型的工单，不做冷热分离，其他类型的工单处理后归档冷数据库（业务限制）：

  • 存在工单类型转换的场景，即原本客户只是咨询，沟通中发现了问题，然后就转投诉了，但是如果采用冷热分离方法，对于已处于冷库中的记录是不能修改工单类型的。

• 读写分离（提升有限）：

  • 使用这个方案得到的工单查询速度提升有限

• 查询分离（最终方案）：

  • 将更新的数据放在主数据库里，而查询的数据放在另外一个专门针对搜索的存储系统里。

  • 对于主数据库，因为数据的更新都是单表更新，不需要关联，也没有外键，而且不会被查询操作占用数据库资源，所以写的性能就没有问题了。

  • 数据的查询则通过一个专门处理大数据量的查询引擎来解决，它的优点就是能够实现快速查询。