当没有消费者准备好时处理生产者线程
关于处理以下场景的模式的建议：
将事件分派给消费者的单个线程。每个事件和消费者之间存在 1:1 的关系（每个事件根据事件/消费者 ID 匹配分派给单个消费者）。
消费者以不同的速度处理事件，并且可以以可配置的批量大小消费事件（例如，消费者一次可以消费 20 个事件）。
生产者线程应该始终能够将事件分派给能够消费的消费者。每个消费者维护一个它已消费的事件队列（可能是批量）并在自己的线程上处理这些事件，因此从生产者到消费者的切换是异步的。
如果任何时间点都没有消费者可以消费，那么调度线程会发生什么情况？
yield()它wait()& 调用notify()- 强制消费者在固定的时间段内
sleep()是否
有理由选择其中之一？
一些优点和缺点缺点：
- yield 很简单，
- 强制消费者调用通知会增加复杂性，
- 固定时间的睡眠将适合非时间敏感的要求，
- 旋转会消耗 CPU，除非我们需要尽可能快的事件传递，否则没有必要
。还有其他考虑因素吗？
Suggestions on patterns for handling the following scenario:
A single thread that dispatches events to consumers. There is a 1:1 between each event and a consumer (each event is dispatched to a single consumer based on event/consumer id match).
Consumers process events at varying speeds and can consume events in configurable batch sizes (e.g. a consumer could consume 20 events at a time).
The producer thread should always be able to dispatch events to consumers that are capable of consuming. Each consumer maintains a queue of events it has consumed (possibly in batch) and processes these on its own thread, so the hand-off from producer to consumer is asynchronous.
If no consumers can consume at any point in time, what should happen to the dispatch thread?
yield()itwait()& force consumers to callnotify()on itsleep()for a fixed time period- spin
Any reason to prefer one over the other?
Some pros & cons:
- yield is simple
- forcing consumers to call notify adds complexity
- sleep for a fixed time would suit for non time sensitive requirements
- spinning eats up a CPU, unnecessary unless we need as fast as possible event delivery
Any other considerations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您应该考虑的另一种方法是将其写入
BlockingQueue。让队列管理在没有侦听器的情况下发送的请求。更好的是：编写一个拥有
BlockingQueue并维护Consumers的List的Broker。当Producer发送新的Event时，让Broker通知Consumers的List。我将使用自 JDK 1.0 以来内置于 Java Bean 中的
PropertyChangeListener和EventObject在内存中执行此操作。Another way you should consider would be writing it to a
BlockingQueue. Let the queue manage requests sent without listeners.Even better: write a
Brokerthat owns aBlockingQueueand maintains aListofConsumers. Have theBrokernotify theListofConsumerswhen aProducersends a newEvent.I'd use the
PropertyChangeListenerandEventObjectbuilt into Java Beans since JDK 1.0 to do this in memory.a) 您可以选择
yield，但根据环境的好坏，这实际上可能会变成无操作。所以这基本上会产生与旋转相同的结果。b) 睡眠是一个简单的选择，但你应该想出睡多长时间。执行
sleep(0)也无济于事，因为它与执行 (a) 相同。通知的力量更复杂，但您可以完全控制流程。
a) You could choose
yieldbut depending on how good the environment is, this could essentially become a no-op. So this would essentially have the same result as spinning.b) Sleep is an easy choice but then you should come up with how long to sleep. Doing
sleep(0)also will not help as it will be same as doing (a)The force of notification is more complicated but you have complete control of your flow.
查看 JMS。 JMS 正是为处理此类用例而设计的。
在您的场景中，全面的 JMS 安装可能有点过分 – 您没有提供足够的信息。
Take a look at JMS. JMS is designed to handle exactly this kind of use case.
A full scale JMS installation might be overkill in your scenario – you don't provide enough information.