redis和mongodb數(shù)據(jù)庫對比_redis、memcache、mongoDB 對比

概況

redis是一個key-value型數(shù)據(jù)庫，信息以鍵對應(yīng)值的關(guān)系存儲在內(nèi)存中，比memcache較大的優(yōu)勢就在于其數(shù)據(jù)結(jié)構(gòu)的多樣性。redis不算一個真正意義上的數(shù)據(jù)庫，因為redis是主要把數(shù)據(jù)存儲在內(nèi)存中（當(dāng)然可以把其存儲至硬盤上，這也是寫shell的必要條件之一），其“緩存”的性質(zhì)遠大于其“數(shù)據(jù)存儲”的性質(zhì)，其中數(shù)據(jù)的正刪改查也只是像變量操作一樣簡單。而mongodb卻是一個“存儲數(shù)據(jù)”的系統(tǒng)，增刪改查數(shù)據(jù)的時候有“與或非”條件，查詢數(shù)據(jù)的方式也能像SQL數(shù)據(jù)庫一樣靈活，這是redis所不具備的。

進入正題，對于redis可能造成的安全問題，提到了寫文件，下文將把方法作簡要分析。

redis安裝完成以后有自己的命令行，也就是redis-cli，其中包含的命令可以在：http://redis.io/commands 進行查閱。各個客戶端基本也就是依照這個命令去增刪改查。之前說了redis的數(shù)據(jù)主要保存在內(nèi)存中，當(dāng)與memcache不同之處在于，我們可以隨時執(zhí)行“save”命令將當(dāng)前redis的數(shù)據(jù)保存到硬盤上，另外redis也會根據(jù)配置自動存儲數(shù)據(jù)到硬盤上。

這不得不說到redis的持久化運作方案 http://redis.io/topics/persistence ，其中說到的一個RDB，一個AOF。RDB更像一個數(shù)據(jù)庫備份文件，而AOF是一個log日志文件。我們可以設(shè)置讓redis再指定時間、指定更改次數(shù)時進行備份，生成RDB文件；而設(shè)置AOF，可以在操作或時間過程后將“日志”寫入一個文件的最末，當(dāng)操作越來越多，則AOF文件越來越大。

二者是相輔相成的，通過二者的配合我們能夠穩(wěn)定地持久地將數(shù)據(jù)存儲于服務(wù)器上。

利用redis寫webshell

而我們就是利用這些儲存數(shù)據(jù)的操作，來進行任意文件寫入。

redis的配置中，有幾個關(guān)鍵項目：

dir，指定的是redis的“工作路徑”，之后生成的RDB和AOF文件都會存儲在這里。

dbfilename，RDB文件名，默認為“dump.rdb”

appendonly，是否開啟AOF

appendfilename，AOF文件名，默認為“appendonly.aof”

appendfsync，AOF備份方式：always、everysec、no

經(jīng)過我的研究發(fā)現(xiàn)，我們可以將dir設(shè)置為一個目錄a，而dbfilename為文件名b，再執(zhí)行save或bgsave，則我們就可以寫入一個路徑為a/b的任意文件：

?

當(dāng)我們獲得了一個redis控制臺，我們可以調(diào)用config set/get等命令對redis的部分配置進行修改。

而恰好的是，我們可以通過config set來更改dir和dbfilename。也就是說我們可以不用修改redis.conf，也不用重啟redis服務(wù)就可以寫入任意文件：

config set dir /home/wwwroot/default/

config set dbfilename redis.php

set webshell “<？php phpinfo（）; ？>“

save

當(dāng)我們隨便set一個變量webshell的值為”<？php phpinfo（）; ？>”后，即可對服務(wù)器進行g(shù)etshell?？梢娨褜懭耄?/p>

?

導(dǎo)出的RDB實際上是一個二進制文件，但因為其中包含<？php phpinfo（）; ？>，所以被解析了：

?

在前圖中，我們可以看到其實還生成了一個appendonly.aof，這個文件名能不能自定義呢？可惜的是，appendfilename的值并不能使用config set命令定義：

但僅有的一個dbfilename已經(jīng)足夠了。

所以，以后如果掃到redis未授權(quán)訪問，先別急著提交烏云?？纯捶?wù)器有沒有web服務(wù)，如果有，不妨試試能不能拿下webshell。

Mongodb與Redis應(yīng)用指標(biāo)對比

MongoDB和Redis都是NoSQL，采用結(jié)構(gòu)型數(shù)據(jù)存儲。二者在使用場景中，存在一定的區(qū)別，這也主要由于二者在內(nèi)存映射的處理過程，持久化的處理方法不同。MongoDB建議集群部署，更多的考慮到集群方案，Redis更偏重于進程順序?qū)懭?，雖然支持集群，也僅限于主-從模式。

?

Redis、Memcached與 MongoDB三者的區(qū)別

如果簡單地比較Redis與Memcached的區(qū)別，大多數(shù)都會得到以下觀點：

1 Redis不僅僅支持簡單的k/v類型的數(shù)據(jù)，同時還提供list，set，hash等數(shù)據(jù)結(jié)構(gòu)的存儲。

