大家好，今天小編來為大家解答redis使用場景以及優缺點這個問題，redis五種類型使用場景很多人還不知道，現在讓我們一起來看看吧！
Redis非關系性數據庫有什么特點
Redis非關系型數據庫簡介
Redis是一款開源的、高性能的一個第三方軟件，就是一個key-value存儲系統。它常被稱作是一款數據結構服務器（datastructureserver）。Redis的鍵值可以包括字符串（strings）、哈希（hashes）、列表（lists）、集合（sets）和有序集合（sortedsets）等數據類型。對于這些數據類型，你可以執行原子操作。例如：對字符串進行附加操作（append）；遞增哈希中的值；向列表中增加元素；計算集合的交集、并集與差集等。
redis是一種Nosql數據庫，Nosql全稱是NotOnlySQL，是一種不同于關系型數據庫的數據庫管理系統設計方式。對NoSQL最普遍的解釋是“非關系型的”，強調Key-Value存儲和文檔數據庫的優點，而不是單純的反對RDBMS.
為了獲得優異的性能，Redis采用了內存中數據集（dataset）的方式。根據使用場景的不同，你可以每隔一段時間將數據集轉存到磁盤上來持久化數據，或者在日志尾部追加每一條操作命令。
Redis同樣支持主從復制（master-slavereplication），并且具有非?？焖俚姆亲枞状瓮?non-blockingfirstsynchronization)、網絡斷開自動重連等功能。同時Redis還具有其它一些特性，其中包括簡單的check-and-set機制、pub/sub和配置設置等，以便使得Redis能夠表現得更像緩存（cache）。
Redis還提供了豐富的客戶端，如ServiceStack.Redis，以便支持現階段流行的大多數編程語言。詳細的支持列表可以參看Redis官方文檔：http://redis.io/clients。Redis自身使用ANSIC來編寫，并且能夠在不產生外部依賴（externaldependencies）的情況下運行在大多數POSIX系統上，例如：Linux、*BSD、OSX和Solaris等。
Redis是啥
想要了解Redis，先從Redis是什么？為何要用Redis？有哪些特性，以及其集群架構來幾個方面來了解。
Redis簡介Redis是一個開源（BSD許可）的、內存中的數據結構存儲系統，它可以用作數據庫、緩存和消息中間件。為什么要用Redis在高并發場景下，如果需要經常連接結果變動頻繁的數據庫，會導致數據庫讀取及存取的速度變慢，數據庫壓力極大。因此我們需要通過緩存來減少數據庫的壓力，使得大量的訪問進來能夠命中緩存，只有少量的需要到數據庫層。由于緩存基于內存，可支持的并發量遠遠大于基于硬盤的數據庫。所以對于高并發設計，緩存的設計是必不可少的一環。而Redis作為比較熱門的內存存儲系統之一，由于其對數據持久化的支持，種類豐富的數據結構，使其定位更傾向于內存數據庫，適用于對讀寫效率要求都很高、數據處理業務復雜和對安全性要求較高的系統。Redis特征
單線程，利用redis隊列技術將訪問變為串行訪問，消除了傳統數據庫串行控制的開銷。Redis的線程模型：Redis支持數據的持久化，包括RDB的全量持久化，或者AOF的增量持久化，從而使得Redis掛了，數據是有機會恢復的。也可以將內存中的數據保持在磁盤中，重啟的時候可以再次加載進行使用。分布式架構，讀寫分離。支持的數據結構豐富。Redis不僅僅支持簡單的key-value類型的數據，同時還提供list、set、zset、hash等數據結構的存儲。Redis支持數據的備份，提供成熟的主備同步，故障切換的功能，從而保證了高可用。RedisCluster架構Redis搭建方式有很多種，本章主要介紹RedisCluster集群構建方式：Redis3.0之后版本支持RedisCluster集群，RedisCluster采用無中心結構，每個節點保存數據和整個集群狀態，每個節點都和其他所有節點連接。RedisCluster為了保證數據的高可用性，加入了主從模式，一個主節點對應一個或多個從節點，主節點提供數據存取，從節點則是從主節點拉取數據備份，當這個主節點掛掉后，就會有這個從節點選取一個來充當主節點，從而保證集群不會掛掉。主從結構，一是為了純粹的冗余備份，二是為了提升讀性能，比如很消耗性能的SORT就可以由從服務器來承擔。Redis的主從同步是異步進行的，這意味著主從同步不會影響主邏輯，也不會降低redis的處理性能。主從架構中，可以考慮關閉主服務器的數據持久化功能，只讓從服務器進行持久化，這樣可以提高主服務器的處理性能。在主從架構中，從服務器通常被設置為只讀模式，這樣可以避免從服務器的數據被誤修改。redis隊列與消息隊列優缺點
Redis隊列和消息隊列它們各自的優缺點如下：
Redis隊列是基于內存的隊列實現方式，具有以下優點：
1.速度快：由于Redis隊列是基于內存實現的，讀寫速度非?？?，適合于高并發場景。
2.簡單易用：Redis隊列的實現非常簡單，易于使用和部署，適合于小型應用。
3.支持多種數據結構：Redis隊列支持多種數據結構，包括列表、哈希表、集合等，可以滿足不同的需求。
但是Redis隊列也有一些缺點：
1.容量有限：由于Redis隊列是基于內存的，容量有限，如果隊列中的數據量過大，可能會導致內存溢出。
2.數據丟失：由于Redis隊列是基于內存實現的，如果Redis服務器宕機或者出現其他故障，可能會導致隊列中的數據丟失。
消息隊列是一種分布式的隊列實現方式，具有以下優點：
1.可靠性高：消息隊列通常采用持久化存儲方式，即使出現故障也不會導致數據丟失。
2.擴展性好：消息隊列可以采用分布式架構，支持多臺服務器共同處理消息，可以很好地擴展應用。
3.支持多種協議：消息隊列支持多種協議，包括AMQP、JMS、MQTT等，可以滿足不同的需求。
但是消息隊列也有一些缺點：
1.配置復雜：消息隊列的配置相對復雜，需要考慮消息的路由、持久化、重試等多個因素。
2.性能較低：由于消息隊列需要進行網絡傳輸和持久化存儲，相對于Redis隊列，性能較低。
綜上所述，Redis隊列適合于速度要求較高、數據量較小的場景，而消息隊列適合于可靠性要求較高、數據量較大、分布式處理的場景。
jwt與token+redis，哪種方案更好用
1.問題描述
jwt與token+redis，哪種方案更好用？
問題結論
剛好最近有項目使用了jwt，而且是定制化的jwt的認證機制，就個人的理解而言，各自有其優缺點，并且針對不同的場景需要進行約束性開發，如用戶剔除、同一用戶每2h只生成一次jwt等。
2.Token機制簡述
2.1Token的用途
用戶在登錄APP時，APP端會發送加密的用戶名和密碼到服務器，服務器驗證用戶名和密碼，如果驗證成功，就會生成相應位數的字符產作為token存儲到服務器中，并且將該token返回給APP端。以后APP再次請求時，凡是需要驗證的地方都要帶上該token，然后服務器端驗證token，成功返回所需要的結果，失敗返回錯誤信息，讓用戶重新登錄。其中，服務器上會給token設置一個有效期，每次APP請求的時候都驗證token和有效期。在存儲的時候把token進行對稱加密存儲，用到的時候再解密。文章最開始提到的簽名sign：將請求URL、時間戳、token三者合并，通過算法進行加密處理。
2.2token+redis機制
用戶驗證通過后，服務端通過如uuid相關的方法，生成token，存儲用戶信息。當請求服務時，客戶端將token帶上來，進行查詢驗證，如token存在并在有限期內，請求有效，否則請求非法。token+redis機制是中心化的，每次驗證token有效性時，都需要訪問redis，其核心優點實服務端可以主動讓token失效，缺點是每次都要進行redis查詢。占用redis存儲空間。
2.3jwt機制
這是一種無狀態身份驗證機制，因為用戶狀態永遠不會保存在服務器內存中。服務器受保護的路由將在授權頭中檢查有效的JWT，如果存在，則允許用戶訪問受保護的資源。由于JWT是獨立的，所有必要的信息都在那里，減少了多次查詢數據庫的需求。
Javajwt普遍選用java-jwt工具包依賴，gradle依賴：compile'com.auth0:java-jwt:3.2.0'用戶發起登錄請求，驗證通過后，服務端創建一個加密后的JWT信息，作為Token返回。在后續請求中JWT信息作為請求頭，發給服務端。服務端拿到JWT之后進行解密，正確解密表示此次請求合法，驗證通過；解密失敗說明Token無效或者已過期。jwt的有點主要有：a.其是去中心化的，便于分布式系統使用；2.基本信息可以直接放在token中。user_id，session_id；3.功能權限信息可以直接放在token中。用bit位表示用戶所具有的功能權限。其缺點有：服務端無法主動讓token失效，另一個是無法很好的控制payload的數據量。
3.小結
jwt和token+redis兩種方案，沒有最優，只有結合不同的業務場景，需求最適合的方案。就比如token2h過期，同一用戶每1.5h只生成一次token，當兩次token并存時，同時有效。大家可以考慮在這兩種方案的前提下，分別如何實現？
作者：夕陽雨晴，歡迎關注我的頭條號：偶爾美文，主流Java，為你講述不一樣的碼農生活。
redis 分布式鎖有啥優點
Redis分布式鎖的優點：在于Redis是基于內存的，并發性能好；缺點是需要考慮原子性、超時、誤刪等場景，并且如果要是獲取鎖失敗時，客戶端只能自旋等待，在高并發情況下，性能消耗較大。
在CAP（一致性（Consistency）、可用性（Availability）、分區容錯性（Partitiontolerance））模型中，如果是分布式環境，只能滿足其中兩個，但是在分布式環境下，分區容錯性又不能不要（如果不要就是單機），所以只能選擇AP或者CP。其中分布式鎖是CP模型，但是Redis是AP模型，這樣就決定了Redis分布式鎖如果不要求強一致性的話，可以使用Redis分布式鎖，例如社交場景等；但是如果要求強一致性的話，例如金融場景，就不能使用Redis分布式鎖，而是要使用CP模型特點的分布式鎖，例如Zookeeper、etcd等。
好了，文章到這里就結束啦，如果本次分享的redis使用場景以及優缺點和redis五種類型使用場景問題對您有所幫助，還望關注下本站哦！
