今天来分析下CPU结构对Redis性能会有影响吗？

在进行Redis性能分析的时候，通常我们会考虑下面这些方面，如：

　　1. 缩短 key 的长度

　　2. 禁止使用 keys *

　我们都知道 keys *， 在使用的时候 Redis 会处于阻塞状态，导致其它任何命令在你的 Redis 实例中都无法执行。这个情况在 Redis 数据量大的时候就很明显，严重影响系统的运行。（一般我们用 scan 来代替）

　　3. 进行数据压缩

　　在把数据存入 Redis 中，我们一般不会使用完整全名的数据，一般会进行适当的数据压缩，这样可以提高 Redis 性能，方便我们数据的储存。

　　4. 设置过期时间

　　我们对一些不是永久性需要的数据，可以进行键的过期时间设置，这样到时间后，数据就会自动清除，节省我们 Redis 存储空间（内存）。

　　5. 使用回收策略

　　为数据设置相关的过期回收策略，节省内存的开销，提高 Redis 运行的性能。（ Redis 目前有8种回收策略，有兴趣可以查看 redis.conf ，多了LFU）。

　　6. 适当使用 bit （位图）

　　适当使用 bit，可节省我们 Redis 存储的成本，即内存的大小。

　　7. 对所存储的数据字段进行优化

　　如：我们只需要在 Redis 存储关键信息即可，详细信息存储到磁盘上即可。

　　8. 使用管道进行数据操作

　　对于命令执行操作，我们要使用管道 pipeline，这样可以节省 Redis 传输过程的成本，提高 Redis 的性能。我们知道如果不适用管道，命令是一个一个进行操作，如果我们加上管道，这样由原来的单条命令变成多条命令进行传输操作，节省多次传输过程的网络开销。

　　N .... (还有很多很多~~)



但是，我们可能有时候会真正忽略 Redis 运行的前提条件，单核 CPU 和多核 CPU 对 Redis 性能影响也是相差甚远。在计算机组成原理中，我们都知道 CPU 是计算机的核心构成之一，中央处理器（Central Processing Unit），是计算机系统的运算和控制中心。一个CPU处理器中一般包含有多个运行核心（物理核），运行核心我们也叫作物理核，一般包含一级缓存（L1 Cache）和二级缓存（L2 Cache）。其架构图如下所示：

对于 L1 缓存和 L2 缓存，在每个物理核上都是独自拥有的，访问速度非常快，基本都在 ns 级别。我们设想如果把数据运行的指令放在这两个缓存上，那么可以大大提高计算机的访问性能。这样我们可以设想这样一个情形：

　　如果，我们把 Redis 实例的数据和指令绑定到一个 CPU 核上，那么当 Redis 频繁执行数据访问和操作时，都是基于CPU 上的缓存进行操作，那么性能是不是大大的提高了，没错，事实就是如此。但是，我们电脑一般都是多核 CPU 的，在进行数据访问和操作时，系统不会只有一个线程在进行操作，是有很多很多的线程在同时进行操作，会同时操作我们的CPU，也就是我们所说的多线程操作CPU。如果一个线程此时在CPU1上运行，后来又跑到了CPU2上运行，这时在CPU1上保留的数据和指令不在CPU2，这时要重新进行数据加载，会降低线程执行的效率，上述所发生的过程，我们也叫作上下文切换，这在操作系统内核环境下，是很常见的现象。

　　所以，我们要避免线程来回在CPU上进行切换，导致指令和数据进行多次加载，增加锁处理的时间。我们从CPU结构出发，如果在多核CPU上，如果我们的每个Redis实例都只在一个CPU上运行的话，那么我们离解决问题的步伐是不是又更近了一步。（问题都是一步一步的剖析，慢慢解开其真容(*╹▽╹*)）。

对相关进程进行绑定，我们可以使用 taskset ：

　　taskset 是依据线程PID（TID）查询或设置线程的CPU亲和性（Affiliation）（与哪个CPU核心绑定）。

如果有伙伴们不知道 taskset 如何使用，没关系，可以使用 man 或者 help 手册进行查看相关参数使用（ man taskset 或 taskset -h ）。在进行绑定的时候，我们要知道自己机器的CPU的核数（ cat /proc/cpuinfo ），以方便我们准确的进行CPU绑定，不会说不知道自己CPU核数随便绑定一个超过自己CPU核数的数。

例子：假如我们要绑定CPU0这个CPU核，那么命令如下：

taskset -c 0 ./redis-server
这时，我们可以通过 Redis 的压测工具进行相关测试 redis-benchmark

例如：对 GET 、PUT 和 SET 进行测试：