哈嘍，大家好呀，我是呼嚕嚕，最近很忙好久沒更新了，今天我們通過緩存與數(shù)據(jù)庫之間的一致性這個老生常談的問題來切入，聊聊如何合理的設(shè)計一個緩存系統(tǒng)?

如今互聯(lián)網(wǎng)應(yīng)用，無論是web還是app，都基本遵循"前端-后端-數(shù)據(jù)庫"的架構(gòu)模型

當(dāng)業(yè)務(wù)處于起步階段，流量比較小的時候，上述能夠支撐；但隨著業(yè)務(wù)的擴張，用戶數(shù)和流量越來越大，也就需要整個架構(gòu)支撐起更大的并發(fā)量，但我們服務(wù)器上的資源總是有限的，當(dāng)每天流量達到高峰時，往往這個時候數(shù)據(jù)庫最先頂不住

當(dāng)我們分析這些互聯(lián)網(wǎng)應(yīng)用的流量時候，發(fā)現(xiàn)大部分的流量實際上都是讀請求，而且大部分數(shù)據(jù)并沒有頻繁被改變**(即讀多寫少場景，注意本文全文討論的方案都是基于這個前提**)。這個時候引入緩存，是提升性能的一種行之有效的方式，緩存在計算機的世界中處處可見，比如CPU緩存，瀏覽器緩存，操作系統(tǒng)緩存，程序代碼中自定義緩存

由于數(shù)據(jù)庫每秒能接受的請求次數(shù)QPS是有限的，當(dāng)我們在數(shù)據(jù)庫前面，引入緩存來充當(dāng)緩沖層；如果命中緩存就直接獲取目標數(shù)據(jù)并返回，不僅能減少對數(shù)據(jù)庫的直接訪問帶來的計算壓力，還能提升響應(yīng)速度，充分壓榨有效的資源，其本質(zhì)是額外消耗更高速的空間來換時間

圖片

凡是有利有弊，引入緩存后，享受緩存帶來的種種好處的優(yōu)點，但緩存系統(tǒng)其實是非常復(fù)雜的，緩存和數(shù)據(jù)庫的一致性也是個繞不開，讓人腦闊疼的問題；還需要考慮緩存的穩(wěn)定性、命中率、熱點數(shù)據(jù)、過期時間等等，我們下文慢慢道來

本地緩存、分布式緩存

緩存有各種分類，常見的是與應(yīng)用耦合程度劃分為：本地緩存local cache和分布式緩存remote cache

本地緩存

本地緩存，由于存在于應(yīng)用程序的本地內(nèi)存，應(yīng)用和緩存在同一個進程內(nèi)，且沒有網(wǎng)絡(luò)延遲，所以速度快

但本地緩存的大小通常受到物理內(nèi)存的限制，而且還要兼顧應(yīng)用程序正常運行，容量有限，擴展性差，無法輕松擴展到多個節(jié)點。還有就是多個應(yīng)用實例下無法直接的共享緩存，數(shù)據(jù)的一致性難以保證，復(fù)雜度高。數(shù)據(jù)會隨著應(yīng)用程序的重啟而丟失

適合讀寫密集、對數(shù)據(jù)一致性要求較低、網(wǎng)絡(luò)環(huán)境不穩(wěn)定的場景

分布式緩存

主要是指與應(yīng)用分離的獨立緩存組件，比如redis，可擴展性強，容量大，可以通過集群水平擴展；通過通過一致性哈希等技術(shù)，保證多節(jié)點之間的數(shù)據(jù)一致性，而且都集成好了，開發(fā)者一般直接使用這些特性

當(dāng)然由于存在網(wǎng)絡(luò)延遲，與本地緩存相比，速度較慢；硬件成本也需要較高，來保證其高可用、高可靠性

更適合電商平臺、社交網(wǎng)絡(luò)等流量并發(fā)大的平臺，或者互聯(lián)網(wǎng)這種隨著業(yè)務(wù)增長，需要彈性擴展以滿足需求的場景

還有綜合二者特點的多級緩存，將本地緩存和分布式緩存結(jié)合起來，本地緩存作為一級緩存，存儲更新頻率低，訪問頻率高數(shù)據(jù)；分布式緩存作為二級緩存，存儲更新頻率很高的數(shù)據(jù)

