rest - ServiceStack Web 服务的存储转发故障转移解决方案

Question

我正在为 Northwest US 的回收中心链开发客户账户系统.我们的主要功能之一是我们的客户可以设置记入其 bottle deposit refunds 的帐户。 ，而不是总是支付现金。客户还可以将在现场处理并记入贷方的可回收袋子丢弃。每个中心都接近满负荷运行，并且可以在离线时物理处理 jar 头和瓶子，因此我们没有太多余地让 IT 基础设施在互联网中断时关闭一切。

基本上，我被要求开发一个客户账户系统，即使与我们的中央服务器的电信中断几个小时，也可以将零售中心的信用记入账户。这将使该中心能够在管道堵塞时继续处理和记入客户。某些交易，如取款，不需要在这种情况下发生，因为我们无法准确获取客户当前的余额。

我们是 100% Windows 商店，IT 经理和网络管理员不想接近任何 *nix。每个零售中心都有一个内部部署的专用 Windows Server，因此这似乎是一个合乎逻辑的起点。

我是 ServiceStack 的 super 粉丝，并且基于 REST-ful 消息的范例似乎可行。我会创建一条“Credit”消息并将其发送到本地服务器。那里的消息代理将记录请求并尝试将该消息转发到处理它的中央服务器。万一中央服务器出现故障，我会依靠 MQ 的可靠消息传递协议(protocol)来保留它，直到电信恢复。每个中心的总体预期消息量为 100 到 1,000 条，用现代计算术语来说太低了。

Redis MQ Client / Server ServiceStack 看起来很有趣，但由于 Windows Redis 服务器被明确标记为“原型(prototype)”和“非生产质量”，因此能够利用它的可能性为 0%。

所以，最终的问题是:

1. 可靠的消息传递系统是解决此问题的正确方法吗？我应该考虑其他方法吗？
2. 是否有能够很好地与 ServiceStack 配合使用的 Redis 替代品？是否有可以在 Windows 上使用的“生产质量”NoSQL 服务器替代品？
3. 我简要地了解了 RabbitMQ。这可能是一个选择吗？我的谷歌搜索没有显示它与 ServiceStack 之间有任何积极的集成，所以我对从头开始写一些东西持怀疑态度。
4. 理想情况下，我的解决方案的开销足够低，如果一切正常，我们可以执行同步更新并向客户返回“当前余额”收据。这是现实吗？

Answer 1

在 Windows 上运行 Redis 的生产解决方案是 run redis-server inside a Linux VM on windows with Vagrant .

当前有一个feature request to add more MQ Options到服务堆栈。 Rabbit MQ 有望成为 future 支持的下一个 MQ 适配器。