图书馆设计方法论

Question

我想做个“陷阱特工”图书馆。陷阱代理库保存客户端系统各种参数的跟踪。如果客户端系统的参数更改超过阈值，则客户端的trap代理库将通知服务器该参数。例如，如果CPU使用率超过阈值，那么它将通知服务器CPU使用量超过阈值。我必须测量50-100个参数(如内存使用量、网络使用率等)。在客户端。现在我对这个设计有了基本的了解，但是我还是坚持了整个图书馆的设计。

我想出了以下解决办法：

1. 我可以为每个参数创建一个线程(即每个线程将监视单个参数)。
2. 我可以为每个参数创建一个进程(即每个进程将监视单个参数)。
3. 我可以将不同的参数分类为不同的组，比如数据使用参数将属于网络组，CPU内存使用参数将属于系统组，然后为每个组创建线程。

现在，与第二方案相比，第一种解决方案看上去不错。如果我采用的是第一种解决方案，那么当我想要升级我的库时，它可能会失败，因为我需要100到1000个参数。因为当时我必须创建1000个线程，这不是一个好的设计(我认为是这样；如果我错了，请纠正我的错误)。

第三种解决方案是好的，但响应时间很长，因为许多参数将被监控在单线程中。

有什么更好的方法吗？

Answer 1

您可以遵循以下方法：

1.可以有两个线程，一个线程专门测量紧急参数，第二个线程监视非紧急参数。因此，应急参数的响应时间将更短。

2.可以定义3个threads.First线程来监控高优先级(紧急参数).Second线程将监控的中间优先级参数。最后一个线程将监视最低优先级参数。因此，与第一个解决方案相比，总体响应时间将得到改善。

3.如果不考虑响应时间，那么您可以监视单个thread.But中的所有参数--在这种情况下，当您将库升级到监视100到1000个参数时，响应时间将变得最糟糕。

因此，在第一种情况下，对于非紧急情况下的parameter.While，会有更多的响应时间，在第三种情况下，肯定会有很高的响应时间。所以解决方案2更好。

Answer 2

一般来说，为代码中的任何逻辑映射生成线程1到1是个坏主意。您可以快速耗尽系统的可用线程。

在.NET中，使用线程池( Thread vs ThreadPool )非常优雅地处理这一问题。

这里是一个C++讨论，但概念是相同的：Thread pooling in C++11

进程在Windows上也有很高的开销。具有讽刺意味的是，这两种设计听起来都会对你试图监控的资源造成很大的负担。

线程(和进程)在需要的地方为您提供并行性。例如，在某些后台任务运行时，允许GUI响应。但是，如果您只是在后台监视并向服务器报告，那么为什么需要这么多并行性呢？

您可以在一个线程中的一个紧密的事件循环中一个接一个地运行每个检查。如果你担心不像以前那样对这些值进行抽样，我会说这实际上是一种好处。它无助于消耗50%的CPU来监控你的CPU。如果你是抽查值每几秒钟一次，这可能是很好的分辨率。

事实上，如果您要向服务器报告，那么高分辨率是没有帮助的。您不希望拒绝服务攻击您的服务器，在某些值触发时，每秒钟对它执行多次HTTP调用。

注意:这并不意味着你不能有一个可插拔的架构。您可以创建一些表示检查资源的基类，然后为每个特定类型创建子类。您的事件循环可以迭代数组或对象列表，依次调用每个对象并聚合结果。在循环结束时，如果有超出范围的报告，则向服务器报告。

您可能需要添加逻辑来停止检查(或至少停止向服务器报告)，以确保一旦陷阱发生，就会有一些“冷却时间”。你不想对你的服务器征税或者垃圾邮件你的日志。