表關(guān)系描述
類似于好友之間的關(guān)聯(lián)關(guān)系，有表N，M以及N與M的關(guān)聯(lián)關(guān)系表，N表與M表假設(shè)均有100W的數(shù)據(jù)，M與N兩者關(guān)系是一個(gè)稀疏矩陣（只有少部分之間有關(guān)系，大約10%）。
業(yè)務(wù)場(chǎng)景
通過表N中的一條記錄，來查詢關(guān)聯(lián)的M有哪些人，并且這是一個(gè)高頻次操作。
存在的問題
mysql單庫承受如此多的查詢請(qǐng)求，容易拖垮整個(gè)庫。
解決方案
以下解決方案的目的是為了過濾掉空查詢。
Redis設(shè)置空值
方案描述
在查詢到N與M關(guān)聯(lián)關(guān)系表中的空值時(shí)，就往Redis存儲(chǔ)一個(gè)空值，設(shè)置一個(gè)的過期時(shí)間（固定時(shí)間+隨機(jī)時(shí)間），大約是3天。
問題
這個(gè)關(guān)系的N*M，需要把所有的空值都放進(jìn)去，按照假設(shè)的數(shù)據(jù)量，極限情況下Redis中需要存儲(chǔ)100W * 100W的數(shù)據(jù)，這個(gè)數(shù)據(jù)量是很大的。按照實(shí)際項(xiàng)目預(yù)估值，Redis大小是128G，每天增長在7GB左右，Redis滿了以后，會(huì)出現(xiàn)部分打在DB上的情況。
方案優(yōu)化
- 優(yōu)化Key的長度，降低內(nèi)存占用；
- 慢慢縮短過期時(shí)間，直到DB能夠承受的穿透查詢量；
- 調(diào)整Redis的緩存淘汰策略，從noevication（默認(rèn)，除了del請(qǐng)求，不會(huì)繼續(xù)服務(wù)寫請(qǐng)求）改為volatile-lru（淘汰設(shè)計(jì)了過期時(shí)間的key，最少使用的key被淘汰）；
- 加內(nèi)存，硬件相對(duì)人力成本很便宜。
將Redis當(dāng)做數(shù)據(jù)庫
方案描述
因?yàn)镹與N關(guān)系表是一個(gè)稀疏矩陣，按照10%的比例，數(shù)據(jù)大概在1000w左右，可以將Redis作為數(shù)據(jù)庫，直接將1000W數(shù)據(jù)放入Redis中。
問題
- 緩存與數(shù)據(jù)庫雙寫存在數(shù)據(jù)一致性問題;
- 業(yè)務(wù)變得更復(fù)雜，當(dāng)業(yè)務(wù)數(shù)據(jù)量增長后，需要付出很大的遷移代價(jià)。
方案優(yōu)化
針對(duì)問題1，可以通過訂閱mysql的binlog，主動(dòng)變更Redis的緩存。問題2是業(yè)務(wù)取舍，沒有什么很好的辦法。
使用布隆過濾器
布隆過濾器判斷數(shù)據(jù)不存在，則一定不存在。判斷數(shù)據(jù)存在，存在誤判概率。
方案描述
對(duì)于新增的數(shù)據(jù)，寫入Redis實(shí)現(xiàn)的布隆過濾器，刪除的數(shù)據(jù)不進(jìn)行處理。定時(shí)的重建布隆過濾器，例如每小時(shí)重建一次，那么在單位時(shí)間內(nèi)刪除量不是很大的情況下，打到數(shù)據(jù)庫層的空請(qǐng)求請(qǐng)求不會(huì)很多。并且，全量的數(shù)據(jù)使用布隆過濾器，對(duì)于3億的數(shù)據(jù)，內(nèi)存只需要大概十幾MB。額外需要再保證存在的數(shù)據(jù)也緩存一份到Redis中，如果有必要可以通過Guava做JVM級(jí)別的緩存。
判斷邏輯如下
- 判斷布隆過濾器中是否存在，若不存在，則返回；
- 布隆過濾器中存在，則判斷Redis是否存在，若存在，則返回；
- 若Redis中不存在，則去數(shù)據(jù)庫中查詢。
問題
- 布隆過濾器重建需要掃描全表，對(duì)與數(shù)據(jù)量多的表來說，mysql的壓力還是比較大；
方案優(yōu)化
需要小心平衡布隆過濾器重建間隔與mysql的訪問壓力。若布隆過濾器重建時(shí)間間隔太長，則被刪除的空數(shù)據(jù)還是會(huì)打入DB，若布隆過濾器重建時(shí)間間隔太短，全表查詢掃描會(huì)對(duì)mysql造成壓力。
