概況
redis是一個(gè)key-value型數(shù)據(jù)庫(kù),信息以鍵對(duì)應(yīng)值的關(guān)系存儲(chǔ)在內(nèi)存中,比memcache較大的優(yōu)勢(shì)就在于其數(shù)據(jù)結(jié)構(gòu)的多樣性。redis不算一個(gè)真正意義上的數(shù)據(jù)庫(kù),因?yàn)閞edis是主要把數(shù)據(jù)存儲(chǔ)在內(nèi)存中(當(dāng)然可以把其存儲(chǔ)至硬盤(pán)上,這也是寫(xiě)shell的必要條件之一),其“緩存”的性質(zhì)遠(yuǎn)大于其“數(shù)據(jù)存儲(chǔ)”的性質(zhì),其中數(shù)據(jù)的正刪改查也只是像變量操作一樣簡(jiǎn)單。而mongodb卻是一個(gè)“存儲(chǔ)數(shù)據(jù)”的系統(tǒng),增刪改查數(shù)據(jù)的時(shí)候有“與或非”條件,查詢數(shù)據(jù)的方式也能像SQL數(shù)據(jù)庫(kù)一樣靈活,這是redis所不具備的。
進(jìn)入正題,對(duì)于redis可能造成的安全問(wèn)題,提到了寫(xiě)文件,下文將把方法作簡(jiǎn)要分析。
redis安裝完成以后有自己的命令行,也就是redis-cli,其中包含的命令可以在:http://redis.io/commands 進(jìn)行查閱。各個(gè)客戶端基本也就是依照這個(gè)命令去增刪改查。之前說(shuō)了redis的數(shù)據(jù)主要保存在內(nèi)存中,當(dāng)與memcache不同之處在于,我們可以隨時(shí)執(zhí)行“save”命令將當(dāng)前redis的數(shù)據(jù)保存到硬盤(pán)上,另外redis也會(huì)根據(jù)配置自動(dòng)存儲(chǔ)數(shù)據(jù)到硬盤(pán)上。
這不得不說(shuō)到redis的持久化運(yùn)作方案 http://redis.io/topics/persistence ,其中說(shuō)到的一個(gè)RDB,一個(gè)AOF。RDB更像一個(gè)數(shù)據(jù)庫(kù)備份文件,而AOF是一個(gè)log日志文件。我們可以設(shè)置讓redis再指定時(shí)間、指定更改次數(shù)時(shí)進(jìn)行備份,生成RDB文件;而設(shè)置AOF,可以在操作或時(shí)間過(guò)程后將“日志”寫(xiě)入一個(gè)文件的最末,當(dāng)操作越來(lái)越多,則AOF文件越來(lái)越大。
二者是相輔相成的,通過(guò)二者的配合我們能夠穩(wěn)定地持久地將數(shù)據(jù)存儲(chǔ)于服務(wù)器上。
利用redis寫(xiě)webshell
而我們就是利用這些儲(chǔ)存數(shù)據(jù)的操作,來(lái)進(jìn)行任意文件寫(xiě)入。
redis的配置中,有幾個(gè)關(guān)鍵項(xiàng)目:
dir,指定的是redis的“工作路徑”,之后生成的RDB和AOF文件都會(huì)存儲(chǔ)在這里。
dbfilename,RDB文件名,默認(rèn)為“dump.rdb”
appendonly,是否開(kāi)啟AOF
appendfilename,AOF文件名,默認(rèn)為“appendonly.aof”
appendfsync,AOF備份方式:always、everysec、no
經(jīng)過(guò)我的研究發(fā)現(xiàn),我們可以將dir設(shè)置為一個(gè)目錄a,而dbfilename為文件名b,再執(zhí)行save或bgsave,則我們就可以寫(xiě)入一個(gè)路徑為a/b的任意文件:
?
當(dāng)我們獲得了一個(gè)redis控制臺(tái),我們可以調(diào)用config set/get等命令對(duì)redis的部分配置進(jìn)行修改。
而恰好的是,我們可以通過(guò)config set來(lái)更改dir和dbfilename。也就是說(shuō)我們可以不用修改redis.conf,也不用重啟redis服務(wù)就可以寫(xiě)入任意文件:
config set dir /home/wwwroot/default/
config set dbfilename redis.php
set webshell “<?php phpinfo(); ?>“
save
當(dāng)我們隨便set一個(gè)變量webshell的值為”<?php phpinfo(); ?>”后,即可對(duì)服務(wù)器進(jìn)行g(shù)etshell??梢?jiàn)已寫(xiě)入:
?
導(dǎo)出的RDB實(shí)際上是一個(gè)二進(jìn)制文件,但因?yàn)槠渲邪??php phpinfo(); ?>,所以被解析了:
?
在前圖中,我們可以看到其實(shí)還生成了一個(gè)appendonly.aof,這個(gè)文件名能不能自定義呢?可惜的是,appendfilename的值并不能使用config set命令定義:
但僅有的一個(gè)dbfilename已經(jīng)足夠了。
所以,以后如果掃到redis未授權(quán)訪問(wèn),先別急著提交烏云??纯捶?wù)器有沒(méi)有web服務(wù),如果有,不妨試試能不能拿下webshell。
Mongodb與Redis應(yīng)用指標(biāo)對(duì)比
MongoDB和Redis都是NoSQL,采用結(jié)構(gòu)型數(shù)據(jù)存儲(chǔ)。二者在使用場(chǎng)景中,存在一定的區(qū)別,這也主要由于二者在內(nèi)存映射的處理過(guò)程,持久化的處理方法不同。MongoDB建議集群部署,更多的考慮到集群方案,Redis更偏重于進(jìn)程順序?qū)懭?,雖然支持集群,也僅限于主-從模式。
?
Redis、Memcached與 MongoDB三者的區(qū)別
如果簡(jiǎn)單地比較Redis與Memcached的區(qū)別,大多數(shù)都會(huì)得到以下觀點(diǎn):
1 Redis不僅僅支持簡(jiǎn)單的k/v類型的數(shù)據(jù),同時(shí)還提供list,set,hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。
2 Redis支持?jǐn)?shù)據(jù)的備份,即master-slave模式的數(shù)據(jù)備份。
3 Redis支持?jǐn)?shù)據(jù)的持久化,可以將內(nèi)存中的數(shù)據(jù)保持在磁盤(pán)中,重啟的時(shí)候可以再次加載進(jìn)行使用。
在Redis中,并不是所有的數(shù)據(jù)都一直存儲(chǔ)在內(nèi)存中的。這是和Memcached相比一個(gè)最大的區(qū)別(我個(gè)人是這么認(rèn)為的)。
Redis只會(huì)緩存所有的key的信息,如果Redis發(fā)現(xiàn)內(nèi)存的使用量超過(guò)了某一個(gè)閥值,將觸發(fā)swap的操作,Redis根據(jù)“swappability = age*log(size_in_memory)”計(jì)算出哪些key對(duì)應(yīng)的value需要swap到磁盤(pán)。然后再將這些key對(duì)應(yīng)的value持久化到磁盤(pán)中,同時(shí)在內(nèi)存中清除。這種特性使得Redis可以保持超過(guò)其機(jī)器本身內(nèi)存大小的數(shù)據(jù)。當(dāng)然,機(jī)器本身的內(nèi)存必須要能夠保持所有的key,畢竟這些數(shù)據(jù)是不會(huì)進(jìn)行swap操作的。
同時(shí)由于Redis將內(nèi)存中的數(shù)據(jù)swap到磁盤(pán)中的時(shí)候,提供服務(wù)的主線程和進(jìn)行swap操作的子線程會(huì)共享這部分內(nèi)存,所以如果更新需要swap的數(shù)據(jù),Redis將阻塞這個(gè)操作,直到子線程完成swap操作后才可以進(jìn)行修改。
可以參考使用Redis特有內(nèi)存模型前后的情況對(duì)比:
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ù)的時(shí)候,如果讀取的key對(duì)應(yīng)的value不在內(nèi)存中,那么Redis就需要從swap文件中加載相應(yīng)數(shù)據(jù),然后再返回給請(qǐng)求方。這里就存在一個(gè)I/O線程池的問(wèn)題。在默認(rèn)的情況下,Redis會(huì)出現(xiàn)阻塞,即完成所有的swap文件加載后才會(huì)相應(yīng)。這種策略在客戶端的數(shù)量較小,進(jìn)行批量操作的時(shí)候比較合適。但是如果將Redis應(yīng)用在一個(gè)大型的網(wǎng)站應(yīng)用程序中,這顯然是無(wú)法滿足大并發(fā)的情況的。所以Redis運(yùn)行我們?cè)O(shè)置I/O線程池的大小,對(duì)需要從swap文件中加載相應(yīng)數(shù)據(jù)的讀取請(qǐng)求進(jìn)行并發(fā)操作,減少阻塞的時(shí)間。
redis、memcache、mongoDB 對(duì)比
從以下幾個(gè)維度,對(duì)redis、memcache、mongoDB 做了對(duì)比,歡迎拍磚
1、性能
都比較高,性能對(duì)我們來(lái)說(shuō)應(yīng)該都不是瓶頸
總體來(lái)講,TPS方面redis和memcache差不多,要大于mongodb
2、操作的便利性
memcache數(shù)據(jù)結(jié)構(gòu)單一
redis豐富一些,數(shù)據(jù)操作方面,redis更好一些,較少的網(wǎng)絡(luò)IO次數(shù)
mongodb支持豐富的數(shù)據(jù)表達(dá),索引,最類似關(guān)系型數(shù)據(jù)庫(kù),支持的查詢語(yǔ)言非常豐富
3、內(nèi)存空間的大小和數(shù)據(jù)量的大小
redis在2.0版本后增加了自己的VM特性,突破物理內(nèi)存的限制;可以對(duì)key value設(shè)置過(guò)期時(shí)間(類似memcache)
memcache可以修改最大可用內(nèi)存,采用LRU算法
mongoDB適合大數(shù)據(jù)量的存儲(chǔ),依賴操作系統(tǒng)VM做內(nèi)存管理,吃內(nèi)存也比較厲害,服務(wù)不要和別的服務(wù)在一起
4、可用性(單點(diǎn)問(wèn)題)
對(duì)于單點(diǎn)問(wèn)題,
redis,依賴客戶端來(lái)實(shí)現(xiàn)分布式讀寫(xiě);主從復(fù)制時(shí),每次從節(jié)點(diǎn)重新連接主節(jié)點(diǎn)都要依賴整個(gè)快照,無(wú)增量復(fù)制,因性能和效率問(wèn)題,
所以單點(diǎn)問(wèn)題比較復(fù)雜;不支持自動(dòng)sharding,需要依賴程序設(shè)定一致hash 機(jī)制。
一種替代方案是,不用redis本身的復(fù)制機(jī)制,采用自己做主動(dòng)復(fù)制(多份存儲(chǔ)),或者改成增量復(fù)制的方式(需要自己實(shí)現(xiàn)),一致性問(wèn)題和性能的權(quán)衡
Memcache本身沒(méi)有數(shù)據(jù)冗余機(jī)制,也沒(méi)必要;對(duì)于故障預(yù)防,采用依賴成熟的hash或者環(huán)狀的算法,解決單點(diǎn)故障引起的抖動(dòng)問(wèn)題。
mongoDB支持master-slave,replicaset(內(nèi)部采用paxos選舉算法,自動(dòng)故障恢復(fù)),auto sharding機(jī)制,對(duì)客戶端屏蔽了故障轉(zhuǎn)移和切分機(jī)制。
5、可靠性(持久化)
對(duì)于數(shù)據(jù)持久化和數(shù)據(jù)恢復(fù),
redis支持(快照、AOF):依賴快照進(jìn)行持久化,aof增強(qiáng)了可靠性的同時(shí),對(duì)性能有所影響
memcache不支持,通常用在做緩存,提升性能;
MongoDB從1.8版本開(kāi)始采用binlog方式支持持久化的可靠性
6、數(shù)據(jù)一致性(事務(wù)支持)
Memcache 在并發(fā)場(chǎng)景下,用cas保證一致性
redis事務(wù)支持比較弱,只能保證事務(wù)中的每個(gè)操作連續(xù)執(zhí)行
mongoDB不支持事務(wù)
7、數(shù)據(jù)分析
mongoDB內(nèi)置了數(shù)據(jù)分析的功能(mapreduce),其他不支持
8、應(yīng)用場(chǎng)景
redis:數(shù)據(jù)量較小的更性能操作和運(yùn)算上
memcache:用于在動(dòng)態(tài)系統(tǒng)中減少數(shù)據(jù)庫(kù)負(fù)載,提升性能;做緩存,提高性能(適合讀多寫(xiě)少,對(duì)于數(shù)據(jù)量比較大,可以采用sharding)
MongoDB:主要解決海量數(shù)據(jù)的訪問(wèn)效率問(wèn)題
評(píng)論