Redis被廣泛使用的一個很重要的原因是它的高性能。因此我們必要要重視所有可能影響Redis性能的因素、機制以及應對方案。影響Redis性能的五大方面的潛在因素，分別是：
這一講，我們來學習一下CPU對Redis的性能影響及應對方法。
主流CPU架構
學習之前，我們先來了解主流CPU架構有哪些，有什么特點，以便我們更好地了解CPU是如何影響Redis的。
CPU多核架構
- 一個CPU處理器中一般有多個運行核心，稱為物理核。
- 物理核包括私有的一級指令/數據緩存（L1緩存）和二級緩存（L2緩存）。
- 每個物理核會運行兩個超線程，也叫作邏輯核。同一個物理核的邏輯核會共享使用L1、L2緩存。
- 不同的物理核共享三級緩存（L3緩存）
多CPU Socket架構
在多CPU架構上，應用程序可以在不同的處理器上運行。
應用程序在不同的Socket間調度運行時，訪問之前的Socket的內存，這種訪問屬於遠端內存訪問。
和訪問Socket直接連接的內存相比，遠端內存訪問會增加應用程序的延遲。
把這個架構稱為非統一內存訪問架構（Non-Uniform Memory Access，NUMA架構）。
CPU多核對Redis性能的影響
如果在CPU多核場景下，Redis實例被頻繁調度到不同CPU核上運行的話，那么，對Redis實例的請求處理時間影響就更大了。每調度一次，一些請求就會受到運行時信息、指令和數據重新加載過程的影響，這就會導致某些請求的延遲明顯高於其他請求。
要避免Redis總是在不同CPU核上來回調度執行。最直接的方法是把Redis實例和CPU核綁定了，讓一個Redis實例固定運行在一個CPU核上。
通過taskset命令進行綁核：
taskset -c 0 ./redis-server
綁核不僅對降低尾延遲有好處，同樣也能降低平均延遲、提升吞吐率，進而提升Redis性能。
CPU的NUMA架構對Redis性能的影響
在實際應用Redis時，有一種做法：為了提升Redis的網絡性能，把操作系統的網絡中斷處理程序和CPU核綁定。
在CPU的NUMA架構下，當網絡中斷處理程序、Redis實例分別和CPU核綁定后，就會有一個潛在的風險：如果網絡中斷處理程序和Redis實例各自所綁的CPU核不在同一個CPU Socket上，那么，Redis實例讀取網絡數據時，就需要跨CPU Socket訪問內存，這個過程會花費較多時間。
為了避免Redis跨CPU Socket訪問網絡數據，我們最好把網絡中斷程序和Redis實例綁在同一個CPU Socket上，這樣一來，Redis實例就可以直接從本地內存讀取網絡數據了。
CPU的NUMA架構下進行綁定要注意CPU核的編號規則，可以執行lscpu命令來查看核的編號。
lscpu Architecture: x86_64 ... NUMA node0 CPU(s): 0-5,12-17 NUMA node1 CPU(s): 6-11,18-23 ...
不過，凡事都有兩面性，綁核也存在一定的風險。接下來就來了解下它的潛在風險點和解決方案。
綁核的風險和解決方案
方案一：一個Redis實例對應綁一個物理核
在給Redis實例綁核時，我們不要把一個實例和一個邏輯核綁定，而要和一個物理核綁定，也就是說，把一個物理核的2個邏輯核都用上。
方案二：優化Redis源碼
通過修改Redis源碼，把子進程和后台線程綁到不同的CPU核上。