Redis08-集群

发表于 2020-07-26 | 分类于 Redis | 阅读次数:

集群

数据分布

数据分布理论

分布式数据库首先要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集化分到多个节点上，每个节点负责整体数据的一个子集

常见的数据分区规则有哈希分区和顺序分区两种

哈希分区：离散度好，数据分布业务无关，无法顺序访问，代表产品：Redis Cluster
顺序分区：离散度易倾斜，数据分布业务相关，可顺序访问，代表产品：HBase

下面是常见的几种哈希分区

节点取余分区

使用特定的数据，如Redis的键或用户ID，再根据节点数量N使用公式：hash(key)%N计算出哈希值，用来决定数据映射到哪一个节点上。这种方案存在一个问题：当节点数量变化时，如扩容或者收缩节点，数据节点映射关系需要重新计算，会导致数据的重新迁移。扩容时通常翻倍扩容（这样可以只迁移约50%的数据），避免数据映射全部被打乱导致全量迁移的情况

一致性哈希分区

可查看参考文章：https://zhuanlan.zhihu.com/p/78285304

一致性哈希分区（Distributed Hash Table）实现思路是为系统每个节点分配一个token，范围一般在0 ~ 2^32，这些token构成一个哈希环。数据读写执行节点查找操作时，先根据key计算hash值（取余是对2^32取余），然后顺时针找到第一个大于等于该哈希值的token节点，如下图所示

一致性哈希环增加节点和删除节点只会影响哈希环中相邻的节点，对其他节点无影响，但它存在如下问题：

加减节点导致部分数据无法命中，需要手动处理或忽略这部分数据，因此一致性哈希常用于缓存
当使用少量节点时，节点变化将大范围影响哈希环中数据映射，因此这种方式不适合少量数据节点的分布式方案（通过虚拟槽分区解决）

虚拟槽分区利用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合中，这个整数定义为槽。这个整数集合的范围一般远大于节点数，比如Redis Cluster槽范围是0 ~ 16383。槽是集群内数据管理和迁移的基本单位。采用大范围槽是为了方便数据拆分和集群扩展。每个节点会负责一定数量的槽，如下图所示

Redis数据分区

Redis Cluster采用虚拟槽分区，所有的键根据哈希函数映射到0 ~ 16383整数槽内，计算公式：slot=CRC16(key)&16383。每一个节点负责维护一部分槽以及槽所映射的键值数据

Redis虚拟槽分区特点：

解耦了数据和节点之间的关系，简化了节点扩容和收缩难度
节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据
支持节点，槽，键之间的映射查询，用于数据路由，在线伸缩等场景

集群功能限制

Redis集群相对单机在功能上存在一些限制：

key批量操作支持有限。如mset，mget，目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于执行mset，mget等操作可能存在于多个节点因此不被支持
key事务操作支持有限。同理只支持多key在同一个节点上的事务操作
key作为数据分区的最小粒度。因此不能将一个大的键值对象如hash，list等映射到不同的节点
不支持多数据库空间。集群模式下只能使用一个数据库空间，即db 0
复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构

搭建集群

三个步骤：准备节点，节点握手，分配槽

准备节点

通过脚本设置集群挂载目录，并启动容器

# 删除网络
docker network rm redis-cluster-net
# 创建docker redis集群网络
docker network create redis-cluster-net
# 获取其网关Gateway，这个网关写在下面的gateway变量
# docker network inspect redis-cluster-net | grep Gateway

# 主目录
dir_redis_cluster='/root/redis-conf/cluster/'
# docker redis集群网关
gateway=$(docker network inspect redis-cluster-net | grep -Po 'Gateway[" :]+\K[^"]+')
# 节点地址号 从2开始
idx=1

# 逐个创建各节点目录和配置文件
for port in `seq 6379 6384`; do
    rm -rf ${dir_redis_cluster}/${port}
    # 创建存放redis数据路径
    mkdir -p ${dir_redis_cluster}/${port}/data;
    # 通过模板个性化各个节点的配置文件
    idx=$(($idx+1));
    port=${port} ip=`echo ${gateway} | sed "s/1$/$idx/g"` \
        envsubst < ${dir_redis_cluster}/redis-cluster.tmpl \
        > ${dir_redis_cluster}/${port}/redis-${port}.conf
done

# 启动Redis容器
for port in `seq 6379 6384`; do
    docker stop redis-${port}
    docker rm redis-${port}
    docker run --name redis-${port} --net redis-cluster-net -d --privileged=true \
        -p ${port}:${port} -p 1${port}:1${port} \
        -v ${dir_redis_cluster}/${port}/data:/data \
        -v ${dir_redis_cluster}/${port}/redis-${port}.conf:/usr/local/etc/redis/redis.conf redis:5.0.2 \
        redis-server /usr/local/etc/redis/redis.conf
done

配置文件模板 redis-cluster.tmpl：

# 基本配置
## 开放端口
port ${port}
## 不作为守护进程
daemonize no
## 启用aof持久化模式
appendonly yes

# 集群配置
## 开启集群配置
cluster-enabled yes
## 存放集群节点的配置文件 系统自动建立
cluster-config-file nodes-${port}.conf
## 节点连接超时时间
cluster-node-timeout 50000  
## 实际为各节点网卡分配ip
cluster-announce-ip ${ip}
## 节点映射端口
cluster-announce-port ${port}
## 节点总线端口
cluster-announce-bus-port 1${port}
cluster-slave-validity-factor 10
cluster-migration-barrier 1
cluster-require-full-coverage yes

启动后，可以在容器的 /data 下执行 cat nodes-{port} 查看集群配置，也可以在 redis-cli 中通过 cluster nodes 查看（目前只能查看自己，因为节点还没有进行握手）

redis-cli –cluster命令自动创建集群

在Redis 5.0中已经不再支持redis-trib.rb，而是使用redis-cli来创建集群，使用该命令可以管理集群，创建主从节点，自动分配槽等

1
2
3

docker exec -it redis-6379 redis-cli --cluster create 172.18.0.2:6379 172.18.0.3:6380 172.18.0.4:6381 172.18.0.5:6382 172.18.0.6:6383 172.18.0.7:6384 --cluster-replicas 1
# --cluster-replicas是从节点个数
# redis-cli --cluster help 可以查看其他命令

手动创建集群

节点握手

节点握手指一批运行在集群模式下的节点通过Gossip协议彼此通信，达到感知对方的过程，由客户端发起命令 cluster meet {ip} {port}

cluster meet 172.18.0.3 6380
cluster meet 172.18.0.4 6381
cluster meet 172.18.0.5 6382
cluster meet 172.18.0.6 6383
cluster meet 172.18.0.7 6384

节点握手 meet 是一个异步命令，执行后会立刻返回，过程如下：

6379节点本地创建6380节点信息对象，发送meet消息
6380节点接受到meet消息，保存6379对象信息并回复pong消息
之后6379和6380定期发送ping/pong进行正常的节点通信

这里的meet/ping/pong都是Gossip协议通信的载体

我们只需要在集群内任意节点上执行 cluster meet 命令加入新节点，握手状态通过消息在集群内传播，这样其他节点会自动发现新节点并发起握手流程，最后执行 cluster nodes 命令确认6个节点都彼此感知并组成集群

节点握手后集群还不能正常工作，此时集群处于下线状态（ cluster info 命令查看），需要分配所有16384个槽集群才进入在线状态

分配槽

# 将16384个槽分配到3个主节点去, 每个节点平均分的5461个槽
# 6379 0~5460
docker exec -it redis-6379 redis-cli -p 6379 cluster addslots {0..5460}
# 6380 5461~10920
docker exec -it redis-6380 redis-cli -p 6380 cluster addslots {5461..10920}
# 6381 10920~16383
docker exec -it redis-6381 redis-cli -p 6381 cluster addslots {10921..16383}

作为一个完整的集群，每个负责处理槽的节点应该都具有从节点，保证它出现故障时可以自动完成故障转移。集群模式下，Redis节点角色分为主节点和从节点。首次启动的节点和被分配槽的节点都是主节点，从节点负责复制主节点槽信息和相关的数据。使用 cluster replicate {nodeId} 让一个主节点称为从节点，命令在从节点执行，nodeId是主节点ID，通过 cluster nodes 获取节点ID信息

# cluster nodes获取节点ID信息
# 设置6382节点为6379节点的从节点
docker exec -it redis-6382 redis-cli -p 6382 cluster replicate 8b5af8174dcfe7704942573510cccef75e90419b
# 设置6383节点为6380节点的从节点
docker exec -it redis-6383 redis-cli -p 6383 cluster replicate 1a36ebef09a2ec389de47c35e279804a7f8d9a51
# 设置6384节点为6381节点的从节点
docker exec -it redis-6384 redis-cli -p 6384 cluster replicate 7f1ff266ab807b2450e16437d7ab5f3fb33576d2

此时通过 cluster nodes 可以查看集群的具体信息，包括主从节点的信息

节点通信

分布式存储中需要提供维护节点元数据信息的机制，元数据指：节点负责哪些数据，是否出现故障等状态信息。

常见的元数据维护方式：集中式和P2P方式。Redis集群使用P2P的Gossip（流言）协议，Gossip协议工作原理就是节点彼此不断通信交换信息，一段时间后所有的节点都会知道集群的完整的信息，流程如下：

集群中每个节点都会单独开辟一个TCP通道，用于节点之间彼此通信，通信端口号在基础端口上加10000，（因此Docker端口映射需要对通信端口号也做映射）
每个节点在固定周期内通过特定规则选择几个节点发送ping消息
接收到ping消息的节点用pong消息作为响应

不断的ping/pong消息在一段时间后能让整个集群知道全部节点的最新状态，包括节点故障，新节点加入，主从角色变化，槽信息变更等事件的发生

Gossip消息

常见的Gossip消息有ping，pong，meet和fail。

meet消息：用于通知新节点加入。消息发送者通知接收者加入到当前集群，meet消息通信正常完成后，接收节点会加入到集群中并进行周期性的ping，pong消息交换
ping消息：集群内交换最频繁的消息，集群内每个节点每秒向多个其他节点发送ping消息，用于检测节点是否在线和交换彼此状态信息。ping消息发送封装了自身节点和部分其他节点的状态数据
pong消息：当接收到ping，meet消息时，作为响应消息回复给发送方确认消息正常通信。pong消息内部封装了自身状态数据。节点也可以向集群内广播自身的pong消息来通知整个集群自身状态的更新
fail消息：当节点判定集群内另一个节点下线后，会向集群内广播一个fail消息，其他节点接收到fail消息后把对应节点更新为下线状态

