如何设计数据库监控应用程序

Posted 2023-04-18

【中文标题】如何设计数据库监控应用程序

【英文标题】：How to Design a Database Monitoring Application

【发布时间】：2015-02-03 08:15:39

【问题描述】：

我正在设计一个数据库监控应用程序。基本上，数据库将托管在云中，并通过 Windows、ios、android 等的自定义编写客户端提供对它的记录级访问。基本场景可以通过 Web 服务 (ASP.NET WebAPI) 实现。例如，客户端将向 Web 服务发出 GET 请求以获取条目。但是，其中一个要求是客户端应该自动刷新 UI，以防另一个用户（使用客户端的不同实例）更新相同的记录，并且自动刷新需要在更新记录的一秒内发生 - 这样信息始终是最新的。

轮询可能是一种选择，但活动客户端的数量可能有数十万，因此我正在寻找一种更强大、更轻量级（在服务器上）的解决方案。我精通 .NET 和 C++/Windows，我可以使用 IO Completion Ports 在 C++/Windows 中推出一个完整的解决方案，但我觉得这太过分了，需要太多的开发时间。查看 ASP.NET WebAPI 但无法发送通知是它的限制。 Windows 生态系统中是否有任何框架/技术可以解决这种情况并轻松扩展？ Windows 生态系统之外的任何好的选择，例如node.js？

【问题讨论】：

SignalR?让 WebAPI 的 POST 向所有连接的客户端推送通知，告知他们要刷新数据。

SignalR 是各种其他技术 websocket、轮询等之上的一个层。我正在寻找一个较低级别的解决方案。找到 PushStreamContent，但无法确定它是否会扩展到数十万个连接。有什么想法吗？

基于用户 SignalR 或 Node.Js 的解决方案。分析股票交易应用程序。

客户端类型、网页或独立应用程序是什么？

@Steve 客户端将是移动和桌面应用程序，使用 C# 或 C++ 编写。

【参考方案1】：

您没有指定可以使用的数据库，因此如果您能够使用 MSSQL Server，您可能需要查找 SQL 依赖项功能。如果正确配置和使用，如果数据库有任何更改，您将收到通知。

将此与 SignalR 或您选择的任何实时前端框架配对，您将获得如您所描述的实时更新。

一个问题是，SQL 依赖只告诉你发生了一些变化。无论它是什么，您都有责任跟踪它是哪条记录。这增加了额外的难度，但比轮询要好得多。

您可能希望在 SO 处搜索 sqldependency 标记，以便从此处转到您希望应用程序所在的位置。

【讨论】：

signalR 无法处理数十万并发连接，或者我应该说 Web 服务器本身不能

SignalR 本身可以配置为处理“成百上千”的并发连接。请参阅文档。但是可以假设，由于它将部署在云中，因此您可以在一定程度上增强 Web 服务器以处理这种负载。

当然……它可以声称它可以同时处理数十万个连接，但是……请记住，这在硬件级别上是不可能的。

哦，加油@Steve :) 在 .net 4.0 中，默认的 maxConcurrentRequestsPerCPU 设置为 5000。获得一个 32 核 EC2 实例或类似的东西，理论上你很容易拥有 160000。 :P

你不妨每隔 1 秒发出一次 HTTP 请求来拉取信息，看看服务器是否喜欢它。我很确定服务器在超过 10k 个并发连接后会很快死掉。顺便说一句，该属性称为 PerCPU 而不是 PerCore。不确定这是否只是一个坏名字。看看所有主机提供者允许的并发 web socket 数量，你会发现大多数都在 1k 以下。我相信你知道为什么会这样

【参考方案2】：

我的第一个想法是让 web 服务调用“保持活跃”或称为 WebSockets 的 html5 协议。您可以保持大量连接，但数十万似乎太大了。因此，Web 服务需要有一种方法来联系具有无状态连接的客户端。因此，在客户端构建一个 Web 服务服务器可以与之通信的 Web 服务。由于防火墙问题，这可能是一个问题。

如果防火墙不是问题，那么您可能不需要客户端中的 Web 服务。您可以改为在客户端上实现服务器套接字。

对于移动客户端，如果无法实现服务器套接字，则使用推送通知。或许请查看https://***.com/a/6676586/4350148 以了解类似问题。

最后，您可能需要考虑一个内容交付网络。

最后一点是，希望您不需要在 1 秒内联系所有 100000 个用户。我假设有这么多用户，你有很多服务器。

查看Maximum concurrent Socket.IO connections关于打开的最大websocket连接数；

还要考虑您对大约 100000 个同时用户的估计是否准确。