前面一篇文章給大家介紹了 SpringBoot 項目是如何從單機切換接入集群的，沒看過的小伙伴可以去看一下SpringBoot 項目接入 Redis 集群 。這篇文章給大家介紹一個 Redis 工具 redis-full-check，主要是用來校驗遷移數(shù)據(jù)過后的準(zhǔn)確性，下面我們來看一下。

想必大家一定對 Redis 不會陌生，平常工作中或多或少都會用到，不管是用來存儲登錄信息還是用來緩存熱點數(shù)據(jù)，對我們來說都是很有幫助的。但是 Redis 的集群估計并不是每個人都會用到，因為很多業(yè)務(wù)場景或者系統(tǒng)都是一些簡單的管理系統(tǒng)，并不會需要用到 Redis 的集群環(huán)境。

哎，最近阿粉又雙叒叕犯事了。事情是這樣的，前一段時間阿粉公司生產(chǎn)交易偶發(fā)報錯，一番排查下來最終原因是因為 Redis 命令執(zhí)行超時。

URL 去重在我們?nèi)粘９ぷ髦泻兔嬖囍泻艹Ｓ龅?，包括阿里，網(wǎng)易云、優(yōu)酷、作業(yè)幫等知名互聯(lián)網(wǎng)公司都出現(xiàn)過類似的面試題，而且和 URL 去重比較類似的，如 IP 黑/白名單判斷等也經(jīng)常出現(xiàn)在我們的工作中，所以我們本文就來“盤一盤”URL 去重的問題。

事情是這樣的，前面面試問了幾個 Java 的相關(guān)問題，我朋友回答還不錯，接下來面試官就問了一句：看來 Java 基礎(chǔ)還不錯，Java HashMap 你熟悉吧？

redis速度快，可靠性高，是互聯(lián)網(wǎng)公司的標(biāo)配。它有單機、主從、哨兵、Cluster等四種部署模式。下面，僅從部署模式上，來說明一下它們的優(yōu)缺點。

但官方在推這個東西，注定了它的應(yīng)用越來越廣泛，這在平常的交流中就能夠發(fā)現(xiàn)。雖然有這樣那樣的缺點，但總抵擋不了權(quán)威推動的浪潮。隨著redis cluster越來越穩(wěn)定，是時候和redis cluster來一次靈魂交流了。

這年頭，你看到的東西未必就是你認為的東西。一個mysql協(xié)議的后面，可能是tidb；一個linux機器后面，可能是一個精簡的docker；你覺得xjjdog是個女的，但可能ta自己也不太清楚；而當(dāng)你大呼php萬歲的時候，可能是研發(fā)人員和你開個玩笑，重寫了后綴，而后端用的卻是java。

幾乎每一個分布式系統(tǒng)，都會給用戶提供自定義路由的功能。因為，僅通過range、mod、hash等方法，很大概率已經(jīng)滿足不了用戶的需求。下面以一個實際場景為例，說一下數(shù)據(jù)路由的思路。

redis功能強大，數(shù)據(jù)類型豐富，再快的系統(tǒng)，也經(jīng)不住瘋狂的濫用。通過禁用部分高風(fēng)險功能，并掛上開發(fā)的枷鎖，業(yè)務(wù)更能夠以簡潔、通用的思想去考慮問題，而不是綁定在某種實現(xiàn)上。