SignalR.Redis 和 ServiceStack.Redis 在同一个 Web 应用程序中答案

【问题标题】：SignalR.Redis and ServiceStack.Redis in the same web appSignalR.Redis 和 ServiceStack.Redis 在同一个 Web 应用程序中
【发布时间】：2013-03-30 08:16:44
【问题描述】：

我在我的 Web 应用程序中使用 SignalR.Redis 和 ServiceStack.Redis。我注意到 SignalR.Redis 使用 Booksleeve redis 客户端，当然 ServiceStack.Redis 有自己的客户端代码。

可以在同一个项目中同时使用这两种方法吗？显然它会起作用，但似乎从同一个应用程序使用多个 redis 客户端（以及因此多个 redis 连接）可能是一个不好的做法。我应该实现一个使用 ServiceStack.Redis 客户端的 SignalR 背板，这样我的所有代码都使用同一个客户端还是没关系？

由于 ServiceStack.Redis 不像 Booksleeve 那样是异步客户端，因此 SignalR 的 ServiceStack.Redis 背板是否也能正常工作？

【问题讨论】：

标签： redis servicestack signalr

【解决方案1】：

在同一个代码库中不使用 ServiceStack.Redis 和 Booksleeve 没有技术问题，每个都只是将自己的（非常轻量的）tcp 套接字连接封装到后端 redis 服务器，没有代码共享或状态突变图书馆之间。

【讨论】：

为 SignalR 编写一个 ServiceStack.Redis 后端看起来相当简单。您是否认为 ServiceStack.Redis 客户端可能会导致 SignalR 中的可伸缩性问题，因为它不是异步客户端？
另外，我知道不存在任何技术问题，他们将毫无问题地协同工作。但我的问题更多，如果他们都使用同一个客户端会更好吗？创建一个新的 SignalR 后端值得麻烦吗？
值得麻烦吗？是主观的，即你会得到什么？看起来它不会有太大的增值作用，只是减少了 1 个外部依赖。
我想我只是认为打开较少的 TCP 连接会是一件好事，但很明显，您根本不认为这是一个问题，我应该继续前进，嗯？
你不会有更少的开放 tcp 连接，它们只是由不同的库管理。如果这样做很简单，那么使用这两个库可能是一个很好的学习练习，只是从技术上讲，我看到的唯一好处是减少了需要管理的外部依赖。我们还在同一个项目中同时使用 ServiceStack.Redis 和 Booksleeve，两者都没有摩擦。