我们正在运行一个 Web 应用程序并从 memcached 切换到 redis (2.4) 进行缓存。现在我们对redis的性能有些失望。Redis 在同一台服务器上运行，我们只使用非常简单的 GET 和 SET 操作。在一些大量使用缓存值的请求上，我们有多达 300 个对 redis 的 GET 请求，但这些请求最多需要 150 毫秒。我们有大约 200,000 个活动密钥，每秒大约有 1,000 个 redis 请求。磁盘 io、ram 或 cpu 没有问题。由于我们现有的代码，我们不能简单地将 redis 请求组合在一起。Memcached 的速度提高了大约 4 倍。我们喜欢 redis 的地方在于，我们不需要任何缓存预热，并且将来可以使用更高级的数据存储功能。我们希望 redis 的性能类似于 memcached。所以也许我们在配置中遗漏了一些东西，
你知道redis性能调优的最佳实践吗？
首先，您可能想阅读Redis 基准页面。它很好地总结了调整 Redis 的要点。
即使假设您不使用流水线，150 毫秒内 300 次 GET 也不是那么有效。这意味着平均延迟为 500 us。但是，它实际上取决于对象的大小。更大的对象，更多的延迟。在我非常旧的 2 GHz AMD 机器上，我可以测量小对象（几个字节）的 150 us 延迟。
要快速检查 Redis 实例的平均延迟，您可以使用：
$ redis-cli --latency
请务必使用最新的 Redis 版本（不是 2.4）来获取此选项。注意：现在 2.4 已经很老了，使用 Redis 2.6 - 如果需要，编译你自己的 Redis 版本，真的很简单。
要快速运行基准测试来研究延迟，您可以启动：
$ redis-benchmark -q -n 10000 -c 1 -d average_size_of_your_objects_in_bytes
它以独特的连接运行，没有流水线，因此可以从吞吐量中推断出延迟。尝试将这些基准测试的结果与您的应用程序测量的数据进行比较。
您可能需要检查以下几点：
为什么使用 memcached 更好？好吧，单个 memcached 实例肯定更具可扩展性，并且可能比单个 Redis 实例响应更快，因为它可以在多个线程上运行。Redis 速度很快，但是是单线程的——所有命令的执行都是序列化的。因此，当一个命令正在进行连接时，所有其他客户端都必须等待 - 给定命令的不良延迟也会影响所有待处理的命令。通常，在低吞吐量下，性能是相当的。
在 1000 q/s（Redis 或 memcached 标准的低吞吐量），我会说您的问题更有可能出现在客户端（即客户端库的选择、连接/断开连接等......），而不是Redis 服务器本身。
最后我要提一下，如果您为每个 HTTP 请求生成多个 Redis 查询，请考虑尽可能将您发送到 Redis 的命令流水线化。开发高效的 Redis 应用程序确实是一个关键点。
如果您的应用程序服务器与 Redis 在同一个机器上，您还可以使用 unix 域套接字而不是 TCP 环回连接到 Redis。它略微提高了性能（不使用流水线时吞吐量提高了 50%）。
检查 redis 是否正在使用操作系统交换内存。如果是这样，那将增加延迟。要找出答案，请在此处搜索“由交换引起的延迟”：http ://redis.io/topics/latency
如果您的服务器硬件支持 NUMA，最好使用 numactl 启动 redis-server。如果您从带有 NUMA 的 redis-server 开始，请不要忘记在 sysctl 中关闭区域回收模式 (vm.zone_reclaim_mode=0)。
尝试在 Lua 脚本中编写 300 GET 请求。它应该工作得更快，因为即使您的客户端代码在本地运行到 Redis，您也可以节省接触 TCP/IP 堆栈的时间。