Redis 是一個(gè)非常快速和強(qiáng)大的 Key-Value 存儲(chǔ)(持久化)系統(tǒng), 相對(duì)于一般的 NoSQL 存儲(chǔ)系統(tǒng), 它最大的特點(diǎn)是支持豐富的數(shù)據(jù)結(jié)構(gòu). 特別是其 zset(sorted set)數(shù)據(jù)結(jié)構(gòu), 堪稱(chēng)表達(dá)能力最強(qiáng)的結(jié)構(gòu)之一(其它強(qiáng)大的數(shù)據(jù)結(jié)構(gòu)如 sorted hashmap), 可以直接地表達(dá)業(yè)務(wù)邏輯。

拿一個(gè) Messaging(消息傳遞)系統(tǒng)來(lái)舉例, 收件箱發(fā)件箱這樣的業(yè)務(wù)邏輯直接用 zset 存儲(chǔ)即可, 因?yàn)?zset 的每一個(gè)元素都有一個(gè)用于排序的權(quán)重值, 可以非常方便快速地地進(jìn)行插入和刪除操作. 如果使用純粹的 KV 系統(tǒng), 存儲(chǔ)列表等非字符串結(jié)構(gòu)的數(shù)據(jù)將是無(wú)盡的痛苦。

由于 Redis 本身的限制, 它所能處理的數(shù)據(jù)必須完全放在內(nèi)存中, 而硬盤(pán)上的數(shù)據(jù)是內(nèi)存數(shù)據(jù)的一個(gè)鏡像, 所以, 限制了它的容量不能超過(guò)內(nèi)存的容量(VM 模式無(wú)實(shí)際意義, 已在新版本中去除). 當(dāng)前, 服務(wù)器的內(nèi)存以 32G 為普遍情況, 96G 算較好, 如果一個(gè)系統(tǒng)要存儲(chǔ) 1T 的數(shù)據(jù), 那么必須用上 10 臺(tái)服務(wù)器, 硬件成本非常高 — 且先不談?dòng)纱嗣媾R的軟件的架構(gòu)改動(dòng). 當(dāng)前, 1T 的數(shù)據(jù)只能算零頭, 對(duì)于一個(gè)100萬(wàn)活躍用戶(hù)的系統(tǒng), 平均每人每天產(chǎn)生 1K 數(shù)據(jù), 便需要 1G 的存儲(chǔ)空間, 這僅相當(dāng)于每個(gè)用戶(hù)每天只發(fā)10條微博或者10條聊天信息, 真正流行的系統(tǒng)將遠(yuǎn)遠(yuǎn)超過(guò)這個(gè)數(shù)據(jù)規(guī)模。

持久化, 復(fù)制和備份帶來(lái)的系統(tǒng)和網(wǎng)絡(luò)問(wèn)題

一般數(shù)據(jù)達(dá)到幾百 M 或者 1G 時(shí), Redis 必須且只能開(kāi)啟 aof 操作日志異步寫(xiě)硬盤(pán)的持久化模式, 由于用戶(hù)記錄數(shù)據(jù)變更日志的 aof 文件體積增加比較嚴(yán)重, 必須定期對(duì) aof 文件進(jìn)行收縮(rewrite). 收縮的過(guò)程其實(shí)是將內(nèi)存數(shù)據(jù)鏡像到硬盤(pán)的過(guò)程, Redis 主進(jìn)程需要 fork 一個(gè)進(jìn)程出來(lái), 雖然操作系統(tǒng)有寫(xiě)時(shí)拷貝功能, 但仍然要為 fork 出來(lái)的進(jìn)程保留足夠的內(nèi)存空間, 所以 Redis 只能使用內(nèi)存容量的 50%。

在寫(xiě) aof 文件時(shí), Redis 完全沒(méi)有任何速度控制策略, 經(jīng)常導(dǎo)致硬盤(pán)讀寫(xiě)占滿(mǎn), 其它進(jìn)程一旦涉及到文件操作, 都將被阻塞住。

