深入理解Redis Cluster

Redis Cluster采用虚拟槽分区,所有的key根据哈希函数映射到0~16383槽内,计算公式:

slot = CRC16(key) & 16383

每个节点负责维护一部分槽以及槽所映射的键值对。

Redis虚拟槽分区的特点,解耦数据与节点之间的关系,简化了节点扩容和收缩难度。但其存在如下限制:

1. key批量操作支持有限。只支持具有相同slot值的key执行批量操作。

2. 事务操作支持有限。只支持同一个节点上的多个key的事务操作。

3. key是数据分区的最小粒度,因为不能讲一个大的键值对象,如hash,list等映射到不同的节点上。

4. 不支持多数据库,单机下的Redis可以支持16个数据库,但集群之只能使用一个数据库空间,即db 0。

5. 复制结构只支持一层,从节点只能复制主节点,不支持嵌套树状复制结构。

 

如何手动创建一个Redis Cluster

创建三个目录,分别用于存放数据,配置文件和日志。

mkdir -p /opt/redis/data/
mkdir -p /opt/redis/conf/
mkdir -p /opt/redis/log

 

编辑配置文件

vim redis_6379.conf

port 6379
daemonize yes
pidfile "/opt/redis/data/redis_6379.pid"
loglevel notice
logfile /opt/redis/log/redis_6379.log
dbfilename dump_6379.rdb
dir /opt/redis/data
appendonly yes
appendfilename appendonly_6379.aof
cluster-enabled yes
cluster-config-file /opt/redis/conf/nodes-.conf
cluster-node-timeout 15000

为简化起见,这里只贴出了redis的几个关键参数,其中,后面三个参数与Cluster有关。

cp redis_6379.conf redis_6380.conf
cp redis_6379.conf redis_6381.conf
cp redis_6379.conf redis_6382.conf
cp redis_6379.conf redis_6383.conf
cp redis_6379.conf redis_6384.conf
sed -i 's/6379/6380/g' redis_6380.conf 
sed -i s/6379/6381/g redis_6381.conf 
sed -i s/6379/6382/g redis_6382.conf 
sed -i s/6379/6383/g redis_6383.conf 
sed -i s/6379/6384/g' redis_6384.conf 

 

启动所有节点

cd /opt/redis/conf
redis-server redis_6379.conf
redis-server redis_6380.conf
redis-server redis_6381.conf
redis-server redis_6382.conf
redis-server redis_6383.conf
redis-server redis_6384.conf

 

节点启动后,会在conf目录下创建nodes-xxxx.conf文件,文件中记录了节点ID。

[root@slowtech conf]# ls
nodes-6379.conf  nodes-6381.conf  nodes-6383.conf  redis_6379.conf  redis_6381.conf  redis_6383.conf
nodes-6380.conf  nodes-6382.conf  nodes-6384.conf  redis_6380.conf  redis_6382.conf  redis_6384.conf

[root@slowtech conf]# cat  nodes-.conf 
260a27a4afd7be954f7cb4fe12be10641f379746 :0@0 myself,master - 0 0 connected
vars currentEpoch 0 lastVoteEpoch 0

 

将节点加入到集群中

redis-cli -p 6379 cluster meet 127.0.0.1 6380
redis-cli -p 127.0.0.1 638163826384

cluster meet命令的流程,以第一条命令为例。

1.  6379节点在收到命令后,会为6380节点创建一个clusterNode结构,并将其添加到自己的clusterState.nodes字典里。接着,6379节点向6380节点发送一条MEET消息。

2.  6380节点在收到6379节点的meet消息后,也会为6379节点创建一个clusterNode结构,并将其添加到自己的clusterSta.nodes字典里。并向6379节点返回一条PONG消息。

3.  6379节点在收到这条PONG消息后,会向6380节点返回一个PING消息。

4 . 6380节点收到6379节点返回的PING消息,知道6379节点已经收到自己返回的PONG消息,握手完成。

