带有订户缓存的WCF Pub / Sub
问题：如何使用WCF提供分布式，可扩展和抗灾的发布/订阅服务。
细节：
请注意，除了消息/中间件解决方案（如Tibco EMS）之外，还考虑采用此方法。
我一直在研究WCF，特别是它如何用于提供pub / sub。 关于这个主题，这篇文章非常好： WCF pub-sub 。
在文章中，作者试图解决拥有多个发布者的问题（就像在几个框中扩展服务层一样）。 问题是如果客户端A向发布者A注册但发布者B希望发布事件，则发布者B将不知道客户端A.即没有人告诉发布者B客户端A想要被通知事件。 作者建议将pub / sub服务作为解决方案。 发布/订阅服务将集中存储订阅。 但是，如果我想通过二级/双发布/订阅服务使pub / sub服务具有抗灾能力，那么我就有了同样的原始问题。
所以，我认为这个问题有几个解决方案：
- 将订户详细信息存储在分布式缓存中（请参阅问题： q1和q2 ）。
- 将订户详细信息存储在数据库/中央文件系统中。
任何人都可以想到任何其他解决方案（即我没有错过WCF的一些奇妙的神奇function？）任何评论赞赏。
我有同样的问题，我在这个问题上做了很多研究。 问题其实很简单。 您希望保持一些集中状态，但是采用分布式方式。 我发现实现这一目标的最佳方法是使用分布式缓存。 以速度为例。 我知道没有可以解决状态管理问题的本机WCF解决方案。 我甚至研究过持久服务，其中状态管理由WCF处理，但不适用于发布/订阅服务，因为状态需要集中在所有客户端连接上。 将数据存储在数据库中也是一种选择，但成本是对数据库的需求，即使数据库中存在单点故障，如果数据库未集群也可能存在多个计算机。
最后，我认为实现零点故障实际上是昂贵的，如果你决定去那里看看Azure，存储的未来在云上，Azure服务将完全可扩展和分布，但我们还没有。
我认为WCF还没有。 您需要的是一个代理处理所有这些细节，以便您可以实现业务逻辑。 像ActiveMQ那样有一些非常好的。 如果您需要编排，那么您可能想要使用也可以坐在经纪人之上的公共汽车。 我认为WCF很精彩，但是尝试将它变成不是的东西，这不是一个好主意。