Redis 自身支持主從模式, 可以方便地進(jìn)行數(shù)據(jù)備份, 避免單點(diǎn)失敗造成數(shù)據(jù)丟失. 但是, Redis 的主從模式并不成熟, 例如當(dāng)網(wǎng)絡(luò)出現(xiàn)抖動(dòng)時(shí), 可以導(dǎo)致主從之間發(fā)生一次全量復(fù)制, 這對(duì)網(wǎng)絡(luò)帶寬是一個(gè)打擊。

無(wú)分布式方案導(dǎo)致軟件設(shè)計(jì)的復(fù)雜度增加

Redis 是一個(gè)單機(jī)的存儲(chǔ)方案, 當(dāng)數(shù)據(jù)超過(guò)單臺(tái)服務(wù)器的內(nèi)存容量時(shí), 必須由軟件的設(shè)計(jì)者在軟件邏輯層面設(shè)計(jì)出一套數(shù)據(jù)拆分的方案. 這必然導(dǎo)致軟件設(shè)計(jì)者無(wú)法關(guān)注于業(yè)務(wù)邏輯, 而將大量的精力放在數(shù)據(jù)存儲(chǔ)層, 即增加了軟件的復(fù)雜度, 也造成可維護(hù)性的下降。

結(jié)論

Redis 不適合作為海量數(shù)據(jù)存儲(chǔ)方案. Redis 適合在數(shù)據(jù)規(guī)模較小, 性能要求較高的條件下應(yīng)用。

海量數(shù)據(jù)存儲(chǔ)的備選方案

根據(jù)業(yè)務(wù)公開(kāi)的經(jīng)驗(yàn), 海量數(shù)據(jù)的存儲(chǔ)方案主要有：

• Cassadra, 據(jù)我所知是純粹的 KV 方案, 對(duì)結(jié)構(gòu)化數(shù)據(jù)表達(dá)能力非常弱.
• HBase, 是 Google Bigtable 的一種實(shí)現(xiàn), 在 Facebook 有應(yīng)用. 其對(duì)結(jié)構(gòu)化數(shù)據(jù)的表達(dá)能力的最大優(yōu)點(diǎn)是數(shù)據(jù)是一維有序的(按 Key 排序)。
• mongoDB

我們需要什么樣的海量數(shù)據(jù)存儲(chǔ)方案(個(gè)人看法)?

實(shí)際經(jīng)驗(yàn)來(lái)看, 純粹的 KV 方案太過(guò)簡(jiǎn)單, 簡(jiǎn)單到幾乎無(wú)法直接表達(dá)任何業(yè)務(wù)數(shù)據(jù), 相當(dāng)于拿著一堆鐵錠, 然后開(kāi)發(fā)者自己再去制作自己需要的零件. 顯然, 對(duì)于使用者角色的開(kāi)發(fā)者來(lái)說(shuō), 這不友好。

真正友好的還是結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)方案, 也就是對(duì)數(shù)據(jù)有一定的理論模型, 從而產(chǎn)生一些數(shù)據(jù)結(jié)構(gòu). 要?jiǎng)?chuàng)造出一個(gè)普遍適用的數(shù)據(jù)模型是非常困難的, Bigtable 那樣的模型并不是經(jīng)常被創(chuàng)造出來(lái), 而且在 Bigtable 之外仍然需要更多的模型。

從我自己的開(kāi)發(fā)經(jīng)驗(yàn)來(lái)看, 最基本的, 數(shù)據(jù)應(yīng)該是有序的, 可以根據(jù)權(quán)重來(lái)排序. 一旦數(shù)據(jù)是有序的, 便能分段訪問(wèn)和傳輸, 而不必全量拷貝, 海量數(shù)據(jù)處理的原則是拷貝(傳輸)最少的數(shù)據(jù)。

大多數(shù)業(yè)務(wù)的模式都是這樣的: 首先, 實(shí)體被存儲(chǔ)在一個(gè)空間里, 可通過(guò) key 訪問(wèn); 其次, 創(chuàng)建實(shí)體 key 的若干個(gè)有序子集. 這兩種結(jié)構(gòu)似乎已經(jīng)包含了所有的業(yè)務(wù)邏輯. 所有聊天消息(實(shí)體), 為所有的用戶(hù)創(chuàng)建表示其收件箱消息集合(子集). 所有的微博消息(實(shí)體), 為每個(gè)用戶(hù)創(chuàng)建 timeline 消息集合(子集)……