节点选择

可以根据带宽资源修改 cluster_node_timeout 参数来对系统负载进行调整

集群伸缩

这里时间原因我偷懒了，以后有这方面的需求，再来补充相关知识

使用 redis-cli --cluster help 命令查看 redis-cli --cluster 支持的命令（Redis 5.0之后）

Redis的集群伸缩可以抽象为槽和对应数据在不同节点之间灵活移动

扩容集群

三步：1.准备新节点；2.加入集群；3.迁移槽和数据

准备新节点略
加入集群
- 手动：cluster meet ip port ，节点加入后还没有分配槽，后续可以为其迁移槽和数据实现扩容或者作为从节点使用
- 自动：redis-cli --cluster add-node new_host:new_port existing_host:existing_port {--cluster-slave} {--cluster-master-id <arg>} ，后面参数是作为从节点并指定其主节点ID
迁移槽：如果上一步是手动迁移，则这一步需要配置，《Redis开发与运维》 P295-301

收缩集群

如果存在负责的槽，首先迁移槽，当下线节点不再负责槽或者本身是从节点，就可以通知集群内其他节点忘记下线节点，当所有节点忘记该节点后它就可以正常关闭

请求路由

请求重定向

集群模式下，Redis接收任何键相关命令时会首先计算键对应的槽，再根据槽找出所对应的节点，如果节点是自身，则处理键命令；否则回复MOVED重定向错误，通知客户端请求正确的节点。这个过程称为MOVED重定向

运行客户端时，使用 redis-cli -c 参数可以在执行命令时自动重定向到指定节点执行

[email protected]:/data# redis-cli
127.0.0.1:6379> set a aha
(error) MOVED 15495 172.18.0.4:6381
127.0.0.1:6379> exit
[email protected]:/data# redis-cli -c
127.0.0.1:6379> set a aha
-> Redirected to slot [15495] located at 172.18.0.4:6381
OK

cluster keyslot key ：获取key的slot值

节点判断键命令是执行还是MOVED重定向，借助槽和节点映射的数组实现。根据MOVED重定向机制，客户端可以随机连接集群内任一Redis获取键所在节点，这种客户端叫Dummy（傀儡）客户端。这种实现代码简单，对客户端协议影响小，只需要根据重定向信息再次发送请求即可。弊端就是每次执行键命令前要到Redis上进行重定向才能找到要执行命令的节点，额外增加了IO开销

Smart客户端

Smart客户端通过内部维护 slot -> node 的映射关系，本地就可以实现键到节点的查找，从而保证IO效率最大化，MOVED重定向用于负责协助Smart客户端更新 slot -> node 的映射关系

客户端的选择查看 https://redis.io/clients

JedisCluster

JedisCluster是Java的Redis Cluster Smart客户端，其过程，实现原理暂时略过（有需要再补充，看书或者源码）

故障转移

故障发现

集群通过ping/pong消息实现节点通信，通信内容包括主从状态，节点故障等。与Redis Sentinel一样，节点故障也分为主观下线和客观下线

主观下线：

客观下线：

每次ping/pong消息的消息体都会携带1/10的其他节点状态数据，包括故障节点的数据。当半数以上持有槽的主节点都标记某个节点是主管下线时，触发客观下线流程。每个节点接受到其他节点下线状态（pfail状态），都会触发客观下线，计算有效下线报告数量，如果大于槽节点总数的一半，就更新为客观下线，并向集群广播下线节点的fail消息

故障恢复

故障节点变为客观下线后，如果下线节点是持有槽的主节点则需要在它的从节点选出一个替换它，流程：

资格检查：每个从节点检查最后与主节点断线时间，如果从节点与主节点断线时间超过 cluster-node-time * cluster-slave-validity-factor ，则当前从节点不具备故障转移资格。参数 cluster-slave-validity-factor 用于从节点的有效因子，默认为10
准备选举时间：采用延迟触发机制，复制偏移量越大，说明从节点延迟越低，应该选择延迟低的从节点提前触发选举流程，每个从节点获取自己的复制偏移量，然后与其他从节点复制偏移量比较，进行排名，排名最前的优先发起选举（同样会延迟，时间为 failover_auth_time）
发起选举：当从节点定时任务检测到到达故障选举时间 failover_auth_time 后，发起选举流程如下：
1. 更新配置纪元（只增不减，当前主节点的版本，所有主节点配置纪元都不相等，从节点会复制主节点配置纪元，整个集群维护一个全局的配置纪元记录集群内所有主节点配置纪元的最大版本）
2. 广播选举消息 FAILOVER_AUTH_REQUEST
选举投票：只有持有槽的主节点才会处理故障选举消息 FAILOVER_AUTH_REQUEST，每个持有槽的节点在一个配置纪元内都有唯一一张选票，当接到第一个请求投票的从节点消息时回复 FAILOVER_AUTH_ACK 消息作为投票，之后相同配置纪元内其他从节点的选举消息将忽略
- 在开始投票之后的 cluster-node-timeout * 2 时间内没有获取足够的投票（N/2+1），则本次选举作废。从节点对配置纪元自增并发起下一轮投票直到成功
替换主节点：
1. 当前从节点取消复制变为主节点
2. 执行 clusterDelSlot 操作撤销故障主节点负责的槽， clusterAddSlot 把这些槽委派给自己
3. 向集群广播自己的pong消息，通知集群内所有的节点当前从节点变为主节点并接管了故障主节点的槽信息

集群运维

保证集群完整性：分配完16384个槽
带宽消耗：集群Gossip消息通信本身会消耗带宽，官方建议集群最大规模在1000以内
Pub/Sub广播问题：频繁应用广播功能时避免在大量节点的集群内使用，否则严重消耗集群内网络带宽，建议使用Sentinel结构
集群倾斜：注意节点槽分配平均，不同槽对应键数量分布问题，集合对象包含大量元素，内存相关配置不一致等问题
集群读写分离：集群模式下从节点不接受任何读写请求，只负责复制主节点做主节点的备份，发送过来的键命令会重定向到负责槽的主节点。当需要使用从节点分担主节点读压力时，使用 readonly 命令打开客户端连接只读状态， slave-read-only 配置在集群下是无效的， readonly 是连接级别生效的，每次新建连接都要执行开启。 readwrite 命令关闭连接只读状态
- 数据迁移：单机Redis数据想要迁移到集群环境，Redis 5.0 cluster命令提供 import host:port --cluster-from <arg> --cluster-copy --cluster-replace 命令进行迁移

问题与总结

redis通信出错，执行 meet 显示 disconnected

解决方案1：创建容器时使用 --net=host 使用host网络

--net=host 告诉Docker不要将容器网络放到隔离的命名空间中，即不要容器化容器内的网络。此时容器使用本地主机的网络，它拥有完全的本地主机接口访问权限。容器进程可以跟主机其它 root 进程一样可以打开低范围的端口，可以访问本地网络服务比如 D-bus，还可以让容器做一些影响整个主机系统的事情，比如重启主机。因此使用这个选项的时候要非常小心。如果进一步的使用 --privileged=true，容器会被允许直接配置主机的网络堆栈。

解决方案2：使用bridge桥接网络，为redis.conf添加 cluster-announce-ip/port/bus-port 等参数

创建集群网络 docker network create redis-cluster-net ，通过 docker network inspect redis-cluster-net | grep Gateway 查找到网关ip 递增修改cluster-announce-ip参数 –redis-cluster-net 是自己创建的bridge网络模式 docker network create redis-cluster-net

Redis09-缓存设计

发表于 2020-07-26 | 分类于 Redis | 阅读次数:

缓存设计

缓存的收益和成本

Redis07-哨兵

发表于 2020-07-14 | 分类于 Redis | 阅读次数:

哨兵

Redis主从复制下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时需要通知应用方更新主节点地址，这种应用场景这种故障处理方式一般是难以接受的。Redis 2.8开始提供了Redis Sentinel架构来解决这个问题

Redis Sentinel的高可用性

当主节点出现故障时，Redis Sentinel能自动完成故障发现和故障转移，并通知应用方，从而实现高可用

Redis Sentinel与Redis主从复制模式只多了若干个Sentinel节点，所以Redis Sentinel没有针对Redis节点做特殊处理

整个故障转移有如下4个步骤：

主节点出现故障，此时从节点与主节点失去连接，主从复制失败
多个Sentinel节点对主节点的故障达成一致，选举出某个Sentinel节点作为领导者负责故障转移
如下图，Sentinel领导者执行了故障转移，它选出 slave-1 来作为新master节点，然后让其它从节点 slaveof slave-1(new-master)，然后通知客户端之后，待原主节点恢复正常后，让原主节点 slaveof slave-1 即可，整个过程都是自动化完成

新的拓扑结构图如下

Redis Sentinel具有以下几个功能：

监控：Sentinel节点会定期检测Redis数据节点，其余Sentinel节点是否可达
通知：将故障转移的结果通知给应用方
主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系
配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息

Sentinel节点本身是独立的Redis节点，只是它不存储数据，只支持部分命令

Docker安装和部署

Sentinel中Redis数据节点没有任何特殊配置，略（需要注意从节点添加 slaveof 配置即可）

在Docker中部署一个Redis主节点，一个Redis从节点和一个Redis Sentinel：

（Redis 5.0后把slave改名为replica，两者其实是一个东西）

部署主节点

配置主节点：（主节点配置文件设置 protected-mode no允许外部客户端接入，配置密码requirepass，配置开启AOF，注释bind参数，或添加需要bind的IP地址，设置logfile）

port 6379
daemonize no
logfile "master-log.log"
protected-mode no
# bind 127.0.0.1
appendonly yes
requirepass asd123

启动主节点：

docker run -p 6379:6379 \
--name redis-master \
-v /root/redis-conf/redis-master/redis-master.conf:/usr/local/etc/redis/redis-master.conf \
-v /root/redis-conf/data/master-data:/data \
--privileged=true \
--restart=always \
-itd redis:5.0.2 redis-server /usr/local/etc/redis/redis-master.conf

# --privileged=true用于centOS 7，安全Selinux禁止了一些安全权限
# -p 端口映射 --name 指定容器名称
# -v /root/redis-conf/redis-master.conf:/usr/local/etc/redis/redis-master.conf 配置文件映射
# -v /root/data:/data 持久化文件映射和日志文件映射
# redis-server /usr/local/etc/redis/redis-master.conf 以容器内部的配置文件启动Redis

在主节点客户端输入 role 可以查看主从实例所属的角色，如果是主节点，会返回其所有从节点的信息

