建站
咨詢
售后
建站咨詢
新聞中心
Redis（Remote Dictionary Server）是一個(gè)開源的內(nèi)存數(shù)據(jù)庫，提供高效的數(shù)據(jù)結(jié)構(gòu)存儲、操作和訪問功能。其一般由五個(gè)主要組件構(gòu)成：客戶端，協(xié)議，服務(wù)器，數(shù)據(jù)存儲和命令。
1. 優(yōu)勢
Redis的優(yōu)勢在于它的存儲方式。相比傳統(tǒng)的存儲方式，它更適應(yīng)Web應(yīng)用的特點(diǎn)，提供了很好的擴(kuò)展性和性能。
Redis采用內(nèi)存存儲方式，數(shù)據(jù)全部存放在內(nèi)存中，保證了高速的讀寫效率。同時(shí)，Redis也提供了非阻塞的IO操作，這對于并發(fā)處理能力也提供了很好的保障。
另外，由于Redis采用的是鍵值對存儲方式，因此在進(jìn)行非關(guān)系型數(shù)據(jù)的存儲時(shí)更加簡單。開發(fā)人員可以非常直觀地使用Redis的數(shù)據(jù)結(jié)構(gòu)類型來存儲數(shù)據(jù)，包括字符串、哈希表、列表、和有序等。
另外，Redis也支持?jǐn)?shù)據(jù)持久化，數(shù)據(jù)可以存儲在磁盤中，以避免內(nèi)存容量的限制。
2. 適用場景
由于Redis的優(yōu)勢，它在很多場景下都能提供出色的服務(wù)。以下是幾個(gè)適用場景的舉例：
2.1 緩存
對于需要頻繁讀取而不經(jīng)常修改的數(shù)據(jù)，Redis的緩存功能可以通過臨時(shí)保存數(shù)據(jù)來提升訪問速度。相比傳統(tǒng)的硬盤緩存，Redis的緩存讀取速度更快、處理能力更強(qiáng)，能夠滿足高并發(fā)和多機(jī)訪問的需求。
2.2 消息隊(duì)列
Redis支持發(fā)布/訂閱模式，可以作為消息隊(duì)列使用。在一些異步通信的場合，它能夠緩存發(fā)送方和接收方之間的信息，提高了消息傳遞的可靠性和數(shù)據(jù)的實(shí)時(shí)性。
2.3 會話存儲
對于需要記錄用戶會話數(shù)據(jù)的場景，Redis的快速讀寫能力可以保護(hù)用戶數(shù)據(jù)的完整性，同時(shí)可以便于管理、維護(hù)和擴(kuò)展。
2.4 排行榜
在在線游戲或者社交媒體應(yīng)用中，Redis可以輕松的實(shí)現(xiàn)排行榜功能。Redis的有序可以按照分值對數(shù)據(jù)進(jìn)行排序，并支持對有序進(jìn)行多種操作。
2.5 地理位置
對于需要存儲地理位置信息的場景，Redis的哈希表數(shù)據(jù)結(jié)構(gòu)可以提供空間索引，支持對范圍查詢和查找最近的操作，可以實(shí)現(xiàn)周邊搜索等應(yīng)用。
3.
Redis是一個(gè)優(yōu)秀的內(nèi)存數(shù)據(jù)庫，其高速讀寫效率和多種數(shù)據(jù)結(jié)構(gòu)類型使其適用于很多Web應(yīng)用場景。同時(shí)，Redis還具有強(qiáng)大的擴(kuò)展性、多機(jī)訪問能力和高并發(fā)處理能力。在開發(fā)Web應(yīng)用時(shí)，選擇Redis作為數(shù)據(jù)存儲方式，能夠提高應(yīng)用的穩(wěn)定性和性能，從而更好地滿足用戶需求。
相關(guān)問題拓展閱讀：
- 總是聽說很多javaweb系統(tǒng)用redis或memcache做緩存，具體怎么操作的
- redis主要解決了什么問題
總是聽說很多javaweb系統(tǒng)用redis或memcache做緩存，具體怎么操作的
其實(shí)就相當(dāng)于在應(yīng)用程序和數(shù)據(jù)庫之間開了一塊內(nèi)存區(qū)域，將一些高頻訪問的數(shù)據(jù)放在其中，避免每次都請求數(shù)據(jù)庫。至于之所以用memcached和redis，而不是自己在程序里開個(gè)hashmap，是因?yàn)檫@塊區(qū)域可以共享且容易管理，在集群環(huán)境下更方便使用。
有些做法是直接將數(shù)據(jù)序列化后存在redis的string或是memcached中，也有些其他做法是利用redis特有的數(shù)據(jù)結(jié)構(gòu)存儲一些關(guān)系，例如用sorted set存排行榜，string用來計(jì)數(shù)，set做一些倒排索引、用戶好友關(guān)系之類的。我覺得這些都可以稱之為緩存。
其實(shí)就相當(dāng)于在應(yīng)用程序和數(shù)據(jù)庫之間開了一塊內(nèi)存區(qū)域，將一些高頻訪問的數(shù)據(jù)放在其中，避免每次都請求數(shù)據(jù)庫。至于之所以用memcached和redis，而不是自己在程序里開個(gè)hashmap，是因?yàn)檫@塊區(qū)域可以共享且容易管理，在集群環(huán)境下更方便使用。
有些做法是直接將數(shù)據(jù)序列化后存在redis的string或是memcached中，也有些其他做法是利用redis特有的數(shù)據(jù)結(jié)構(gòu)存儲一些關(guān)系，例如用sorted set存排行榜，string用來計(jì)數(shù)，set做一些倒排索引、用戶好友關(guān)系之類的。我覺得這些都可以稱之為緩存。
redis是一個(gè)內(nèi)存數(shù)據(jù)庫（它的數(shù)據(jù)存儲在內(nèi)存中，一段時(shí)間之后會自動讀入硬盤），和關(guān)系型數(shù)據(jù)庫（MySQL，oracle）有很大的不同，但它也是一個(gè)數(shù)據(jù)庫，它需要一套自己的操作API。既然是緩存，那么你就需要把那些經(jīng)常需要讀取的數(shù)據(jù)放到redis中就OK，具體怎么操作？不就是去學(xué)習(xí)怎么連接redis，然后用redis的操作API做增刪改查嗎。。。
redis主要解決了什么問題
redis是內(nèi)存數(shù)據(jù)庫，訪問速度非?？欤阅軌蚪鉀Q的也都是這些緩存類型的問題，如下：
1、會話緩存（Session
Cache）
最常用的一種使用Redis的情景是會話緩存（session
cache）。用Redis緩存會話比其他存儲（如Memcached）的優(yōu)勢在于：Redis提供持久化。當(dāng)維護(hù)一個(gè)不是嚴(yán)格要求一致性的緩存時(shí)，如果用戶的購物車信息全部丟失，大部分人都會不高興的，現(xiàn)在，他們還會這樣嗎？
幸運(yùn)的是，隨著
Redis
這些年的改進(jìn)，很容易找到怎么恰當(dāng)?shù)氖褂肦edis來緩存會話的文檔。甚至廣為人知的商業(yè)平臺Magento也提供Redis的插件。
2、全頁緩存（FPC）
除基本的會話token之外，Redis還提供很簡便的FPC平臺?；氐揭恢滦詥栴}，即使重啟了Redis實(shí)例，因?yàn)橛写疟P的持久化，用戶也不會看到頁面加載速度的下降，這是一個(gè)極大改進(jìn)，類似PHP本地FPC。
再次以Magento為例，Magento提供一個(gè)插件來使用Redis作為全頁緩存后端。
此外，對WordPress的用戶來說，Pantheon有一個(gè)非常好的插件
wp-redis，這個(gè)插件能幫助你以最快速度加載你曾瀏覽過的頁面。
3、隊(duì)列
Reids在內(nèi)存存儲引擎領(lǐng)域的一大優(yōu)點(diǎn)是提供
list
和
set
操作，這使得Redis能作為一個(gè)很好的消息隊(duì)列平臺來使用。Redis作為隊(duì)列使用的操作，就類似于本地程序語言（如Python）對
list
的
push/pop
操作。
如果你快速的在Google中搜索“Redis
queues”，你馬上就能找到大量的開源項(xiàng)目，這些項(xiàng)目的目的就是利用Redis創(chuàng)建非常好的后端工具，以滿足各種隊(duì)列需求。例如，Celery有一個(gè)后臺就是使用Redis作為broker，你可以從這里去查看。
排行榜/計(jì)數(shù)器
Redis在數(shù)扮雹內(nèi)存中對數(shù)字進(jìn)行遞增或遞減的操作實(shí)現(xiàn)的非常好。（Set）和有序缺蔽（Sorted
Set）也使得我們在執(zhí)行這些操作的時(shí)候變的非常簡單，Redis只是正好提供了這兩種數(shù)據(jù)結(jié)構(gòu)。所以，我們要從排序中獲取到排名最靠前的10個(gè)用戶–我們稱之為“user_scores”，我們只需要像下面一樣執(zhí)行即可：
當(dāng)然，這是假定你是根據(jù)你用戶的分?jǐn)?shù)做遞增的排序。如果你想返回用戶及用戶的分?jǐn)?shù)，你需要這樣執(zhí)行：
ZRANGE
user_scores
WITHSCORES
Agora
Games就是一個(gè)很好的例子，用Ruby實(shí)現(xiàn)的，它的排行榜就是使用Redis來存儲數(shù)據(jù)的，你可以在這里看到。
5、發(fā)布/訂閱
最后（但肯定不是最不重要的）是Redis的發(fā)布/訂閱功能。發(fā)布/訂閱的使用場景確實(shí)非常多。我已看見人們在社交網(wǎng)絡(luò)連接中使用，還可作為基于發(fā)布/訂閱的腳本觸發(fā)器，甚至用Redis的發(fā)布/訂閱功能來建立聊天系統(tǒng)?。ú唬@是真的，你可以去核實(shí)）。
Redis提供的所有特性中，我感覺這個(gè)薯帆是喜歡的人最少的一個(gè)，雖然它為用戶提供如果此多功能。
等等？
Redis 常見的性能問題和解決方法
1.Master寫內(nèi)存快照
save命令調(diào)度rdbSave函數(shù)，會阻塞主線程的工作，當(dāng)快照比較大時(shí)對性能影響是非常大的，會間斷性暫停服務(wù)，所以Master更好不要寫內(nèi)存快照。
2.Master AOF持久化
如果不重寫AOF文件，這個(gè)持久化方式對性能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啟的恢復(fù)速度。
3.Master調(diào)用BGREWRITEAOF
Master調(diào)用BGREWRITEAOF重寫AOF文件，AOF在重寫的時(shí)候會占大量的CPU和內(nèi)存資源，導(dǎo)致服務(wù)load過高，出現(xiàn)短暫服務(wù)暫?，F(xiàn)象。
下面是我的一個(gè)實(shí)際項(xiàng)目的情況，大概情況是這樣的：一個(gè)Master，4個(gè)Slave，沒有Sharding機(jī)制，僅是讀寫分離，Master負(fù)責(zé)寫入操作和AOF日志備份，AOF文件大概5G，Slave負(fù)責(zé)讀操作，當(dāng)Master調(diào)用BGREWRITEAOF時(shí)，Master和Slave負(fù)載會突然陡增，Master的寫入請求基本上都不響應(yīng)了，持續(xù)了大概5分鐘，Slave的讀請求過也半無法及時(shí)響應(yīng)，Master和Slave的服務(wù)器負(fù)載圖如下：
Master Server load：
Slave server load：
上面的情況本來不會梁喊滾也不應(yīng)該發(fā)生的，是因?yàn)橐郧癕aster的這個(gè)機(jī)器是Slave，在上面有一個(gè)shell定時(shí)任務(wù)在每天的上午10點(diǎn)調(diào)用BGREWRITEAOF重寫AOF文件，后來由于Master機(jī)器down了，就把備份的這個(gè)Slave切成Master了，但是這個(gè)定時(shí)任務(wù)忘記刪除了，就導(dǎo)致了上面悲劇情況的發(fā)生，原因還是找了幾天才找到的。
將no-appendfsync-on-rewrite的配置設(shè)為yes可以緩解這個(gè)問題，設(shè)置為yes表示rewrite期間對新寫操作不fsync，暫時(shí)存在內(nèi)存中，等rewrite完成后再寫入。更好是不開啟Master的AOF備份功能。
4.Redis主從復(fù)制的性能問題
之一次Slave向Master同步的實(shí)現(xiàn)是：Slave向Master發(fā)出同步請求，Master先dump出rdb文件，然后將rdb文件全量傳輸給slave，然后Master把緩存的命令轉(zhuǎn)發(fā)給Slave，初次同步完成。第二次以及以后的同步實(shí)現(xiàn)是：Master將變量的快照直接實(shí)時(shí)依次發(fā)送給各個(gè)Slave。不管什么原因?qū)е耂lave和Master斷開重連都會重復(fù)以上過程。Redis的主從復(fù)制是建立在內(nèi)存快照的持久化基礎(chǔ)上，只要有Slave就一定會有內(nèi)存快照發(fā)生。雖然Redis宣稱主從復(fù)制無阻塞，但由于Redis使用單線程服務(wù)，如果Master快照文件比較大，那么之一次全量傳輸會耗費(fèi)比較長時(shí)間，且文件傳輸過程中Master可能無法提供服務(wù)，也就是說服務(wù)會中斷，對于關(guān)鍵服務(wù)，這個(gè)后果也是很可怕的。
以上1.2.3.4根本問題的原因都離不開系統(tǒng)io瓶頸問題，也就是硬盤讀寫速度不夠快，主進(jìn)程 fsync()/write() 操作被阻塞。
5.單點(diǎn)故障問題
由于目前Redis的主從滲滑復(fù)制還不夠成熟，所以存在明顯的單點(diǎn)故障問題，這個(gè)目前只能自己做方案解決，如：主動復(fù)制，Proxy實(shí)現(xiàn)Slave對Master的替換等，這個(gè)也是Redis作者目前比較優(yōu)先的任務(wù)之一，作者的解決方案思路簡單優(yōu)雅，詳情可見 Redis Sentinel design draft
總結(jié)
Master更好不要做任何持久化工作，包括內(nèi)存快照和AOF日志文件，特別是不要啟用內(nèi)存快照做持久化。
如果數(shù)據(jù)比較關(guān)鍵，某個(gè)Slave開啟AOF備份數(shù)據(jù)，策略為每秒同步一次。
為了主從復(fù)制的速度和連接的穩(wěn)定性，Slave和Master更好在同一個(gè)局域網(wǎng)內(nèi)。
盡量避免在壓力較大的主庫上增加從庫
為了Master的穩(wěn)定性，主從復(fù)制不要用圖狀結(jié)構(gòu)，用單向鏈表結(jié)構(gòu)更穩(wěn)定，即主從關(guān)系為：Master
內(nèi)存數(shù)據(jù)庫 redis 存儲的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于內(nèi)存數(shù)據(jù)庫 redis 存儲,Redis：高效存儲的內(nèi)存數(shù)據(jù)庫,總是聽說很多javaweb系統(tǒng)用redis或memcache做緩存，具體怎么操作的,redis主要解決了什么問題的信息別忘了在本站進(jìn)行查找喔。
成都服務(wù)器托管選創(chuàng)新互聯(lián)，先上架開通再付費(fèi)。
創(chuàng)新互聯(lián)（www.cdcxhl.com）專業(yè)-網(wǎng)站建設(shè),軟件開發(fā)老牌服務(wù)商！微信小程序開發(fā),APP開發(fā),網(wǎng)站制作，網(wǎng)站營銷推廣服務(wù)眾多企業(yè)。電話：028-86922220
當(dāng)前文章：Redis：高效存儲的內(nèi)存數(shù)據(jù)庫 (內(nèi)存數(shù)據(jù)庫 redis 存儲)
分享路徑：http://m.5511xx.com/article/djpddjs.html
