Redis全量復(fù)制與部分復(fù)制示例詳解
更新時(shí)間：2019年08月27日 08:35:29 作者：豆子先生
這篇文章主要給大家介紹了關(guān)于Redis全量復(fù)制與部分復(fù)制的相關(guān)資料，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家學(xué)習(xí)或者使用Redis爬蟲(chóng)具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面來(lái)一起學(xué)習(xí)學(xué)習(xí)吧
Redis 主從復(fù)制
- Redis 實(shí)例劃分為主節(jié)點(diǎn)(master)和從節(jié)點(diǎn)(slave)
- 默認(rèn)情況下，Redis都是主節(jié)點(diǎn)
- 每個(gè)從節(jié)點(diǎn)只能有一個(gè)主節(jié)點(diǎn)，而主節(jié)點(diǎn)可以同時(shí)具有多個(gè)從節(jié)點(diǎn)
- 復(fù)制的數(shù)據(jù)流是單向的，只能由主節(jié)點(diǎn)復(fù)制到從節(jié)點(diǎn)
- slaveof 命令在使用時(shí)，可以運(yùn)行期動(dòng)態(tài)配置，也可以提前寫(xiě)到配置文件中
- 主從復(fù)制
| 步驟 | 詳細(xì)描述 |
|---|---|
| 保存主節(jié)點(diǎn)信息 | 執(zhí)行slaveof后從節(jié)點(diǎn)只保存主節(jié)點(diǎn)的地址信息便直接返回 |
| 主從建立socket連接 | 從節(jié)點(diǎn)(slave)內(nèi)部通過(guò)每秒運(yùn)行的定時(shí)任務(wù)維護(hù)復(fù)制相關(guān)邏輯，當(dāng)定時(shí)任務(wù)發(fā)現(xiàn)存在新的主節(jié)點(diǎn)后，會(huì)嘗試與該節(jié)點(diǎn)建立網(wǎng)絡(luò)連接;從節(jié)點(diǎn)會(huì)建立一個(gè)socket套接字，專(zhuān)門(mén)用于接受住節(jié)點(diǎn)發(fā)送的復(fù)制命令；如果從節(jié)點(diǎn)無(wú)法建立連接，定時(shí)任務(wù)會(huì)無(wú)限重試直到連接成功或者執(zhí)行 slaveof no one 取消復(fù)制 |
| 發(fā)送ping命令 | 連接建立成功后從節(jié)點(diǎn)發(fā)送ping請(qǐng)求進(jìn)行首次通信，ping請(qǐng)求的目的：檢測(cè)主從之間套接字是否可用；檢測(cè)主節(jié)點(diǎn)當(dāng)前是否可接受處理命令.如果發(fā)送ping命令后，從節(jié)點(diǎn)沒(méi)有收到主節(jié)點(diǎn)的pong回復(fù)或者超時(shí)，比如網(wǎng)絡(luò)超時(shí)或者主節(jié)點(diǎn)正在阻塞無(wú)法響應(yīng)命令，從節(jié)點(diǎn)會(huì)端口復(fù)制連接，下次定時(shí)任務(wù)會(huì)發(fā)起重連 |
| 權(quán)限驗(yàn)證 | 如果主節(jié)點(diǎn)設(shè)置了requirepass 參數(shù)，則需要密碼驗(yàn)證，從節(jié)點(diǎn)必須配置masterauth參數(shù)保證與主節(jié)點(diǎn)相同的密碼才能通過(guò)驗(yàn)證；如果驗(yàn)證失敗復(fù)制將終止，從節(jié)點(diǎn)重新發(fā)起復(fù)制流程 |
| 同步數(shù)據(jù)集 | 主從復(fù)制連接正常通信后，對(duì)于首次建立復(fù)制的場(chǎng)景，主節(jié)點(diǎn)會(huì)把持有的數(shù)據(jù)全部發(fā)送給從節(jié)點(diǎn). |
| 命令持續(xù)復(fù)制 | 當(dāng)主節(jié)點(diǎn)把當(dāng)前的數(shù)據(jù)同步給從節(jié)點(diǎn)后，變成了復(fù)制的建立流程，接下來(lái)主節(jié)點(diǎn)會(huì)持續(xù)地把寫(xiě)命令發(fā)送給從節(jié)點(diǎn)，保證主從數(shù)據(jù)一致性 |
- 啟動(dòng)6380、6381
- 6381 執(zhí)行命令
127.0.0.1:6381> slaveof 127.0.0.1 6380 Redis5.0.0 改為 ： replicaof <masterip> <masterport>
- 6380 啟動(dòng)
6381 啟動(dòng)
查看info replication
數(shù)據(jù)同步
| 類(lèi)型 | 描述 |
|---|---|
| 全量復(fù)制 | 一般用于初次復(fù)制場(chǎng)景，Redis早期支持的復(fù)制功能只有全量復(fù)制，它會(huì)把主節(jié)點(diǎn)全部數(shù)據(jù)一次性發(fā)送給從節(jié)點(diǎn)，當(dāng)數(shù)據(jù)量較大時(shí)，會(huì)對(duì)主從節(jié)點(diǎn)和網(wǎng)絡(luò)造成很大的開(kāi)銷(xiāo) |
| 部分復(fù)制 | 用于處理在主從復(fù)制中因網(wǎng)絡(luò)閃斷等原因造成的數(shù)據(jù)丟失場(chǎng)景，當(dāng)從節(jié)點(diǎn)再次連上主節(jié)點(diǎn)后，如果條件允許，主節(jié)點(diǎn)會(huì)補(bǔ)發(fā)丟失數(shù)據(jù)給從節(jié)點(diǎn)。因?yàn)檠a(bǔ)發(fā)的數(shù)據(jù)遠(yuǎn)遠(yuǎn)小于全量數(shù)據(jù)，可以有效避免全量復(fù)制的過(guò)高開(kāi)銷(xiāo) |
復(fù)制偏移量
| 參數(shù) | 描述 |
|---|---|
| master_repl_offset | 參與復(fù)制的主從節(jié)點(diǎn)都會(huì)維護(hù)自身復(fù)制偏移量。主節(jié)點(diǎn)(master)在處理完寫(xiě)入命令后，會(huì)把命令的字節(jié)長(zhǎng)度做累加記錄，統(tǒng)計(jì)信息在info replication中的master_repl_offset指標(biāo)中 |
| slave0 | 從節(jié)點(diǎn)(slave) 每秒鐘上報(bào)自身的復(fù)制偏移量給主節(jié)點(diǎn)，因此主節(jié)點(diǎn)也會(huì)保存從節(jié)點(diǎn)的復(fù)制偏移量 |
| slave_repl_offset | 從節(jié)點(diǎn)在接收到主節(jié)點(diǎn)發(fā)送的命令后，也會(huì)累加記錄自身的偏移量。 |
復(fù)制積壓緩沖區(qū)
- 復(fù)制積壓緩沖區(qū)是保存在主節(jié)點(diǎn)上的一個(gè)固定長(zhǎng)度的隊(duì)列，默認(rèn)大小為1MB，當(dāng)主節(jié)點(diǎn)有連接的從節(jié)點(diǎn)(slave)時(shí)被創(chuàng)建，這是主節(jié)點(diǎn)(master)響應(yīng)寫(xiě)命令時(shí)，不但會(huì)把命名發(fā)送給從節(jié)點(diǎn)，還會(huì)寫(xiě)入復(fù)制積壓緩沖區(qū)
- 由于緩沖區(qū)本質(zhì)上是先進(jìn)先出的定長(zhǎng)隊(duì)列，所以能實(shí)現(xiàn)保存最近已復(fù)制數(shù)據(jù)的功能，用于部分復(fù)制和復(fù)制命令丟失的數(shù)據(jù)補(bǔ)救
| 參數(shù) | 描述 |
|---|---|
| repl_backlog_active:1 | 開(kāi)啟復(fù)制緩沖區(qū) |
| repl_backlog_size:1048576 | 緩沖區(qū)最大長(zhǎng)度 |
| repl_backlog_first_byte_offset:1 | 起始偏移量，計(jì)算當(dāng)前緩沖區(qū)可用范圍 |
| repl_backlog_histlen:2301 | 已保存數(shù)據(jù)的有效長(zhǎng)度 |
| master_replid | 主節(jié)點(diǎn)實(shí)例的master_replid相同 |
| master_replid2 | 未發(fā)生切換，即主實(shí)例未發(fā)生過(guò)變化，所以初始值為0 |
psync 命令
從節(jié)點(diǎn)使用psync命令完成部分復(fù)制和全量復(fù)制功能
30227:M 05 Aug 2019 18:52:44.698 * Replica 127.0.0.1:6381 asks for synchronization 30227:M 05 Aug 2019 18:52:44.698 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'e7d71fb600183a175afadbd1354e97edddb2541a', my replication IDs are 'e24f6e42917e7c162ec45a713b0ee3872005ee8b' and '0000000000000000000000000000000000000000')
6381 從節(jié)點(diǎn)打印分析
31771:S 06 Aug 2019 12:21:40.213 * DB loaded from disk: 0.000 seconds 31771:S 06 Aug 2019 12:21:40.213 * Before turning into a replica, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer. #啟動(dòng)成功 31771:S 06 Aug 2019 12:21:40.213 * Ready to accept connections # 開(kāi)始連接主節(jié)點(diǎn) 31771:S 06 Aug 2019 12:21:40.214 * Connecting to MASTER 127.0.0.1:6380 # 開(kāi)始同步 31771:S 06 Aug 2019 12:21:40.214 * MASTER <-> REPLICA sync started 31771:S 06 Aug 2019 12:21:40.214 * Non blocking connect for SYNC fired the event. 31771:S 06 Aug 2019 12:21:40.214 * Master replied to PING, replication can continue... # 嘗試增量同步 31771:S 06 Aug 2019 12:21:40.214 * Trying a partial resynchronization (request 668b25f85e84c5900e1032e4b5e1f038f01cfa49:5895). # 全量同步 31771:S 06 Aug 2019 12:21:40.215 * Full resync from master: c88cd043d66193e867929d9d5fadc952954371e5:0 31771:S 06 Aug 2019 12:21:40.215 * Discarding previously cached master state. 31771:S 06 Aug 2019 12:21:40.240 * MASTER <-> REPLICA sync: receiving 224 bytes from master 31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Flushing old data 31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Loading DB in memory 31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Finished with success
全量復(fù)制
- 全量復(fù)制是Redis最早支持的復(fù)制方式，也是主從第一次建立復(fù)制時(shí)必須經(jīng)歷的階段。觸發(fā)全量復(fù)制的命令是sync和psync
- 發(fā)送psync命令進(jìn)行數(shù)據(jù)同步，由于是第一次進(jìn)行復(fù)制，從節(jié)點(diǎn)沒(méi)有復(fù)制偏移量和主節(jié)點(diǎn)的運(yùn)行ID，所以發(fā)送psync-1
- 主節(jié)點(diǎn)根據(jù)psync-1解析出當(dāng)前為全量復(fù)制，回復(fù)+FULLRESYNC響應(yīng)
- 從節(jié)點(diǎn)接收主節(jié)點(diǎn)的響應(yīng)數(shù)據(jù)保存運(yùn)行ID和偏移量offset
- 主節(jié)點(diǎn)執(zhí)行bgsave保存RDB文件到本地
31651:M 06 Aug 2019 11:08:40.802 * Starting BGSAVE for SYNC with target: disk 31651:M 06 Aug 2019 11:08:40.802 * Background saving started by pid 31676 31676:C 06 Aug 2019 11:08:40.805 * DB saved on disk 31676:C 06 Aug 2019 11:08:40.806 * RDB: 0 MB of memory used by copy-on-write 31651:M 06 Aug 2019 11:08:40.886 * Background saving terminated with success 31651:M 06 Aug 2019 11:08:40.886 * Synchronization with replica 127.0.0.1:6381 succeeded
- 主節(jié)點(diǎn)發(fā)送RDB給從節(jié)點(diǎn)，從節(jié)點(diǎn)把接收的RDB文件保存在本地并直接作為從節(jié)點(diǎn)的數(shù)據(jù)文件,接收完RDB后從節(jié)點(diǎn)打印相關(guān)日志
31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: receiving 224 bytes from master
- 對(duì)于從節(jié)點(diǎn)開(kāi)始接收RDB快照到接收完成期間，主節(jié)點(diǎn)仍然響應(yīng)讀寫(xiě)命令，因此主節(jié)點(diǎn)會(huì)把這期間寫(xiě)命令數(shù)據(jù)保存在復(fù)制客戶端緩沖區(qū)內(nèi)，當(dāng)從節(jié)點(diǎn)加載完RDB文件后，主節(jié)點(diǎn)再把緩沖區(qū)內(nèi)的數(shù)據(jù)發(fā)送個(gè)從節(jié)點(diǎn)，保證主從之間數(shù)據(jù)一致性。
- redis.conf 配置
client-output-buffer-limit replica 256mb 64mb 60
- 如果主節(jié)點(diǎn)創(chuàng)建和傳輸RDB的時(shí)間過(guò)長(zhǎng)，對(duì)于高流量寫(xiě)入場(chǎng)景非常容易造成主節(jié)點(diǎn)復(fù)制客戶端緩沖區(qū)溢出。默認(rèn)配置如上所示，如果60秒內(nèi)緩沖區(qū)消耗持續(xù)大于64MB或者直接超過(guò)256MB時(shí)，主節(jié)點(diǎn)將直接關(guān)閉復(fù)制客戶端連接，造成全量同步失敗
- 對(duì)于主節(jié)點(diǎn)，當(dāng)發(fā)送完所有的數(shù)據(jù)后就認(rèn)為全量復(fù)制完成.
31651:M 06 Aug 2019 11:08:40.886 * Synchronization with replica 127.0.0.1:6381 succeeded
- 從節(jié)點(diǎn)接收完主節(jié)點(diǎn)傳送來(lái)的全部數(shù)據(jù)后會(huì)清空自身舊數(shù)據(jù)
31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Flushing old data
- 從節(jié)點(diǎn)清空數(shù)據(jù)后開(kāi)始加載RDB文件，對(duì)于較大的RDB文件，這一步操作依然比較耗時(shí)，可以通過(guò)計(jì)算日志之間的時(shí)間差來(lái)判斷加載RDB的總耗時(shí)
31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Loading DB in memory 31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Finished with success
- 從節(jié)點(diǎn)成功加載完RDB后，如果當(dāng)前節(jié)點(diǎn)開(kāi)啟了AOF持久化功能，它會(huì)立刻做bgrewriteaof操作，為了保證全量復(fù)制后AOF持久化文件立刻可用。
- 全量復(fù)制耗時(shí)的原因：
- 主節(jié)點(diǎn)bgsave時(shí)間
- RDB文件網(wǎng)絡(luò)傳輸時(shí)間
- 從節(jié)點(diǎn)清空數(shù)據(jù)時(shí)間
- 可能的AOF重寫(xiě)時(shí)間
- 以下為Redis 3.0才會(huì)有
| 標(biāo)識(shí) | 含義 |
|---|---|
| M | 當(dāng)前為主節(jié)點(diǎn)日志 |
| S | 當(dāng)前為從節(jié)點(diǎn)日志 |
| C | 子進(jìn)程日志 |
部分復(fù)制
- 部分復(fù)制主要是Redis針對(duì)全量復(fù)制的過(guò)高開(kāi)銷(xiāo)做出的一種優(yōu)化措施，使用psync {runId}{offset}命令實(shí)現(xiàn)。當(dāng)從節(jié)點(diǎn)(slave)正在復(fù)制主節(jié)點(diǎn)(master)時(shí)，如果出現(xiàn)網(wǎng)絡(luò)閃斷或者命令丟失等異常情況時(shí)，從節(jié)點(diǎn)會(huì)向主節(jié)點(diǎn)要求補(bǔ)發(fā)丟失的命令數(shù)據(jù)，如果主節(jié)點(diǎn)的復(fù)制積壓緩沖區(qū)內(nèi)存咋這部分?jǐn)?shù)據(jù)則直接發(fā)送給從節(jié)點(diǎn)，這樣就可以保持主從節(jié)點(diǎn)復(fù)制的一致性。補(bǔ)發(fā)的這部分?jǐn)?shù)據(jù)一般遠(yuǎn)遠(yuǎn)小于全量數(shù)據(jù).
- 當(dāng)主節(jié)點(diǎn)直接網(wǎng)絡(luò)出現(xiàn)中斷是，如果超過(guò)repl-timeout時(shí)間，主節(jié)點(diǎn)會(huì)認(rèn)為從節(jié)點(diǎn)故障并中斷復(fù)制連接
31767:M 06 Aug 2019 14:13:26.096 # Connection with replica 127.0.0.1:6381 lost.
- 主從連接中斷期間主節(jié)點(diǎn)依然響應(yīng)命令，但因復(fù)制連接中斷命令無(wú)法發(fā)送給從節(jié)點(diǎn)，不過(guò)主節(jié)點(diǎn)內(nèi)部存在的復(fù)制積壓緩沖區(qū)，依然可以保存最近一段時(shí)間的寫(xiě)命令數(shù)據(jù)，默認(rèn)最大緩存1MB，可以通過(guò)into replication 查看
- 當(dāng)從節(jié)點(diǎn)網(wǎng)絡(luò)恢復(fù)后，從節(jié)點(diǎn)會(huì)再次連上主節(jié)點(diǎn)
從節(jié)點(diǎn)打?。? 31934:S 06 Aug 2019 14:20:54.745 * MASTER <-> REPLICA sync started 31934:S 06 Aug 2019 14:20:54.745 * Non blocking connect for SYNC fired the event. 31934:S 06 Aug 2019 14:20:54.745 * Master replied to PING, replication can continue... 31934:S 06 Aug 2019 14:20:54.745 * Trying a partial resynchronization (request c88cd043d66193e867929d9d5fadc952954371e5:9996). 31934:S 06 Aug 2019 14:20:54.746 * Successful partial resynchronization with master. 31934:S 06 Aug 2019 14:20:54.746 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization. 主節(jié)點(diǎn)打?。? 31767:M 06 Aug 2019 14:21:49.065 * Replica 127.0.0.1:6381 asks for synchronization 31767:M 06 Aug 2019 14:21:49.066 * Partial resynchronization request from 127.0.0.1:6381 accepted. Sending 0 bytes of backlog starting from offset 10066.
- 當(dāng)主從連接恢復(fù)后，由于從節(jié)點(diǎn)之前保存了自身已復(fù)制的偏移量和主節(jié)點(diǎn)的運(yùn)行ID。因此會(huì)把它們當(dāng)做psync參數(shù)發(fā)送個(gè)主節(jié)點(diǎn)，要求進(jìn)行部分復(fù)制操作.從節(jié)點(diǎn)對(duì)應(yīng)日志：
31938:S 06 Aug 2019 14:21:49.065 * Trying a partial resynchronization (request c88cd043d66193e867929d9d5fadc952954371e5:10066).
- 主節(jié)點(diǎn)接到psync命令后首先核對(duì)參數(shù)runId是否與自身一致，如果一致，說(shuō)明之前復(fù)制的是當(dāng)前主節(jié)點(diǎn)；之后根據(jù)參數(shù)offset在自身復(fù)制積壓緩沖區(qū)查找，如果偏移量之后的數(shù)據(jù)存在緩沖區(qū)中，則對(duì)從節(jié)點(diǎn)發(fā)送+COUTINUE響應(yīng)，表示可以進(jìn)行部分復(fù)制。從節(jié)點(diǎn)接到回復(fù)打印如下：
31938:S 06 Aug 2019 14:21:49.066 * Successful partial resynchronization with master. 31938:S 06 Aug 2019 14:21:49.066 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.
- 主節(jié)點(diǎn)根據(jù)偏移量把復(fù)制積壓緩沖區(qū)里的數(shù)據(jù)發(fā)送給從節(jié)點(diǎn)，保證主從復(fù)制進(jìn)入正常狀態(tài)。發(fā)送的數(shù)據(jù)量可以在主節(jié)點(diǎn)的日志獲取
31767:M 06 Aug 2019 14:21:49.065 * Replica 127.0.0.1:6381 asks for synchronization 31767:M 06 Aug 2019 14:21:49.066 * Partial resynchronization request from 127.0.0.1:6381 accepted. Sending 0 bytes of backlog starting from offset 10066.
心跳
- 主從節(jié)點(diǎn)在建立復(fù)制后,它們之間維護(hù)著長(zhǎng)連接并彼此發(fā)送心跳命令
- 主從心跳判斷機(jī)制：
- 主從節(jié)點(diǎn)彼此都有心跳檢測(cè)機(jī)制，各自模擬對(duì)方的客戶端進(jìn)行通信，主節(jié)點(diǎn)的連接狀態(tài)為flags=M,從節(jié)點(diǎn)連接狀態(tài)為flags=S
- 主節(jié)點(diǎn)默認(rèn)每隔10秒對(duì)從節(jié)點(diǎn)發(fā)送ping命令，判斷從節(jié)點(diǎn)的存活性和連接狀態(tài)。可以通過(guò)repl-ping-replica-period 10 控制發(fā)送頻率
- 從節(jié)點(diǎn)在主線程中每隔一秒發(fā)送replconf ack{offset} 命令，給主節(jié)點(diǎn)上報(bào)自身當(dāng)前的復(fù)制偏移量。主節(jié)點(diǎn)根據(jù)replconf命令判斷從節(jié)點(diǎn)超時(shí)時(shí)間，體現(xiàn)在info replication 統(tǒng)計(jì)中的lag信息中，lag表示從節(jié)點(diǎn)最后一次通信延遲的秒數(shù)，正常延遲應(yīng)該在0到1之間。如果超過(guò)repl-timeout配置的值(默認(rèn)60秒),則判定從節(jié)點(diǎn)下線并斷開(kāi)復(fù)制客戶端連接。即使主節(jié)點(diǎn)判定從節(jié)點(diǎn)下線后，如果從節(jié)點(diǎn)重新恢復(fù)，心跳檢測(cè)和繼續(xù)執(zhí)行.
異步復(fù)制
- 主節(jié)點(diǎn)不但負(fù)責(zé)數(shù)據(jù)讀寫(xiě)，還負(fù)責(zé)把寫(xiě)命令同步給從節(jié)點(diǎn)。寫(xiě)命令的發(fā)送過(guò)程是異步完成，也就是說(shuō)主節(jié)點(diǎn)自身處理完寫(xiě)命令后直接返回給客戶端，并不等待從節(jié)點(diǎn)復(fù)制完成。
讀寫(xiě)分離
- 對(duì)于讀占比較高的場(chǎng)景，可以通過(guò)把一部分讀流量分?jǐn)偟綇墓?jié)點(diǎn)(slave)來(lái)減輕主節(jié)點(diǎn)(master)壓力，同時(shí)需要注意永遠(yuǎn)只對(duì)主節(jié)點(diǎn)執(zhí)行寫(xiě)操作
- 建議大家在做讀寫(xiě)分離之前，可以考慮使用Redis Cluster 等分布式解決方案
總結(jié)
以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。
相關(guān)文章
今天小編就為大家分享一篇關(guān)于Redis主從復(fù)制詳解，小編覺(jué)得內(nèi)容挺不錯(cuò)的，現(xiàn)在分享給大家，具有很好的參考價(jià)值，需要的朋友一起跟隨小編來(lái)看看吧2019-01-01
Redis 緩存使用內(nèi)存來(lái)保存數(shù)據(jù),隨著需要緩存的數(shù)據(jù)量越來(lái)越大,有限的緩存空間不可避免地會(huì)被寫(xiě)滿,本文主要介紹了Redis 緩存滿了如何解決,感興趣的可以了解一下2023-08-08
Redis實(shí)現(xiàn)高并發(fā)計(jì)數(shù)器
這篇文章主要為大家詳細(xì)介紹了Redis實(shí)現(xiàn)高并發(fā)計(jì)數(shù)器，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2018-10-10
Redis對(duì)lua腳本的支持是從Redis2.6.0版本開(kāi)始引入的,它可以讓用戶在Redis服務(wù)器內(nèi)置的Lua解釋器中執(zhí)行指定的lua腳本,本文就來(lái)介紹一下Redis整合Lua腳本的實(shí)現(xiàn),感興趣的可以了解一下2024-03-03
散列類(lèi)型的鍵值其實(shí)也是一種字典解耦，其存儲(chǔ)了字段和字段值的映射，但字段值只能是字符串，不支持其他數(shù)據(jù)類(lèi)型，所以說(shuō)散列類(lèi)型不能嵌套其他的數(shù)據(jù)類(lèi)型。下面就來(lái)詳細(xì)介紹下Redis中散列類(lèi)型的常用命令，有需要的可以參考學(xué)習(xí)。2016-09-09
redis數(shù)據(jù)類(lèi)型_動(dòng)力節(jié)點(diǎn)Java學(xué)院整理
這篇文章主要介紹了redis數(shù)據(jù)類(lèi)型，小編覺(jué)得挺不錯(cuò)的，現(xiàn)在分享給大家，也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧2017-08-08
文章介紹了Redis連接池的配置方法,包括與數(shù)據(jù)庫(kù)連接時(shí)引入連接池的必要性、Java中使用Redis連接池的示例、jar包準(zhǔn)備、編寫(xiě)配置代碼以及連接池參數(shù)的設(shè)置2024-12-12
redis是一個(gè)開(kāi)源的、使用C語(yǔ)言編寫(xiě)的、支持網(wǎng)絡(luò)交互的、可基于內(nèi)存也可持久化的Key-Value數(shù)據(jù)庫(kù)。本文給大家介紹SpringBoot 集成Redis 過(guò)程，感興趣的朋友一起看看吧2021-06-06
超賣(mài)問(wèn)題是典型的多線程安全問(wèn)題,本文就來(lái)介紹一下Redis分布式鎖解決超賣(mài)問(wèn)題,具有一定的參考價(jià)值,感興趣的可以了解一下2023-12-12
本文主要介紹了redis擊穿現(xiàn)象如何防止，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2023-07-07