建站
咨詢
售后
建站咨詢
新聞中心
Redis 是一個非?？焖俸蛷姶蟮?Key-Value 存儲(持久化)系統(tǒng), 相對于一般的 NoSQL 存儲系統(tǒng), 它最大的特點是支持豐富的數(shù)據(jù)結(jié)構(gòu). 特別是其 zset(sorted set)數(shù)據(jù)結(jié)構(gòu), 堪稱表達(dá)能力最強的結(jié)構(gòu)之一(其它強大的數(shù)據(jù)結(jié)構(gòu)如 sorted hashmap), 可以直接地表達(dá)業(yè)務(wù)邏輯。
綠春網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站開發(fā)等網(wǎng)站項目制作，到程序開發(fā)，運營維護(hù)。創(chuàng)新互聯(lián)成立于2013年到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。
拿一個 Messaging(消息傳遞)系統(tǒng)來舉例, 收件箱發(fā)件箱這樣的業(yè)務(wù)邏輯直接用 zset 存儲即可, 因為 zset 的每一個元素都有一個用于排序的權(quán)重值, 可以非常方便快速地地進(jìn)行插入和刪除操作. 如果使用純粹的 KV 系統(tǒng), 存儲列表等非字符串結(jié)構(gòu)的數(shù)據(jù)將是無盡的痛苦。
由于 Redis 本身的限制, 它所能處理的數(shù)據(jù)必須完全放在內(nèi)存中, 而硬盤上的數(shù)據(jù)是內(nèi)存數(shù)據(jù)的一個鏡像, 所以, 限制了它的容量不能超過內(nèi)存的容量(VM 模式無實際意義, 已在新版本中去除). 當(dāng)前, 服務(wù)器的內(nèi)存以 32G 為普遍情況, 96G 算較好, 如果一個系統(tǒng)要存儲 1T 的數(shù)據(jù), 那么必須用上 10 臺服務(wù)器, 硬件成本非常高 — 且先不談由此面臨的軟件的架構(gòu)改動. 當(dāng)前, 1T 的數(shù)據(jù)只能算零頭, 對于一個100萬活躍用戶的系統(tǒng), 平均每人每天產(chǎn)生 1K 數(shù)據(jù), 便需要 1G 的存儲空間, 這僅相當(dāng)于每個用戶每天只發(fā)10條微博或者10條聊天信息, 真正流行的系統(tǒng)將遠(yuǎn)遠(yuǎn)超過這個數(shù)據(jù)規(guī)模。
持久化, 復(fù)制和備份帶來的系統(tǒng)和網(wǎng)絡(luò)問題
一般數(shù)據(jù)達(dá)到幾百 M 或者 1G 時, Redis 必須且只能開啟 aof 操作日志異步寫硬盤的持久化模式, 由于用戶記錄數(shù)據(jù)變更日志的 aof 文件體積增加比較嚴(yán)重, 必須定期對 aof 文件進(jìn)行收縮(rewrite). 收縮的過程其實是將內(nèi)存數(shù)據(jù)鏡像到硬盤的過程, Redis 主進(jìn)程需要 fork 一個進(jìn)程出來, 雖然操作系統(tǒng)有寫時拷貝功能, 但仍然要為 fork 出來的進(jìn)程保留足夠的內(nèi)存空間, 所以 Redis 只能使用內(nèi)存容量的 50%。
在寫 aof 文件時, Redis 完全沒有任何速度控制策略, 經(jīng)常導(dǎo)致硬盤讀寫占滿, 其它進(jìn)程一旦涉及到文件操作, 都將被阻塞住。
Redis 自身支持主從模式, 可以方便地進(jìn)行數(shù)據(jù)備份, 避免單點失敗造成數(shù)據(jù)丟失. 但是, Redis 的主從模式并不成熟, 例如當(dāng)網(wǎng)絡(luò)出現(xiàn)抖動時, 可以導(dǎo)致主從之間發(fā)生一次全量復(fù)制, 這對網(wǎng)絡(luò)帶寬是一個打擊。
無分布式方案導(dǎo)致軟件設(shè)計的復(fù)雜度增加
Redis 是一個單機的存儲方案, 當(dāng)數(shù)據(jù)超過單臺服務(wù)器的內(nèi)存容量時, 必須由軟件的設(shè)計者在軟件邏輯層面設(shè)計出一套數(shù)據(jù)拆分的方案. 這必然導(dǎo)致軟件設(shè)計者無法關(guān)注于業(yè)務(wù)邏輯, 而將大量的精力放在數(shù)據(jù)存儲層, 即增加了軟件的復(fù)雜度, 也造成可維護(hù)性的下降。
結(jié)論
Redis 不適合作為海量數(shù)據(jù)存儲方案. Redis 適合在數(shù)據(jù)規(guī)模較小, 性能要求較高的條件下應(yīng)用。
海量數(shù)據(jù)存儲的備選方案
根據(jù)業(yè)務(wù)公開的經(jīng)驗, 海量數(shù)據(jù)的存儲方案主要有：
- Cassadra, 據(jù)我所知是純粹的 KV 方案, 對結(jié)構(gòu)化數(shù)據(jù)表達(dá)能力非常弱.
- HBase, 是 Google Bigtable 的一種實現(xiàn), 在 Facebook 有應(yīng)用. 其對結(jié)構(gòu)化數(shù)據(jù)的表達(dá)能力的最大優(yōu)點是數(shù)據(jù)是一維有序的(按 Key 排序)。
- mongoDB
我們需要什么樣的海量數(shù)據(jù)存儲方案(個人看法)?
實際經(jīng)驗來看, 純粹的 KV 方案太過簡單, 簡單到幾乎無法直接表達(dá)任何業(yè)務(wù)數(shù)據(jù), 相當(dāng)于拿著一堆鐵錠, 然后開發(fā)者自己再去制作自己需要的零件. 顯然, 對于使用者角色的開發(fā)者來說, 這不友好。
真正友好的還是結(jié)構(gòu)化數(shù)據(jù)存儲方案, 也就是對數(shù)據(jù)有一定的理論模型, 從而產(chǎn)生一些數(shù)據(jù)結(jié)構(gòu). 要創(chuàng)造出一個普遍適用的數(shù)據(jù)模型是非常困難的, Bigtable 那樣的模型并不是經(jīng)常被創(chuàng)造出來, 而且在 Bigtable 之外仍然需要更多的模型。
從我自己的開發(fā)經(jīng)驗來看, 最基本的, 數(shù)據(jù)應(yīng)該是有序的, 可以根據(jù)權(quán)重來排序. 一旦數(shù)據(jù)是有序的, 便能分段訪問和傳輸, 而不必全量拷貝, 海量數(shù)據(jù)處理的原則是拷貝(傳輸)最少的數(shù)據(jù)。
大多數(shù)業(yè)務(wù)的模式都是這樣的: 首先, 實體被存儲在一個空間里, 可通過 key 訪問; 其次, 創(chuàng)建實體 key 的若干個有序子集. 這兩種結(jié)構(gòu)似乎已經(jīng)包含了所有的業(yè)務(wù)邏輯. 所有聊天消息(實體), 為所有的用戶創(chuàng)建表示其收件箱消息集合(子集). 所有的微博消息(實體), 為每個用戶創(chuàng)建 timeline 消息集合(子集)……
本文題目：基于Redis構(gòu)建系統(tǒng)的經(jīng)驗和教訓(xùn)
鏈接URL：http://www.5511xx.com/article/dpsdoio.html
