① java面試中redis，mongodb類的，會問哪些問題，怎麼回答
1、可能會問nosql和關系型資料庫的區別：
優點：
1）成本：nosql資料庫簡單易部署，基本都是開源軟體，不需要像使用Oracle那樣花費大量成本購買使用，相比關系型資料庫價格便宜
2）查詢速度：nosql資料庫將數據存儲於緩存之中，關系型資料庫將數據存儲在硬碟中，自然查詢速度遠不及nosql資料庫
3）存儲數據的格式：nosql的存儲格式是key,value形式、文檔形式、圖片形式等等，所以可以存儲基礎類型以及對象或者是集合等各種格式，而資料庫則只支持基礎類型
4）擴展性：關系型資料庫有類似join這樣的多表查詢機制的限制導致擴展很艱難
缺點：
1）維護的工具和資料有限，因為nosql是屬於新的技術，不能和關系型資料庫10幾年的技術同日而語。
2）不提供對sql的支持，如果不支持sql這樣的工業標准，將產生一定用戶的學習和使用成本
3）不提供關系型資料庫對事物的處理
2、介紹下redis和mongodb：
自行google。
3、應用場景：
redis：
a.主要是做熱點數據緩存。
b.數據過期處理。
c.消息隊列等功能。
d.計數，例如投票等。
mongodb：
mongodb的主要目標是在鍵/值存儲方式（提供了高性能和高度伸縮性）以及傳統的RDBMS系統（豐富的功能）架起一座橋梁，集兩者的優勢於一身。mongo適用於以下場景：
a.網站數據：mongo非常適合實時的插入，更新與查詢，並具備網站實時數據存儲所需的復制及高度伸縮性。
b.緩存：由於性能很高，mongo也適合作為信息基礎設施的緩存層。在系統重啟之後，由mongo搭建的持久化緩存可以避免下層的數據源過載。
c.大尺寸、低價值的數據：使用傳統的關系資料庫存儲一些數據時可能會比較貴，在此之前，很多程序員往往會選擇傳統的文件進行存儲。
d.高伸縮性的場景：mongo非常適合由數十或者數百台伺服器組成的資料庫。
e.用於對象及JSON數據的存儲：mongo的BSON數據格式非常適合文檔格式化的存儲及查詢。
4、支持的數據類型:
內容比較多，自行將網上的信息整理一下。
② 多級緩存的讀取順序
讀取數據順序:L1、L2、L3、內存、外部存儲器。
傳統的cpu通過fsb直連內存的方式顯然就會因為內存訪問的等待，導致cpu吞吐量下降，內存成為性能瓶頸。同時又由於內存訪問的熱點數據集中性，所以需要在cpu與內存之間做一層臨時的存儲器作為高速緩存。
應用於SOA甚至微服務的場景，內存相當於存儲業務數據的持久化資料庫，其吞吐量肯定是遠遠小於緩存的，而對於java程序來講，本地的jvm緩存優於集中式的redis緩存。關系型資料庫操作方便、易於維護且訪問數據靈活，但是隨著數據量的增加，其檢索、更新的效率會越來越低。所以在高並發低延遲要求復雜的場景，要給資料庫減負，減少其壓力。
③ Redis是什麼，用來做什麼
Redis是一個nosql資料庫，可以存儲key-value值。因為其底層實現中，數據讀寫是基於內存，速度非常快，所以常用於緩存；進而因其為獨立部署的中間件，常用於分布式緩存的實現方案。
常用場景有：緩存、秒殺控制、分布式鎖。
雖然其是基於內存讀寫，但底層也有持久化機制；同時具備集群模式；不用擔心其可用性。
關於Redis的使用，可以參考《Redis的使用方法、常見應用場景》
④ 資料庫表結構設計，常見的資料庫管理系統
一、數據場景 1、表結構簡介 任何工具類的東西都是為了解決某個場景下的問題，比如Redis緩存系統熱點數據，ClickHouse解決海量數據的實時分析，MySQL關系型資料庫存儲結構化數據。數據的存儲則需要設計對應的表結構，清楚的表結構，有助於快速開發業務，和理解系統。表結構的設計通常從下面幾個方面考慮：業務場景、設計規范、表結構、欄位屬性、數據管理。
2、用戶場景
例如存儲用戶基礎信息數據，通常都會下面幾個相關表結構：用戶信息表、單點登錄表、狀態管理表、支付賬戶表等。
用戶信息表
存儲用戶三要素相關信息：姓名，手機號，身份證，登錄密碼，郵箱等。
CREATE TABLE `ms_user_center` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用戶ID', `user_name` varchar(20) NOT NULL COMMENT '用戶名', `real_name` varchar(20) DEFAULT NULL COMMENT '真實姓名', `pass_word` varchar(32) NOT NULL COMMENT '密碼', `phone` varchar(20) NOT NULL COMMENT '手機號', `email` varchar(32) DEFAULT NULL COMMENT '郵箱', `head_url` varchar(100) DEFAULT NULL COMMENT '用戶頭像URL', `card_id` varchar(32) DEFAULT NULL COMMENT '身份證號', `user_sex` int(1) DEFAULT '1' COMMENT '用戶性別:0-女,1-男', `create_time` datetime DEFAULT NULL COMMENT '創建時間', `update_time` datetime DEFAULT NULL COMMENT '更新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶表'; 單點登錄表
用意是在多個業務系統中，用戶登錄一次就可以訪問所有相互信任的業務子系統，是聚合業務平台常用的解決方案。
CREATE TABLE `ms_user_sso` ( `user_id` int(11) NOT NULL COMMENT '用戶ID', `sso_id` varchar(32) NOT NULL COMMENT '單點信息編號ID', `sso_code` varchar(32) NOT NULL COMMENT '單點登錄碼,唯一核心標識', `log_ip` varchar(32) DEFAULT NULL COMMENT '登錄IP地址', `create_time` datetime DEFAULT NULL COMMENT '創建時間', `update_time` datetime DEFAULT NULL COMMENT '更新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶單點登錄表'; 狀態管理表
系統用戶在使用時候可能出現多個狀態，例如賬戶凍結、密碼鎖定等，把狀態聚合到一起，可以更加方便的管理和驗證。
CREATE TABLE `ms_user_status` ( `user_id` int(11) NOT NULL COMMENT '用戶ID', `account_status` int(1) DEFAULT '1' COMMENT '賬戶狀態：0-凍結,1-未凍結', `real_name_status` int(1) DEFAULT '0' COMMENT '實名認證狀態：0-未實名,1-已實名', `pay_pass_status` int(1) DEFAULT '0' COMMENT '支付密碼是否設置：0-未設置,1-設置', `wallet_pass_status` int(1) DEFAULT '0' COMMENT '錢包密碼是否設置：0-未設置,1-設置', `wallet_status` int(1) DEFAULT '1' COMMENT '錢包是否凍結:0-凍結,1-未凍結', `email_status` int(1) DEFAULT '0' COMMENT '郵箱狀態:0-未激活,1-激活', `message_status` int(1) DEFAULT '1' COMMENT '簡訊提醒開啟：0-未開啟,1-開啟', `letter_status` int(1) DEFAULT '1' COMMENT '站內信提醒開啟：0-未開啟,1-開啟', `emailmsg_status` int(1) DEFAULT '0' COMMENT '郵件提醒開啟：0-未開啟,1-開啟', `create_time` datetime DEFAULT NULL COMMENT '創建時間', `update_time` datetime DEFAULT NULL COMMENT '更新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶狀態表'; 支付賬戶表
用戶交易的核心表，存儲用戶相關的賬戶資金信息。
CREATE TABLE `ms_user_wallet` ( `wallet_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '錢包ID', `user_id` int(11) NOT NULL COMMENT '用戶ID', `wallet_pwd` varchar(32) DEFAULT NULL COMMENT '錢包密碼', `total_account` decimal(20,2) DEFAULT '0.00' COMMENT '賬戶總額', `usable_money` decimal(20,2) DEFAULT '0.00' COMMENT '可用余額', `freeze_money` decimal(20,2) DEFAULT '0.00' COMMENT '凍結金額', `freeze_time` datetime DEFAULT NULL COMMENT '凍結時間', `thaw_time` datetime DEFAULT NULL COMMENT '解凍時間', `create_time` datetime DEFAULT NULL COMMENT '創建時間', `update_time` datetime DEFAULT NULL COMMENT '更新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`wallet_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶錢包'; 二、設計規范 1、涉及模塊
通過上面幾個表設計的案例，可以看到表設計關聯到資料庫的各個方面知識：數據類型，索引，編碼，存儲引擎等。表設計是一個很大的命題，不過也遵循一個基本規范：三範式。
2、三範式 基礎概念
一範式
表的列的具有原子性,不可再分解，即列的信息，不能分解,關系型資料庫MySQL、Oracle等自動的滿足。
二範式
每個事實的數據記錄只會出現一次, 不會冗餘, 通常設計一個主鍵來實現。
三範式
要求一個表中不包含已經存在於其它表的非主鍵信息，例如部門和員工的信息，員工表包含部門表的主鍵ID，則可以關聯獲取相關信息，沒必要在員工表保存相關信息。
優缺點對比
範式化設計
範式化結構設計通常更新快，因為冗餘數據較少，表結構輕巧，也更好的寫入內存中。但是查詢起來涉及到關聯，代價非常高，非常損耗查詢性能。
反範式化設計
所有的數據都在一張表中，避免關聯查詢，索引的有效性更高，但是數據的冗餘性極高。
建議結論
上述的兩種設計方式在實際開發中都是不存在的，在實際開發中都是混合使用。比如匯總統計，緩存數據，都會基於反範式化的設計。
三、欄位屬性
合適的欄位類型對於高性能來說非常重要，基本原則如下：簡單的類型佔用資源更少；在可以正確存儲數據的情況下，選最小的數據類型。
1、數據類型選擇 整數類型
TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，根據數據類型範圍合理選擇即可。
實數類型
FLOAT、DOUBLE、DECIMAL，建議資金貨幣相關類型使用高精度DECIMAL存儲，或者把數據成倍擴大為整數，採用BIGINT存儲，不過處理相對麻煩。
字元類型
CHAR、VARCHAR，長度不確定建議採用VARCHAR存儲，不過VARCHAR類型需要額外開銷記錄字元串長度。CHAR適合存儲短字元，或者定長字元串，例如MD5的加密結構。
時間類型
DATETIME、TIMESTAMP，DATETIME保存大范圍的值，精度秒。TIMESTAMP以時間戳的格式，范圍相對較小，效率也相對較高，所以通常情況建議使用。
MySQL的欄位類型有很多種，可以根據數據特性選擇合適的，這里只描述常見的幾種類型。
2、基礎用法操作 數據類型
修改欄位類型
ALTER TABLE ms_user_sso MODIFY state CHAR(1) DEFAULT '0' ; ALTER TABLE ms_user_sso MODIFY state INT(1) DEFAULT '1' COMMENT '狀態：0不可用,1可用';
修改名稱位置
ALTER TABLE ms_user_sso CHANGE log_ip login_ip VARCHAR(32) AFTER update_time ; 索引使用
索引類型：主鍵索引，普通索引，唯一索引，組合索引，全文索引。這里演示普通索引的操作。MySQL的核心模塊，後續詳說。
添加索引
ALTER TABLE ms_user_wallet ADD INDEX user_id_index(user_id) ; CREATE INDEX state_index ON ms_user_wallet(state) ;
查看索引
SHOW INDEX FROM ms_user_wallet;
刪除索引
DROP INDEX state_index ON ms_user_wallet ;
修改索引
不具有真正意義上的修改，可以把原有的索引刪除之後，再次添加索引。
外鍵關聯
用處：外鍵關聯的作用保證多個數據表的數據一致性和完整性，建表時先有主表，後有從表；刪除數據表，需要先刪從表，再刪主表。復雜場景不建議使用，實際開發中用的也不多。
添加外鍵
ALTER TABLE ms_user_wallet ADD CONSTRAINT user_id_out_key FOREIGN KEY(user_id) REFERENCES ms_user_center(id) ;
刪除外鍵
ALTER TABLE ms_user_wallet DROP FOREIGN KEY user_id_out_key ; 四、表結構管理 1、查看結構 DESC ms_user_status ; SHOW CREATE TABLE ms_user_status ; 2、欄位結構 添加欄位 ALTER TABLE ms_user_status ADD `delete_time` datetime DEFAULT NULL COMMENT '刪除時間' ; 刪除欄位 ALTER TABLE ms_user_status DROP COLUMN delete_time ; 3、修改表名 ALTER TABLE ms_user_center RENAME ms_user_info ; 4、存儲引擎 存儲引擎 SELECT VERSION() ; SHOW ENGINES ;
MySQL 5.6 支持的存儲引擎有InnoDB、MyISAM、Memory、Archive、CSV、BLACKHOLE等。一般默認使用InnoDB，支持事務管理。該模塊MySQL核心，後續詳解。
修改引擎
數據量大的場景下，存儲引擎修改是一個難度極大的操作，容易會導致表的特性變動，引起各種後續反應，後續會詳說。
ALTER TABLE ms_user_sso ENGINE = MyISAM ; 5、修改編碼
表字元集默認使用utf8，通用，無亂碼風險，漢字3位元組，英文1位元組，utf8mb4是utf8的超集，有存儲4位元組例如表情符號時使用。
查看編碼 SHOW VARIABLES LIKE 'character%'; 修改編碼 ALTER TABLE ms_user_sso DEFAULT CHARACTER SET utf8mb4; 五、數據管理 1、增刪改查
添加數據
INSERT INTO ms_user_sso ( user_id,sso_id,sso_code,create_time,update_time,login_ip,state ) VALUES ( '1','SSO7637267','SSO78631273612', '2019-12-24 11:56:57','2019-12-24 11:57:01','127.0.0.1','1' );
更新數據
UPDATE ms_user_sso SET user_id = '1',sso_id = 'SSO20191224',sso_code = 'SSO20191224', create_time = '2019-11-24 11:56:57',update_time = '2019-11-24 11:57:01', login_ip = '127.0.0.1',state = '1' WHERE user_id = '1';
查詢數據
一般情況下都是禁止使用 select* 操作。
SELECT user_id,sso_id,sso_code,create_time,update_time,login_ip,state FROM ms_user_sso WHERE user_id = '1';
刪除數據
DELETE FROM ms_user_sso WHERE user_id = '2' ;
不帶where條件，就是刪除全部數據。原則上不允許該操作，優化篇會詳解。TRUNCATE TABLE也是清空表數據，但是佔用的資源相對較少。
2、數據安全 不可逆加密
這類加密演算法，多用來做數據驗證操作，比如常見的密碼驗證。
SELECT MD5('cicada')='' ; SELECT SHA('cicada')=''; SELECT PASSWORD('smile')='*' ; 可逆加密
安全性要求高的系統，需要做三級等保，對數據的安全性極高，數據在存儲時必須加密入庫，取出時候需要解密，這些就需要可逆加密。
SELECT DECODE(ENCODE('123456','key_salt'),'key_salt') ; SELECT AES_DECRYPT(AES_ENCRYPT('cicada','salt123'),'salt123');
上述數據安全的管理，也可以基於應用系統的服務(代碼)層進行處理，相對專業的流程是從數據生成源頭處理，規避數據傳遞過程泄露，造成不必要的風險。
⑤ Redis 都有哪些應用場景
緩存：這應該是 Redis 最主要的功能了，也是大型網站必備機制，合理地使用緩存不僅可以加 快數據的訪問速度，而且能夠有效地降低後端數據源的壓力。
共享Session：對於一些依賴 session 功能的服務來說，如果需要從單機變成集群的話，可以選擇 redis 來統一管理 session。
消息隊列系統：消息隊列系統可以說是一個大型網站的必備基礎組件，因為其具有業務 解耦、非實時業務削峰等特性。Redis提供了發布訂閱功能和阻塞隊列的功 能，雖然和專業的消息隊列比還不夠足夠強大，但是對於一般的消息隊列功 能基本可以滿足。比如在分布式爬蟲系統中，使用 redis 來統一管理 url隊列。
分布式鎖：在分布式服務中。可以利用Redis的setnx功能來編寫分布式的鎖，雖然這個可能不是太常用。 當然還有諸如排行榜、點贊功能都可以使用 Redis 來實現，但是 Redis 也不是什麼都可以做，比如數據量特別大時，不適合 Redis，我們知道 Redis 是基於內存的，雖然內存很便宜，但是如果你每天的數據量特別大，比如幾億條的用戶行為日誌數據，用 Redis 來存儲的話，成本相當的高。
⑥ 用redis 做為數據緩存，怎麼能把redis中的數據定時更新到mysql中
這是個有坑的方法，一般流量不大的情況可以用，比如，後台系統。但是前端用戶流量大的場景下，一旦熱數據緩存命中率發生問題，瞬間轉移到資料庫的請求會把系統搞死的。所以，不應該採用這種策略。
⑦ SpringBoot進階之緩存中間件Redis
大家好，一直以來我都本著 用最通俗的話理解核心的知識點， 我認為所有的難點都離不開 「基礎知識」 的鋪墊
「大佬可以繞過 ~」
本節給大家講講 「Java的SpringBoot框架」 , 之前我們學習的都是java的基礎知識和底層提供的一些能力，我們日常工作都是在寫介面。在我們在產品開發中，一般我們都會選擇比較穩定的框架來幫我們加速開發，不會自己去造輪子，而在java眾多框架中，spring框架表現的非常好，大部分公司都會首選它作為開發框架，而至今，大部分企業都是以 springboot 來構建項目了,一個穩健的系統需要引入穩定的技術~
如果你是一路看過來的，很高興你能夠耐心看完。前幾期都是帶大家學習了 SpringBoot 的基礎使用以及集成 mybatis 開發，這也是我們寫業務的基礎，如果你還不熟悉這些，請先看完它們。接下來的幾期內容將會帶大家進階使用，會先講解基礎 中間件 的使用和一些場景的應用，或許這些技術你聽說過，沒看過也沒關系，我會帶大家一步一步的入門，耐心看完你一定會有 收獲 ,本期將會給大家講解最熱門的緩存中間件技術 Redis ,同樣的，我們集成到 Springboot 中。最近github可能會被牆，所以我把源碼放到了國內gitee上,本節我們依然使用上期的代碼
Redis 是由義大利人Salvatore Sanfilippo（網名：antirez）開發的一款內存高速緩存資料庫。全稱叫 Remote Dictionary Server（遠程數據服務） 是由 C語言 編寫的，Redis是一個 key-value 存儲系統，它支持豐富的數據類型，如： string、list、set、zset(sorted set)、hash 。
它本質上是一種鍵值對資料庫，我們之前學習的 mysql 它是持久層的關系型資料庫,而 redis 它的存儲主要存在 內存 中。我們都知道在 內存 中的數據讀取是非常快的，就好比你把一個變數存到磁碟讀取和直接放到代碼中運行，肯定是在代碼中拿到的速度快，因為運行時期，都是直接存到內存的。
給大家總結一下：
有了基本的概念之後，我們下面進行環境搭建,在學習階段，安裝 redis 很簡單,生產環境一般我們也會選擇雲產品，一切為了服務保障,雖說它只是做緩存用，但也是系統的一把 保護傘
如果你是 mac 用戶，你可以運行如下命令:
安裝完成後會提示你運行命令，運行即可。
win 用戶也很簡單，直接下載 redis 軟體，雙擊運行即可，運行之後它會有一個小方塊的圖案，和 locahost:6379 的log,說明運行成功了。初始階段沒有配置的 redis 默認 host 就是本地, port 就是 6379 , 而且是 沒有密碼 就可以訪問的。
推薦一個客戶端軟體 Redis Desktop Manager ，它是 redis 的客戶端界面軟體,方便麵我們學習的時候 清理緩存 使用,生產慎連。
我們不給大家講它的基本命令使用，它也有語法，可以通過類似命令執行,如果想學習的小夥伴，可以自行搜索。本期重點內容是在 sprinboot 中的使用,我們平時開發不可能是去命令行里敲的，都是代碼里執行，而目前市面上有很多封裝好的庫，我們可以直接調用它的方法，很方便的就可以操作它了，不用記一些繁瑣的命令,下面我們就實際操作一下:
修改 pom.xml
修改 application.yml :
redis 默認是有 16 個庫,不是 15 個啊，從 0 開始算的,我們隨便連一個
通過代碼很好理解, 首先需要引入 StringRedisTemplate ,然後需要設置一個 key ,那麼思考一下，這個 key 允許重復嗎
我們進客戶端看一下，發現 key 還是只有一個,但是值變成了新的值了，所以可以得知 key 是唯一的，我們重新設置的時候相當於刷新了它。
在 redis 中刪除緩存有兩種方式，一種是自我消亡，也就是 過期 銷毀,還有有一種是 主動 銷毀，我們先看一下，過期時間如何設置
我們設置了 10s 後過期,過完10s後發現，這個```key data``消失了。我們在看看如何主動刪除
我們可以利用 Redis 做一個計數器，實現自增功能,你可以用它做網站訪問統計
通常做法，我們會把它封裝一下，後續使用直接引入封裝好的即可，把它直接交給 Springboot容器 管理
其實這個類，你還可以繼續進一步封裝，比如約束 key 的規范，約束過期時間，約束數據類型等等，這一切也都是為了規范和後期維護，防止濫用緩存
緩存的主要場景是用於解決熱點數據問題，因為這些數據是訪問頻率比較高的，當大量的請求進來, mysql 可能壓力很大，這樣一來，數據查詢效率就很慢，用戶肯不高興等了，這樣用戶體驗很不好。所以我們一般做法，都是把這些熱點數據放到緩存里，因為緩存讀取速度很快。當有新數據的時候，我們再及時更新它，一般流程是先查詢緩存，查到了直接返回緩存數據，查不到再走資料庫，然後再刷回緩存。
但是並發足夠大的時候，還是會暴露出很多問題，比如面試常問的一些高頻問題 緩存雪崩、緩存穿透、緩存雪崩 ,這些問題後邊會給大家專門講，和如何去防範。所以總的來說，引入任何一門技術並不是萬事大吉，還需我們不斷的在實踐中積累經驗
本期到這里就結束了，總結一下，我們了解了什麼是 redis ，以及在 springboot 中如何去使用它們，很簡單，沒什麼復雜的東西。但這里想多說一點的是，緩存的設計卻是很復雜的，因為工具是死的，人是活的，我們如何正確設計，需要我們在項目中不斷的積累。
我們之前教大家查詢列表數據，都是所有數據返回，還沒有教大家如何去做分頁，下期將帶大家學習一下 mybatis 分頁插件的使用 ，下期不見不散, 關注我，不迷路~
⑧ 華為技術架構師分享：高並發場景下緩存處理的一些思路
在實際的開發當中，我們經常需要進行磁碟數據的讀取和搜索，因此經常會有出現從資料庫讀取數據的場景出現。但是當數據訪問量次數增大的時候，過多的磁碟讀取可能會最終成為整個系統的性能瓶頸，甚至是壓垮整個資料庫，導致系統卡死等嚴重問題。
常規的應用系統中，我們通常會在需要的時候對資料庫進行查找，因此系統的大致結構如下所示：
1.緩存和資料庫之間數據一致性問題
常用於緩存處理的機制我總結為了以下幾種：
首先來簡單說說Cache aside的這種方式：
Cache Aside模式
這種模式處理緩存通常都是先從資料庫緩存查詢，如果緩存沒有命中則從資料庫中進行查找。
這裡面會發生的三種情況如下：
緩存命中：
當查詢的時候發現緩存存在，那麼直接從緩存中提取。
緩存失效：
當緩存沒有數據的時候，則從database裡面讀取源數據，再加入到cache裡面去。
緩存更新：
當有新的寫操作去修改database裡面的數據時，需要在寫操作完成之後，讓cache裡面對應的數據失效。
關於這種模式下依然會存在缺陷。比如，一個是讀操作，但是沒有命中緩存，然後就到資料庫中取數據，此時來了一個寫操作，寫完資料庫後，讓緩存失效，然後，之前的那個讀操作再把老的數據放進去，所以，會造成臟數據。
Facebook的大牛們也曾經就緩存處理這個問題發表過相關的論文，鏈接如下:
分布式環境中要想完全的保證數據一致性是一件極為困難的事情，我們只能夠盡可能的減低這種數據不一致性問題產生的情況。
Read Through模式
Read Through模式是指應用程序始終從緩存中請求數據。 如果緩存沒有數據，則它負責使用底層提供程序插件從資料庫中檢索數據。 檢索數據後，緩存會自行更新並將數據返回給調用應用程序。使用Read Through 有一個好處。
我們總是使用key從緩存中檢索數據, 調用的應用程序不知道資料庫， 由存儲方來負責自己的緩存處理，這使代碼更具可讀性， 代碼更清晰。但是這也有相應的缺陷，開發人員需要給編寫相關的程序插件，增加了開發的難度性。
Write Through模式
Write Through模式和Read Through模式類似，當數據發生更新的時候，先去Cache裡面進行更新，如果命中了，則先更新緩存再由Cache方來更新database。如果沒有命中的話，就直接更新Cache裡面的數據。
2.緩存穿透問題
在高並發的場景中，緩存穿透是一個經常都會遇到的問題。
什麼是緩存穿透？
大量的請求在緩存中沒有查詢到指定的數據，因此需要從資料庫中進行查詢，造成緩存穿透。
會造成什麼後果？
大量的請求短時間內湧入到database中進行查詢會增加database的壓力，最終導致database無法承載客戶單請求的壓力，出現宕機卡死等現象。
常用的解決方案通常有以下幾類：
1.空值緩存
在某些特定的業務場景中，對於數據的查詢可能會是空的，沒有實際的存在，並且這類數據信息在短時間進行多次的反復查詢也不會有變化，那麼整個過程中，多次的請求資料庫操作會顯得有些多餘。
不妨可以將這些空值（沒有查詢結果的數據）對應的key存儲在緩存中，那麼第二次查找的時候就不需要再次請求到database那麼麻煩，只需要通過內存查詢即可。這樣的做法能夠大大減少對於database的訪問壓力。
2.布隆過濾器
通常對於database裡面的數據的key值可以預先存儲在布隆過濾器裡面去，然後先在布隆過濾器裡面進行過濾，如果發現布隆過濾器中沒有的話，就再去redis裡面進行查詢，如果redis中也沒有數據的話，再去database查詢。這樣可以避免不存在的數據信息也去往存儲庫中進行查詢情況。
什麼是緩存雪崩？
當緩存伺服器重啟或者大量緩存集中在某一個時間段失效，這樣在失效的時候，也會給後端系統(比如DB)帶來很大壓力。
如何避免緩存雪崩問題？
1.使用加鎖隊列來應付這種問題。當有多個請求湧入的時候，當緩存失效的時候加入一把分布式鎖，只允許搶鎖成功的請求去庫裡面讀取數據然後將其存入緩存中，再釋放鎖，讓後續的讀請求從緩存中取數據。但是這種做法有一定的弊端，過多的讀請求線程堵塞，將機器內存占滿，依然沒有能夠從根本上解決問題。
2.在並發場景發生前，先手動觸發請求，將緩存都存儲起來，以減少後期請求對database的第一次查詢的壓力。數據過期時間設置盡量分散開來，不要讓數據出現同一時間段出現緩存過期的情況。
3.從緩存可用性的角度來思考，避免緩存出現單點故障的問題，可以結合使用 主從+哨兵的模式來搭建緩存架構，但是這種模式搭建的緩存架構有個弊端，就是無法進行緩存分片，存儲緩存的數據量有限制，因此可以升級為Redis Cluster架構來進行優化處理。（需要結合企業實際的經濟實力，畢竟Redis Cluster的搭建需要更多的機器）
4.Ehcache本地緩存 + Hystrix限流&降級,避免MySQL被打死。
使用 Ehcache本地緩存的目的也是考慮在 Redis Cluster 完全不可用的時候，Ehcache本地緩存還能夠支撐一陣。
使用 Hystrix進行限流 & 降級 ，比如一秒來了5000個請求，我們可以設置假設只能有一秒 2000個請求能通過這個組件，那麼其他剩餘的 3000 請求就會走限流邏輯。
然後去調用我們自己開發的降級組件（降級），比如設置的一些默認值呀之類的。以此來保護最後的 MySQL 不會被大量的請求給打死。