關于redis的幾件小事(一)redis的使用目的與問題

1.redis是用來干嘛的？

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes with radius queries and streams. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster.

通過上面redis官網(wǎng)的說明可以看出，redis是一個可以對內(nèi)存數(shù)據(jù)結(jié)構(gòu)進行存儲的東西，它可以用作數(shù)據(jù)庫、緩存和消息代理。它支持數(shù)據(jù)結(jié)構(gòu)，如字符串，散列，列表，集合，帶有范圍查詢的排序集，位圖，超級日志，具有半徑查詢和流的地理空間索引。Redis具有內(nèi)置復制，Lua腳本，LRU驅(qū)逐，事務和不同級別的磁盤持久性，并通過Redis Sentinel提供高可用性并使用Redis Cluster自動分區(qū)。
在項目中主要用來用作數(shù)據(jù)的緩存，將數(shù)據(jù)緩存在redis中，減輕對底層數(shù)據(jù)庫的訪問壓力，獲得更高的并發(fā)和更快的請求響應速度。
2.在項目中如何使用?
我們知道，項目中的數(shù)據(jù)一般情況下都是存在于數(shù)據(jù)庫當中的，而且數(shù)據(jù)庫的并發(fā)性能不是特別高，如果同時接收到大量的請求，數(shù)據(jù)庫可能就會崩掉，而且sql查詢會消耗一定的時間，增加請求的響應時間，所以不用緩存會出現(xiàn)系統(tǒng)無法支撐大量的并發(fā)情況，請求響應時間會變長等問題。
如果我們在第一次訪問某個數(shù)據(jù)的時候，比如根據(jù)一個訂單id獲取訂單的詳細信息，將這條數(shù)據(jù)再返回的時候，也放到緩存里面去，那么下次就可以直接在緩存里面返回數(shù)據(jù)，不必去查詢數(shù)據(jù)庫，這樣就可以減輕數(shù)據(jù)庫的訪問壓力，而且緩存在內(nèi)存中，勢必要比直接訪問數(shù)據(jù)庫的速度要快很多，這樣也就減小了請求的響應時間，redis在項目中就主要使用來解決數(shù)據(jù)的緩存問題。
3.為啥要使用緩存？
使用緩存的目的主要有兩個：
（1）高性能
比如說有一個很復雜的sql數(shù)據(jù)查詢，這個查詢要耗費大量的時間，如果每次都直接取數(shù)據(jù)查詢，那必然會對請求響應時間造成很大的影響，如果能在第一次查詢完畢之后，將其直接保存在緩存當中，下次查詢的時候，直接在緩存中拿走現(xiàn)成的數(shù)據(jù)，這樣就會大大縮短請求的響應時間。
（2）高并發(fā)
我們知道數(shù)據(jù)庫能承受的并發(fā)是有限的，那么在流量高峰期(比如，搶購、打折、秒殺等等)，會有大量的請求進入我們的系統(tǒng)，比如查詢某個商品的詳情，如果我們沒有緩沖，那么給次查詢都要走數(shù)據(jù)庫，假如我們的數(shù)據(jù)庫每秒只能接受2000個請求，結(jié)果一秒鐘進來了5000個請求，那么數(shù)據(jù)庫就直接崩掉了，毫無高并發(fā)可言，而如果我們中間具有緩存服務，那么在第一個用戶查詢商品詳情時(或者提前將放好)我們可以直接將商品的詳情信息數(shù)據(jù)放到緩存里面，這樣在后續(xù)用戶查詢時就可以直接走緩存，不走數(shù)據(jù)庫，緩存是基于內(nèi)存的，它的訪問速度快，并發(fā)高；因此就可以提供一個高并發(fā)的支持。
4.用了緩存會出現(xiàn)什么問題？
主要常見的有下面三個問題
1）緩存與數(shù)據(jù)庫雙寫不一致
2）緩存雪崩
3）緩存穿透
4）緩存并發(fā)競爭

Flink系列精華文章合集：

• Flink入門

• Flink DataSet&DataSteam API

• Flink集群部署

• Flink重啟策略

• Flink分布式緩存

• Flink重啟策略

• Flink中的Time

• Flink中的窗口

• Flink的時間戳和水印

• Flink廣播變量

• Flink-Kafka-connetor

• Flink-Table&SQL

• Flink實戰(zhàn)項目-熱銷排行

• Flink-Redis-Sink

• Flink消費Kafka寫入Mysql

? ??后面會繼續(xù)更新更多實戰(zhàn)案例...