之后,6379会将6380的消息通过Gossip协议传播给集群中的其它节点,让其它节点也同6380节点握手,最终,6380节点会被集群中的所有节点认识。

 

查看当前集群的节点信息

0.1:6379> cluster nodes
260a27a4afd7be954f7cb4fe12be10641f379746 6379@16379 myself,1)">1539088861000 1 connected
645438fcdb241603fbc92770ef08fa6d2d4c7ffc 6380@16380 master - 1539088860000 2 connected
bf1aa1e626988a5a35bc2a837c3923d472e49a4c 6381@16381 master - 1539088860730  connected
5350673149500f4c2fd8b87a8ec1b01651572fae 6383@16383 master - 4 connected
7dd5f5cc8d96d08f35ff395d05eb30ac199f7568 6382@16382 master - 1539088862745 3 connected
8679f302610e9ea9a464c247f70924e34cd20512 6384@16384 master - 1539088862000 5 connected

虽然六个节点已经加入到集群中了,但此时集群仍处于下线状态。

 cluster info
cluster_state:fail
cluster_slots_assigned:
cluster_slots_ok:
cluster_slots_pfail:
cluster_slots_fail:
cluster_known_nodes:6
cluster_size:
cluster_current_epoch:5
cluster_my_epoch:
cluster_stats_messages_ping_sent:799
cluster_stats_messages_pong_sent:826
cluster_stats_messages_meet_sent:
cluster_stats_messages_sent:1630
cluster_stats_messages_ping_received:
cluster_stats_messages_pong_received:804
cluster_stats_messages_received:1630

 

分配槽

将16384个slot平均分配给6379,6380,6381三个节点。

redis-cli -p 6379 cluster addslots {0..5461}

redis-cli -p 6380 cluster addslots {5462..10922}

redis-cli -p 6381 cluster addslots {10923..16383}

集群的整个数据库被分为16384个槽,集群中的每个节点可以处理0个或最多16384个槽。当数据库中的16384个槽都有节点在处理时,集群处于上线状态(ok),反之,如果数据库中有任何一个槽没有得到处理,则集群处理下线状态(fail)。

查看集群状态

# redis-cli -p 6379
 cluster info
cluster_state:ok
cluster_slots_assigned:163846212634812565621712565

查看节点和槽的分配关系

1539094639000 1 connected 0-5461
645438fcdb241603fbc92770ef08fa6d2d4c7ffc 1539094636362 2 connected 5462-10922
bf1aa1e626988a5a35bc2a837c3923d472e49a4c 1539094639389 0 connected 10923-16383
5350673149500f4c2fd8b87a8ec1b01651572fae 1539094637000 1539094638000 1539094638381 5 connected

 

使用cluster replicate添加从节点

cluster replicate命令必须在对应的从节点上执行,后面接的是主节点的节点ID。

[root@slowtech conf]# redis-cli -p 6382
6382> cluster replicate 260a27a4afd7be954f7cb4fe12be10641f379746
OK
 quit
[root@slowtech conf]# redis-cli -p 6383
6383> cluster replicate 645438fcdb241603fbc92770ef08fa6d2d4c7ffc
OK
6384
6384> cluster replicate bf1aa1e626988a5a35bc2a837c3923d472e49a4c
OK

快捷命令

echo cluster replicate `redis-cli -p 6379 cluster nodes | grep 6379 | awk '{print $1}'`" | redis-cli -p 6382 -x
echo cluster replicate `redis-cli -p 6379 cluster nodes | grep 6380 | awk '{print $1}'`6383 -cluster replicate `redis-cli -p 6379 cluster nodes | grep 6381 | awk '{print $1}'`6384 -x

 

查看节点和槽的分配关系

 cluster nodes
8679f302610e9ea9a464c247f70924e34cd20512 16384 myself,slave bf1aa1e626988a5a35bc2a837c3923d472e49a4c 1539094947000 16382 slave 260a27a4afd7be954f7cb4fe12be10641f379746 16383 slave 645438fcdb241603fbc92770ef08fa6d2d4c7ffc 1539094946000 1539094948000 1539094947306 
260a27a4afd7be954f7cb4fe12be10641f379746 16379 master - 1539094948308 5461

