请帮我设计一下这个事件报告系统

时间:2011-06-30 13:38:07

标签: c# .net architecture fault-tolerance

我正在尝试设计一个系统,通过Web服务将活动事件报告给数据库。 Web服务和数据库已经建立(COTS软件) - 我所要做的就是提供事件源。

但问题是,事件源需要具有容错能力。我有多个可以与之交谈的复制数据库,所以如果我正在谈论的Web服务或数据库发生故障,软件可以快速切换到另一个正在运行的数据库。

我需要帮助的是所有数据库都关闭的情况。我已经设计了一个队列,当它们堆积在一起时会保留事件(并在连接恢复后突然爆发),但是队列是一个内存结构:如果我的应用程序在这种状态下崩溃,或者如果电力丢失等,然后队列中的所有事件都将丢失。这是无法接受的。我需要的是一种持久化事件的方法,以便当数据库重新联机时,即使在断电或崩溃的情况下,我也可以发送一连串的排队事件。

我知道我不想重新实现队列本身以将文件系统用作后备存储。这会起作用(我已经尝试过了) - 但随着硬盘成为瓶颈,这种方法会大大降低系统速度。除此之外,我想不出设计这个系统的单一方法,只有当无法访问数据库时,所有事件才安全地存储在硬盘驱动器上。

有没有人有任何想法? =)

3 个答案:

答案 0 :(得分:0)

当我需要具有容错功能的消息传递(和/或保证传送,基于您的描述我猜你也需要)时,我通常会转向MSMQ。它提供容错功能(在机器重启的情况下消息存储在磁盘上)和保证传送(消息将自动并连续重新发送,直到收到它们),以及事务发送和接收,消息日志记录,毒物消息处理和其他特征

我已经能够使用MSMQ实现每秒数千条消息的吞吐量。坦率地说,我不确定在保持容错的情况下,你会比这更好。

答案 1 :(得分:0)

MSMQ。我想你也可以看一下Job object的概念。

答案 2 :(得分:0)

我同意那些最好使用开箱即用系统的人,比如MSMQ,手头有一套信息模式。

无论如何,如果你必须自己做,你可以在内存数据库中使用而不是自己序列化数据,我相信它应该更快。