线程或状态机来管理应用程序状态？
我有一个可以自动配置设备的网络应用程序。通信是使用 HTTP 以请求-响应方式实现的。我目前正在使用线程来管理配置过程，但通常建议不要在 Web 服务器中生成应用程序线程，所以我的问题是我应该使用基于事件的机制而不是线程吗？事件框架是用于维护应用程序状态还是我以错误的方式思考它们？
如果有任何更适用的设计模式，我很想听听。
多谢。
I have a web application that automatically configures a device. Communication is achieved in a request - response fashion using HTTP. I am currently using a thread to manage the configuration procedure but it is generally recommended that application threads are not spawned in web servers so my question is should I be using a event based mechanism rather than a thread? are event framework's used to maintain application state or am I thinking about them in the wrong way?
If there are any more applicable design patterns, I'd love to hear about them.
Thanks a lot.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不确定我是否完全理解你的情况，但无论如何我都会尝试一下。
几年前，我设计了一个应用程序，为我国的一家大型电信运营商提供 ADSL 激活请求服务。
我们收到来自上游应用程序的“激活请求”，我们的工作是操作一系列配置步骤，这些步骤必须在不同的设备上使用不同的协议完成，可能会失败，可能必须被撤回（当然，实现如果顾客离开，则取消一个或多个步骤）。
我们选择了一种基于“状态机”的解决方案。每个请求（在 Oracle DB 中）表示为一个标头记录，该标头记录总结了状态（从“新”到“已完成”，带有各种中间步骤）和一系列子记录，每个记录代表所需的 N 个步骤中的一个来完成配置。
我们为每种步骤安排了批次，基本上选择适当操作类型的记录，并尝试解析每个步骤（这使我们能够根据协议对操作进行分组，例如 snmp 或 telnet，并且还可以定义一些操作）此类操作应该仅在夜间或高峰办公时间之外运行，等等
我们还安排了一个“元批次”，它将定期检查每个打开的“标题”记录，检查所有连接的步骤记录是否都在“中”。完成”状态，并更新标题 它的扩展性
，我们都有一个具体的记录，显示它是否已完成。
足够好，并且允许我们以最少的麻烦来建模不同的步骤。完全或部分“回滚”也很容易 - 因为对于每个步骤 我今天必须解决类似的问题，我更喜欢基于状态机的方法。
Not sure if I am fully understanding your situation, here, but I'll have a stab at it anyway.
Years ago I designed an application for the servicing of ADSL activation requests for a large Telco operator in my country.
We received "activation requests" from an upstream application, and our job was to operate a series of configuration steps which had to be done on different devices, using different protocols, could fail, might have to be retracted (and of course, implement the cancellation of one or more steps in case the customer receded).
We opted for a solution based on a "state machine" of sort. Each request was represented (in an Oracle DB) as a header record which summarized the status (from "new" to "completed", with various intermediate steps) and a series of child records, each one representing one of the N-steps required to complete the configuration.
We had scheduled batches for each kind of step, basically selecting the records of the appropriate operation-type, and attempting to resolve each one (this allowed us to group the operation according to protocol, e.g. snmp or telnet, and also to define that some kind of operations should run only during night, or outside of peak office hours and so on.
We also scheduled a "meta-batch" which would periodically check every open "header" record, check if all the connected step-records were in "finished" state, and update the header status accordingly.
It scaled well enough, and allowed us to model different steps with a minimum of hassle. Full or partial "rollback" was easy, too - because for each step we had a concrete record showing if it had completed or not.
If I had to work on a similar problem today, I'd favour a state-machine based approach.
我同意@Prashant 的观点，即尝试将状态机模式与线程进行比较是有区别的。您当前如何使用线程配置设备？跟踪设备状态的长期要求是什么？设备的状态会随着时间的推移而改变吗？
换句话说，该配置是否是一次性工作，可以方便地推送到单独的线程上？如果您关心 CPU 的转换，尤其是在相对较长的时间内，状态机模式是帮助您对不同状态和可能的转换进行建模的工具。
您可以通过多种方式实现状态机。例如，您可以使用事件来触发转换，而某些静态变量则跟踪当前状态。您可以在一个单独的线程中执行此操作，该线程有一个大循环，其中有一个大 switch 语句。
我会问两个问题：
1）您如何对设备的状态进行建模？
2）该线程是否为您购买了任何特定于配置设备的东西？
I agree with @Prashant that trying to compare the State-Machine pattern with threading is apples and oranges. How do you currently configure the device withing the thread? What are the long-term requirements for tracking the state of the device and will the state of the device change over time?
In other words, is the configuration a one-shot effort in which it was convienent to push off onto a separate thread? If you care about the transitions, especially over a relatively long period of time, for a CPU, the State-Machine pattern is a tool to help you model the different states and the possible transitions.
You can implement a state-machine many ways. For example you can use events to trigger transitions while some static variable tracks the current state. You could do it in a separate thread which has a big loop with a large switch statement inside of it.
I would ask two questions:
1) How have you modeled the state of your device?
2) Does the thread buy you anything specific towards configuring the device?