主节点输入 info replication 可以查看相关信息

部署从节点

部署从节点，可以写 slaveof，在5.0后也可以写成 replicaof （5.0之后的版本同样支持 slaveof）

配置从节点：开启 replicaof，注释bind，设置 masterauth，设置 requirepass，修改端口，设置 protected-mode，

port 6380
# 配置两个从节点端口，6380，6381
# bind 127.0.0.1
logfile "slave-log.log" # 多个从节点修改这个名称，避免覆盖，或者启动中指定
replicaof 192.168.186.128 6379 # 你的主机地址，在docker中不能为127.0.0.1
masterauth asd123
requirepass asd123

启动从节点：

docker run -p 6380:6380 \
--name redis-slave-01 \
-v /root/redis-conf/redis6380/redis-slave.conf:/usr/local/etc/redis/redis-slave.conf \
-v /root/redis-conf/data/6380:/data \
--privileged=true \
--restart=always \
-itd redis:5.0.2 redis-server /usr/local/etc/redis/redis-slave.conf

docker run -p 6381:6381 \
--name redis-slave-02 \
-v /root/redis-conf/redis6381/redis-slave.conf:/usr/local/etc/redis/redis-slave.conf \
-v /root/redis-conf/data/6381:/data \
--privileged=true \
--restart=always \
-itd redis:5.0.2 redis-server /usr/local/etc/redis/redis-slave.conf

# --privileged=true用于centOS 7，安全Selinux禁止了一些安全权限
# -p 端口映射 --name 指定容器名称
# -v /root/redis-conf/redis6381/redis-slave.conf:/usr/local/etc/redis/redis-slave.conf 配置文件映射
# -v /root/redis-conf/data/6381:/data 持久化文件映射
# redis-server /usr/local/etc/redis/redis-master.conf 以容器内部的配置文件启动Redis

如果需要启动多个从节点，修改 -p new-port:6379 和 --name new-slave-name 启动即可

如果需要部署多个从节点，需要把data文件夹和conf文件分开放置

从节点输入 info replication 或 role 可以查看相关信息

部署Sentinel节点

# Sentinel有自己专属的配置文件
port 26379
# 配置三个不同端口，26379.26380,26381
logfile "sentinel-log.log"
dir /data
sentinel monitor mymaster 192.168.186.128 6379 1
# 1代表主节点失败至少需要1个Sentinel节点同意，mymaster是主节点别名
sentinel auth-pass mymaster asd123
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

启动Sentinel节点：

docker run --name redis-sentinel-01 \
-p 26379:26379 \
-v /root/redis-conf/redis26379/redis-sentinel.conf:/usr/local/etc/redis/redis-sentinel.conf \
-v /root/redis-conf/data/26379:/data \
--privileged=true \
-itd redis:5.0.2 redis-sentinel /usr/local/etc/redis/redis-sentinel.conf

docker run --name redis-sentinel-02 \
-p 26380:26380 \
-v /root/redis-conf/redis26380/redis-sentinel.conf:/usr/local/etc/redis/redis-sentinel.conf \
-v /root/redis-conf/data/26380:/data \
--privileged=true \
-itd redis:5.0.2 redis-sentinel /usr/local/etc/redis/redis-sentinel.conf

docker run --name redis-sentinel-03 \
-p 26381:26381 \
-v /root/redis-conf/redis26381/redis-sentinel.conf:/usr/local/etc/redis/redis-sentinel.conf \
-v /root/redis-conf/data/26381:/data \
--privileged=true \
-itd redis:5.0.2 redis-sentinel /usr/local/etc/redis/redis-sentinel.conf

如果需要部署多个Sentinel文件夹，需要把data文件夹和conf文件分开放置

info sentinel 可以查看哨兵的信息

问题：部署在同一个物理机上，哨兵之间不能互相检测，目前还没找到原因所在（2020-07-09）

（哨兵不应该部署在同一个物理机上，这样不算是真正的高可用）

在所有节点启动后，Sentinel节点配置文件会发生变化，会去掉一些默认配置，添加了一些从节点，Sentinel节点的配置信息

测试

docker stop redis-master 关闭主节点，此时会发现某个从节点变成了 master，再次启动原来的主节点，查看会发现它变成了 slave 节点

配置讲解

sentinel monitor <master-name> <ip> <port> <quorum> ：监控目标主节点，quorum代表Sentinel节点集群要判断主节点最终不可达所需要的票数（建议值为Sentinel节点数除以2再加1），同时它也与Sentinel节点的领导者选举有关系
sentinel down-after-milliseconds <master-name> <times> ：单位毫秒，每个Sentinel节点定时发送ping命令判断数据节点和其余Sentinel节点是否可达，如果回复超过该时间，则判断不可达
sentinel parallel-syncs <master-name> <nums> ：当Sentinel节点集合对主节点故障达成一致时，Sentinel领导者节点会做故障转移操作，选出新的节点，原来的从节点会向新主节点发起复制操作，parallel-syncs就是用于限制在一次故障转移后，每次向新主节点发起复制操作的从节点个数
sentinel failover-timeout <master-name> <times> ：故障转移超时时间，故障转移过程（包括从选出合适从节点到等待原主节点恢复后命令它去复制新主节点）超过该时间则判断为超时
sentinel auth-pass <master-name> <password> ：此密码与对应主节点密码一致
sentinel notification-script <master-name> <script-path> ：在故障转移期间，如果出现警告级别的Sentinel事件发生（如-sdown：客观下线，-odown：主观下线），会触发对应路径的脚本，并向脚本发送相应的事件参数，可以利用此参数把错误信息发送到邮件或短信
sentinel client-reconfig-script <master-name> <script-path> ：故障转移结束后，触发对应路径的脚本，并向脚本发送故障转移结果的相关参数（参数为：<master-name> <role> <from-ip> <from-port> <to-ip> <tp-port> 分别为主节点名，Sentinel节点的角色（leader和observer），原主节点地址信息，新主节点地址信息）
Sentinel可以监控多个主节点，配置不同的主节点名称即可
Sentinel节点可以动态配置参数，使用命令 sentinel set <param> <value> ，支持如下参数：

Sentinel 的 set 命令只对当前Sentinel节点有效，会立刻刷新到配置文件（数据节点执行 config rewrite 才会刷新）

API

sentinel masters ：查看所有被监控的主节点状态以及相关的统计信息，可以添加参数主节点名称查看对应主节点的信息
sentinel slaves <master name> ：查看从节点状态的统计信息
sentinel sentinels <master name> ：查看sentinel节点集合（不包含当前）
sentinel get-master-addr-by-name <master name> ：返回指定 <master name> 主节点的IP地址和端口
sentinel reset <pattern> ：当前sentinel节点对符合样式的主节点的配置进行重置，包含清除主节点相关状态（如故障转移），重新发现从节点和Sentinel节点
sentinel failover <master name> ：对指定名称的主节点进行强制故障转移，其他Sentinel节点在转移完成后更新自身配置
sentinel ckquorum <master name> ：检测当前可达Sentinel节点总数是否达到 quorum 的个数
sentinel flushconfig ：将Sentinel节点的配置强制刷到磁盘上
sentinel remove <master name> ：取消当前Sentinel节点对指定主节点的监控
sentinel monitor <master name> <ip> <port> <quorum> ：添加对主节点的监控
sentinel set <master name> ：动态修改Sentinel节点配置选项，略
sentinel is-master-down-by-addr ：Sentinel节点间用来交换对主节点是否下线的判断，根据参数不同还可以作为Sentinel领导者选举的通信方式

实现原理

三个定时监控任务

每10秒每个Sentinel节点会向主节点发送info命令获取最新的拓扑结构
- 向主节点发送info获取从节点的信息
- 当有新的从节点加入时可以立刻感知
- 节点不可达或者故障转移时，通过info命令实时更新节点拓扑信息
每隔2秒，每个Sentinel节点会向Redis数据节点的 __sentinel__:hello 频道发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息。每个Sentinel节点都会订阅该频道，用于了解其他Sentinel节点以及它们对主节点的判断
- 该频道用于发现新的Sentinel节点，以及Sentinel节点之间交换主节点状态，作为后面客观下线以及领导者选举的依据
每隔1秒，每个Sentinel节点向主节点，从节点和其余Sentinel节点发送ping命令做一次心跳检测，来确认这些节点是否可达

主观下线和客观下线

主观下线：第三个定时任务每秒向其余节点发送ping命令，如果这些节点超过 down-after-milliseconds 没有进行回复，Sentinel节点会对该节点做失败判定，这个行为叫做主观下线
客观下线：当Sentinel主观下线的节点是主节点时，该Sentinel节点通过 sentinel is-master-down-by-addr 命令向其他Sentinel节点询问对主节点的判断，当超过 quorum 个数，Sentinel节点认为该主节点确实有问题，会做出客观下线的决定
sentinel is-master-down-by-addr <ip> <port> <current_epoch> <runid> ：current_epoch：当前配置纪元，runid：若为*，则用于Sentinel判定主节点下线，若为当前Sentinel节点的runid，则用于发送给目标Sentinel节点希望其同意自己成为领导者
- 返回结果包含3个参数：
- down_state：目标Sentinel节点对于主节点下线判断，1为下线，0为在线
- leader_runid：当leader_runid等于*，代表返回结果用来做主节点是否不可达，若为具体runid，代表目标节点同意runid成为领导者
- leader_epoch：领导者纪元

领导者Sentinel节点选举

每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观下线的时候，会向其他Sentinel节点发送 sentinel is-master-down-by-addr 命令，请求将自己设置为领导者
收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的请求成为领导者命令，则同意该请求，否则拒绝
如果该Sentinel节点发现自己的票数已经大于等于max(quorum, num(sentinel)/2 + 1)，则它成为领导者
如果此过程没有选出一个领导者，则进入下一次选举

故障转移

在从节点列表选出一个节点作为新的主节点，选择方法：

过滤：主观下线，断线，5秒内没有回复过Sentinel节点ping响应，与主节点失联超过 down-after-milliseconds*10 秒
选择slave-priority最高的从节点列表，存在则返回，不存在则继续
选择复制偏移量最大的从节点（复制得最完整），如果存在则返回，不存在则继续
选择runid最小的从节点

后记

单机部署多个从节点，每个从节点必须使用不同的端口以及端口映射，否则Sentinel节点无法识别，会出现奇怪的错误
Sentinel节点无法启动，查看docker logs日志显示不能打开Sentinel节点log file， Can't open the log file: Permission denied ，则在本地 /root/data/sentinel-data/26379 下新建一个 sentinel-log.log 文件，并修改其权限

