作者：z小趙

一枚用心堅(jiān)持寫(xiě)原創(chuàng)的“無(wú)趣”程序猿，在自身受益的同時(shí)也讓朋友們?cè)诩夹g(shù)上有所提升。

最近 DBA 反饋線(xiàn)上的一個(gè) Redis 資源已經(jīng)超過(guò)了預(yù)先設(shè)計(jì)時(shí)的容量，并且已經(jīng)進(jìn)行了兩次擴(kuò)容，內(nèi)存增長(zhǎng)還在持續(xù)中，希望業(yè)務(wù)方排查一下容量增長(zhǎng)是否正常，若正常則期望重新評(píng)估資源的使用情況，若不正常請(qǐng)盡快查明問(wèn)題并給出解決方案進(jìn)行處理。

問(wèn)題現(xiàn)象

下面是當(dāng)時(shí)資源容量使用和 key 數(shù)量的監(jiān)控情況：

從監(jiān)控可以看出，6.1 號(hào)開(kāi)始容量和 keys 的增長(zhǎng)陡增。首先懷疑是有惡意刷量的操作導(dǎo)致 key 數(shù)量增加比較多，經(jīng)過(guò)代碼排查后發(fā)現(xiàn)，確實(shí)有代碼漏洞導(dǎo)致可以惡意刷量，后經(jīng)過(guò) bug 修復(fù)后上線(xiàn)。你以為到這里就完事了？天真，要不然寫(xiě)這篇文章還有什么用？

但是從接口的請(qǐng)求量來(lái)看的話(huà)，刷量的情況并沒(méi)有那么明顯，下面是接口請(qǐng)求的 qps:

繼續(xù)排查存儲(chǔ)設(shè)計(jì)發(fā)現(xiàn)，存儲(chǔ)使用了 Set 結(jié)構(gòu)（由于產(chǎn)品最開(kāi)始沒(méi)有明確說(shuō)明一個(gè) key 下存儲(chǔ)多少元素，所以采用了 Set，這也為后續(xù)容量異常增長(zhǎng)打下了 堅(jiān)實(shí)的基礎(chǔ) ），實(shí)際每個(gè) Set 中只存儲(chǔ)了一個(gè)元素，但實(shí)際容量卻增長(zhǎng)了 30M，根據(jù)容量計(jì)算公式 9w * 14(key 長(zhǎng)度) * 1(元素個(gè)數(shù)) * 10（元素長(zhǎng)度）= 8.4M，實(shí)際容量卻超出了近 4 倍。

到此，產(chǎn)生了兩個(gè)懷疑點(diǎn)，其一：實(shí)際存儲(chǔ)的數(shù)據(jù)占用內(nèi)存大小有問(wèn)題，其二：容量評(píng)估公式有問(wèn)題。

疑點(diǎn)一：實(shí)際存儲(chǔ)的數(shù)據(jù)占用內(nèi)存大小有問(wèn)題

查看 Redis 的 Set 底層存儲(chǔ)結(jié)構(gòu)發(fā)現(xiàn)，Set 集合采用了整數(shù)集合和字典兩種方式來(lái)實(shí)現(xiàn)的，當(dāng)滿(mǎn)足如下兩個(gè)條件的時(shí)候，采用整數(shù)集合實(shí)現(xiàn)；一旦有一個(gè)條件不滿(mǎn)足時(shí)則采用字典來(lái)實(shí)現(xiàn)。

• Set 集合中的所有元素都為整數(shù)
• Set 集合中的元素個(gè)數(shù)不大于 512（默認(rèn) 512，可以通過(guò)修改 set-max-intset-entries 配置調(diào)整集合大小）

排查到這里，按照正常情況的話(huà)，其應(yīng)該采用的是整數(shù)集合存儲(chǔ)的才對(duì)啊，但是登陸到機(jī)器上，使用memory usage key命令查看內(nèi)存的使用情況發(fā)現(xiàn)，單個(gè) key 的內(nèi)存占用竟然達(dá)到了 218B ：

是不是覺(jué)得不可思議，只是存儲(chǔ)一個(gè) 10 位的數(shù)據(jù)且內(nèi)容是數(shù)字，為什么會(huì)占用這么大的內(nèi)存呢？