至此,我们基于Redis协议手动创建了一个Cluster,其由6个节点组成,3个主节点负责处理数据,3个从节点负责故障切换。

 

键到slot的映射算法

HASH_SLOT=CRC16(key)mod16384

 

重新分片的流程

1. 对目标节点发送cluster setslot <slot> importing <source-node-id>命令,让目标节点准备导入槽的数据。

2. 对源节点发送cluster setslot <slot> migrating <destination-node-id>命令,让源节点准备迁出槽的数据。

3.  源节点循环执行cluster getkeysinslot {slot} {count}命令,获取count个属于槽{slot}的键。

4. 在源节点执行

4. 对于步骤3中获取的每个key,redis-trib.rb都向源节点发送一个MIGRATE <target_ip> <target_port> <key_name> 0 <timeout> 命令,将被选中的键原子性地从源节点迁移至目标节点。

5. 重复执行步骤3和4,直到源节点保存的所有属于槽slot的键值对都被迁移到目标节点为止。

6. redis-trib.rb向集群中的任意一个节点发送CLUSTER SETSLOT <slot> NODE <node-id>命令,将槽slot指派给目标节点。这一消息会发送给整个集群。

 

客户端ASK重定向流程

Redis集群支持在线迁移slot和数据来完成水平伸缩,当slot对应的数据从源节点到目标节点迁移过程中,客户端需要做到智能识别,保证键命令可正常执行。例如,当一个slot数据从源节点迁移到目标节点时,可能会出现一部分数据在源节点,另一部分在目标节点。

如果出现这种情况,客户端键执行流程将发生变化,如下所示,

1. 客户端根据slot缓存发送命令到源节点,如果存在key则直接执行并返回结果。

2. 如果key不存在,则可能存在于目标节点,这时会回复ASK重定向异常,格式如下:(error) ASK {slot} {targetIP}:{targetPort}。

3. 客户单从ASK重定向异常提出目标节点信息,发送asking命令到目标节点打开客户端连接标识,再执行键命令。如果存在则执行,不存在则返回不存在信息。

ASK与MOVED虽然都是对客户端进的重定向,但是有着本质区别,前者说明集群正在进行slot数据迁移,所以只是临时性的重定向,不会更新slot缓存,但是MOVED重定向说明键对应的槽已经明确指定到新的节点,会更新slot缓存。

 

模拟Redis Cluster FAILOVER的过程

模拟主节点故障,手动kill 6379节点。

1. 首先,该节点对应的从节点会有日志输出。

16387:S 15 Oct 10:34:30.149 # Connection with master lost.
30.149 * Caching the disconnected master state.
30.845 * Connecting to MASTER 30.845 * MASTER <-> SLAVE sync started
30.845 # Error condition on socket for SYNC: Connection refused
...
49.994 * MASTER <->49.994 # Error condition on socket  SYNC: Connection refused
50.898 * FAIL message received from bd341bb4c10e0dbff593bf7bafb1309842fba155 about 72af03587f5e9f064721d3b3a92b1439b3785623
50.898 # Cluster state changed: fail

发现连接断开的时间点是10:34:30.149,判断其主观下线的时间为10:34:50,相差20s,这也是cluster-node-timeout的设置。

 

2. 再来看看6380节点的日志。

16383:M 50.897 * Marking node 72af03587f5e9f064721d3b3a92b1439b3785623 as failing (quorum reached).
50.897 # Cluster state changed: fail

6381节点的日志同样如此,超过半数,因此标记6379节点为客观下线。

 

3. 再来看看从节点的日志

51.003 * Connecting to MASTER 51.003 * MASTER <->51.003 # Start of election delayed for 566 milliseconds (rank #0,offset 154).
51.003 # Error condition on socket for SYNC: Connection refused

从节点识别正在复制的主节点进入客观下线后准备选举时间,日志打印了选举延迟566毫秒之后执行。