Redis06-内存

发表于 2020-07-03 | 分类于 Redis | 阅读次数:

内存

info memory 查看内存情况

自身内存指Redis进程自身内存，对象内存指用户数据，包括键和值的内存，缓冲内存指客户端缓冲，复制积压缓冲区和AOF缓冲区的内存。内存碎片跟操作系统内存分配有关（Redis使用jemalloc）

内存管理

设置内存上限

Redis使用 maxmemory 参数来限制最大可用内存，当超出上限时使用LRU等删除策略释放空间

内存回收策略

删除过期键对象：分为两种情况删除
- 惰性删除：当客户端读取带有超时属性的键时，如果已经超过键设置的过期时间，才执行删除操作兵返回空。这种策略出于节省CPU成本考虑，不需要单独维护TTL链表来处理过期键的删除
- 定时任务删除：默认每秒运行10次（通过配置hz控制），流程如下图，每次随机检查20个键，当发现过期时删除对应键，如果超过检查数25%的键过期，循环执行直到不足25%或运行超时为止，慢模式下超时时间为25毫秒，若超时，则触发内部事件以快模式运行，快模式超时时间1毫秒，且2秒内只能运行一次

当内存超出maxmemory会触发溢出策略，由参数 maxmemory-policy 参数控制，Redis支持6种策略

noeviction：默认策略，不会删除任何数据，拒绝所有写入操作并返回客户端错误信息（OOM），Redis此时只响应读操作
volatile-lru：根据LRU算法删除设置了超时属性（expire）的键，直到腾出足够空间为止，如果没有可删除的键对象，回退到noeviction策略
allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时，直到腾出足够空间
allkeys-random：随机删除所有键，直到腾出足够空间
volatile-random：随机删除过期键，直到腾出足够空间
volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据，如果没有，则回退到noeviction

内存优化

Redis存储的所有值对象在内部定义为redisObject结构体，如下：

共享对象池

Redis内部维护 [0-9999] 的整数对象池，用于节约内存，set foo 100 set bar 100 之后，它们指向整数共享对象池，节省了内存开销

注意，设置了 maxmemory 并启用LRU相关淘汰策略后，Redis会禁止使用共享对象池（lru计时时钟不准确）。ziplist编码的值对象，同样不能使用共享对象池（与内部结构有关）

字符串优化

Redis内部字符串结构如下图所示

O(1)时间复杂度的获取，可用于保存字节数组，内部实现预分配机制（需要注意预分配带来的内存浪费，在append数据追加时关注内存情况），惰性删除机制（字符串缩减后空间不释放，作为预分配空间保留）

编码优化

底层编码在第一章有说明，内部编码转换只能由小内存编码向大内存编码转换，不可逆（因为大内存向小内存转换消耗CPU，得不偿失）

ziplist

zlbytes记录整个压缩列表长度（int-32类型）
zltail记录距离尾节点的偏移量（int-32类型）
zllen：记录压缩链表节点数量（int-16）
prev_entry_bytes_length：记录前一个节点所占空间
encoding：标示当前节点编码和长度，前两位表示编码类型：字符串/整数，其余位表示数据长度
zlend：记录列表结尾，1字节长

intset

intset对写入的整数进行排序，O(log(n))时间复杂度实现查找和去重，encoding表示整数类型，有3种：int-16，int-32和int-64

控制键数量

Redis存储大量键的时候，可以考虑使用hash结构降低键数量，注意只能使用ziplist底层结构的hash类型来实现内存的节省

Redis05-复制

发表于 2020-07-02 | 分类于 Redis | 阅读次数:

复制

在分布式系统中为了解决单点问题，通常会把数据复制多个副本部署到其他机器，满足故障恢复和负载均衡等需求，Redis也提供了复制功能，实现了相同数据的多个Redis副本

配置

建立复制

参与复制的Redis实例分为主节点（master）和从节点（slave）。默认情况下，Redis都是主节点，每个从节点只能有一个主节点，而主节点可以同时具有多个从节点，复制的数据流是单向的，只能由主节点复制到从节点

配置复制的方式有以下三种：

在配置文件中加入slaveof {masterHost} {masterPort}随Redis启动生效
在redis-server启动命令中加入–slaveof {masterHost} {masterPort}生效
直接使用命令：slaveof {masterHost} {masterPort}生效

使用 info replication 查看复制相关状态

断开复制

在从节点执行 slaveof no one 来断开与主节点复制关系，断开不会抛弃原有数据，只是无法再获取主节点上的数据变化，可以使用 slaveof 来切换主节点，切换新主节点会删除原有主节点的所有数据

安全性

主节点可以通过 requirepass 参数来进行密码验证，所有客户端访问必须使用 auth 命令实行校验，从节点需要配置 masterauth 参数来与主节点密码（requirepass的值）保持一致，这样从节点才可以正确连接到主节点并发起复制操作

只读

默认情况下，从节点使用 slave-read-only=yes 配置为只读模式。由于复制只能主节点到从节点，对于从节点的任何修改主节点都无法感知，修改从节点会造成主从数据不一致。因此建议线上不要修改从节点的只读模式

传输延迟

复制时的网络延迟也是需要考虑到问题，Redis提供了 repl-disable-tcp-nodelay 参数来控制是否关闭TCP_NODELAY，默认为no

当关闭时，主节点产生的命令数据无论大小都会及时发送给从节点，这样主从之间延迟会变小，但会增加网络带宽的消耗。适用于主从之间网络环境良好的场景，如同机架或同机房部署
当开启时，主节点会合并较小的TCP数据包从而节省带宽。默认发送时间间隔取决于Linux内核，一般默认为40毫秒。这种配置节省了带宽但是增大了主从之间的延迟

拓扑

Redis的复制拓扑结构可以支持单层或多层复制关系，分为一主一从结构，一主多从结构和树状主从结构

一主一从结构：用于主节点出现宕机时从节点提供故障转移支持。当应用写命令并发量较高且需要持久化时，可以只在从节点上开启AOF。（需要注意主节点如果没有开启AOF，要脱机的话需要避免自动重启操作，否则从节点因为复制主节点会导致数据也清空，安全的做法是从节点上执行 slave no one 之后再重启主节点
一主多从结构：多个从节点来实现读写分离
树状主从结构：从节点不但可以复制主节点数据，同时可以作为其他从节点的主节点继续向下复制，可以有效降低主节点负载和需要传送给从节点的数据量

原理

复制过程

发送ping命令主要检测主从之间网络套接字是否可用，以及主节点当前是否可接受处理命令

第一次同步数据集时，主节点会把所有的数据发送给从节点，后续主节点会持续把写命令发送给从节点，保持主从数据一致性

数据同步

Redis在2.8版本开始使用psync命令完成主从数据同步，支持全量复制和部分复制，当主从复制过程由于某些原因造成数据丢失，可以使用部分复制把丢失的数据发送给从节点

部分复制有如下3个组件支持：

复制偏移量：主从节点各自维护，从节点每秒上传自身偏移给主节点，通过对比可以判断主从数据的一致， info replication 的 master_repl_offset 查看
复制积压缓冲区（repl-backlog-buffer）：保存在主节点上的一个固定长度的队列，默认是1MB，主节点响应写命令时会把命令发送给从节点和复制积压缓冲区
主节点运行ID： Redis节点运行后动态分配一个40位的16进制字符串作为运行ID， info server 查看当前节点的ID（用ip+port识别主节点不合适，主节点替换RDB/AOF文件重新运行，从节点再基于偏移复制数据是不安全的）

psync

psync {runId} {offset} 从节点发送psync给主节点，runId是主节点的运行ID，没有默认为?，offset是偏移量，第一次复制则为-1

如果回复 +FULLRESYNC {runId} {offset}，从节点触发全量复制
回复 +CONTINUE，从节点触发部分复制
回复 +ERR，主节点版本低于2.8，无法识别psync，从节点发送旧版的sync触发全量复制

全量复制

部分复制

心跳

主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通信，client list 的flags查看。主节点默认每隔10秒发送ping命令，判断从节点的存活性和连接状态，通过参数 repl-ping-slave-period 控制发送频率。从节点主线程每隔1秒发送 replconf ack {offset} 命令，用于实时监测主从节点网络状态，上报自身复制偏移量和保证从节点的数量和延迟性功能。主节点根据 replconf 命令判断从节点超时时间，体现在 info replication 的lag属性，如果超过 repl-timeout （默认60秒），则判断从节点下线并断开连接，如果此后从节点重新恢复，心跳检测会继续进行

异步复制

主节点把写命令发送给从节点的过程是异步完成的，主节点把写命令发送给客户端后就返回了，并不等待从节点复制完成

Redis04-持久化

发表于 2020-07-02 | 分类于 Redis | 阅读次数:

持久化

RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发

save：阻塞当前Redis服务器，直到RDB过程完成，对内存比较大的实例会造成长时间的阻塞，线上环境不建议使用
bgsave：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段

RDB内部存在自动触发RDB的持久化机制

使用save相关配置，如 save m n ，表示m秒内数据集存在n次修改时，自动触发bgsave（配置文件conf中有相关配置，默认有 save 900 1，save 300 10，save 60 10000）
如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
执行debug reload命令重新加载Redis时，也会自动触发save操作
默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave

RDB流程

执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回
父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒
父进程fork后，bgsave返回 Background saving started 信息后不再阻塞父进程，可以响应其他命令
子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项
进程发送信号给父进程表示完成，父进程更新统计信息，具体见 info Persistence 下的rdb_*选项

RDB文件的处理

RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定。可以通过执行 config set dir {newDir} 和 config set dbfilename {newFileName} 运行期动态执行，当下次运行时RDB文件会保存到新目录（win10下目录默认喂我当前目录，文件名默认为dump.rdb，所以配置都可以在conf下修改）

RDB使用LZF算法对生成的RDB文件做压缩处理，可以关闭：config set rdbcompression {yes|no}

RDB优缺点

优点：

RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照，适用于备份，全量复制等场景，比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或文件系统中，用于灾难恢复
Redis加载RDB恢复数据远远快于AOF方式

缺点：

RDB无法做到实时持久化/秒级持久化，bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本大
RDB使用二进制格式保存，版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题

AOF

AOF（append only file）持久化，以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决数据持久化的实时性，目前是Redis持久化的主流方式

使用AOF

config get appendonly：查看当前是否使用AOF

confgi set appendony yes：开启AOF，同样可以在conf配置文件下开启