到此我們開(kāi)始懷疑是不是序列化的方式有問(wèn)題導(dǎo)致實(shí)際寫(xiě)入 Redis 的內(nèi)容不是一個(gè)數(shù)字，所以接著查數(shù)據(jù)實(shí)際寫(xiě)入時(shí)用的序列化方式。經(jīng)過(guò)排查發(fā)現(xiàn)寫(xiě)入的 value 被序列化以后變成了一個(gè)十六進(jìn)制的數(shù)據(jù)，到這里這個(gè)疑點(diǎn)基本就真相大白了，因?yàn)榇藭r(shí) Redis 認(rèn)為存儲(chǔ)的內(nèi)容已經(jīng)不適用于整數(shù)集合存儲(chǔ)了，而改為字典存儲(chǔ)。將序列化方式修改以后，測(cè)試添加一個(gè)元素進(jìn)去，發(fā)現(xiàn)實(shí)際內(nèi)存占用只有 72B，縮減為原來(lái)的 1/3：

疑點(diǎn)二：容量評(píng)估公式有問(wèn)題

容量評(píng)估公式忽略了 Redis 對(duì)于不同的情況下內(nèi)存的占用情況，統(tǒng)一按照元素的大小去計(jì)算，導(dǎo)致實(shí)際內(nèi)容占用過(guò)小。

到此，整個(gè) Redis 內(nèi)存容量增長(zhǎng)異?；旧峡梢愿嬉欢温妨?，接下來(lái)就是修改正確的序列化和反序列化方式，然后進(jìn)行洗庫(kù)操作，經(jīng)業(yè)務(wù)調(diào)查發(fā)現(xiàn)，目前的實(shí)際使用方式可以改為 KV 結(jié)構(gòu)，所以將底層存儲(chǔ)進(jìn)行了改造。

洗庫(kù)流程介紹

1. 上線(xiàn)雙寫(xiě)邏輯
2. 同步歷史數(shù)據(jù)
3. 切換讀取新數(shù)據(jù)源
4. 觀(guān)察線(xiàn)上業(yè)務(wù)是否正常
5. 關(guān)閉舊存儲(chǔ)的寫(xiě)入
6. 刪除舊資源
7. 下線(xiàn)舊的讀寫(xiě)邏輯

關(guān)于新數(shù)據(jù)的存儲(chǔ)位置有兩種選擇，

• 第一種方式是：舊數(shù)據(jù)正常寫(xiě)舊資源，新數(shù)據(jù)寫(xiě)到新部署的資源下。此種方式的優(yōu)點(diǎn)是，將舊數(shù)據(jù)全量洗入新資源后，然后下線(xiàn)舊資源就可以了；缺點(diǎn)是，需要在代碼層重新寫(xiě)一套到資源的配置，DBA 也需要新部署一個(gè)資源。
• 第二種方式是：新舊數(shù)據(jù)都寫(xiě)到舊資源里面，然后將舊數(shù)據(jù)映射到新數(shù)據(jù)結(jié)構(gòu)上，然后全量洗入舊資源。此種方式的優(yōu)點(diǎn)是，不需要重新寫(xiě)一套到資源的配置，DBA 也不需要新部署資源，只需要將舊資源的內(nèi)存進(jìn)行擴(kuò)容操作即可；缺點(diǎn)是，全量數(shù)據(jù)洗入完成后，需要手動(dòng)剔除舊數(shù)據(jù)。

兩種方案都可行，可以根據(jù)自己的喜好來(lái)選擇，我們最終選擇了第二種方案進(jìn)行數(shù)據(jù)清洗操作。

上線(xiàn)雙寫(xiě)邏輯

在資源存儲(chǔ)層，對(duì)上下行讀寫(xiě)操作分別增加 switcher（開(kāi)關(guān)），然后增加讀寫(xiě)新存儲(chǔ)的邏輯，代碼測(cè)試通過(guò)后上線(xiàn)。

這一步的流程在于開(kāi)關(guān)，可以選擇熱部署的任何方式來(lái)修改標(biāo)志位，從而控制代碼流程的執(zhí)行，另外需要注意的一點(diǎn)是：開(kāi)關(guān)狀態(tài)的修改不能被工程上下線(xiàn)所影響。

同步歷史數(shù)據(jù)

