请帮我设计这个事件报告系统
我正在尝试设计一个通过网络服务向数据库报告活动事件的系统。 Web 服务和数据库已经构建（COTS 软件） - 我所要做的就是提供事件源。
但问题是事件源需要具有容错能力。我们有多个可以与之通信的复制数据库，因此，如果我正在通信的 Web 服务或数据库出现故障，该软件可以快速切换到另一个可用的数据库。
但我需要帮助的是所有数据库都关闭的情况。我已经设计了一个队列，它将在事件堆积时保留它们（并在连接恢复后将它们突发出去），但队列是内存中结构：如果我的应用程序在此状态下崩溃，或者如果断电等，那么队列中的所有事件都会丢失。这是不可接受的。我需要一种保存事件的方法，以便当数据库重新联机时，即使在断电或崩溃的情况下，我也可以发送大量排队的事件。
我知道我不想重新实现队列本身以使用文件系统作为后备存储。这是可行的（我已经尝试过） - 但随着硬盘驱动器成为瓶颈，该方法会显着减慢系统速度。除此之外，我想不出一种单一的方法来设计这个系统，以便仅当无法访问数据库时所有事件才安全地存储在硬盘上。
有人有什么想法吗？ =)
I'm trying to design a system which reports activity events to a database via a web service. The web service and database have already been built (COTS software) - all I have to do is provide the event source.
The catch, though, is that the event source needs to be fault tolerant. We have multiple replicated databases that I can talk to, so if the web service or database I'm talking to goes down, the software can quickly switch to another one that's up.
What I need help with though is the case when all the databases are down. I've already designed a queue that will hold on to the events as they pile in (and burst them out once the connection is restored), but the queue is an in-memory structure: if my app crashes in this state, or if power is lost, etc., then all the events in the queue are lost. This is unacceptable. What I need is a way to persist the events so that when a database comes back online I can send a burst of queued-up events, even in the event of power loss or crash.
I know that I don't want to re-implement the queue itself to use the file system as a backing store. This would work (and I've tried it) - but that method slows the system down dramatically as the hard drive becomes a bottleneck. Aside from this though, I can't think of a single way to design this system such that all the events are safely stored on the hard drive only when access to the database isn't available.
Does anyone have any ideas? =)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当我需要具有容错功能的消息传递（和/或保证交付，根据您的描述，我猜您也需要）时，我通常会转向 MSMQ。它提供容错（消息存储在磁盘上，以防机器重新启动）和有保证的传送（消息将自动持续重新发送，直到收到），以及事务发送和接收、消息日志记录、有害消息处理等特征。
我已经能够使用 MSMQ 实现每秒数千条消息的吞吐量。坦率地说，我不确定你会在保持容错的同时得到比这更好的结果。
When I need messaging with fault tolerance (and/or guaranteed delivery, which based on your description I am guessing you also need), I usually turn to MSMQ. It provides both fault tolerance (messages are stored on disk in case of machine restart) and guaranteed delivery (messages will automatically and continually resend until they are received), as well as transactional sends and receives, message journaling, poison message handling, and other features.
I have been able to achieve a throughput of several thousand messages per second using MSMQ. Frankly, I am not sure that you will get too much better than that while still being fault tolerant.
msmq。我想你也可以看看 作业对象。
msmq. I think you could also take a look at the notion of Job object.
我同意那些最好使用开箱即用的系统（例如 MSMQ）并拥有一组消息传递模式的观点。
不管怎样，如果你必须自己做，你可以使用内存数据库而不是自己序列化数据，我相信它应该足够快。
I would agree with guys that better to use out of the box system like MSMQ with a set of messaging patterns in hand.
Anyway, if you have to do it yourself, you can use in memory database instead of serializing data yourself, I believe it should be faster enough.