2 Redis支持數(shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。

3 Redis支持數(shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中，重啟的時候可以再次加載進行使用。

在Redis中，并不是所有的數(shù)據(jù)都一直存儲在內(nèi)存中的。這是和Memcached相比一個最大的區(qū)別（我個人是這么認為的）。

Redis只會緩存所有的key的信息，如果Redis發(fā)現(xiàn)內(nèi)存的使用量超過了某一個閥值，將觸發(fā)swap的操作，Redis根據(jù)“swappability = age*log（size_in_memory）”計算出哪些key對應(yīng)的value需要swap到磁盤。然后再將這些key對應(yīng)的value持久化到磁盤中，同時在內(nèi)存中清除。這種特性使得Redis可以保持超過其機器本身內(nèi)存大小的數(shù)據(jù)。當(dāng)然，機器本身的內(nèi)存必須要能夠保持所有的key，畢竟這些數(shù)據(jù)是不會進行swap操作的。

同時由于Redis將內(nèi)存中的數(shù)據(jù)swap到磁盤中的時候，提供服務(wù)的主線程和進行swap操作的子線程會共享這部分內(nèi)存，所以如果更新需要swap的數(shù)據(jù)，Redis將阻塞這個操作，直到子線程完成swap操作后才可以進行修改。

可以參考使用Redis特有內(nèi)存模型前后的情況對比：

VM off： 300k keys， 4096 bytes values： 1.3G used

VM on： 300k keys， 4096 bytes values： 73M used

VM off： 1 million keys， 256 bytes values： 430.12M used

VM on： 1 million keys， 256 bytes values： 160.09M used

VM on： 1 million keys， values as large as you want， still： 160.09M used

當(dāng)從Redis中讀取數(shù)據(jù)的時候，如果讀取的key對應(yīng)的value不在內(nèi)存中，那么Redis就需要從swap文件中加載相應(yīng)數(shù)據(jù)，然后再返回給請求方。這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現(xiàn)阻塞，即完成所有的swap文件加載后才會相應(yīng)。這種策略在客戶端的數(shù)量較小，進行批量操作的時候比較合適。但是如果將Redis應(yīng)用在一個大型的網(wǎng)站應(yīng)用程序中，這顯然是無法滿足大并發(fā)的情況的。所以Redis運行我們設(shè)置I/O線程池的大小，對需要從swap文件中加載相應(yīng)數(shù)據(jù)的讀取請求進行并發(fā)操作，減少阻塞的時間。

redis、memcache、mongoDB 對比

從以下幾個維度，對redis、memcache、mongoDB 做了對比，歡迎拍磚

1、性能

都比較高，性能對我們來說應(yīng)該都不是瓶頸

總體來講，TPS方面redis和memcache差不多，要大于mongodb

2、操作的便利性

memcache數(shù)據(jù)結(jié)構(gòu)單一

redis豐富一些，數(shù)據(jù)操作方面，redis更好一些，較少的網(wǎng)絡(luò)IO次數(shù)

mongodb支持豐富的數(shù)據(jù)表達，索引，最類似關(guān)系型數(shù)據(jù)庫，支持的查詢語言非常豐富

3、內(nèi)存空間的大小和數(shù)據(jù)量的大小

redis在2.0版本后增加了自己的VM特性，突破物理內(nèi)存的限制；可以對key value設(shè)置過期時間（類似memcache）

memcache可以修改最大可用內(nèi)存，采用LRU算法

mongoDB適合大數(shù)據(jù)量的存儲，依賴操作系統(tǒng)VM做內(nèi)存管理，吃內(nèi)存也比較厲害，服務(wù)不要和別的服務(wù)在一起

4、可用性（單點問題）

對于單點問題，

redis，依賴客戶端來實現(xiàn)分布式讀寫；主從復(fù)制時，每次從節(jié)點重新連接主節(jié)點都要依賴整個快照，無增量復(fù)制，因性能和效率問題，

所以單點問題比較復(fù)雜；不支持自動sharding，需要依賴程序設(shè)定一致hash 機制。

一種替代方案是，不用redis本身的復(fù)制機制，采用自己做主動復(fù)制（多份存儲），或者改成增量復(fù)制的方式（需要自己實現(xiàn)），一致性問題和性能的權(quán)衡

Memcache本身沒有數(shù)據(jù)冗余機制，也沒必要；對于故障預(yù)防，采用依賴成熟的hash或者環(huán)狀的算法，解決單點故障引起的抖動問題。

mongoDB支持master-slave，replicaset（內(nèi)部采用paxos選舉算法，自動故障恢復(fù)），auto sharding機制，對客戶端屏蔽了故障轉(zhuǎn)移和切分機制。

5、可靠性（持久化）

對于數(shù)據(jù)持久化和數(shù)據(jù)恢復(fù)，

redis支持（快照、AOF）：依賴快照進行持久化，aof增強了可靠性的同時，對性能有所影響

memcache不支持，通常用在做緩存，提升性能；

MongoDB從1.8版本開始采用binlog方式支持持久化的可靠性

6、數(shù)據(jù)一致性（事務(wù)支持）

Memcache 在并發(fā)場景下，用cas保證一致性

redis事務(wù)支持比較弱，只能保證事務(wù)中的每個操作連續(xù)執(zhí)行

mongoDB不支持事務(wù)

7、數(shù)據(jù)分析

mongoDB內(nèi)置了數(shù)據(jù)分析的功能（mapreduce），其他不支持

8、應(yīng)用場景

redis：數(shù)據(jù)量較小的更性能操作和運算上

memcache：用于在動態(tài)系統(tǒng)中減少數(shù)據(jù)庫負載，提升性能;做緩存，提高性能（適合讀多寫少，對于數(shù)據(jù)量比較大，可以采用sharding）

MongoDB：主要解決海量數(shù)據(jù)的訪問效率問題