Redis的性能在一定程度上会受到服务器CPU的多核架构影响。
CPU多核架构
一台计算机的处理器部分，在设计的时候有几种选择：多个单核CPU和单个多核CPU。举个例子1个8核的处理器，可以有如下设计选择：
- 把8个核全部做到一个大Die上，Die很大。这个Die加上一些外围电路组成一个单Die多核CPU。
- 弄4个小Die，每个Die 2个内核，每个Die很小。把这4个Die，加上互联总线和外围电路，全部封装（Packaging）到一个多Die多核CPU中。
- 还是弄4个Die，每个Die 2个内核，每个Die很小。每个Die加上外围电路封装成一个单独的CPU，4个CPU再通过总线组成一个多路(way/socket)系统。
性能上，大Die多核的处理器性能最好，同样造价最昂贵。
下面针对单Die多核的情况进行说明。
我们把一个运行核心看作一个物理核，一个物理核可以处理一个程序，每个物理核都拥有私有的一级缓存（一级指令+数据缓存），二级缓存，多个物理核可以共享一个三级缓存。
另外，现在主流的CPU处理器，每个物理核还可以通过超线程模拟两个逻辑核，因此两个逻辑核共享一级和二级缓存。整个关系可以表示如下：
如果服务器上的CPU设计采用开始例子中的第三种设计模式，则服务器上会存在多个CPU Socket，每个CPU都有自己的物理核核内存，不同处理器之间通过总线连接。
在多CPU架构上，应用程序在运行过程中，可能由于调度问题，运行在不同的处理器上。
跨socket进行内存访问要比直接访问本socket直连的内存增加延迟。
因此，我们可以总结出多核架构对应用程序运行的影响：
- 充分利用一级缓存和二级缓存，可以有效缩短应用程序的执行时间。
- 远端内存访问会增加执行延时。
Redis多核影响
对应到Redis上来说：
Redis的实例如果被频繁调度到不同的CPU上，就会影响请求处理延时。因为每次调度都需要重新加载运行时信息、指定和数据。
针对这种场景，我们可以尝试讲Redis实例和固定的CPU核进行绑定。
同时，我们考虑到Redis接收网络请求，网络中断程序是需要核Redis实例进行数据交互的，而
网络中断程序也可以通过绑定CPU来避免在不同的内存上切换造成的开销，提升网络处理性能。
此时，我们就要注意：
如果网络中断程序和Redis实例绑定的CPU核不在同一个CPU Socket上，那么Redis实例读取网络数据时，就需要跨CPU Socket进行内存访问，开销较大。