一. 壓測環境
1臺3u8機器(PHP-C3)、1臺lg 3u8機器(PHP-LG)：運行PHP腳本，發起codis讀寫請求
3臺3u8機器(CODIS-C3)：codis集羣，運行1個proxy實例、2組redis(每組1主2從)，proxy與redis混部
二. 壓測方式
1. 在PHP-C3、PHP-LG機器起多個PHP進程，以模擬併發請求；
2. 每個PHP進程循環、同步發起codis請求；
3. 每個codis請求使用的key、value是隨機生成的，key長度爲50byte，value長度爲100byte；
4. 耗時統計是在PHP端做的，另只統計了PHP-C3上的請求耗時，PHP-LG機器涉及到跨機房調用，所需耗時增加跨機房RTT即可.
三. 壓測結果
1. codis寫操作
|
併發數 |
PHP機器load |
Codis機器load |
QPS |
最小耗時 |
最大耗時 |
平均耗時 |
99%耗時 |
|
c3: 5 |
0.01 |
0.11 |
11000 |
0.219ms |
186.194ms |
0.386ms |
0.629ms |
|
c3: 10 |
0.63 |
0.22 |
19000 |
0.212ms |
221.679ms |
0.434ms |
0.875ms |
|
c3: 20 |
10.26 |
0.11 |
24600 |
0.218ms |
510.217ms |
0.739ms |
1.509ms |
|
c3: 20 lg: 20 |
c3: 11.56 lg: 0.02 |
0.16 |
37000 |
0.223ms |
390.256ms |
0.732ms |
1.498ms |
|
c3: 20 lg：40 |
c3: 11.52 lg: 0.81 |
0.18 |
47500 |
0.226ms |
503.914ms |
0.752ms |
1.525ms |
|
c3: 20 lg: 50 |
c3: 8.71 lg: 15.44 |
0.11 |
48500 |
0.223ms |
201.484ms |
0.732ms |
1.505ms |
結論：
(1) Codis在後端掛2組redis下，1個proxy實例的寫操作能到48500/s，由於到併發70時，PHP-C3、PHP-LG機器負載已經較高，所以Codis的實際寫處理能力可能比48500/s還更高點.
(2) 平均耗時在1ms以內.
2. codis讀操作
|
併發數 |
PHP機器load |
Codis機器load |
QPS |
最小耗時 |
最大耗時 |
平均耗時 |
99%耗時 |
|
c3: 5 |
0.43 |
0.14 |
19500 |
0.208ms |
201.627ms |
0.429ms |
0.756ms |
|
c3: 10 |
0.41 |
0.25 |
21000 |
0.211ms |
202.139ms |
0.463ms |
0.894ms |
|
c3: 20 |
13.31 |
0.3 |
30500 |
0.214ms |
200.854ms |
0.66ms |
1.245ms |
|
c3: 20 lg: 20 |
c3: 14.84 lg: 0.22 |
0.14 |
43500 |
0.219ms |
28.686ms |
0.632ms |
1.014ms |
|
c3: 20 lg: 40 |
c3: 13.74 lg: 8.78 |
0.27 |
56100 |
0.22ms |
202.118ms |
0.616ms |
1.204ms |
|
c3: 20 lg: 50 |
c3: 10.81 lg: 9.19 |
0.19 |
58200 |
0.223ms |
40.478ms |
0.623ms |
1.265ms |
結論：
(1) Codis在後端掛2組redis下，1個proxy實例的讀操作能到58200/s，由於到併發70時，PHP-C3、PHP-LG機器負載已經較高，所以Codis的實際讀處理能力可能比58200/s還更高點.
(2) 平均耗時在1ms以內.
3. codis擴容、數據遷移對讀寫性能的影響
codis數據遷移分爲2個階段：
(1)pre-migrate階段：codis整個集羣的狀態信息存儲在zookeeper，每個proxy從zookeeper同步集羣狀態信息。由於同步速度有快慢，每個proxy的狀態可能在某一時間點會不一致，在狀態不一致的情況下做數據遷移操作，會導致數據不一致。所以codis設計了一個pre-migrate階段，將需要遷移的slot先標記爲pre-migrate，等所有proxy都同步到了這個pre-migrate狀態，才發起下一步真正的數據遷移操作。
若slot被標記爲pre-migrate，proxy會拒絕對該slot的寫操作，所以在該階段，會影響線上的寫操作.
(2)migrate階段：當所有proxy都將要遷移的slot標記爲pre-migrate後，codis再將該slot標記爲migrate，此時可進行真正的數據遷移了。proxy接收到某個key的讀寫請求時，若該key落在被標記爲migrate的slot，則先發slotmigratekey命令，保證該key的數據已遷移到新的redis group，然後再將讀寫請求路由到新的redis group.
因此在數據遷移的migrate階段，若請求落在正在遷移的slot，會多一次slotmigratekey的操作.
也就是從理論上講，會有以下2點影響：
(1)在pre-migrate階段，被遷移的slot上的寫請求將會被拒絕。該階段持續時間特別短，對線上影響不大.
(2)在migrate階段，被遷移的slot上的所有讀寫請求將增加slotmigratekey操作，一定程度上加大處理耗時。由於遷移單位是slot，總共有1024個slot，也就是說線上的1/1024的請求處理耗時會增大.
實際壓測結果：
|
操作類別 |
併發數 |
Codis機器load |
QPS |
最小耗時 |
最大耗時 |
平均耗時 |
99%耗時 |
|
write |
20 |
0.14 |
24500 |
0.218ms |
960.166ms |
0.738ms |
1.706ms |
|
read |
20 |
0.07 |
29800 |
0.211ms |
522.158ms |
0.648ms |
1.217ms |
結論：
(1) 沒有出現由於pre-migrate階段拒絕寫請求，從而寫失敗的情況.
(2) QPS略有所下降，但下降幅度很低；最大耗時有所增加.
總體來說，數據遷移對讀寫請求沒有特別大影響.
調整了下codis集羣，proxy單獨部署，1臺proxy，1組redis(1主、1從)，codis沒有讀寫分離機制，也就是所有讀寫請求會全落到主redis。
壓測結果如下：
純讀操作(QPS)：27W/s
純寫操作(QPS)：11W/s
