OpenIMServer 优化定时任务处理性能的技术实践

背景

在 OpenIMServer 3.8.2 版本中，我们发现当 conversation 集合中文档数量较多时，定时任务处理消息销毁的效率会显著下降。这主要是因为当前实现采用了传统的分页查询方式，随着数据量的增长，MongoDB 的 skip 操作会导致性能急剧恶化。

问题分析

通过 MongoDB 慢查询日志分析，我们发现当前实现存在两个主要性能瓶颈：

1. skip 操作的低效性：当前代码每次只处理 100 条数据，当需要处理靠后的数据时，skip 值会变得很大，导致 MongoDB 需要扫描大量文档才能定位到目标数据。

2. 小批量处理的开销：每次仅处理少量数据，导致需要多次查询才能完成全部数据的处理，增加了网络和查询解析的开销。

优化方案

我们提出了以下优化措施：

1. 使用游标式分页替代 skip

传统的分页方式：

pagination := &sdkws.RequestPagination{
    PageNumber: pageNumber,
    ShowNumber: batchNum,
}

优化后的游标式分页：

pagination := &sdkws.RequestPagination{
    PageNumber: 0,
    ShowNumber: batchNum,
}
filter := bson.M{"conversation_id": bson.M{"$gt": lastID}}

这种基于字段值的分页方式利用了索引的有序性，避免了 skip 操作带来的性能问题。

2. 增大批量处理大小

将每次处理的批量大小从 100 增加到 200，减少了总的查询次数。经过测试，这个值在大多数场景下能提供较好的平衡：

const batchNum = 200

3. 实现细节优化

优化后的核心逻辑流程：

1. 首先获取总对话数，计算需要处理的批次
2. 使用游标式分页按批次获取对话ID
3. 批量查询对话详情
4. 筛选出需要销毁消息的对话
5. 记录最后处理的对话ID作为下一批次的起点

实现代码

关键实现代码如下：

func (c *conversationServer) GetConversationsNeedDestructMsgs(ctx context.Context, _ *pbconversation.GetConversationsNeedDestructMsgsReq) (*pbconversation.GetConversationsNeedDestructMsgsResp, error) {
    // 获取总数并计算批次
    num, _ := c.conversationDatabase.GetAllConversationIDsNumber(ctx)
    const batchNum = 200
    maxPage := (num + batchNum - 1) / batchNum

    var temp []*model.Conversation
    var curConversationID string

    for pageNumber := 0; pageNumber < int(maxPage); pageNumber++ {
        // 使用游标式分页
        conversationIDs, _ := c.conversationDatabase.GetConversationIDsGtID(ctx, curConversationID, &sdkws.RequestPagination{
            PageNumber: 0,
            ShowNumber: batchNum,
        })

        if len(conversationIDs) == 0 {
            break
        }

        // 批量查询对话详情
        conversations, _ := c.conversationDatabase.GetConversationsByConversationID(ctx, conversationIDs)
        
        for _, conv := range conversations {
            if conv.IsMsgDestruct && /* 其他条件 */ {
                temp = append(temp, conv)
            }
            curConversationID = conv.ConversationID
        }
    }

    return &pbconversation.GetConversationsNeedDestructMsgsResp{
        Conversations: convert.ConversationsDB2Pb(temp),
    }, nil
}

性能对比

优化前后的性能对比：

指标	优化前	优化后
查询时间	随skip值线性增长	稳定在较低水平
内存使用	较低	略高(因批量增大)
网络开销	较高(多次查询)	较低
MongoDB负载	高(全表扫描)	低(索引扫描)

注意事项

1. 批量大小的选择：200是一个经验值，实际应用中应根据数据特点和服务器配置进行调整。过大的批量可能导致内存压力，过小则无法充分发挥优化效果。

2. 排序字段的选择：必须选择有索引且唯一的字段作为游标字段，本例中使用的是 conversation_id。

3. 边界条件处理：需要妥善处理最后一页数据以及空结果集的情况。

4. 错误处理：虽然示例中简化了错误处理，实际应用中应保持适当的错误处理逻辑。

总结

通过这次优化，我们解决了 OpenIMServer 中定时任务处理大量对话数据时的性能瓶颈。关键点在于：

1. 避免使用 skip 进行分页，转而使用基于字段值的游标式分页
2. 适当增大批量处理大小，减少查询次数
3. 保持代码的清晰性和可维护性

这种优化思路不仅适用于消息销毁场景，也可以推广到其他需要处理大量数据的定时任务中。在实际应用中，建议结合具体业务场景和数据特点进行参数调优，以达到最佳性能。