上線(xiàn)完成后，導(dǎo)出線(xiàn)上庫(kù)的 RDB 文件，解析出所有 key（關(guān)于 RDB 文件的解析，如果有專(zhuān)門(mén)的 DBA 同事，可以讓 DBA 同事給解析好，如果沒(méi)有的話(huà)，可以自己在網(wǎng)上查查 RDB 文件解析的工具，也不是很難）；依次遍歷解析出來(lái)的 key，查詢(xún) key 對(duì)應(yīng)的舊數(shù)據(jù)，將舊數(shù)據(jù)映射到新數(shù)據(jù)結(jié)構(gòu)下，最后寫(xiě)入到新的存儲(chǔ)下。

關(guān)于同步歷史數(shù)據(jù)，需要根據(jù)自身實(shí)際的業(yè)務(wù)場(chǎng)景去做適當(dāng)?shù)恼{(diào)整，這里只提供一個(gè)思路。下面是洗數(shù)據(jù)可以使用的小工具，需要的朋友可以適當(dāng)調(diào)整代碼邏輯就可以使用了：

public class fixData { public static void main(String[] args) {
        String fileName = "test.txt"; int rate = 500; int size = 200; if (args != null) {
            fileName = args[0];
            rate = Integer.parseInt(args[1]);
            size = Integer.parseInt(args[2]);
        }
        RateLimiter rateLimiter = RateLimiter.create(rate);
        ThreadPoolExecutor executorService = new ThreadPoolExecutor(size, size, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue());
        executorService.prestartAllCoreThreads(); try {
            FileReader fr = new FileReader(fileName);
            LineNumberReader br = new LineNumberReader(fr);
            String line; while ((line = br.readLine()) != null) { try {
                    rateLimiter.acquire();
                    executorService.submit(() -> { // TODO 編寫(xiě)自己的數(shù)據(jù)處理邏輯 });
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        System.exit(0);
    }
}

切換讀取新數(shù)據(jù)源

歷史所以數(shù)據(jù)同步完成后，將讀操作的開(kāi)關(guān)關(guān)閉，讓其走讀新存儲(chǔ)的邏輯

這一步需要注意的是，此時(shí)只修改下行讀取數(shù)據(jù)的開(kāi)關(guān)狀態(tài)，讓其讀取新數(shù)據(jù)源，上行寫(xiě)入數(shù)據(jù)開(kāi)關(guān)不動(dòng)，依舊讓其進(jìn)行雙寫(xiě)操作，防止下行切到新數(shù)據(jù)源有問(wèn)題需要回滾導(dǎo)致新舊數(shù)據(jù)不一致的尷尬情況發(fā)生。

觀(guān)察線(xiàn)上業(yè)務(wù)是否正常

切到讀新存儲(chǔ)的邏輯下，觀(guān)察線(xiàn)上業(yè)務(wù)，有無(wú)用戶(hù)投訴數(shù)據(jù)異常的情況

關(guān)閉就存儲(chǔ)的寫(xiě)入

線(xiàn)上業(yè)務(wù)無(wú)異常情況，將寫(xiě)操作也切到只寫(xiě)新存儲(chǔ)的邏輯下，停止舊資源的寫(xiě)入

刪除舊資源

將寫(xiě)上所有舊 key 全部剔除，剔除舊數(shù)據(jù)的操作方式可以復(fù)用洗數(shù)據(jù)的流程即可。

下線(xiàn)舊的讀寫(xiě)邏輯

將線(xiàn)上就的讀寫(xiě)邏輯代碼全部下線(xiàn)，最終完成整個(gè)數(shù)據(jù)清洗的全流程

總結(jié)

以上，是一次完整的真實(shí)生產(chǎn)環(huán)境中問(wèn)題排查及數(shù)據(jù)清洗全過(guò)程，通過(guò)本次問(wèn)題的排查，也進(jìn)一步加深了對(duì) Redis 的底層實(shí)現(xiàn)的認(rèn)識(shí)和理解；

同時(shí)，透過(guò)本次事故需要我們反思的是，面對(duì)親手寫(xiě)下的每一行代碼，都需要懷著一顆敬畏心理，永遠(yuǎn)不要輕視，有可能一個(gè)不小心就會(huì)釀成一個(gè)災(zāi)難性的事故。文章到此就先告一段落了，但是排查問(wèn)題的腳步還在繼續(xù)，歡迎關(guān)注我學(xué)習(xí)更多有干貨的知識(shí)。