前言

redis在最近的版本中，開始了對多執行緒的支援。加上之前對多程序的支援，模型的複雜度也比過去複雜了不少。

redis本身又是一個對效能、延遲非常敏感的業務，多種因素都可能導致小問題。基於上述原因，作者對redis做了CPU親和性的系統支援，併合入了upstream。

分析程式碼

Redis 6.0.2版本中開始支援綁核操作，參考release note

https://github.com/redis/redis/commit/ae306a3df6cf63b31a0814cb5393a9df59947d2e

或者手工合入patch

https://github.com/redis/redis/commit/1a0deab2a548fa306171f03439e858c00836fe69

在redis.conf中可以配置

server_cpulistbio_cpulistaof_rewrite_cpulistbgsave_cpulist

引數配置和taskset命令一致。配合和上述的commit中類似，或者參考redis.conf。

哪幾種情況下綁核會有收益大規格伺服器上多個redis例項共同部署的場景下，多個redis程序之間，存在一定的競爭，尤其是比較隱性的競爭。例如，一般的intel的CPU都會開啟超執行緒（Hyper Thread），兩個HT之間，在CPU內部會有一些競爭。作者在skylake上實際測試，兩個HT上同時執行的QPS結果是隻有一個HT執行的130%左右。使用perf可以觀察到，IPC（Clock cycle Per Instruction）會有一定幅度的上漲。所以，對於效能要求比較高的場景下，需要精細化的控制，儘可能讓redis的server程序（執行緒）互相間不干擾，同時可以把bio、aof和bgsave繫結在同一個core上另外的HT上。小規格伺服器（通常是2C的虛擬機器）場景下，可以在每個伺服器中部署一個redis例項。對於小規格的虛擬機器，有可能網絡卡並不支援多佇列。由於網絡卡中斷都在vCPU0上處理，儘量把redis程序繫結到vCPU0上，可以防止多個CPU之間互相通知和資料複製。同時，在目前的虛擬化技術下，一個vCPU跑到100%通常比2個vCPU都跑到50%具有更好的效能（因為vCPU跑的越高，越少發生halt的vm-exit）。網絡卡佇列低於CPU數量的場景下，例如48CPU，網絡卡40佇列的場景下，通常會40個佇列分別繫結到前40個CPU上。這種情況下，如果啟動40個redis例項，繫結在前40個CPU上是否有更好的效能，作者沒有測試。