记一次群聊消息查询优化的实践

引言

我们在成长，代码也要成长。

一晃，做群聊业务两年多了。

随着业务的增长，群数量不断增长，聊天消息也在不断增长。

群聊的全局搜索的性能问题愈发凸显。

设计之初，考虑群消息的急剧增长，选择了使用阿里云的tablestore，这是一个类似ElasticSearch，拥有强大的搜索能力。

现在来看，还是过于乐观了。

当单表数据达到2亿+的时候，查询变得异常艰难，甚至频繁超时，被客户疯狂吐槽。

当然，遇到这些问题，或许是我们使用的方式不对，欢迎大家帮忙斧正。本篇仅用于问题记录和经验交流分享。

tablestore简介

表格存储（Tablestore）面向海量结构化数据提供Serverless表存储服务，同时针对物联网场景深度优化提供一站式的IoTstore解决方案。适用于海量账单、IM消息、物联网、车联网、风控、推荐等场景中的结构化数据存储，提供海量数据低成本存储、毫秒级的在线数据查询和检索以及灵活的数据分析能力。

基本概念

在使用表格存储前，您需要了解以下基本概念。

术语	说明

|--------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 术语 | 说明 |
| 地域 | 地域（Region）物理的数据中心，表格存储服务会部署在多个阿里云地域中，您可以根据自身的业务需求选择不同地域的表格存储服务。更多信息，请参见表格存储已经开通的Region。 |
| 读写吞吐量 | 读吞吐量和写吞吐量的单位为读服务能力单元和写服务能力单元，服务能力单元（Capacity Unit，简称CU）是数据读写操作的最小计费单位。更多信息，请参见读写吞吐量。 |
| 实例 | 实例（Instance）是使用和管理表格存储服务的实体，每个实例相当于一个数据库。表格存储对应用程序的访问控制和资源计量都在实例级别完成。更多信息，请参见实例。 |
| 服务地址 | 每个实例对应一个服务地址（EndPoint），应用程序在进行表和数据操作时需要指定服务地址。更多信息，请参见服务地址。 |
| 数据生命周期 | 数据生命周期（Time To Live，简称TTL）是数据表的一个属性，即数据的存活时间，单位为秒。表格存储会在后台对超过存活时间的数据进行清理，以减少您的数据存储空间，降低存储成本。更多信息，请参见数据版本和生命周期。 |

应用场景

表格存储有互联网应用架构（包括数据库分层架构和分布式结构化数据存储架构）、数据湖架构和物联网架构三种典型应用架构。

互联网应用
- 历史订单数据场景
- IM场景
- Feed流场景
大数据
- 推荐系统
- 舆情&风控分析（数据爬虫）场景
物联网

基于我们的实际场景，选择了IM场景。

java sdk

更加详细的介绍请查看：《java sdk》

火线告警：500错误频发

从日志记录可以看出，异常的主要集中在去年9月~12月之间，基本上超时请求。

除此以外，还有大量的慢查询。

这是其中一个包含搜索群消息逻辑的接口，确实很慢。

特别是在去年年底，几乎每天技术群都会有几个报警。

真相大白：单表数据超2亿,tablestore连接超时

经过排查，存储群聊消息的宽表超过接近3亿条。

因为是群聊场景，每条消息发出都会投递给其他群成员，我们是按照接收人的方式存储的，所以消息数量会激增。

消息存储数量已经过亿，这个就导致ts查询性能急剧下降，不知道Elastic Search的在这种数量下的性能如何，请有这方面经验的朋友指点一下。

如何应对呢？

能想到的就是删除TS中历史数据，保留一定时段内的数据，控制数据量在一定范围内。

但是保留多久的数据，产品、运营都无法给出一个合理的时段。

于是陷入僵局。

紧急发版：快速关闭查询功能

每一个群报警，都像是敌人发起的冲锋号角，我不能坐视不管。

短时间内没有更好地解决方案，和运营沟通后，选择暂时关闭群聊查询功能。

紧急给这个功能增加了开关，下班就发版了。报警群安静了，安稳过年。

数据清理：仅保留半年内的数据

选择妥协，别为难自己。

程序员朋友爱较真，有些人甚至到了丧心病狂的程度。

我有个写代码的同事，每次有人找他改问题都像是干架。

我呢，有时候也会钻进牛角尖。

经过一顿操作，我发现暂时没有很好的解决方案，于是我妥协了。

既然，没有很好的优化办法，那就把历史数据删除了，只保留半年的数据。

为此，转为写了一个定时任务，每天执行。

短时间内，我们将数据降低到2亿条以内。

收紧入口：只同步一条到tablestore

真正的猛士敢于直面困难，有些问题必须解决。

本以为定时删除数据的方案已经稳了，没想到增长的比删除的还快。

没到一个月，数据量又上来了。

我再次选择了关闭了群聊查询功能。

痛定思痛，我决定优化方案------从源头控制写入TS的数量。

我们一起来看看之前的存储方案：

这样设计是考虑到可能会按照接收人来控制查看消息的权限。

比如尽管在一个聊天群，但是进群的人是有先后的，不同时间进群的人可能看到的消息不一样。

弊端就是同一份消息会存储多份。

为什么要这样做呢？

因为我们的IM并没有使用本地数据库的方式，所有消息都是从服务端拉取的。

上面的分析我们知道，数据量太大是导致tablestore查询性能差的根本原因。

那我们考虑对现有方案进行改进：

放开消息查询的限制，不在限制接收人
消息按照发送人存储，仅存储一条

这样存储，我们的数据将会大幅度下降。

双保险：增加功能开关

防患未然，功能可开关。

我们总是喋喋不休的强调程序的稳定性、健壮性、可扩展性...

但是，我们总是无法一次性写出完美的程序。

业务需求的变化、数据量的变化、三方接口的升级等都不得不让我们经常考虑到对程序的重构，总之有各种不确定性的因素出现。

在《记一次加锁导致ECS服务器CPU飙高分析》一文中，我们提到为了防患未然，对一些复杂功能增加开关是一个比较好的处理办法。

通过两个主要措施：

数据清理：仅保留半年内的数据
收紧入口：只同步一条到tablestore

几天之后，我们再次查看tablestore中单表的数据量已经大幅降低。

随着时间的推移，我们的策略会持续执行，那么数据量将会降低到千万级别。

当然，这个数据量，我们可以比较放心的打开这个群消息查询功能。

结语

善战者无赫赫之功。

哪有什么岁月静好，我们总是在打怪升级中成长。

或许对于大众而言所谓的"技术好"，不是单纯的卖弄技术，而是能够针对灵活多变的场景，恰到好处的运用技术。

活到老，学到老。

这里笔者只根据个人的工作经验,一点点思考和分享,抛砖引玉,欢迎大家怕批评和斧正。

2024.03.11

成都