當(dāng)用戶獲取數(shù)據(jù)時，先從一級緩存中獲取數(shù)據(jù)，如果一級緩存有數(shù)據(jù)則返回數(shù)據(jù)，否則從二級緩存中獲取數(shù)據(jù)。如果二級緩存中有數(shù)據(jù)則更新一級緩存，然后將數(shù)據(jù)返回客戶端。如果二級緩存沒有數(shù)據(jù)則去數(shù)據(jù)庫查詢數(shù)據(jù)，然后更新二級緩存，接著再更新一級緩存，最后將數(shù)據(jù)返回給客戶端。這里邏輯其實和CPU內(nèi)部的緩存很像，大家感興趣地可以自行查閱筆者之前的一篇文章-CPU緩存

但緩存相關(guān)的問題邏輯挑戰(zhàn)，無論本地緩存還是分布式緩存都是一樣的，為方便起見，本文將全文以redis為例，來代稱緩存

緩存穿透、緩存擊穿、緩存雪崩

在將緩存和數(shù)據(jù)庫的一致性之前，我們需要保證，引入的緩存，即構(gòu)建的緩存系統(tǒng)是穩(wěn)定的，這是保證數(shù)據(jù)一致性的前提

關(guān)于緩存的穩(wěn)定性，有3種經(jīng)典問題：緩存穿透、緩存擊穿、緩存雪崩，聊這3個問題前，我們得知曉緩存最常見的應(yīng)用模式Cache-Aside Pattern旁路緩存的讀模式：

圖片

旁路緩存模式，是指優(yōu)先查詢緩存，查詢不到再去查詢數(shù)據(jù)庫。如果這時候數(shù)據(jù)庫查到數(shù)據(jù)了，就將緩存的數(shù)據(jù)回寫更新，這樣緩存可以為后續(xù)請求服務(wù)！

緩存穿透

緩存穿透: 當(dāng)請求過來，訪問不存在的數(shù)據(jù)時(即既不在緩存中，也不在數(shù)據(jù)庫中)，這會導(dǎo)致訪問緩存，未命中，繼續(xù)訪問數(shù)據(jù)庫db，然后發(fā)現(xiàn)在數(shù)據(jù)庫中還是未查詢到數(shù)據(jù)，這個時候也就不能回寫緩存，來為后續(xù)的請求服務(wù)；也就是說，當(dāng)這種請求過來，每次都會去查數(shù)據(jù)庫，緩存形同虛設(shè)，一旦流量暴增，容易直接帶崩數(shù)據(jù)庫

圖片

這種不存在的數(shù)據(jù)可能被管理員誤刪，也有可能被黑客惡意利用(惡意請求)，不斷地去試，一旦發(fā)現(xiàn)一個不存在的數(shù)據(jù)，就拼命發(fā)請求訪問這個數(shù)據(jù)，直到數(shù)據(jù)庫鎖住

那解決辦法也很簡單，常見的有：

1. 比如每次訪問數(shù)據(jù)如果既不在緩存中，也不在數(shù)據(jù)庫中，那就緩存一個占位符或者空值，過期時間也不要設(shè)置過長，比如1分鐘就行，這樣的話，在1分鐘內(nèi)，這么多請求只有一次能直接訪問數(shù)據(jù)庫，這樣就能顯著降低數(shù)據(jù)庫的壓力；如果緩存過期時間過長，會出現(xiàn)大量的空緩存，進而導(dǎo)致緩存資源的浪費
2. 還可以針對請求攜帶的參數(shù)，比如是那種特殊字符、非法字符等，我們數(shù)據(jù)庫肯定不會存這些東西，直接在應(yīng)用服務(wù)層進行限制，不允許訪問
3. 還可以通過第三方組件來實現(xiàn)，比如布隆過濾器，其主要是其特性:布隆過濾器判斷一個元素不在集合中，那肯定就不在。如果判斷存在，那有一定可能性它在說謊，具體原理可以參考筆者以前的一篇文章海量數(shù)據(jù)處理的利器-布隆過濾器。在緩存和數(shù)據(jù)庫之間再加上布隆過濾器，通過布隆過濾器快速判斷數(shù)據(jù)是否存在，從而避免多次之間請求數(shù)據(jù)庫

緩存擊穿