延迟选举时间到达后,从节点更新配置纪元并发起故障选举。

51.605 # Starting a failover election for epoch 7.

 

4. 6380和6381主节点为从节点投票

16385:M 51.618 # Failover auth granted to 886c1f990191854df1972c4bc4d928e44bd36937 7

 

5. 从节点获取2个主节点投票之后,超过半数执行替换主节点操作,完成故障切换。

51.622 # Failover election won: Im the new master.
51.622 # configEpoch set to 7 after successful failover
16387:M 51.622 # Setting secondary replication ID to 207c65316707a8ec2ca83725ae53ab49fa25dbfb,valid up to offset: 155. New replication ID is 0ec4aac9562b3f4165244153646d9c9006953736
16387
:M 51.622 * Discarding previously cached master state. 51.622 # Cluster state changed: ok

 

Failover的流程

一、主观下线

集群中每个节点都会定期向其他节点发送ping消息,接收节点回复pong消息作为响应。如果在cluster-node-timeout时间内通信一直失败,则发送节点会认为接收节点存在故障,把接收节点标记为主观下线(pfail)状态。


二、客观下线

当某个节点判断另一个节点主观下线后,相应的节点状态会跟随消息在集群内传播。通过Gossip消息传播,集群内节点不断收集到故障节点的下线报告。当半数以上持有槽的主节点都标记某个节点是主观下线时,触发客观下线流程。

集群中的节点每次接收到其他节点的pfail状态,都会尝试触发客观下线,流程说明:

1. 首先统计有效的下线报告数量,如果小于集群内持有槽的主节点总数的一半则退出。

2. 当下线报告大于槽主节点数量一半时,标记对应故障节点为客观下线状态。

3. 向集群广播一条fail消息,通知所有的节点将故障节点标记为客观下线,fail消息的消息体只包含故障节点的ID。

 

广播fail消息是客观下线的最后一步,它承担着非常重要的职责:

1. 通知集群内所有的节点标记故障节点为客观下线状态并立刻生效。

2. 通知故障节点的从节点触发故障转移流程。

 

三、故障切换

故障节点变为客观下线后,如果下线节点是持有槽的主节点则需要在它的从节点中选出一个替换它,从而保证集群的高可用。下线主节点的所有从节点承担故障恢复的义务,当从节点通过内部定时任务发现自身复制的主节点进入客观下线时,将会触发故障切换流程。

1.资格检查

每个从节点都要检查最后与主节点断线时间,判断是否有资格替换故障的主节点。如果从节点与主节点断线时间超过cluster-node-time*cluster-slave-validity-factor,则当前从节点不具备故障转移资格。参数cluster-slavevalidity-factor用于从节点的有效因子,默认为10。

2.准备选举时间

当从节点符合故障切换资格后,更新触发切换选举的时间,只有到达该时间后才能执行后续流程。

这里之所以采用延迟触发机制,主要是通过对多个从节点使用不同的延迟选举时间来支持优先级问题。复制偏移量越大说明从节点延迟越低,那么它应该具有更高的优先级来替换故障主节点。

3.发起选举

当从节点定时任务检测到达故障选举时间(failover_auth_time)到达后,发起选举流程如下:

1> 更新配置纪元

2> 广播选举消息

在集群内广播选举消息(FAILOVER_AUTH_REQUEST),并记录已发送过消息的状态,保证该从节点在一个配置纪元内只能发起一次选举。

4.选举投票

只有持有槽的主节点才会处理故障选举消息(FAILOVER_AUTH_REQUEST),因为每个持有槽的节点在一个配置纪元内都有唯一的一张选票,当接到第一个请求投票的从节点消息时回复FAILOVER_AUTH_ACK消息作为投票,之后相同配置纪元内其他从节点的选举消息将忽略。

Redis集群没有直接使用从节点进行领导者选举,主要因为从节点数必须大于等于3个才能保证凑够N/2+1个节点,将导致从节点资源浪费。使用集群内所有持有槽的主节点进行领导者选举,即使只有一个从节点也可以完成选举过程。