AOF文件通过 appendfilename 配置，默认为 appendonly.aof，保存路径同RDB，使用 dir 来进行配置

AOF工作流程如下：

所有的写入命令追加到aof_buf（缓冲区）中
AOF缓冲区根据对应的策略向硬盘做同步操作
随着AOF文件的越来越大，需要定期对AOF文件进行重写，达到压缩的目的
当Redis服务器重启时，可以加载AOF文件进行数据恢复

命令写入

AOF命令写入的内容直接是文本协议格式，具体格式参照RESP

使用aof_buf可以避免性能取决于硬盘负载的问题，可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡

文件同步

Redis提供多种AOF缓冲区同步文件策略，由参数 appendfsync 控制，不同值的含义如下：

系统调用write和fsync说明：

write操作会触发延迟写（delayed write）机制，Linux在内核提供页缓冲区来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步操作依赖系统调度机制，如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果系统故障宕机，缓冲区内的数据将丢失
fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化

AOF缓冲区同步文件策略说明：

always：每次写入都要同步AOF文件，一般的SATA硬盘上，Redis只能提供大约几百TPS写入，显然跟Redis高性能特性背道而驰，不建议配置
no：由于操作系统每次同步AOF文件的周期不可控，而且会加大每次同步硬盘的数据量，虽然提高了性能，但数据安全性无法保证
everysec：是建议的同步策略，也是默认配置，理论上只有在系统突然宕机的情况下丢失1秒的数据

重写机制

随着命令不断写入AOF，文件会越来越大，Redis支持AOF重写机制来压缩文件体积以此解决这个问题。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程

重写能压缩文件主要有如下原因：

进程内已经超时的数据不再写入文件
旧的AOF文件含有无效命令，如：del key1，hdel key2，srem keys，set a 111等，重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令
多条写命令可以合并为一个，如：lpush list a，lpush list b，lpush list c可以转化为：lpush list a b c，为了防止单条命令过大造成客户端缓冲区溢出，以64个元素为界拆分写入命令

AOF重写过程可以手动触发和自动触发

手动触发：直接调用 bgrewriteaof 命令

自动触发：根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定自动触发时机，前者表示运行AOF重写时文件的最小体积，默认为64MB，后者代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值

自动触发时机 = aof_current_size > auto-aof-rewrite-min-size && (aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage

执行AOF重写请求，如果当前进程正在执行bgsave，重写命令延迟到bgsave完成之后执行
父进程执行fork创建子进程，开销等同于bgsave
1. 主进程fork完成后，继续响应其他命令，所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性
2. 由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用”AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据
子进程根据内存快照，按照命令合并规则写入到新AOF文件，每次批量写入硬盘的数据量由 aof-rewrite-incremental-fsync 控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞
1. 新AOF文件写入后，子进程发送信号给父进程，父进程更新统计信息，具体见 info persistence 下的 aof_* 相关统计
2. 父进程把AOF重写缓冲区的数据写入到新的AOF文件
3. 使用新AOF文件替换老文件，完成AOF重写

重启加载

如果AOF已经开启，就优先加载AOF文件，AOF关闭时，加载RDB文件，AOF/RDB文件存在错误时，Redis启动失败并打印错误信息

加载AOF文件时，可能由于机器断电等情况导致AOF尾部文件命令写入不全，Redis提供 aof-load-truncated 配置来兼容这种情况，默认开启，加载AOF时，当遇到这类问题会忽略并继续启动，同时打印警告信息

问题定位与优化

Redis持久化是影响Redis性能的高发地，需要对其持久化问题进行分析定位和优化

主要方向是fork消耗，CPU，内存，硬盘的资源监控，AOF追加阻塞，多实例部署的子进程处理问题等，详细有需要再查阅书籍，博客等资料

Redis03-客户端

发表于 2020-06-30 | 分类于 Redis | 阅读次数:

客户端

服务端

服务端需要指定conf启动的话，在命令行指定： redis-server redis.conf 来指定配置文件启动

客户端通信协议

几乎所有主流编程语言都有Redis的客户端，Redis制定了RESP（Redis Serialization Protocol，Redis序列化协议）实现客户端与服务端的正常交互，客户端与服务端的连接建立在TCP之上

Java客户端

Java一般使用Jedis，具体使用略，主要留意如下几点：

区分Jedis直连与连接池，生产环境中应该使用连接池，连接池需要注意对异常进行判断
Jedis.close()在直连是关闭连接，在连接池是归还连接
Jedis客户端没有内置序列化，需要自己选用

客户端管理

client list

client list列出与Redis服务端相连的所有客户端连接信息

id：客户端连接唯一标识，自增
addr：客户端连接的ip和端口
fd：socket的文件描述符，与lsof命令结果的fd是同一个，如果fd=-1代表当前客户端不是外部客户端，而是Redis内部的伪装客户端
name：客户端名称
qbuf：输入缓冲区总容量
qbuf-free：输入缓冲区剩余容量

输入缓冲区模型如下图所示

输入缓冲区没有相应配置规定大小，会根据输入内容动态调整

一旦某个客户端的输入缓冲区超过1G，客户端就会被关闭

输入缓冲区不受maxmemory控制，已超出maxmemory的部分可能会产生数据丢失，键值淘汰，OOM等情况
age：当前客户端已经连接的时间，单位秒
idle：当前客户端最近一次的空闲时间，单位秒
maxclients：最大客户端连接数，通过 config set maxclients 设置，默认10000
timeout：连接的最大空闲时间，单位秒，如果idle超过timeout，连接会被关闭，默认为0，实际开发和运维中，timeout设置大于0，客户端添加空闲检测和验证等
obl：输出缓冲区的固定缓冲区长度
oll：输出缓冲区的动态缓冲区长度
omem：输出缓冲区一共使用的字节数

输出缓冲区的作用是保存命令执行的结果返回给客户端，容量可以通过 client-output-buffer-limit 来进行设置，按照客户端的不同分为三种输出缓冲区：普通客户端，发布订阅客户端，slave客户端

对应配置规则： client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>

<class>：客户端类型，normal：普通客户端，slave：slave客户端，用于复制，pubsub：发布订阅客户端

<hard limit>：如果客户端使用的输出缓冲区大于该值，客户端会被立即关闭

<soft limit> 和 <soft seconds>：如果客户端使用的输出缓冲区超过了soft limit并且持续了soft seconds秒，客户端会被立即关闭

默认配置：

1
2
3

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

输出缓冲区由两部分组成：固定缓冲区（16KB，字节数组）和动态缓冲区（列表），固定缓冲区用于返回比较小的执行结果，动态缓冲区返回比较大的结果，固定缓冲区用满后新的返回结果会存放在动态缓冲区

flag：客户端类型，如下图所示
db：当前客户端使用的数据库索引下标
sub/psub：当前客户端订阅的频道/模式数
multi：当前事务已执行命令个数
events：文件描述符事件（r、w）：r和w分别代表客户端套接字可读和可写
cmd：当前客户端最后一次执行的命令，不包括参数

info clients

它执行速度比client list快，但是不能精准定位到客户端，不能显示所有输入缓冲区的总量，只会显示最大量

connected_clients：已连接的客户端数量
client_longest_output_list：输出缓冲区列表最大对象数
client_biggest_input_buf：最大的输入缓冲区
blocked_clients：正在执行阻塞命令（blpop，brpop，brpoplpush）的客户端个数

info stats

total_connections_received：Redis自启动来处理的客户端连接数总数
rejected_connections：Redis自启动以来拒绝的客户端连接数，需要重点监控

client setName和client getName

用于客户端设置名称

client kill

client kill ip:port 用于沙雕指定IP地址和端口的客户端

client pause

client pause timeout(毫秒) 用于阻塞客户端timeout毫秒数

此命令只对普通和发布订阅客户端有效，对于主从复制是无效的，在此期间主从复制是正常进行，可以用来让主从复制保持一致

monitor

监控Redis正在执行的命令和详细的时间戳，但注意如果Redis并发量过大，monitor客户端的输出缓冲会暴涨，占用大量内存

其他客户端配置

在conf配置文件同样可以配置

timeout：超时时间
maxclients：最大连接数
tcp-keepalive：检测TCP连接活性的周期，默认是0，也就是不检测，建议60，Redis每隔60秒对它创建的TCP连接进行活性检测，防止大量死连接占用系统资源
tcp-backlog：TCP三次握手后将接受的连接放入队列中，tcp-backlog就是队列的大小，默认是511

Redis02-其他数据结构API

发表于 2020-06-29 | 分类于 Redis | 阅读次数:

其他功能数据结构API

慢查询分析

所谓慢查询日志就是系统在命令执行前后计算每条命令的执行时间，当超过预设阈值，就将这条命令的相关信息记录下来（如发生时间，耗时，命令的详细信息）

慢查询分析主要分析的是第三步的时间

Redis提供两个参数：

slowlog-log-slower-than：预设阈值，默认是10000（微妙）
slowlog-max-len：Redis使用一个列表来存储慢查询日志，这个参数就是列表的最大长度。当慢查询日志列表已处于最大长度，最早插入的一条命令会被从列表中移出
使用config set命令来动态修改，使用config rewrite命令来将配置持久化到本地配置文件

获取慢查询日志：

slowlog get [n]：n指定条数，结果有4个属性，分别是：慢查询日志的标识ID，发生时间戳，命令耗时，执行命令和参数

slowlog len：获取慢查询日志当前的长度
slowlog reset：慢查询日志重置

慢查询分析最佳实践

slowlog-max-len配置建议：线上调大慢查询列表，可设置为1000以上（会对长命令截断操作，不会占用大量内存）
slowlog-log-slower-than配置建议：默认超过10毫秒判定为慢查询，需要根据Redis并发量调整该值，对于高OPS场景Redis建议设置为1毫秒
慢查询仅仅记录命令执行时间，而不包括命令排队时间（单线程）和网络传输时间，因为命令执行排队机制，慢查询会导致其他命令级联阻塞，当客户端出现请求超时，需要检查该时间点是否有对应的慢查询，从而分析出是否为慢查询导致的命令级联阻塞
慢查询日志是一个先进先出的队列，如果慢查询比较多，可能导致部分慢查询命令丢失，可以定期执行slow get命令将慢查询日志持久化到其他存储中（比如MySQL），然后制作可视化界面进行查询

Redis Shell

redis-cli

-r：命令执行多次，e.g. redis-cli -r 3 ping
-i：间隔几秒执行一次，必须和-r一起使用，e.g. redis-cli -r 5 -i 1 ping，表示间隔1秒执行一次ping，一共执行5次
-x：从标准输入读取数据作为redis-cli的最后一个参数
-c：连接Redis Cluster节点使用，防止moved和ask异常
-a：不需要手动输入auth命令
–scan和–pattern：扫描指定模式的键，相当于scan命令
–salve：把当前客户端模拟成当前Redis节点的从节点，可用来获取当前Redis节点的更新操作
–rdb：请求Redis实例生成并发送RDB持久化文件，保存在本地
–pipe：将命令封装成Redis通信协议定义的数据格式，批量发送给Redis执行
–bigkeys：使用scan对Redis键采样，找到内存占用比较大的键值
–eval：执行Lua脚本
–latency，–latency-history，–latency-dist：测试客户端到目标Redis的网络延迟
–stat：实时获取Redis的重要统计信息
–raw和–no-raw：–no-raw要求命令返回的结果是原始的格式，–raw则相反，返回格式化后的结果

redis-server

–test-memory：检测当前OS是否稳定地分配指定容量的内存给Redis

redis-benchmark

redis-benchmark可以为Redis做基准性能测试

-c：代表客户端的并发数量（默认是50）
-n：代表客户端请求总量（默认是100000）
-q：显示requests per second信息
-r：默认只插入3个键，可以使用-r插入更多的随机的键
-p：每个请求pipeline的数据量（默认为1）
-k [boolean]：客户端是否使用keepalive，1位使用，0不使用，默认1
-t：对指定命令进行基准测试
–csv：结果按照csv格式输出

Pipeline

RTT（Round Trip Time，往返时间），RTT在Redis中为发送命令的时间加上返回结果的时间（不包括命令排队和命令执行时间）。Pipeline能将一组Redis命令进行组装，通过一次RTT传输给Redis，再将这组Redis命令的执行结果按顺序返回给客户端

一般不建议使用命令行（Redis-cli的–pipe选项）来使用pipeline机制，更多的是高级语言有封装pipeline，建议使用

但需要注意pipeline不是原子的，一次pipeline如果数据量过大，会增加客户端等待时间和造成网络阻塞，因此不宜过大

事务与Lua

事务

Redis事务使用在 multi 和 exec 两个命令之间， multi 命令代表事务开始， exec 命令代表事务结束，它们之间的命令是原子顺序执行的，Redis的事务是简单的，它不支持回滚，无法实现命令之间的逻辑关系计算

127.0.0.1:6379> multi
OK
127.0.0.1:6379> sadd user:a:follow user:b
QUEUED
127.0.0.1:6379> sadd user:b:fans user:a
QUEUED
127.0.0.1:6379> exec
1) (integer) 1
2) (integer) 1