在我們正常的業(yè)務(wù)之中，總有一些數(shù)據(jù)會被頻繁訪問，這就是熱點數(shù)據(jù)

所謂的緩存擊穿指的是，緩存中熱點數(shù)據(jù)的key過期失效，由于是熱點數(shù)據(jù)，在過期的一瞬間會有大量的請求過來(高并發(fā))，這些請求，最終都會直接訪問數(shù)據(jù)庫，這樣數(shù)據(jù)庫很容易被打垮，緩存仿佛被"擊穿"了

常見的解決方案：

1. 加鎖，進程鎖/分布式鎖，當(dāng)請求過來時，緩存未命中時，會通過鎖將這個緩存key鎖上，等當(dāng)這個請求從數(shù)據(jù)庫獲取數(shù)據(jù)后再回寫到緩存中后，再釋放鎖；期間其他請求過來，會獲取鎖失敗，等待一段時間重試，就可以直接讀取緩存了。需要注意的是，如果業(yè)務(wù)量不大，進程鎖就夠了的話，也就沒必要上分布式鎖，多引入額外組件，就會增加系統(tǒng)的不穩(wěn)定性

圖片

還可以繼續(xù)改進，將請求2未獲得鎖，直接返回，升級成自旋鎖，它不直接返回，而是等待一會重新嘗試獲取鎖，這種高并發(fā)情況下，只有唯一請求是db請求，所有請求共享結(jié)果

2. 給緩存的Key設(shè)置合理的過期時間并加上隨機值，盡量減少緩存短期大量失效，出現(xiàn)大量訪問數(shù)據(jù)庫的情況，實現(xiàn)"削峰填谷"
3. 網(wǎng)上有文章提出，可以讓熱點數(shù)據(jù)的緩存不設(shè)置過期時間，這樣不就可以永不過期嘛，但這其實是個很危險的操作

使用緩存的前提是一定要設(shè)置過期時間，因為由于項目會不斷迭代更新，業(yè)務(wù)不斷復(fù)雜，開發(fā)人員更替，緩存會變得越來越難以維護，另外緩存和數(shù)據(jù)庫無法避免的數(shù)據(jù)不一致的情況，緩存的過期時間其實就是兜底，防止緩存和數(shù)據(jù)庫數(shù)據(jù)長時間不一致

我們還可以通過消息隊列來間接地讓熱點數(shù)據(jù)的緩存延期，當(dāng)熱點緩存過期時，后臺服務(wù)再檢測更新緩存，防止緩存擊穿；至于是否延期，得做訪問量分析與統(tǒng)計，當(dāng)然引入新的組件也會帶來額外的穩(wěn)定性問題，還是得根據(jù)業(yè)務(wù)情況，實事求是

緩存雪崩

緩存雪崩，指定是大量請求未命中緩存，直接訪問數(shù)據(jù)庫，導(dǎo)致數(shù)據(jù)庫壓力過大，倘若請求足夠的多，會直接將數(shù)據(jù)庫壓垮，繼而影響整個系統(tǒng)，如同"雪崩"

個人感覺緩存擊穿是緩存雪崩的一個子集，緩存雪崩一般有2種誘因：緩存服務(wù)異常，比如redis故障宕機或者緩存服務(wù)是正常的，但大量緩存數(shù)據(jù)在同一時間過期

一般解決redis故障宕機，是搭建集群，由單節(jié)點到多節(jié)點，提升redis的容災(zāi)能力，當(dāng)主節(jié)點宕機后，從節(jié)點可以切換成為主節(jié)點，繼續(xù)提供緩存服務(wù)；若是真的宕機了，那我們應(yīng)該使用熔斷機制，同時當(dāng)流量到達一定的閾值，直接禁止請求對數(shù)據(jù)庫的訪問，返回系統(tǒng)擁擠之類的提示，維持系統(tǒng)穩(wěn)定，等待緩存恢復(fù)再允許對數(shù)據(jù)庫訪問

防止大量緩存數(shù)據(jù)在同一時間過期，一般是給緩存的Key設(shè)置合理的過期時間并加上隨機偏差，盡量讓緩存失效時間均勻分布，實現(xiàn)"削峰填谷"，簡單而有效

圖片

要么加鎖，唯一db請求，所有同類請求共享結(jié)果，與緩存擊穿的解決方法一致，我們就不再贅述了