5.替换主节点

当从节点收集到足够的选票之后,触发替换主节点操作:

1> 当前从节点取消复制变为主节点。

2> 执行clusterDelSlot操作撤销故障主节点负责的槽,并执行clusterAddSlot把这些槽委派给自己。

3> 向集群广播自己的pong消息,通知集群内所有的节点当前从节点变为主节点并接管了故障主节点的槽信息。

 

故障切换时间

在介绍完故障发现和恢复的流程后,我们估算下故障切换时间:

1> 主观下线(pfail)识别时间=cluster-node-timeout。

2> 主观下线状态消息传播时间<=cluster-node-timeout/2。消息通信机制对超过cluster-node-timeout/2未通信节点会发起ping消息,消息体在选择包含哪些节点时会优先选取下线状态节点,所以通常这段时间内能够收集到半数以上主节点的pfail报告从而完成故障发现。

3> 从节点转移时间<=1000毫秒。由于存在延迟发起选举机制,偏移量最大的从节点会最多延迟1秒发起选举。通常第一次选举就会成功,所以从节点执行转移时间在1秒以内。

根据以上分析可以预估出故障转移时间,如下:

failover-time(毫秒) ≤ cluster-node-timeout + cluster-node-timeout/2 + 1000

因此,故障转移时间跟cluster-node-timeout参数息息相关,默认15秒。

 

Redis Cluster的相关参数

cluster-enabled <yes/no>:是否开启集群模式。

cluster-config-file <filename>:集群配置文件,由集群自动维护,不建议手动编辑。

cluster-node-timeout <milliseconds>:集群中每个节点都会定期向其他节点发送ping消息,接收节点回复pong消息作为响应。如果在cluster-node-timeout时间内通信一直失败,则发送节点会认为接收节点存在故障,把接收节点标记为主观下线(pfail)状态。默认15000,即15s。

cluster-slave-validity-factor <factor>:每个从节点都要检查最后与主节点断线时间,判断其是否有资格替换故障的主节点。如果从节点与主节点断线时间超过cluster-node-time*cluster-slave-validity-factor,则当前从节点不具备故障转移资格。

cluster-migration-barrier <count>:主节点需要的最小从节点数,只有达到这个数,才会将多余的从节点迁移给其它孤立的主节点使用。

cluster-require-full-coverage <yes/no>:默认情况下当集群中16384个槽,有任何一个没有指派到节点时,整个集群是不可用的。对应在线上,如果某个主节点宕机,而又没有从节点的话,是不允许对外提供服务的。建议将该参数设置为no,避免某个主节点的故障导致其它主节点不可用。

 

Redis Cluster的相关命令

CLUSTER ADDSLOTS slot [slot ...]:对当前节点手动分配slot。

CLUSTER MEET ip port:将其它节点添加到Redis Cluster中。

CLUSTER INFO:打印Cluster的相关信息。

# redis-cli -c cluster info
cluster_state:ok
cluster_slots_assigned:7026641366659
cluster_stats_messages_meet_received:1366

 

CLUSTER KEYSLOT key:查看key对应的slot

 cluster keyslot hello
(integer) 866
 cluster keyslot world
(integer) 9059
 cluster keyslot hello{tag}
(integer) 8338
 cluster keyslot world{tag}
(integer) 8338

 

CLUSTER NODES:获取Cluster的节点信息,与当前节点的集群配置文件中的内容基本一致,只不过后者还会维护当前节点的配置纪元。

[root@slowtech conf]# redis-cli -p 6380 -c cluster nodes
72969ae6214dce5783d5b13b1bad34701303e96c 16382 slave 7396e133fd8143335d5991734e68fcfcfc5adfd1 1539594959692  connected
a0efce44c96f95b2cdaf1101805710f41dfe4d06 1539594962724 3 connected 
276cf1128c50faa81a6b073079cc5e2c7a51a4ec 16380 myself,1)">1539594958000 5461-
b39826ebe9e741c8dc1fea7ee6966a42c5030726 16384 slave a0efce44c96f95b2cdaf1101805710f41dfe4d06 1539594961000  connected
81f99ce264626895e30a5030ac27b84efedfa622 16383 slave 276cf1128c50faa81a6b073079cc5e2c7a51a4ec 1539594961713  connected
7396e133fd8143335d5991734e68fcfcfc5adfd1 1539594960703 5460

