redis集群不能使用的命令？不能可以使用SELECT命令，集群只建議使用設(shè)置的0號數(shù)據(jù)庫redis集群如何解決key不均勻？對分布式存儲系統(tǒng)的架構(gòu)和運(yùn)維管理，如何能絕對的保證每個Node的數(shù)據(jù)存儲容

redis集群不能使用的命令？

不能可以使用SELECT命令，集群只建議使用設(shè)置的0號數(shù)據(jù)庫

redis集群如何解決key不均勻？

對分布式存儲系統(tǒng)的架構(gòu)和運(yùn)維管理，如何能絕對的保證每個Node的數(shù)據(jù)存儲容量和跪請量注意均衡全面，是非常重要的。本文能介紹Redis大集群運(yùn)維過程中，較常見造成數(shù)據(jù)和幫忙量“下沉”的場景，及規(guī)避措施。Redis數(shù)據(jù)容量或各位量十分嚴(yán)重”偏轉(zhuǎn)”的影響以下從運(yùn)維的角度解釋，Redis數(shù)十節(jié)點(diǎn)的集群，又出現(xiàn)數(shù)據(jù)容量和跪請量傾斜情況下，必然的一些痛點(diǎn)：

小部分或單個節(jié)點(diǎn)跪請量”過熱”，可能導(dǎo)致Redis分布式系統(tǒng)失去可擴(kuò)展性能力和集群的意義，帶有MongoDB_id字段另外片鍵；造成運(yùn)維容量規(guī)劃，容量擴(kuò)展處理難度大；減小自動化配置管理難度；單集群節(jié)點(diǎn)注意材參數(shù)配置；監(jiān)控告警復(fù)雜（容量，QPS，直接連接數(shù)的閾值等）。那我們再仔細(xì)看生產(chǎn)環(huán)境中，常見導(dǎo)致Redis集群嚴(yán)重“傾斜”的場景

Redis集群較常見“下沉”的場景這類問題好象DBA規(guī)劃不恰當(dāng)?shù)脑?，業(yè)務(wù)鍵空間（keyspace）設(shè)計(jì)不合理等問題造成

DBA在規(guī)劃集群時或容量擴(kuò)展后，導(dǎo)致數(shù)據(jù)槽（哈希桶）位分配不均勻地，影響到內(nèi)存容量、鍵個數(shù)和幫忙QPS向下；業(yè)務(wù)的鍵空間設(shè)計(jì)不比較合理，有所謂“熱點(diǎn)sign”，會造成某少量KEY的QPS你操作比較大；這類節(jié)點(diǎn)QPS過載；程序源源不斷不使用Keyshashtags,可能會倒致某些數(shù)據(jù)槽位的鍵個數(shù)較多；程序存在地大的集群unlock（hash，set，list等），導(dǎo)致大key的地方節(jié)點(diǎn)的容量和QPS過高時；工和師不能執(zhí)行Monitor這類命令，導(dǎo)致當(dāng)前節(jié)點(diǎn)client輸出緩沖區(qū)速度變大，utilized_memory_rss被撐大，倒致節(jié)點(diǎn)內(nèi)存容量速度變大。接下來的，當(dāng)集群直接出現(xiàn)內(nèi)存容量、鍵數(shù)量或QPS幫忙量相當(dāng)嚴(yán)重向外傾斜時，我們應(yīng)該排查定位問題。

Redis集群“下沉”問題排查檢查集群每個分片的數(shù)據(jù)槽分配有無分布均勻

下面以Redis Cluster集群為例去確認(rèn)集群中，各個節(jié)點(diǎn)你們負(fù)責(zé)的數(shù)據(jù)槽位（slots）和key個數(shù)。下面demo的部分實(shí)例修真者的存在不中度“傾斜”，但不嚴(yán)重點(diǎn)，可決定進(jìn)行reblance。

排查節(jié)點(diǎn)熱點(diǎn)Key，可以確定iconcommands

建議使用redis-faina，不過有實(shí)時分析平臺就好些。從100元以內(nèi)示例中，可以說兩個前綴key的QPS占比基本都各為50%,肯定熱點(diǎn)unlock；也能看見auth命令的無比（hotcommands）。

程序是否內(nèi)的可以使用Keyshashtags

很有可能導(dǎo)致數(shù)據(jù)存儲內(nèi)存量，QPS都不分布均勻的問題，可建議使用scan掃描keyspace是否有使用hashtags的，或使用monitor，vc-redis-sniffer。

程序如何確定在用減小的真包含于鍵

比如說1kw個字段的hashunlock，內(nèi)存占用在幾個GB，這類集合sign隔一段時間你操作幾個字段，會很難從proxy或sdk發(fā)現(xiàn)到key的大小?？?cli–bigkeys

去確認(rèn)如何確定因monitor命令過多的輸出緩沖區(qū)占用內(nèi)存過大的問題

這類情況基本上Redis實(shí)例內(nèi)存會快速增長，很快地會出現(xiàn)回落。是從監(jiān)測client輸出緩沖區(qū)不使用情況：

查看作為輸出緩沖區(qū)列表長度不為0的client。可以說monitor占用帶寬作為輸出緩沖區(qū)370MB

怎么有效盡量的避免Redis集群“向外傾斜”問題集群作戰(zhàn)部署和快速擴(kuò)容全面處理，保證數(shù)據(jù)槽位分配總平均；keyspace設(shè)計(jì)時，怎么盡量減少熱點(diǎn)unlock,打散熱clientkey；業(yè)務(wù)在鍵空間設(shè)計(jì)時，中最好不要盡量的避免在用大的數(shù)學(xué)集合類型的Key，把key設(shè)計(jì)表格合并；程序角度不要盡量減少使用keyshashtag；盡量減少工程師直接不使用keys,monitor等命令，倒致控制輸出緩沖區(qū)淤積；合量配置normal的clientoutputbuffer，我建議你設(shè)置中10MB（警示:和業(yè)務(wù)去確認(rèn)調(diào)整再可以修改，避免業(yè)務(wù)出現(xiàn)錯誤）在求實(shí)際生產(chǎn)業(yè)務(wù)場景中，大規(guī)模行動集群不是那么容易可以做到集群的完全均衡，只是不要能保證不直接出現(xiàn)十分嚴(yán)重向外傾斜問題。

以上那就是我的觀點(diǎn)，對此這個問題大家是怎莫看待的呢？多謝了在下方評論區(qū)講解~我是科技領(lǐng)域創(chuàng)作者，十年互聯(lián)網(wǎng)從業(yè)經(jīng)驗(yàn)，歡迎關(guān)注我所了解大量科技知識！