Redis处理错误机制如下：

命令错误：比如把set写成sett，属于语法错误，会造成整个事务无法执行
运行时错误：比如用户B在添加粉丝列表时，误把sadd命令写成zadd，这时上面的往用户A添加关注用户B的sadd命令会执行成功，而下面的用户B添加粉丝会执行失败报错，不支持回滚，需要开发人员自己修复这类问题

有些应用场景需要在事务开始之前，确保事务中的key没有被其他客户端修改过，才执行事务，否则不执行（类似乐观锁），Redis提供了watch命令来解决这类问题

Lua

Lua语法

Lua语言提供如下几种数据类型：booleans（布尔），numbers（数值），strings（字符串），tables（表格）

字符串： local strings val = "world" ，local代表val是一个全局变量

数组： local tables myArray = {"redis", "jedis"} ，Lua数组下标从1开始

for：

local int sum = 0
for i = 1, 100
do
    sum = sum + 1
end
-- 输出结果5050
print(sum)
-- 遍历myArray
for i = 1, #myArray
do
    print(myArray[i])
end
-- 遍历myArray的下标和值
for index, value in ipairs(myArray)
do
    print(index)
    print(value)
end

while

local int sum = 0
local int i = 0
while i <= 100
do
    sum = sum + i
    i = i + 1
end
print(sum)

if else

local tables myArray = {"redis", "jedis", true, 88.0}
for i = 1, #myArray
do
    if myArray[i] == "jedis"
    then
        print("true")
        break
    else
        -- do nothing
    end
end

哈希： local tables user_1 = {age = 28, name = "tom"} ，使用tables类型实现哈希功能

遍历：

local tables user_1 = {age = 28, name = "tom"}
for key, value in pairs[user_1]
do print(key .. value)
end

函数定义：
1
2
3
function funcName(arg1, arg2)
...
end

Redis与Lua

Redis中使用Lua脚本：

eval 脚本内容 key个数 key列表参数列表
- e.g. eval 'return "hello " .. KEYS[1] .. ARGV[1]' 1 redis world，输出 hello redisworld
evalsha：使用SHA1作为参数可以直接执行对应Lua脚本，避免每次发送Lua脚本的开销，这样客户端就不需要每次执行脚本内容，脚本常驻服务端，也得到复用
- script load：加载脚本，redis-cli script load "${cat lua_get.lua}"，会返回其SHA1值
- evalsha 脚本SHA1值 key个数 key列表参数列表：执行Lua脚本
- script exists sha1：判断内存中是否存在此sha1对应的Lua脚本
- script flush：清除Redis内存中已加载的所有Lua脚本
- script kill：杀掉正在执行的Lua脚本

Lua使用Redis.call函数实现对Redis的访问
- e.g. redis.call("set", "hello", "world")，redis.call("get", "hello")

Lua脚本的好处：

原子执行，中途不会插入其他命令
帮助开发和运维人员创造出自己定制的命令，并常驻在内存中实现复用
将多条命令一次性打包，减少网络开销

Bitmaps

Redis提供Bitmaps实现对位的操作，在Redis中，Bitmaps有如下特性：

Redis的Bitmaps本身不是一种数据结构，实际上是一种字符串，但它可以对字符串的位进行操作
Bitmaps单独提供一套命令，所以在Redis中使用Bitmaps和使用字符串的方法不太一样。可以把Bitmaps想象成一个以为单位的数组，数组的每个单元只能存储0和1，数组的下标在Bitmaps中叫做偏移量

命令

setbit key offset value：设置值，设置键的第offset个位的值（从0开始），位图的长度跟max(offset)有关，如果执行了 setbit bitmapsKey 5000 1，位图就长5000位
getbit key offset：获取值，获取键的第offset位的值
bitcount key [start end]：获取Bitmaps指定范围值为1的个数，start和end代表起始字节和结束字节
bitop op destkey key [key …]：可以对多个Bitmaps做and，or，not，xor操作，并把结果保存在destkey中
- e.g. 对两天都访问过网站的用户统计 bitop and unique:users:and:2016-04-04_03 unique:users:and:2016-04-03 unique:users:and:2016-04-04
bitpos key targetBit [start] [end]：计算Bitmaps中第一个值为targetBit的偏移量，start和end代表起始字节和结束字节，

Bitmaps分析

假设网站有1亿用户，每天独立访问的用户有5千万，每天使用集合类型和Bitmaps存储独立用户性能如下：

但是如果网站每天独立用户很少，例如只有10万（大量僵尸用户），那么两者对比如下图，这时候使用Bitmaps就不合适了，因为基本上大部分位都是0

HyperLogLog

HyperLogLog是一种基数算法（在Redis中实际是字符串类型），通过它可以利用极小的内存空间完成独立总数的统计，数据集可以是IP，Email，ID等。

HyperLogLog提供三个命令：pfadd，pfcount，pfmerge

如下图，2016-03-06的访问用户是uuid-1，uuid-2，uuid-3，uuid-4,2016-03-05的访问用户是uuid-4，uuid-5，uuid-6，uuid-7

pfadd key element [element …]：往HyperLogLog添加元素，成功返回1
pfcount key [key …]：计算一个或多个HyperLogLog的独立总数
- HyperLogLog占用内存和集合类型对比如下，HyperLogLog存在误差，Redis官方的数字是0.81%的失误率：
pfmerge destkey sourcekey [sourcekey …]：可以求出多个HyperLogLog的并集并赋值给destkey
使用HyperLogLog一般有如下两条目的和约束
- 只为了计算独立总数，不需要获取单条数据
- 为了HyperLogLog的内存占用量优势，可以容忍一定误差率

发布订阅

Redis的发布订阅模型如下图所示

命令

publish channel message：发布消息
- e.g. publish channel:sports "Tim won the championship"，往channel:sports频道发布一条”Tim won the championship”的消息
subscribe channel [channel …]：订阅消息
- 订阅后客户端处于订阅状态，只能接收subscribe，psubscribe，unsubscribe，punsubscribe四个命令
- 新开启的订阅客户端不会接收到该频道之前的消息，因为Redis不会对发布的消息进行持久化
- 订阅后接收到消息如下图
unsubscribe [channel [channel …]]：取消订阅
psubscribe pattern [pattern …]：按照正则表达式模式订阅
punsubscribe [pattern [pattern …]]：按照正则表达式模式取消订阅
pubsub channels [pattern]：查看活跃的频道，活跃的频道指当前频道至少有一个订阅者
pubsub numsub [channel …]：查看频道订阅数
pubsub numpat：查看模式订阅数，即查看多少个客户端通过模式订阅频道

使用场景

聊天室，公告牌，服务之间利用消息解耦都可以使用发布订阅模式，如视频管理系统和视频服务

GEO

Redis 3.2版本提供GEO（地理信息定位）功能，支持存储地理位置信息用来实现诸如附近位置，摇一摇这类依赖地理位置信息的功能。Redis的GEO是借鉴Ardb实现的

geoadd key longitude latitude member [longitude latitude member …]：增加地理位置信息，longitude，latitude，member分别是精度，维度，成员，返回结果是成功添加的个数
geopos key member [member …]：获取地理位置信息
geodist key member1 member2 [unit]：获取两个地理位置的距离，unit表示返回结果的单位，包含四种：m（米），km（公里），mi（英里），ft（尺）
georadius key longitude latitude radius m|km|ft|mi [withcoord] [withdist] [withhash] [asc|desc] [COUNT count] [store key] [storedist key]：获取指定位置范围内的地理信息位置集合，longitude和latitude指定经纬度，radius指定半径，后面是单位
- withcoord：返回结果包含经纬度
- withdist：返回结果包含离中心节点位置的距离
- withhash：返回结果包含geohash
- count：指定返回结果的数量
- asc|desc：按照离中心节点距离作升降序排序
- store key：将返回结果的地理位置信息保存到指定键
- storedist key：将返回结果离中心节点的距离保存到指定键
georadiusbymember key member radius m|km|ft|mi [withcoord] [withdist] [withhash] [asc|desc] [COUNT count] [store key] [storedist key]：同上，只不过它的目标中心是成员
geohash key member [member …]：获取geohash，geohash用来把二维经纬度转换为一维字符串，有如下特点：
- GEO的数据类型为zset，Redis把所有地理位置信息的geohash存放在zset中
- 字符串越长，表示位置更精准，具体长度与精度如下图
- 两个字符串越相似，它们之间的距离越近，Redis利用字符串前缀匹配算法实现相关的命令
- geohash编码和经纬度之间可以互相转换
zrem key member：删除地理位置信息，GEO没有删除命令，但是底层使用的zset，所以可以使用zrem来删除

