Redis默认配置下怎么才能把访问性能压榨到极限，顺便聊聊默认访发量那些事儿

想把Redis在默认配置下的性能压榨到极限，首先得明白一个核心概念：Redis本身就是一个“速度狂魔”，它的性能瓶颈往往不在它自己身上，而在我们怎么用它，以及它所在的运行环境，默认配置已经为大多数场景提供了一个相当不错的起点，但要想触及极限，我们需要在“默认”的框架内,把能做的事情做到极致。

第一，硬件和操作系统是地基，这里省不了。

根据Redis官方文档（Redis documentation）的精神，CPU、内存、网络是三大关键，虽然说是默认配置，但如果你用的是一台老爷机,那再怎么优化也白搭。

• CPU：Redis是单线程处理命令的（这里指核心网络请求和数据处理），所以高频CPU比多核CPU更重要，把它绑定在同一个CPU插槽的单个核心上运行，可以减少上下文切换带来的损耗，这点在默认配置下可以通过启动命令taskset来手动优化，虽然不是Redis.conf里的配置,但属于环境调优。
• 内存：速度要快，别把钱省在内存上，快的内存条直接决定Redis存取数据的速度，确保操作系统没有开启巨大的交换分区（swap），一旦Redis的数据被挤到硬盘上，性能会呈断崖式下跌，你可以通过sudo swapoff -a命令关闭swap,但这需要评估系统整体内存风险。
• 网络：这是最容易被忽视的“暗伤”，网络带宽和延迟至关重要，如果客户端和Redis服务器之间网络状况不佳，动不动就丢包、延迟高，那Redis内部处理再快也没用，尽量让客户端和Redis服务器在同一个局域网内，或者使用高质量的内网通信，对于云服务,选同可用区的实例能极大降低网络延迟。

第二，客户端的使用方式是关键，乱用会直接把Redis“堵死”。

Redis官方文档和其创始人Antirez的博文（Antirez blog）多次强调,滥用客户端是性能杀手之首。

• 管道（Pipeline）是王牌：默认配置下，提升吞吐量的最有效手段就是使用管道，简单说，就是客户端把一堆命令打包，一次性发给Redis，然后一次性读取所有回复，这避免了每个命令都经历“网络往返时间”，对于需要连续执行多个写操作或非关联读操作的场景，管道能将性能提升数倍甚至数十倍，但要注意，管道内的命令数量也不能无限制，一般建议每批几百到几千个,需要自己测试找到甜点。
• 避免“巨无霸”Key和Value：一个Key对应的Value值太大，比如一个List里面塞了几十万个元素，或者一个String值有几百KB，会在序列化、反序列化、网络传输时产生严重延迟，这就像一辆大卡车堵在单行道上，后面的小车都过不去,要把大数据拆成更小的片段。
• 警惕慢查询：KEYS * 这种命令在数据量大的时候是灾难性的，它会遍历所有键，导致Redis假死，默认配置下，可以用SLOWLOG命令来监控哪些命令执行得慢，然后优化业务逻辑，比如用SCAN命令替代KEYS。
• 连接池：为每个请求都创建和断开连接的成本极高，一定要使用连接池来复用连接，这是客户端库应该做好的事情,但你需要确保正确配置了连接池的大小。

第三，聊聊“默认访问量那些事儿”

你问默认访问量，这其实没有标准答案，因为它完全取决于上面提到的所有因素,但我们可以给一些感性的认知。

在理想的实验室环境下（高性能硬件、本地回环网络、使用管道、处理简单的SET/GET命令），一个单核Redis实例每秒可以处理几十万甚至上百万次请求，这听起来很吓人,但这只是理论极限。

在实际生产环境的“默认配置”下，一个更现实的、能够稳定运行的峰值吞吐量可能在几万到十几万QPS（每秒查询次数）之间,这个数字会受到以下事情的严重影响：

1. 命令复杂度：你是在做简单的GET/SET，还是在做复杂的集合运算（如求交集SINTER）？复杂度为O(N)的命令，N越大,耗时越长。
2. 数据大小：传输1KB的数据和传输100字节的数据,网络和序列化开销完全不同。
3. 读写比例：写的操作通常比读的操作要稍微重一些。
4. 是否使用管道：这可能是影响最大的因素，不用管道和合理使用管道,性能可能差一个数量级。

不要纠结于一个具体的“默认”数字，而应该关注如何通过优化客户端使用方式（尤其是管道）和保障运行环境（网络、内存），来让你自己的业务系统逼近Redis在你硬件上的极限，最好的方法就是模拟真实业务场景进行压测，用redis-benchmark工具只是一个起点，用自己的业务代码和数据进行测试，才能得到最有价值的性能数据，当你发现性能上不去时，首先检查网络延迟，其次检查是否用了管道，最后用SLOWLOG看看有没有慢查询,基本上就能找到瓶颈所在。