還有一種方式就是，當(dāng)每天系統(tǒng)訪問的流量高峰來臨之前，先提前將熱點數(shù)據(jù)入緩存，避免直到用戶請求的時候，再先查詢數(shù)據(jù)庫，然后將數(shù)據(jù)緩存的過程，這個也叫緩存預(yù)熱

CAP原則 和 如何保證緩存一致性

由于在數(shù)據(jù)庫層前，引入緩存，主要是通過空間去換時間，享受緩存帶來的種種好處的優(yōu)點，但此時一份數(shù)據(jù)存在不同的副本，且在不同空間中，此時更新緩存、db就會帶來緩存一致性的挑戰(zhàn)

我們還需要了解一下著名的CAP原則，指在一個分布式系統(tǒng)中，一致性Consistency、可用性Availability、分區(qū)容錯性Partition tolerance，這3者最多同時滿足2項，不可能同時滿足3項！?。?/p>

圖片

1. 一致性Consistency，即所有節(jié)點在同一時間具有相同的數(shù)據(jù)，強一致性
2. 可用性Availability，即服務(wù)必須一直處于可用的狀態(tài)，每次請求都能獲取到正常的響應(yīng)，高可用
3. 分區(qū)容錯性Partition tolerance，即分區(qū)故障時，要求在一定時限內(nèi)，仍然或者恢復(fù)到能對外提供滿足一致性和可用性的服務(wù)，系統(tǒng)繼續(xù)正常運行

還記得本文的一開始嗎？

為了應(yīng)對高流量，我們的系統(tǒng)選擇了高性能和高吞吐量，所以只能滿足AP。

而緩存與數(shù)據(jù)庫的緩存一致性難以避免的具體原因是：由于無法保證同時更新db和緩存不在同一個事務(wù)中，所以其不是原子操作，緩存不一致是無法避免的！

圖片

要保證強一致性，我們可以上分布式鎖，但會導(dǎo)致整個系統(tǒng)的并發(fā)性能下降，還記得我們引入緩存的初衷嗎？是為了提升系統(tǒng)的整體性能吶?。。∷赃@種方案我們一般不采用~

但我們可以通過一些方案，來實現(xiàn)緩存的最終一致性，其次盡可能減小緩存不一致的時間窗口，我們下面分別來聊聊常見的幾種方式及其它們的問題：

1. 先更新數(shù)據(jù)庫，再更新緩存
2. 先更新緩存，再更新數(shù)據(jù)庫
3. 先刪緩存，再更新數(shù)據(jù)庫
4. 先更新數(shù)據(jù)庫，再刪除緩存

先更新數(shù)據(jù)庫，再更新緩存

先更新數(shù)據(jù)庫，再更新緩存，可能會遇到下面這種情況：

圖片

當(dāng)請求(或者可以說線程)并發(fā)的情況，比如2個請求1、2同時去更新db時，請求1快一點；但當(dāng)程序延遲或者其他情況，導(dǎo)致當(dāng)請求去更新緩存時，請求2快一點，這就會導(dǎo)致最終db=20，緩存=10這種數(shù)據(jù)不一致的情況，不一致的情況將持續(xù)到下次緩存失效，或者去更新數(shù)據(jù)庫緩存的時候，在此期間還不能保證更新緩存一定就可以成功

先更新緩存，再更新數(shù)據(jù)庫

這種和先更新數(shù)據(jù)庫，再更新緩存是類似的情況：

圖片

這種更新緩存的方式，是無法避免并發(fā)導(dǎo)致的數(shù)據(jù)不一致問題，而且出現(xiàn)的頻率也不低，所以我們應(yīng)該盡量不更新緩存。

先刪緩存，再更新數(shù)據(jù)庫 和 延遲雙刪

前一個更新請求，先刪除緩存，再更新數(shù)據(jù)庫，當(dāng)后面讀請求來發(fā)現(xiàn)沒有命中緩存，去數(shù)據(jù)庫讀數(shù)據(jù)，然后再回寫到緩存中，給后續(xù)請求服務(wù)，這是個很不錯的設(shè)想，但它還是會出現(xiàn)下面這種情況：

圖片

