Teams Bot中notification.findMember性能问题与数据库优化方案咨询

问题背景 #

我使用TypeScript和Teams Toolkit开发了一款Teams频道机器人，需向成员发送个人消息通知，因此用到内置函数notificationApp.notification.findMember。当前应用安装数据存储在Azure存储账户的blobStorage中，但存在严重性能问题：findMember会先检索所有安装记录、验证有效性，再获取所有成员并过滤——开发环境仅6名成员时运行较快，但生产环境1900名成员时耗时达90秒。

我计划维护一个以邮箱为键、存储所有成员对象的数据库，通过定期刷新或事件触发更新，现针对两个问题寻求解决方案：

1. 高效处理10000-50000名成员的大规模数据集 #

若使用带定时任务的Azure Function刷新数据库，可通过以下方式优化，且完全支持增量更新：

• 增量拉取数据：调用Microsoft Graph API获取团队成员时，利用$filter参数结合lastModifiedDateTime字段，仅拉取上次刷新时间戳之后有变更的成员。需在数据库中记录每次刷新的时间戳，作为下次查询的过滤条件。
• 分页分批处理：借助Graph API的分页机制（通过@odata.nextLink获取下一页数据），每次批量处理1000条左右的成员数据，避免一次性加载大量数据导致内存溢出或超时。Azure Function中可循环处理分页结果，直至无后续数据。
• 批量写入优化：使用数据库的批量写入接口（如SQL的BULK INSERT、Cosmos DB的BulkExecutor），减少单次写入的IO开销；同时通过事务保证数据一致性，避免部分更新失败导致数据异常。
• 缓存高频访问数据：对变更频率低的成员数据，可在Azure Function中加入本地缓存（如MemoryCache），设置合理的过期时间，减少重复调用Graph API的次数。

2. 基于onInstallationUpdateAdd事件触发刷新时的成员对象获取 #

在onInstallationUpdateAdd事件处理函数内可以直接获取成员对象，具体操作如下：

• 事件触发时，Teams会传递包含安装上下文的Payload，其中包含团队ID、用户ID等核心信息。
• 利用这些ID调用Microsoft Graph API的/teams/{team-id}/members/{user-id}接口，直接获取当前触发事件的成员对象。
• 无需拉取全量成员数据，仅针对该成员进行单条数据的插入或更新，这种方式比定时全量刷新更高效，适合实时性要求高的场景。

内容的提问来源于stack exchange，提问作者Lior Lew