用户连通性：投入生产两年 — 经验教训与新模式

Source: Dev.to

引言

这是我之前关于 用户连通性：在线和离线用户状态的实时 Web 解决方案 的文章的后续。自从我首次将用户连通性解决方案部署到生产环境，已经快两年了。最初的实验已经成为我架构的基石。

最近，我遇到了由多个 API 进程引起的复杂数据库死锁问题。经过分析，我发现可以利用我的事件驱动架构来解决。通过将特定任务拆分并异步处理，我彻底消除了死锁。

事件分发器 的目标很简单：一个监听 Redis 过期事件且仅此而已的中心服务。

事件分发器的优势

• 可追踪性 – 所有事件都经过同一点，便于追踪问题。
• 日志记录 – 每个接收到的事件都会记录到 Azure Cosmos DB 并标记其状态。
• 可伸缩性 – 工作函数可以根据队列深度独立扩展。
• 可靠性 – 单一、受良好监控的监听器降低了漏掉事件的风险。

在运行该架构两年后，我对使用 Azure 服务实现类似方案的人员有两点关键观察。

关键观察

1. 为 Redis 监听器使用 Premium 计划

为什么？
Consumption 计划存在冷启动延迟和连接寿命限制。当 Function App 处于空闲状态时，它可能会进入休眠，从而错过 Redis 的事件。使用 Premium 计划时，Function App 始终保持在线，拥有长连接——没有冷启动，也不会错过事件。自从迁移到 Premium 后，我没有看到过任何丢失的事件。

你可能会问：原来的用户连通性方案是如何在 Consumption 计划上工作的？
它能够运行，但错过事件的风险更高。

2. Azure 托管 Redis 的限制

有一个重要限制：Azure 托管的 Redis 服务器无法完整配置以可靠地发送过期事件。当底层服务器重启或循环时，它们会丢失配置，进而停止发送过期事件。

我已向微软报告了此问题。他们确认已列入待办事项，但截至目前仍没有解决方案。如果你的架构依赖 Redis 键的过期事件，请在迁移到 Azure 托管 Redis 之前注意此限制。

收获

• 为 Redis 监听器使用 Premium 计划，以避免冷启动和事件丢失。
• 如果依赖过期事件，请对 Azure 托管 Redis 持谨慎态度，因为服务器重启时配置可能会丢失。

希望这些经验能帮助其他人更好地利用此架构。