當(dāng)2個并發(fā)請求過來，請求1是更新請求，當(dāng)請求1刪除調(diào)緩存后，還沒去db更新數(shù)據(jù)，期間請求2來獲取數(shù)據(jù)，緩存未命中(剛被請求1刪了嘛)，去數(shù)據(jù)庫獲取數(shù)據(jù)10后，后回寫緩存，把緩存更新為10；這個時候請求1終于去更新db了，把db更新為20，這個時候還是會出現(xiàn)緩存和數(shù)據(jù)庫不一致的情況

一旦發(fā)生數(shù)據(jù)不一致，臟數(shù)據(jù)會一直在緩存中，直到下一次更新請求過來

補充：延遲雙刪關(guān)注我，我再多講幾句~如今在先刪緩存，再更新數(shù)據(jù)庫的基礎(chǔ)上，還有個優(yōu)化版叫延遲雙刪

既然請求可能會把臟數(shù)據(jù)重新寫入緩存中，臟數(shù)據(jù)會一直在緩存中，直到下一次更新請求過來，這個數(shù)據(jù)不一致的時間窗口較長，如果這個時候休眠指定時間N，我們另起線程(異步化)去刪除這個臟數(shù)據(jù)緩存，這個時候不就能縮短極端情況下不一致的時間窗口了嘛，一般N設(shè)為5s左右，需要根據(jù)項目實際情況而定。

另外也可以通過消息隊列MQ來刪除緩存，利用消息隊列的可靠性，來保證刪除緩存的操作能夠成功執(zhí)行，并異步化進行復(fù)雜邏輯的解耦

先更新數(shù)據(jù)庫，再刪除緩存

那先更新數(shù)據(jù)庫，再刪除緩存呢？它也被稱為Cache Aside Pattern旁路緩存的寫模式，我們再來看一種情況：

圖片

從上面時序圖，我們可以看出，先更新數(shù)據(jù)庫，再刪除緩存這種方案是可以保證緩存的最終一致性，但它在某一時間內(nèi)，還是存在緩存不一致的時間窗口(上圖請求2命中緩存與數(shù)據(jù)庫不一致)

但這個不一致的時間窗口很短，通常不超過1ms，在互聯(lián)網(wǎng)項目中通?？梢院雎赃@么短時間的不一致

但你覺得這就是終極方案了？

別急我們再看它有可能發(fā)生的一種情況：

圖片

當(dāng)2個并發(fā)請求過來，請求1是讀請求，正好緩存不存在，直接讀取db=20，在回寫緩存期間，請求2又過來更新db=10，在刪除緩存(沒緩存)，然后請求1再姍姍來遲地更新緩存=20，這就導(dǎo)致了緩存與數(shù)據(jù)的不一致情況

但實際上這種情況，觸發(fā)的概率非常低，因為緩存的存取速度(內(nèi)存)，要遠遠快于數(shù)據(jù)庫(磁盤)。關(guān)于儲存介質(zhì)的速度差異，感興趣地可以去看看計算機儲存器的讀寫速度差異

所以很難出現(xiàn)請求1已經(jīng)更新了數(shù)據(jù)庫并且刪除了緩存，請求2才更新完緩存的情況；為防止刪除緩存失敗，給緩存加個過期時間簡單而有效

但這其實也反映了：

1. 先更新數(shù)據(jù)庫，再刪除緩存這種模式并不太適合寫請求遠遠多于讀請求的場景下，而且當(dāng)并發(fā)量特別高的情況下，緩存刪除的代價也會較大(容易緩存擊穿)，這個時候更新數(shù)據(jù)庫后更新緩存可能是更適合的方案，還能進而通過MQ異步來優(yōu)化
2. 如果讀請求遠遠大于寫請求的場景下，先更新數(shù)據(jù)庫，再刪除緩存是個較好的方案，背后是lazy計算的思想：不要每次都重新做復(fù)雜的計算，而是等到它需要用的時候再重新計算
3. 本文提到的這4種方案，無論是哪種方案都是無法絕對保證緩存的一致性，只能保證最終一致性，縮短不一致的時間窗口。所以緩存必須要設(shè)置過期時間，這就是對緩存不一致的兜底措施
4. 最后如果對數(shù)據(jù)一致性要求極高的話，就不要再額外引入緩存，不引入緩存就沒有這么多煩惱！

如何保證刪除緩存能執(zhí)行成功

