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

Flink系列精華文章合集：

• Flink入門

• Flink DataSet&DataSteam API

• Flink集群部署

• Flink重啟策略

• Flink分布式緩存

• Flink重啟策略

• Flink中的Time

• Flink中的窗口

• Flink的時間戳和水印

• Flink廣播變量

• Flink-Kafka-connetor

• Flink-Table&SQL

• Flink實戰項目-熱銷排行

• Flink-Redis-Sink

• Flink消費Kafka寫入Mysql

? ??后面會繼續更新更多實戰案例...