[root@slowtech conf]# cat nodes-.conf 
72969ae6214dce5783d5b13b1bad34701303e96c 1539592972569 1539592969000 1539592971000 1539592971558 
vars currentEpoch 6 lastVoteEpoch 0

 

CLUSTER REPLICATE node-id:在对应的从节点上执行,后面接的是主节点的节点ID。

 

CLUSTER SLAVES node-id:查看某个节点的从节点。

[root@slowtech conf]# redis-cli -c cluster slaves a0efce44c96f95b2cdaf1101805710f41dfe4d06
1) b39826ebe9e741c8dc1fea7ee6966a42c5030726 127.0.0.1:6384@16384 slave a0efce44c96f95b2cdaf1101805710f41dfe4d06 0 1539596409000 6 connected

[root@slowtech conf]# redis-cli -c cluster slaves b39826ebe9e741c8dc1fea7ee6966a42c5030726
(error) ERR The specified node is not a master

 

CLUSTER SLOTS:输出slot与节点的映射关系。

# redis-cli cluster slots
1) (integer) 5461
   2) (integer) 10922
   3) 127.0.0.1"
      6380
      276cf1128c50faa81a6b073079cc5e2c7a51a4ec"
   4) 6383
      81f99ce264626895e30a5030ac27b84efedfa622"
2) 0
   5460
   6379
      7396e133fd8143335d5991734e68fcfcfc5adfd16382
      72969ae6214dce5783d5b13b1bad34701303e96c10923
   16383
   6381
      a0efce44c96f95b2cdaf1101805710f41dfe4d066384
      b39826ebe9e741c8dc1fea7ee6966a42c5030726"

 

READONLY:默认情况下,从节点不对外提供读服务,即使收到了读请求,也会重定向到对应的主节点。若要读节点对外提供读服务,可执行readonly。

# redis-cli -p 6382> get k3
(error) MOVED 4576 readonly
OK
 k3
hello"

 

READWRITE: 关闭READONLY选项。

# redis-cli -p  readwrite
OK
6379

 

CLUSTER SETSLOT slot IMPORTING|MIGRATING|STABLE|NODE [node-id]:设置slot的状态。

CLUSTER DELSLOTS slot [slot ...]:

 

 

注意:

1. 是否开启集群模式,从进程名中也可看出。

[root@slowtech conf]# ps -ef | grep redis
root     17497     1  20:18 ?        00:00 redis-server  [cluster]
root     17720     21 ?        17727     17734     17741     17748     18154 15726  29 pts/5    00 grep --color=auto redis

  

原文地址:https://www.cnblogs.com/ivictor

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


