2

我一直在成功使用 ServiceStack PooledRedisClientManager。我现在将 Twemproxy 添加到组合中，并在单个 Ubuntu 服务器上运行 4 个 Redis 实例，前面是 Twemproxy。

这导致通过 ServiceStack 连接到 Redis 的轻负载测试（100 个用户）出现问题。我已经尝试过原始的 PooledRedisClientManager 和 BasicRedisClientManager，两者都给出错误No connection could be made because the target machine主动拒绝它

我需要做些什么才能让这两个一起玩得很好吗？这是 Twemproxy 配置

alpha:
  listen: 0.0.0.0:12112
  hash: fnv1a_64
  distribution: ketama
  auto_eject_hosts: true
  redis: true
  timeout: 400
  server_retry_timeout: 30000
  server_failure_limit: 3
  server_connections: 1000
  servers:
   - 0.0.0.0:6379:1
   - 0.0.0.0:6380:1
   - 0.0.0.0:6381:1
   - 0.0.0.0:6382:1

我可以单独连接到每个 Redis 服务器实例，它只是通过 Twemproxy 失败。

4

1 回答 1

2

我以前没有使用过 twemproxy，但我会说你的服务器列表是错误的。我不认为你使用0.0.0.0正确。

您的服务器需要（用于本地测试）：

servers:
 - 127.0.0.1:6379:1
 - 127.0.0.1:6380:1
 - 127.0.0.1:6381:1
 - 127.0.0.1:6382:1

您使用0.0.0.0onlisten命令告诉 twemproxy侦听服务器上所有可用的网络接口。这意味着 twemproxy 将尝试监听：

  • 环回地址 127.0.0.1 (localhost),
  • 在您的私有 IP（即 192.168.0.1）和
  • 在您的公共 IP（即 134.xxx.50.34）上

当您指定服务器时，服务器配置需要知道它应该连接的实际地址。0.0.0.0没有意义。它需要一个真正的价值。所以当你开始使用不同的 Redis 机器时，你会想要使用每台机器的私有 IP，如下所示：

servers:
 - 192.168.0.10:6379:1
 - 192.168.0.13:6379:1
 - 192.168.0.14:6379:1
 - 192.168.0.27:6379:1

显然您的 IP 地址会有所不同。您可以使用ifconfig来确定每台机器上的 IP。尽管如果您的 IP 不是静态分配的，那么使用主机名可能是值得的。

更新：

正如您所说，您仍然遇到问题，我将提出以下建议：

  1. 删除auto_eject_hosts: true. 如果您获得了一些连接，那么一段时间后您最终没有连接，这是因为某些事情导致 twemproxy 认为 Redis 主机有问题并拒绝它们。

    因此，最终当您的 ServiceStack 客户端连接到 twemproxy 时，将没有主机可以将请求传递到并且您会收到错误消息No connection could be made because the target machine actively refused it。

  2. 您实际上是否有足够的 RAM 来以这种方式对本地计算机进行压力测试？您正在运行至少 4 个 Redis 实例，这些实例需要真实内存来存储值，twemproxy 会消耗大量内存来缓冲它传递给 Redis 的请求，此内存池永远不会释放，请参阅此处了解更多信息。您的 ServiceStack 应用程序将消耗内存——在调试模式下更是如此。您可能会打开 Visual Studio 或其他 IDE、压力测试应用程序和操作系统。最重要的是，您可能还没有关闭后台进程和其他应用程序。

    一个好的做法是尽可能在隔离的硬件上运行测试。如果不可能，则必须监视系统以检查基准是否受到某些外部活动的影响。

    您应该在此处阅读有关基准测试的Redis 文章。

  3. 当您在某种localhost情况下使用它时，请使用BasicRedisClientManagernot PooledRedisClientManager。

于 2014-01-25T09:09:51.970 回答