你如果要對(duì)自己剛剛搭建好的redis做一個(gè)基準(zhǔn)的壓測表窘，測一下你的redis的性能和QPS（query per second）redis自己提供的redis-benchmark壓測工具，是最快捷最方便的，當(dāng)然啦翎嫡，這個(gè)工具比較簡單湃鹊，用一些簡單的操作和場景去壓測1村缸、對(duì)redis讀寫分離架構(gòu)進(jìn)行壓測汉形，單實(shí)例寫QPS+單實(shí)例讀QPSredis-3.2.8/src./redis-benchmark -h 192.168.31.187-cNumber of parallel connections (default 50)-nTotal number of requests (default 100000)-d Data size of SET/GET value in bytes (default 2)
根據(jù)你自己的高峰期的訪問量擅憔，在高峰期鸵闪，瞬時(shí)最大用戶量會(huì)達(dá)到10萬+，-c 100000雕欺，-n 10000000岛马，-d 50
各種基準(zhǔn)測試，直接出來
1核1G屠列，虛擬機(jī)
====== PING_INLINE ======
? 100000 requests completed in 1.28 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
99.78% <= 1 milliseconds
99.93% <= 2 milliseconds
99.97% <= 3 milliseconds
100.00% <= 3 milliseconds
78308.54 requests per second
====== PING_BULK ======
? 100000 requests completed in 1.30 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
99.87% <= 1 milliseconds
100.00% <= 1 milliseconds
76804.91 requests per second
====== SET ======
? 100000 requests completed in 2.50 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
5.95% <= 1 milliseconds
99.63% <= 2 milliseconds
99.93% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
40032.03 requests per second
====== GET ======
? 100000 requests completed in 1.30 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
99.73% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
76628.35 requests per second
====== INCR ======
? 100000 requests completed in 1.90 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
80.92% <= 1 milliseconds
99.81% <= 2 milliseconds
99.95% <= 3 milliseconds
99.96% <= 4 milliseconds
99.97% <= 5 milliseconds
100.00% <= 6 milliseconds
52548.61 requests per second
====== LPUSH ======
? 100000 requests completed in 2.58 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
3.76% <= 1 milliseconds
99.61% <= 2 milliseconds
99.93% <= 3 milliseconds
100.00% <= 3 milliseconds
38684.72 requests per second
====== RPUSH ======
? 100000 requests completed in 2.47 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
6.87% <= 1 milliseconds
99.69% <= 2 milliseconds
99.87% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
40469.45 requests per second
====== LPOP ======
? 100000 requests completed in 2.26 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
28.39% <= 1 milliseconds
99.83% <= 2 milliseconds
100.00% <= 2 milliseconds
44306.60 requests per second
====== RPOP ======
? 100000 requests completed in 2.18 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
36.08% <= 1 milliseconds
99.75% <= 2 milliseconds
100.00% <= 2 milliseconds
45871.56 requests per second
====== SADD ======
? 100000 requests completed in 1.23 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
99.94% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
81168.83 requests per second
====== SPOP ======
? 100000 requests completed in 1.28 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
99.80% <= 1 milliseconds
99.96% <= 2 milliseconds
99.96% <= 3 milliseconds
99.97% <= 5 milliseconds
100.00% <= 5 milliseconds
78369.91 requests per second
====== LPUSH (needed to benchmark LRANGE) ======
? 100000 requests completed in 2.47 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
15.29% <= 1 milliseconds
99.64% <= 2 milliseconds
99.94% <= 3 milliseconds
100.00% <= 3 milliseconds
40420.37 requests per second
====== LRANGE_100 (first 100 elements) ======
? 100000 requests completed in 3.69 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
30.86% <= 1 milliseconds
96.99% <= 2 milliseconds
99.94% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
27085.59 requests per second
====== LRANGE_300 (first 300 elements) ======
? 100000 requests completed in 10.22 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
0.03% <= 1 milliseconds
5.90% <= 2 milliseconds
90.68% <= 3 milliseconds
95.46% <= 4 milliseconds
97.67% <= 5 milliseconds
99.12% <= 6 milliseconds
99.98% <= 7 milliseconds
100.00% <= 7 milliseconds
9784.74 requests per second
====== LRANGE_500 (first 450 elements) ======
? 100000 requests completed in 14.71 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
0.00% <= 1 milliseconds
0.07% <= 2 milliseconds
1.59% <= 3 milliseconds
89.26% <= 4 milliseconds
97.90% <= 5 milliseconds
99.24% <= 6 milliseconds
99.73% <= 7 milliseconds
99.89% <= 8 milliseconds
99.96% <= 9 milliseconds
99.99% <= 10 milliseconds
100.00% <= 10 milliseconds
6799.48 requests per second
====== LRANGE_600 (first 600 elements) ======
? 100000 requests completed in 18.56 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
0.00% <= 2 milliseconds
0.23% <= 3 milliseconds
1.75% <= 4 milliseconds
91.17% <= 5 milliseconds
98.16% <= 6 milliseconds
99.04% <= 7 milliseconds
99.83% <= 8 milliseconds
99.95% <= 9 milliseconds
99.98% <= 10 milliseconds
100.00% <= 10 milliseconds
5387.35 requests per second
====== MSET (10 keys) ======
? 100000 requests completed in 4.02 seconds
? 50 parallel clients
? 3 bytes payload
? keep alive: 1
0.01% <= 1 milliseconds
53.22% <= 2 milliseconds
99.12% <= 3 milliseconds
99.55% <= 4 milliseconds
99.70% <= 5 milliseconds
99.90% <= 6 milliseconds
99.95% <= 7 milliseconds
100.00% <= 8 milliseconds
24869.44 requests per second
我們這個(gè)讀寫分離這一塊的第一講
大部分情況下來說啦逆，看你的服務(wù)器的機(jī)器性能和配置，機(jī)器越牛逼笛洛，配置越高
單機(jī)上十幾萬夏志，單機(jī)上二十萬
很多公司里，給一些低配置的服務(wù)器苛让，操作復(fù)雜度
大公司里沟蔑，都是公司會(huì)提供統(tǒng)一的云平臺(tái)，比如京東狱杰、騰訊瘦材、BAT、其他的一些仿畸、小米食棕、美團(tuán)
虛擬機(jī)，低配
搭建一些集群错沽，專門為某個(gè)項(xiàng)目簿晓，搭建的專用集群，4核4G內(nèi)存千埃，比較復(fù)雜的操作憔儿，數(shù)據(jù)比較大
幾萬，單機(jī)做到放可，差不多了
redis提供的高并發(fā)谒臼，至少到上萬，沒問題
幾萬~十幾萬/二十萬不等
QPS耀里，自己不同公司蜈缤，不同服務(wù)器，自己去測試备韧，跟生產(chǎn)環(huán)境還有區(qū)別
生產(chǎn)環(huán)境劫樟，大量的網(wǎng)絡(luò)請(qǐng)求的調(diào)用痪枫，網(wǎng)絡(luò)本身就有開銷织堂，你的redis的吞吐量就不一定那么高了
QPS的兩個(gè)殺手：一個(gè)是復(fù)雜操作叠艳，lrange，挺多的; value很大易阳，2 byte附较，我之前用redis做大規(guī)模的緩存
做商品詳情頁的cache，可能是需要把大串?dāng)?shù)據(jù)潦俺，拼接在一起拒课，作為一個(gè)json串，大小可能都幾k事示，幾個(gè)byte
2早像、水平擴(kuò)容redis讀節(jié)點(diǎn)，提升度吞吐量
就按照上一節(jié)課講解的肖爵，再在其他服務(wù)器上搭建redis從節(jié)點(diǎn)卢鹦，單個(gè)從節(jié)點(diǎn)讀請(qǐng)QPS在5萬左右，兩個(gè)redis從節(jié)點(diǎn)劝堪，所有的讀請(qǐng)求打到兩臺(tái)機(jī)器上去冀自，承載整個(gè)集群讀QPS在10萬+