Redis01-背景与数据结构API

发表于 2020-06-26 | 分类于 Redis | 阅读次数:

Redis01-背景与基本数据类型API

NoSQL概述

NoSQL全称Not Only SQL

分类：

KV键值对：Redis，Memecached，Tair
文档型数据库：MongoDB
列存储数据库：HBase
图数据库：Neo4j

Redis简述

Redis（Remote Dictionary Server），远程字典服务，是一个开源的，使用ANSI C编写的，支持网络的，可支持网络，可基于内存也可持久化的日志型，Key-Value数据库，提供多种语言的API

Redis中的值可以由String,Hash,List,Set,ZSet,Bitmaps,HyperLogLog,GEO等多种数据结构和算法组成，基于内存，可以将内存的数据利用快照和日志的形式保存在硬盘上，提供键过期，发布订阅，事务，流水线，Lua脚本等附加功能

Redis周期性把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现master-slave同步

Redis特性

速度快：
- 基于内存
- 使用C语言实现，更接近操作系统
- 单线程架构，避免多线程产生的竞争问题
- 源码精打细磨，集性能和优雅于一身
基于键值对的数据结构服务器
丰富的功能,包括键过期,发布订阅,Lua脚本,事务,流水线
简单稳定
客户端语言多
持久化(RDB,AOF)
主从复制
高可用和分布式

Redis使用场景

缓存
排行榜系统(提供列表和有序集合实现)
计数器应用(天然支持计数功能)
社交网络(赞/踩,粉丝,共同好友/喜好,推送,下拉刷新等)
消息队列系统(提供发布订阅和阻塞队列可以实现)

Redis不建议用于冷数据，数据量大的数据

Docker运行redis

启动redis：docker run -itd --name redis-test -p 6379:6379 redis

进入redis：docker exec -it redis01 redis-cli

远程连接：docker exec -it redis01 redis-cli -h ip_address -p 6379 -a your_password //如果有密码使用 -a参数

Redis性能测试

使用Redis官方工具benchmark

Docker指令：docker exec -it redis01 redis-benchmark [option] [option-value]

具体参数如下：

Redis数据结构API

全局命令

查看所有键：keys *
键总数：dbsize
检查键是否存在exists key
删除键：del key [key …]
键过期：expire key second
- ttl命令返回键的剩余过期时间，大于等于0表示键的剩余过期时间，-1表示键没设置过期时间，-2表示键不存在
查看键数据结构类型：type key
查看内部编码：object encoding key
清空当前数据库：flushdb
清空所有数据库：flushall
切换数据库：select num（默认0-15一共16个）

5种数据结构类型及其内部编码

单线程架构

Redis使用单线程架构和I/O多路复用模型来实现高性能的内存数据库服务

单线程速度快原因：

纯内存访问
非阻塞I/O，使用epoll作为I/O多路复用的实现，将epoll中连接，读写，关闭都转换为事件
避免线程切换和竞争产生的消耗

字符串

字符串可以是字符串（简单字符串，JSON,XML等），数字（整型，浮点数），二进制（图片，音频，视频），值最大512MB

命令

set：set key value [ex seconds] [px milliseconds] [nx|xx]
- ex：秒级过期时间，px：毫秒级过期时间
- nx：键必须不存在才能设置成功，用于添加，setnx命令可代替，可作为分布式锁，http://redis.io/topics/distlock
- xx：键必须存在才能设置成功，用于修改，setex命令可代替
get
mset key value [key value …]：批量设置值
mget key [key …]：批量获取值，它只发送一次请求，这次请求包含所有get，可以有效减少网络时间，但注意如果获取key过多可能造成阻塞，所需时间=1次网络时间+n次命令时间
incr key：自增
- 如果值不是整数，返回错误
- 值为整数，返回自增后结果
- 键不存在，按照值为0自增，返回结果1
decr自减，incrby自增指定数字，decrby自增指定数字，incrbyfloat自增浮点数
append key value：字符串尾部追加值，返回追加后的长度
strlen key：字符串长度
getset key value：设置并返回原来的值
setrange key offset value：设置指定位置的字符
getrange key start end：获取部分字符串

内部编码

int：8个字节的长整型
embstr：小于等于39字节的字符串
raw：大于39字节的字符串

使用场景

缓存
计数：使用incr
共享session：分布式Web服务将用户session信息保存在各自服务器中，这样会造成一个问题，由于负载均衡，分布式服务将用户的访问均衡在不同服务器上，用户刷新一次访问可能会发现需要重新登录，使用Redis将用户session集中管理
限速：比如获取手机验证码1分钟内只能获取5次，可以设置过期时间，后台检查键是否存在，键的值是否小于5即可

哈希

Redis中的哈希类型指的是键值对中值本身也是一个键值对结构，形如：value=({field1,value1},…,{fieldN,valueN})

哈希中键称为key，值中的映射关系为field-value

命令

hset key field value：设置值，成功返回1
hget key field：获取值
hdel key field [field …]：删除field，返回删除成功的个数
hlen key：计算field个数
hmget key field [field …]：批量获取
hmset key field value [field value …]：批量设置
hexists key field：是否存在field，成功放回1
hkeys key：获取所有field
hvals key：获取所有value
hgetall key：获取所有field-value
hincrby key field increment：自增
hincrbyfloat key field increment：自增
hstrlen key field：计算value的字符串长度（Redis 3.2以上）

内部编码

ziplist（压缩列表）：当哈希类型元素个数小于hash-max-ziplist-entries配置（默认512个），同时所有值都小于hash-max-ziplist-value配置（默认64字节），Redis使用ziplist作为哈希的内部实现，它采用更紧凑的结构实现多个元素的连续存储，更加节省内存
hashtable（哈希表）：哈希类型无法满足ziplist的条件时，就使用hashtable作为内部实现，因为此时ziplist的读写效率就会下降，而hashtable的读写时间复杂度是O(1)

使用场景

可以使用哈希类型来缓存用户信息，但需要注意哈希类型是稀疏的，每个键可以有不同的field，哈希类型不可以做复杂的关系查询

实现用户信息缓存的三种方法

原生字符串类型：每个属性一个键
- set user:1:name tom
- set user:1:age 23
- set user:1:city beijing
- 优点：简单直观，每个属性都支持更新
- 缺点：占用过多键，内存占用大，用户内聚性差
序列化字符串类型：将用户信息序列化后用一个键保存
- 优点：简化编程，合理使用序列化可以提高内存使用效率
- 缺点：序列化和反序列化有一定开销，且更新需要把全部数据取出进行反序列化，更新后再序列化进Redis
哈希类型：每个用户属性使用一堆field-value
- hmset user:1 name tom age 23 city beijing
- 优点：简单直观，合理可以减少内存使用
- 缺点：控制哈希在ziplist和hashtable之间编码的转换，hashtable更消耗内存

列表

列表用于存储多个有序的字符串，Redis中可以对列表两端插入和弹出，列表元素可以重复，最多存2^32-1个元素

命令

rpush key value [value …]：从右边插入
lpush key value [value …]：从左边插入
linsert key before|after pivot value：从列表中找到等于pivot的元素，在其前或后插入一个新元素value，并返回当前列表长度
lrange key start end：获取指定范围内的元素列表，lrange key 0 -1 表示获取所有。从左到右下标包括0到N-1，从右到左下标分别是-1到-N，获取的元素列表包括下标为end的元素本身（闭区间）
lindex key index：获取列表指定索引下标的元素
llen key：获取列表长度
lpop key：从列表左侧弹出元素
rpop key：从列表右侧弹出元素
lrem key count value：找到等于value的元素进行删除，返回删除成功的个数
- count > 0，从左到右，删除最多count个元素
- count < 0，从右到左，删除最多count绝对值个元素
- count = 0，删除所有
ltrim key start end：按照索引范围修剪列表
lset key index newValue：修改index下标的元素
blpop(brpop) key [key …] timeout：阻塞弹出，有如下两种情况
- 列表为空，timeout=3，则客户端等待3秒返回，如果timeout=0，客户端会一直等待下去，此时如果向列表添加了数据element1，客户端会立即弹出返回该数据
- 列表不为空，则客户端会立即返回

内部编码

ziplist（压缩列表）：列表元素小于list-max-ziplist-entries（默认512个）并且列表中每个元素的值都小于list-max-ziplist-value（默认64字节）
linkedlist（链表）：列表类型无法满足ziplist时使用linkedlist

使用场景

消息队列：lpush+brpop可以实现阻塞队列
文章列表：有序，支持索引获取元素

集合

集合不允许有重复元素，无序，最多存2^32-1个元素

命令

sadd key element [element …]：添加元素，返回添加元素的个数
srem key element [element …]：删除元素，返回成功删除元素的个数
scard key：计算元素个数
sismember key element：判断元素是否在集合中，成功返回1，否则返回0
srandmember key [count]：count默认为1，随机从集合返回指定个数元素
spop key：从集合随机弹出元素
smembers key：获取所有元素
sinter key [key …]：求多个集合的交集
sunion key [key …]：求多个集合的并集
sdiff key [key …]：求多个集合的差集
将交集，并集，差集结果保存在destination：
- sinterstore destination key [key …]
- sunionstore destination key [key …]
- sdiffstore destination key [key …]

内部编码

intset（整数集合）：当集合中元素都是整数且元素个数小于set-max-intset-entries（默认512个）
hashtable（哈希表）：无法满足intset的条件时

使用场景

标签

有序集合

元素不可重复，可以排序，使用分数（score）作为排序的依据

命令