另外在實際環(huán)境中，執(zhí)行刪除緩存，也會有問題，因為無法保證系統(tǒng)會一定去刪除緩存，如果刪除緩存失敗，也會造成緩存與數(shù)據(jù)庫的不一致，下面介紹幾種常見的方案：

基于消息隊列刪除緩存

由于刪除緩存不一定能成功，一般會采用多次重試刪除的方案，需要一個隊列來記錄，是否刪除成功，如果沒有成功就繼續(xù)回隊列中，一般會引入中間件消息隊列MQ來，利用其高可靠性來保證刪除操作的執(zhí)行，同時還能異步化，實現(xiàn)復(fù)雜業(yè)務(wù)邏輯的解耦

我們來看下其主要流程：

更新數(shù)據(jù)庫的同時，發(fā)送刪除緩存的消息到消息隊列中，首次消費消息去執(zhí)行刪除緩存的操作，如果成功就直接返回業(yè)務(wù)，并把這個消息消費掉；如果由于各種原因?qū)е戮彺鎰h除失敗，那就重新將這個消息放進消息隊列中，等待下一次的消費

當(dāng)?shù)诙蜗M刪除該緩存的消息時，如果刪除成功就把該消息消費掉，并返回；如果沒有刪除成功就繼續(xù)放回消息隊列中，每個消息都有消費次數(shù)的上限，超出就報錯告警

圖片

另外一般將更新數(shù)據(jù)庫的模塊和同時發(fā)生刪除緩存消息的模塊放在同一個服務(wù)里，因為這樣后期維護起來，才不會發(fā)現(xiàn)莫名奇妙，不然就是給排查和維護上強度~~

當(dāng)然再引入mq，也要額外考慮mq的高可用性，所以需要根據(jù)實際情況，考慮是否有必要引入mq，如果不引入怎么辦？最簡單的我們可以通過內(nèi)存隊列、線程池等方式實現(xiàn)，性能更高，畢竟在本地沒有網(wǎng)絡(luò)延遲，代價就是更考驗程序員的心智，啥都要操心~

基于binlog來刪除緩存

還有一種比較有意思的方式，我們上面需要在程序中顯式去發(fā)送消息，講人話就是程序需要額外承擔(dān)發(fā)送消息的壓力， 而通過訂閱數(shù)據(jù)庫比如Mysql的binlog，來監(jiān)聽數(shù)據(jù)的真實變化來直接去處理有關(guān)的緩存，讓程序?qū)Ｐ牡厝ゲ僮鲾?shù)據(jù)庫

binlog用于記錄數(shù)據(jù)庫執(zhí)行的寫入性操作(不包括查詢)信息，以二進制的形式保存在磁盤中。binlog是mysql的邏輯日志，并且由Server層進行記錄，使用任何存儲引擎的mysql數(shù)據(jù)庫都會記錄binlog日志?？赏ㄟ^解析binlog文件來查看數(shù)據(jù)庫的操作歷史記錄

業(yè)內(nèi)比較成熟的有中間件Canal，我司也用的這個，Canal會模擬MySQL主從復(fù)制的交互協(xié)議，把自己偽裝成一個 MySQL 的從節(jié)點，向MySQL主節(jié)點發(fā)送dump請求，MySQL收到請求后，就會開始推送Binlog給Canal，Canal解析Binlog字節(jié)流，解析出其中有關(guān)數(shù)據(jù)庫中數(shù)據(jù)更新的日志，解析日志并執(zhí)行對應(yīng)數(shù)據(jù)的刪除緩存操作，然后再引入MQ，通過消息隊列的ACK機制，來確保這條消息的執(zhí)行成功

圖片

關(guān)注我，小牛呼嚕嚕，我再說幾句：

希望大家通過這些方案的學(xué)習(xí)，能夠領(lǐng)悟為什么只能滿足AP？

為什么緩存的數(shù)據(jù)一致性問題是無法避免的挑戰(zhàn)？

引入緩存后，我們該如何監(jiān)控起來呢？進一步分析過期時間是否合適，緩存的命中率

或者是否必需引入緩存？不引入緩存可就沒有緩存的數(shù)據(jù)一致性，這些都需要數(shù)據(jù)分析作為支撐

或者引入緩存如何進一步優(yōu)化，緩存的key如何花式設(shè)置，緩存預(yù)熱有講究，還有團隊如何規(guī)范使用緩存等等，有太多可以深究