Redis性能测试与建议

原文链接：https://www.cnblogs.com/mindwind/p/5067905.html
官方文档中也提到，在局域网环境下只要传输的包不超过一个 MTU （以太网下大约 1500 bytes），那么对于 10、100、1000 bytes 不同包大小的处理吞吐能力实际结果差不多。诚然，1k 基本是 Redis 性能的一个拐点。

残酷

Redis 是个好东西，提供了很多好用的功能，而且大部分实现的都还既可靠又高效（主从复制除外）。所以一开始我们犯了一个天真的用法错误：把所有不同类型的数据都放在了一组 Redis 集群中。长生命周期的用户状态数据
临时缓存数据
后台统计用的流水数据
导致的问题就是当你想扩分片的时候，客户端 Hash 映射就变了，这是要迁移数据的。而所有数据放在一组 Redis 里，要把它们分开就麻烦了，每个 Redis 实例里面都是千万级的 key。而另外一个问题是单个 Redis 的性能上限带来的瓶颈问题。由于 CPU 的单核频率都发展到了瓶颈，都在往多核发展，一个 PC Server 一般 24或32 核。但 Redis 的单线程设计机制只能利用一个核，导致单核 CPU 的最大处理能力就是 Redis 单实例处理能力的天花板了。举个具体的案例，新功能上线又有点不放心，于是做了个开关放在 Redis，所有应用可以很方便的共享。通过读取 Redis 中的开关 key 来判断是否启用某个功能，对每个请求做判断。这里的问题是什么？这个 key 只能放在一个实例上，而所有的流量进入都要去这个 Redis GET 一下，导致该分片实例压力山大。而它的极限在我们的环境上不过 4 万 OPS，这个天花板其实并不高。

总结

认识清楚了现实的残酷性，了解了你所在环境 Redis 的真实性能指标，区分清幻想和现实。我们才能真正考虑好如何合理的利用 Redis 的多功能特性，并有效规避的它的弱项，再给出一些 Redis 的使用建议：-根据数据性质把 Redis 集群分类；我的经验是分三类：cache、buffer 和 db
- cache：临时缓存数据，加分片扩容容易，一般无持久化需要。- buffer：用作缓冲区，平滑后端数据库的写操作，根据数据重要性可能有持久化需求。
- db：替代数据库的用法，有持久化需求。规避在单实例上放热点 key。
同一系统下的不同子应用或服务使用的 Redis 也要隔离开
另外，有一种观点认为用作缓存 Memcache 更合适，这里可以独立分析下其中的优劣取舍吧。Memcache 是设计为多线程的，所以在多核机器上单实例对 CPU 的利用更有效，所以它的性能天花板也更高。（见下图）要达到同样的效果，对于一个 32 核机器，你可能需要部署 32 个 Redis 实例，对运维也是一种负担。除此，Redis 还有个 10k 问题，当缓存数据大于 10k（用作静态页面的缓存，就可能超过这个大小）延迟会明显增加，这也是单线程机制带来的问题。如果你的应用业务量离 Redis 的性能天花板还比较远而且也没有 10k 需求，那么用 Redis 作缓存也是合理的，可以让应用减少多依赖一种外部技术栈。最后，搞清楚现阶段你的应用到底需要什么，是多样的数据结构和功能、更好的扩展能力还是更敏感的性能需求，然后再来选择合适的工具吧。别只看到个基准测试的性能数据，就欢呼雀跃起来了。

参考

[1] antirez. Redis Documentation.
[2] antirez. Clarifications about Redis and Memcached.
[3] antirez. Lazy Redis is better Redis.
[4] antirez. On Redis, Memcached, Speed, Benchmarks and The Toilet.
[5] antirez. An update on the Memcached/Redis benchmark.
[6] dormando. Redis VS Memcached (slightly better bench).
[7] Mike Perham. Storing Data with Redis.
[8] 温柔一刀. Redis 常见的性能问题和解决方法.