zadd key score member [score member …]：添加成员，返回添加成功的个数
- Redis 3.2为zadd添加了nx，xx，ch，incr四个选项
- nx：member必须不存在才可以设置成功，用于添加
- xx：member必须存在才可以设置成功，用于更新
- ch：返回此次操作后，有序集合元素和分数发生变化的个数
- incr：对score做增加，相当于zincrby
- zadd的时间复杂度为O(log(n))
zcard key：计算成员个数
zscore key member：计算某个成员的分数
zrank key member：分数从高到低计算成员排名（排名从0开始计算）
zrevrank key member：分数从低到高计算成员排名
zincrby key increment member：增加成员的分数
zrange key start end [withscores]：返回指定排名范围内的成员，加上withscores会同时返回其分数
zrevrange key start end [withscores]：同上，从高到低排名
zrangebyscore key min max [withscores] [limit offset count]：返回指定分数范围内的成员，从低到高，limit，offset，count可以限制输出的起始位置和个数，min，max支持开闭区间，支持无穷，如：(200 +inf ； [200, 300]等
zrevrangebyscore key max min [withscores] [limit offset count]：从高到低
zcount key min max：返回指定分数范围成员个数
zremrangebyrank key start end：删除指定排名内的升序元素
zremrangebyscore key min max：删除指定分数范围内的成员，同样支持开闭区间和无穷
zinterstore destination numkeys key [key ..] [weights weigeht [weight …]] [aggregate sum|min|max]：求交集
- numkeys表示需要做交集计算键的个数，key表示具体键
- weight表示权重，每个member会将自己分数乘以这个权重，默认权重1
- 计算成员交集后，分值按照sum，min或max做汇总
- e.g. zinterstore user:ranking:1_inter_2 2 user:ranking:1 user:ranking:2 weights 1 0.5 aggregate max
zunionstore destination numkeys key [key ..] [weights weigeht [weight …]] [aggregate sum|min|max]：求并集

内部编码

ziplist（压缩列表）：有序集合的元素个数小于zset-max-ziplist-entries（默认128个），同时每个元素的值都小于zset-max-ziplist-value（默认64字节）
skiplist（跳跃表）：ziplist条件不满足时，会使用skiplist，因为ziplist读写效率会下降

使用场景

添加用户赞数，使用zadd和zincrby
取消用户赞数，zrem
展示获取赞数最多的十个用户：zrevrange
展示用户信息及用户分数

键管理

单个键管理

rename key newkey：键重命名，如果newkey已存在，会被覆盖，可以使用renamex，它在newkey存在时会重命名失败，如果键对应值比较大，重命名可能会阻塞（因为要执行del操作）
randomkey：随机返回一个键
expire key seconds：设置过期时间，秒级
expireat key timestamp：设置过期时间，在秒级timestamp后过期
pexpire key milliseconds：毫秒级过期时间，redis 2.6之后
pexpireat key milliseconds
persist key [key …]：将键过期时间清除
move key db：迁移键到另一个内部数据库
dump key + restore key ttl value：在源redis上，dump把键值序列化，采用RDB格式，在目标redis上，restore将上面序列化的值复原，ttl代表过期时间，如果等于0则没有过期时间
migrate host port key|”” destination-db timeout [copy] [replace] [keys key [key …]]：在redis实例间数据迁移，原子操作
- key|””：如果要迁移多个键，这里为空字符串””
- destination-db：目标redis的数据库索引，如果为0号数据库则填写0
- timeout：迁移的超时时间（毫秒）
- copy：添加此选项，迁移后不删除源键
- replace：添加此选项，不管目标redis是否存在该键都会正常迁移进行数据覆盖

遍历键

keys pattern：正则表达式匹配遍历键
- keys可能造成阻塞，不建议在生产环境使用，有如下三种情况可以使用：
- 在一个不对外提供服务的redis从节点上可以执行，这样不会阻塞客户端的请求，但会影响到主从复制
- 如果确认键值总数少可以使用
- 使用scan代替
scan cursor [match pattern] [count number]：渐进式遍历
- cursor是必需参数，代表游标，第一次遍历从0开始，每次scan遍历完都会返回当前游标的值，直到游标值为0，表示遍历结束
- pattern是模式匹配
- number表明每次要遍历的键个数，默认是10，可以适当增大
- scan的结果分为两部分，第一部分是下次scan需要的cursor，第二部分是这次scan的键（默认10个）

数据库管理

select dbIndex：切换数据库（默认16个，编号0-15），不建议使用多数据库
flushdb/flushall：清除数据库，flushdb只清除当前数据库，flushall清除所有

其他功能数据结构API

慢查询分析

慢查询分析主要分析的是第三步的时间

Redis提供两个参数：

slowlog-log-slower-than：预设阈值，默认是10000（微妙）
slowlog-max-len：Redis使用一个列表来存储慢查询日志，这个参数就是列表的最大长度。当慢查询日志列表已处于最大长度，最早插入的一条命令会被从列表中移出
使用config set命令来动态修改，使用config rewrite命令来将配置持久化到本地配置文件

获取慢查询日志：

slowlog get [n]：n指定条数，结果有4个属性，分别是：慢查询日志的标识ID，发生时间戳，命令耗时，执行命令和参数

slowlog len：获取慢查询日志当前的长度
slowlog reset：慢查询日志重置

慢查询分析最佳实践

slowlog-max-len配置建议：线上调大慢查询列表，可设置为1000以上（会对长命令截断操作，不会占用大量内存）
slowlog-log-slower-than配置建议：默认超过10毫秒判定为慢查询，需要根据Redis并发量调整该值，对于高OPS场景Redis建议设置为1毫秒
慢查询仅仅记录命令执行时间，而不包括命令排队时间（单线程）和网络传输时间，因为命令执行排队机制，慢查询会导致其他命令级联阻塞，当客户端出现请求超时，需要检查该时间点是否有对应的慢查询，从而分析出是否为慢查询导致的命令级联阻塞
慢查询日志是一个先进先出的队列，如果慢查询比较多，可能导致部分慢查询命令丢失，可以定期执行slow get命令将慢查询日志持久化到其他存储中（比如MySQL），然后制作可视化界面进行查询

Redis Shell

redis-cli

-r：命令执行多次，e.g. redis-cli -r 3 ping
-i：间隔几秒执行一次，必须和-r一起使用，e.g. redis-cli -r 5 -i 1 ping，表示间隔1秒执行一次ping，一共执行5次
-x：从标准输入读取数据作为redis-cli的最后一个参数
-c：连接Redis Cluster节点使用，防止moved和ask异常
-a：不需要手动输入auth命令
–scan和–pattern：扫描指定模式的键，相当于scan命令
–salve：把当前客户端模拟成当前Redis节点的从节点，可用来获取当前Redis节点的更新操作
–rdb：请求Redis实例生成并发送RDB持久化文件，保存在本地
–pipe：将命令封装成Redis通信协议定义的数据格式，批量发送给Redis执行
–bigkeys：使用scan对Redis键采样，找到内存占用比较大的键值
–eval：执行Lua脚本
–latency，–latency-history，–latency-dist：测试客户端到目标Redis的网络延迟
–stat：实时获取Redis的重要统计信息
–raw和–no-raw：–no-raw要求命令返回的结果是原始的格式，–raw则相反，返回格式化后的结果

redis-server

–test-memory：检测当前OS是否稳定地分配指定容量的内存给Redis

redis-benchmark

redis-benchmark可以为Redis做基准性能测试

-c：代表客户端的并发数量（默认是50）
-n：代表客户端请求总量（默认是100000）
-q：显示requests per second信息
-r：默认只插入3个键，可以使用-r插入更多的随机的键
-p：每个请求pipeline的数据量（默认为1）
-k [boolean]：客户端是否使用keepalive，1位使用，0不使用，默认1
-t：对指定命令进行基准测试
–csv：结果按照csv格式输出

Pipeline

一般不建议使用命令行（Redis-cli的–pipe选项）来使用pipeline机制，更多的是高级语言有封装pipeline，建议使用

但需要注意pipeline不是原子的，一次pipeline如果数据量过大，会增加客户端等待时间和造成网络阻塞，因此不宜过大

事务与Lua

事务

127.0.0.1:6379> multi
OK
127.0.0.1:6379> sadd user:a:follow user:b
QUEUED
127.0.0.1:6379> sadd user:b:fans user:a
QUEUED
127.0.0.1:6379> exec
1) (integer) 1
2) (integer) 1

Redis处理错误机制如下：

命令错误：比如把set写成sett，属于语法错误，会造成整个事务无法执行
运行时错误：比如用户B在添加粉丝列表时，误把sadd命令写成zadd，这时上面的往用户A添加关注用户B的sadd命令会执行成功，而下面的用户B添加粉丝会执行失败报错，不支持回滚，需要开发人员自己修复这类问题

Lua

Lua语言提供如下几种数据类型：booleans（布尔），numbers（数值），strings（字符串），tables（表格）

字符串： local strings val = "world" ，local代表val是一个全局变量

vue快速入门

发表于 2020-03-08 | 分类于 vue | 阅读次数:

vue快速入门

文档啥都有
vue
vue-cli
webpack
vue-router
axios
element-ui
vue-element-admin
vant

vue是MVVM模式的实现者

Model：模型层，这里表示JS对象
View：视图层，表示DOM
ViewModel：连接视图和数据的中间件，Vue.js就是MVVM中ViewModel层的实现者

ViewModel能够观察到数据的变化，并对视图对应的内容进行更新；也能够监听视图的变化，并通知数据发生改变

MVVM如下：

View展现的不是Model的数据，而是ViewModel的数据，由ViewModel来与Model进行交互，这就完全解耦了View层和Model层

Vue-cli

安装nodejs

安装cnpm： npm install cnpm -g
安装vue-cli： cnpm install vue-cli -g（这个可能过时了，vue-cli官方文档有最新的安装）
查看可以基于哪些模板创建vue应用程序： vue list

安装webpack：
npm install webpack -g
npm install webpack-cli -g

第一次创建vue项目：
vue init webpack myvue
填写基本信息，一路选No（自己体验一次自己创建的流程）
cd myvue
npm install
npm run dev 启动项目

webstorm配置启动vue：
右上角Add Configuration，点击加号里面的npm，在Scripts栏添加dev即可，然后启动就成功启动项目了

使用Vue-router

当前目录路径下安装vue-router： npm install vue-router --save-dev
（axios也是同理，查看官方文档）

使用element-ui

当前目录路径下安装： npm i element-ui -S
安装SASS加载器：npm install sass-loader node-sass --save-dev

如果报错 Module build failed: TypeError: this.getResolve is not a function
修改sass-loader版本降为 ^7.3.1

1 2	卸载当前版本 npm uninstall sass-loader 安装 npm install [email protected] --save-dev

MakaLoo

Beautifully struggle every day

GitHub 知乎 E-Mail