導語：當面臨存儲選型時是選擇關系型還是非關系型數(shù)據(jù)庫？ 如果選擇了非關系型的redis，redis常用數(shù)據(jù)類型占用內(nèi)存大小如何估算的？ redis的性能瓶頸又在哪里？
背景前段時間接手了一個業(yè)務，響應時間達到 10s左右。 閱讀源碼后發(fā)現(xiàn)，每一次請求都是查詢多個分表數(shù)據(jù)（task1,task2….），然后再join其他表(course,teacher..)， 時間全部花在了大量磁盤I/O上。 腦袋一拍，重構，上redis！
為什么選擇redis拍腦袋做技術方案肯定是不行的，得用數(shù)據(jù)和邏輯說服別人才可以。
以redis一組K-V為例（”hello” -> “world”），一個簡單的set命令最終會產(chǎn)生4個消耗內(nèi)存的結構。
關于Redis數(shù)據(jù)存儲的細節(jié)，又要涉及到內(nèi)存分配器（如jemalloc），簡單說就是存儲170字節(jié)，其實內(nèi)存分配器會分配192字節(jié)存儲。
那么總的花費就是
一個dictEntry，24字節(jié)，jemalloc會分配32字節(jié)的內(nèi)存塊
一個redisObject，16字節(jié)，jemalloc會分配16字節(jié)的內(nèi)存塊
一個key，5字節(jié)，所以SDS(key)需要5+9=14個字節(jié)，jemalloc會分配16字節(jié)的內(nèi)存塊
綜上，一個dictEntry需要32+16+16+16=80個字節(jié)。
上面這個算法只是舉個例子，想要更深入計算出redis所有數(shù)據(jù)結構的內(nèi)存大小，可以參考 這篇文章 。 筆者使用的是哈希結構，這個業(yè)務需求大概一年的數(shù)據(jù)量是200MB，從使用redis成本上考慮沒有問題。筆者這個需求背景讀多寫少，冷數(shù)據(jù)占比比較大，但數(shù)據(jù)結構又很復雜（涉及多個維度數(shù)據(jù)總和），因此只要啟動定時任務離線增量寫入redis，請求到達時直接讀取redis中的數(shù)據(jù)，無疑可以減少響應時間。
[ 最終方案 ]
redis瓶頸和優(yōu)化
最終存儲到redis中的數(shù)據(jù)結構如下圖。
采用同步的方式對三個月（90天）進行HGETALL操作，每一天花費30ms，90次就是2700ms！ redis操作讀取應該是ns級別的，怎么會這么慢？ 利用多核cpu計算會不會更快？
常識告訴我，redis指令執(zhí)行速度 >> 網(wǎng)絡通信(內(nèi)網(wǎng)) > read/write等系統(tǒng)調(diào)用。
因此這里其實是I/O密集型場景，就算利用多核cpu，也解決不到根本的問題，最終影響redis性能，
**其實是網(wǎng)卡收發(fā)數(shù)據(jù)
和用戶態(tài)內(nèi)核態(tài)數(shù)據(jù)拷貝
**。
于是我把代碼改了一版，原來是90次I/O，現(xiàn)在通過redis pipeline操作，一次請求半個月，那么3個月就是6次I/O。 很開心，時間一下子少了1000ms。
我使用是golang的 redisgo 的客戶端，翻閱源碼發(fā)現(xiàn)，redisgo執(zhí)行pipeline邏輯是 把命令和參數(shù)寫到golang原生的bufio中，如果超過bufio默認大值（4096字節(jié)），就發(fā)起一次I/O，flush到內(nèi)核態(tài)。
redisgo編碼pipeline規(guī)則 如下圖， *表示后面參數(shù)加命令的個數(shù)，$表示后面的字符長度 ，一條HGEALL命令實際占45字節(jié)。
那其實90天數(shù)據(jù)，一次I/O就可以搞定了（90 * 45 < 4096字節(jié)）!
果然，又快了1000ms，耗費時間達到了1秒以內(nèi)
簡單寫了一個壓測程序，通過比較請求量和qps的關系，來看一下吞吐量和qps的變化，從而選擇一個適合業(yè)務需求的值。
重慶分公司
重慶分公司
package main
import (
"crypto/rand"
"fmt"
"math/big"
"strconv"
"time"
"github.com/garyburd/redigo/redis"
)
const redisKey = "redis_test_key:%s"
func main() {
for i := 1; i < 10000; i++ {
testRedisHGETALL(getPreKeyAndLoopTime(i))
}
}
func testRedisHGETALL(keyList [][]string) {
Conn, err := redis.Dial("tcp", "127.0.0.1:6379")
if err != nil {
fmt.Println(err)
return
}
costTime := int64(0)
start := time.Now().Unix()
for _, keys := range keyList {
for _, key := range keys {
Conn.Send("HGETALL", fmt.Sprintf(redisKey, key))
}
Conn.Flush()
}
end := time.Now().Unix()
costTime = end - start
fmt.Printf("cost_time=[%+v]ms,qps=[%+v],keyLen=[%+v],totalBytes=[%+v]",
1000*int64(len(keyList))/costTime, costTime/int64(len(keyList)), len(keyList), len(keyList)*len(keyList[0])*len(redisKey))
}
//根據(jù)key的長度，設置不同的循環(huán)次數(shù)，平均計算，取除網(wǎng)絡延遲帶來的影響
func getPreKeyAndLoopTime(keyLen int) [][]string {
loopTime := 1000
if keyLen < 10 {
loopTime *= 100
} else if keyLen < 100 {
loopTime *= 50
} else if keyLen < 500 {
loopTime *= 10
} else if keyLen < 1000 {
loopTime *= 5
}
return generateKeys(keyLen, loopTime)
}
func generateKeys(keyLen, looTime int) [][]string {
keyList := make([][]string, 0)
for i := 0; i < looTime; i++ {
keys := make([]string, 0)
for i := 0; i < keyLen; i++ {
result, _ := rand.Int(rand.Reader, big.NewInt(100))
keys = append(keys, strconv.FormatInt(result.Int64(), 10))
}
keyList = append(keyList, keys)
}
return keyList
}
windows上單機版redis結果如下：
擴展 （分布式方案下pipeline操作）需求最終是完成了，可是轉(zhuǎn)念一想，現(xiàn)在都是集群版的redis，pipeline批量請求的key可能分布在不同的機器上，但pipeline請求最終可能只被一臺redis server處理，那不就是會讀取數(shù)據(jù)失敗嗎？ 于是，筆者查找?guī)讉€通用的redis 分布式方案，看看他們是如何處理這pipeline問題的。
github.com/go-redis就是這樣做的，有興趣可以閱讀下源碼。
總結在做需求的過程中，發(fā)現(xiàn)了很多東西不能拍腦袋決定，而是前期做技術方案的時候，想清楚，調(diào)研好，用數(shù)據(jù)和邏輯去說服自己。