文章浏览阅读1.3k次。在 Redis 中,键(Keys)是非常重要的概念,它们代表了存储在数据库中的数据的标识符。对键的有效管理和操作是使用 Redis 数据库的关键一环,它直接影响到数据的存取效率、系统的稳定性和开发的便利性。本文将深入探讨 Redis 中键的管理和操作,包括键的命名规范、常用的键操作命令以及一些最佳实践。我们将详细介绍如何合理命名键、如何使用键的过期和持久化特性、如何批量删除键等技巧,旨在帮助读者更好地理解并灵活运用 Redis 中的键,从而提高数据管理和操作的效率和可靠性。
文章浏览阅读3.3k次,点赞44次,收藏88次。本篇是对单节点的应用,但从中我们也能推断出一些关于集群的应用,不过大多数公司能搞个主从就已经是不错了,所以你能学会这个已经算是很有用了,关于ES,博主前面也讲过一些基础应用,创建一个工具类利用ES的数据模型进行存储就可以达到一个canal同时对Redis和ES的同步,如果担心出问题,可以把Canal搞成集群的形式,这个后续有时间博主再给大家做讲解。今天就到这里了,觉得不错就支持一下吧。_canal redis
文章浏览阅读8.4k次,点赞8次,收藏18次。Spring Boot 整合Redis实现消息队列,RedisMessageListenerContainer的使用,Pub/Sub模式的优缺点_springboot redis 消息队列
文章浏览阅读978次,点赞25次,收藏21次。在Centos上安装Redis5.0保姆级教程!_centos7 安装redis5.0服务器
文章浏览阅读1.2k次,点赞21次,收藏22次。Docker-Compose部署Redis(v7.2)主从模式首先需要有一个redis主从集群,才能接着做redis哨兵模式。_warning: sentinel was not able to save the new configuration on disk!!!: dev
文章浏览阅读2.2k次,点赞59次,收藏38次。合理的JedisPool资源池参数设置能为业务使用Redis保驾护航,本文将对JedisPool的使用、资源池的参数进行详细说明,最后给出“最合理”配置。_jedispool资源池优化
文章浏览阅读1.9k次。批量删除指定前缀的Key有两中方法,一种是借助 redis-cli,另一种是通过 SCAN命令来遍历所有匹配前缀的 key,并使用 DEL命令逐个删除它们。_redis删除前缀的key
文章浏览阅读890次,点赞18次,收藏20次。1. Redis时一个key-cakye的数据库,key一般是String类型,不过value类型有很多。eg.String Hash List Set SortedSet (基本) | GEO BitMap HyperLog (特殊)2.Redis为了方便学习,将操作不同类型的命令做了分组,在官网可以进行查询。
文章浏览阅读1.1k次,点赞19次,收藏26次。若不使用Redisson,而是用synchronized(this),此时会造成对服务器的加锁,若开始大量查询ID为1的商品,每台机器都会先跑一遍加个锁,然后在查询ID为2的数据,此时需要等待ID为1的锁释放,所以需要将this对象调整为全局商品ID。若在执行bgsave命令时,还有其他redis命令被执行(主线程数据修改),此时会对数据做个副本,然后bgsave命令执行这个副本数据写入rdb文件,此时主线程还可以继续修改数据。在当前redis目录下会生成aof文件,对redis修改数据的命令进行备份。
文章浏览阅读1.5k次,点赞39次,收藏24次。本文全面剖析Redis集群在分布式环境下的数据一致性问题,从基础原理到高级特性,涵盖主从复制、哨兵模式、持久化策略等关键点,同时也分享了关于监控、故障模拟与自适应写一致性策略的实践经验。_redis集群一致性
文章浏览阅读1k次。RDB因为是二进制文件,在保存的时候体积也是比较小的,它恢复的比较快,但是它有可能会丢数据,我们通常在项目中也会使用AOF来恢复数据,虽然AOF恢复的速度慢一些,但是它丢数据的风险要小很多,在AOF文件中可以设置刷盘策略,我们当时设置的就是每秒批量写入一次命令。AOF的含义是追加文件,当redis操作写命令的时候,都会存储这个文件中,当redis实例宕机恢复数据的时候,会从这个文件中再次执行一遍命令来恢复数据。:在Redis中提供了两种数据持久化的方式:1、RDB 2、AOF。
文章浏览阅读1k次,点赞24次,收藏21次。NoSQL(No only SQL)数据库,泛指非关系型数据库,实现对于传统数据库而言的。NoSQL 不依赖业务逻辑方式进行存储,而以简单的 key-value 模式存储。因此大大增加了数据库的扩展能力。不遵循SQL标准不支持ACID远超于SQL的性能Redis是当前比较热门的NOSQL系统之一,它是一个开源的使用ANSI c语言编写的key-value存储系统(区别于MySQL的二维表格的形式存储。
文章浏览阅读988次,点赞17次,收藏19次。在上面的步骤中,我们已经开启了 MySQL 的远程访问功能,但是,如果使用 MySQL 管理工具 navicat 连接 MySQL 服务端时,还是可能会出现连接失败的情况。在实际工作中,如果我们需要从其他地方访问和管理 MySQL 数据库,就需要开启 MySQL 的远程访问功能并设置相应的权限。这对于我们的工作效率和数据安全都有很大的帮助。通过查看 MySQL 用户表,我们可以看到’host’为’%’,说明 root 用户登录 MySQL 的时候,可以允许任意的 IP 地址访问 MySQL 服务端。
文章浏览阅读956次。Redis Desktop Manager(RDM)是一款用于管理和操作Redis数据库的图形化界面工具。提供了简单易用的界面,使用户能够方便地执行各种Redis数据库操作,并且支持多个Redis服务器的连接_redisdesktopmanager安装包
文章浏览阅读1.9k次,点赞52次,收藏27次。缓存击穿指的是数据库有数据,缓存本应该也有数据,但是缓存过期了,Redis 这层流量防护屏障被击穿了,请求直奔数据库。缓存穿透指的是数据库本就没有这个数据,请求直奔数据库,缓存系统形同虚设。缓存雪崩指的是大量的热点数据无法在 Redis 缓存中处理(大面积热点数据缓存失效、Redis 宕机),流量全部打到数据库,导致数据库极大压力。
文章浏览阅读1.2k次。一次命令时间(borrow|return resource + Jedis执行命令(含网络) )的平均耗时约为1ms,一个连接的QPS大约是1000,业务期望的QPS是50000,那么理论上需要的资源池大小是50000 / 1000 = 50个,实际maxTotal可以根据理论值合理进行微调。JedisPool默认的maxTotal=8,下面的代码从JedisPool中借了8次Jedis,但是没有归还,当第9次(jedisPool.getResource().ping())3、发生异常可能的情况。_redis.clients.jedis.exceptions.jedisconnectionexception: could not get a res
文章浏览阅读1k次,点赞27次,收藏18次。在这篇文章中,你将了解到如何在 CentOS 系统上安装 Redis 服务,并且掌握通过自定义域名来访问 Redis 服务的技巧。通过使用自定义域名,你可以方便地管理和访问你的 Redis 数据库,提高工作效率。无论你是开发者、系统管理员还是对 Redis 感兴趣的读者,这篇文章都会为你提供清晰的指导和实用的技巧。阅读本文,轻松搭建自己的 Redis 服务,并体验自定义域名带来的便捷!_redis怎么自定义域名
文章浏览阅读1.1k次,点赞15次,收藏18次。我们post请求,拦截器要预先读取HtppServletRequest里面的body的数据,是通过io的方式,都知道io读取完毕之后,之前的数据是变为null的,但是,当我么后面的接口来委派的时候,也是通过io读取body。我们要考虑一个事情,就是我们要验证数据的重复提交: 首先第一次提交的数据肯定是要被存储的,当而第二次往后,每次提交数据都会与之前的数据产生比对从而验证数据重复提交,我们要具体判断数据是否重复提交的子类。发现数据是成功存入的,剩余7s过期,在10s之内,也就是数据没过期之前,在发送一次。_json.parseobject(str, clazz, auto_type_filter);
文章浏览阅读3.9k次,点赞3次,收藏7次。PHP使用Redis实战实录系列:我们首先检查$redis->connect()方法的返回值来确定是否成功连接到Redis服务器。如果连接失败,我们可以输出相应的错误信息。如果连接成功,我们再执行一些操作,如$redis->set()、$redis->get()等,并检查每个操作的返回结果来判断是否发生了异常。_php redis
文章浏览阅读1.5w次,点赞23次,收藏51次。Redis(Remote Dictionary Server ),即远程字典服务,是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。Redis 是一个高性能的key-value数据库。redis的出现,很大程度补偿了memcached这类key/value存储的不足,在部 分场合可以对关系数据库起到很好的补充作用。_redisdesktopmanager下载