上次针对 redis 的源码浏览波及一般的 client,这次针对 cluster 模式下的 client 源码进行剖析。
具体的源码门路就是在 lib/cluster 目录下了。
Cluster 实例化
单刀直入,咱们应用 Cluster
模式最开始也是要进行实例化的,这里调用的代码位于 lib/cluster/index.ts
:
const {Cluster} = require('ioredis')
const cluster = new Redis.Cluster([
{
port: 6380,
host: "127.0.0.1",
},
{
port: 6381,
host: "127.0.0.1",
},
])
cluster.get('someKey').then()
从源码上来看,Cluster
预期接管两个参数,第一个是启动的节点汇合 startNodes
,第二个是一个可选的 options
,
第一个参数是比拟固定的,没有太多含意,而第二个参数能够传递很多配置,这个能够在 README 中找到(目前是 12 个参数):https://www.npmjs.com/package/ioredis#cluster
如果没有传入的话,则会有默认值来填充,但并不是所有的参数都会有默认值。
与 Redis Client
一样的解决逻辑,在构造函数中会 call
一下 Commander
,随后还会实例化一个 ConnectionPool
对象,并将 options.redisOptions
传入进去。
代码位于 lib/cluster/ConnectionPool.ts
在实例化 ConnectionPool
的过程中并没有做什么实质性的操作,只是把 options.redisOptions
放到了一个 private 属性中。
随后在 Cluster
构造函数中注册了四个对应的事件,别离是 -node
、+node
、drain
和 nodeError
,别离代表了 移除节点、减少节点、节点为空、节点出错。
是 ConnectionPool
本人实现的一些事件,后续会看到在哪里触发。
接下来实例化了一个 ClusterSubscriber
对象,并将上边实例化的 connectionPool
实例作为参数放了进去,并把 Cluster
实例的援用也传了进去。
实例化过程中做的事件也比较简单,就是监听了上边咱们提到的 -node
与 +node
两个事件,在移除节点时,会判断是否存在 subscriber
属性,如果不存在则跳出,如果存在的话,会判断被移除的 key 是否等于以后 subscriber
。
这里能够提一下 subscriber
到底是什么,这个在下边的 selectSubscriber
函数中能够看到,就是实例化了一个 Redis Client
,而实例化 Redis Client
所应用的参数,都是通过调用 connectionPool
的 getNodes
办法所拿到的,并随机筛选其中一个节点配置来进行实例化。
之后就会通过该 Redis Client
来调用两个命令,subscriber
与 psubscriber
,这两个是用来实现 Pub/Sub 的,具体区别其实就是后者能够监听一个带有通配符的服务。
subscriber 与 psubscriber 的区别:https://redis.io/topics/pubsub
并在接管到数据当前,通过emit
的形式转发给Cluster
,后续 Cluster 模式下的 Pub/Sub 将会通过这里来进行数据的传递。
Connect
最初咱们调用 connect
函数就实现了整个 Cluster
实例化的过程。
如果是开启了 lazyConnect 那么这里就间接批改实例状态为 wait,而后完结整个流程。
在 connect
时咱们首先会解析 startNodes,拿到对应的 IP 和 端口等信息,而后会调用 reset 重置 connectionPool
中的实例,connectionPool
中会存储多个 IP+ 端口 的 Redis 实例援用,调用 reset 会把一些应该不存在的实例给关掉,而后把一些新减少的进行创立,复用曾经存在的实例,同时在新增节点的时候会触发 ClusterSubscriber
的 +node
事件,如果此时是第一次触发,那么这时 ClusterSubscriber
才会真正的去创立用于 Pub/Sub 的 Redis 实例。
之后会注册一个 refresh
事件,在事件外部会调用 readyCheck
,在这之前,则须要先去获取 Redis
节点的一些信息,这里是通过 getInfoFromNode
办法来实现的,外部会拿到一个 Redis
实例,并调用 duplicate
创立一个额定的实例,而后调用 cluster slots
命令来获取以后 Redis 集群服务状态,这里返回的数据会蕴含所有的节点 IP + 端口,同时蕴含某个节点的起始完结返回,具体的返回值如下:
redis 127.0.0.1:6379> cluster slots
1) 1) (integer) 0
1) (integer) 4095
2) 1) "127.0.0.1"
1) (integer) 7000
3) 1) "127.0.0.1"
1) (integer) 7004
2) 1) (integer) 12288
1) (integer) 16383
2) 1) "127.0.0.1"
1) (integer) 7003
3) 1) "127.0.0.1"
1) (integer) 7007
3) 1) (integer) 4096
1) (integer) 8191
2) 1) "127.0.0.1"
1) (integer) 7001
3) 1) "127.0.0.1"
1) (integer) 7005
4) 1) (integer) 8192
1) (integer) 12287
2) 1) "127.0.0.1"
1) (integer) 7002
3) 1) "127.0.0.1"
1) (integer) 7006
转换成 JS 的数据大抵是一个这样的构造:
[
[ // slot info
0, // slot range start
4095, // slot range end
[
'127.0.0.1', // IP
7000 // port
]
],
[ // other slot info
12288,
16383,
[
'127.0.0.1',
7003
]
],
]
cluster slot 的形容:https://redis.io/commands/cluster-slots
在获取到这些实在的节点信息当前,会根据拿到的节点汇合,再次调用 connectionPool
的 reset
办法,因为上次调用其实是应用的 startNode
传入的初始值,这里则会应用以后服务正在运行的数据进行一次替换。
在实现这一动作后,则会触发 refresh
事件,也就会进入下边的 readyCheck
环节,确保服务是可用的。
readyCheck
查看 readyCheck
的实现,次要也是通过调用 cluster info
命令来获取以后服务的状态。
在前文所讲解决 twemproxy 模式下的问题时,将 Redis Client
的 readyCheck
从 info
批改为了 ping
命令来实现,而这里,则没有进行批改,因为要留神的是,这里并不是 info
命令,而是 cluster
命令,只不过参数是 info
。
Cluster
模块会应用 cluster info
命令中的 cluster_state
字段来作为检测的根据,数据会依照 k:v\nk:v\n 这种格局组合,所以咱们会在代码中看到通过匹配换行来获得对应的字段,并通过截取的形式拿到具体的值。
不过针对这里的逻辑,我集体倒是感觉间接用正则匹配反而更简略一些,因为拿到参数的值并没有做一些额定的操作,仅仅是用来验证。
private readyCheck(callback: CallbackFunction<void | "fail">): void {(this as any).cluster("info", function (err, res) {if (err) {return callback(err);
}
if (typeof res !== "string") {return callback();
}
let state;
const lines = res.split("\r\n");
for (let i = 0; i < lines.length; ++i) {const parts = lines[i].split(":");
if (parts[0] === "cluster_state") {state = parts[1];
break;
}
}
if (state === "fail") {debug("cluster state not ok (%s)", state);
callback(null, state);
} else {callback();
}
});
}
当咱们发现 cluster info
中返回的数据为 fail
时,那么阐明集群中的这个节点是一个不可用的状态,那么就会调用 disconnect
断开并进行重连。
在触发 disconnect
的时候,同时会敞开 ClusterSubscriber
中的实例,因为咱们的连贯曾经要敞开了,那么也没有必要留着一个注册 Pub/Sub 的实例在这里了。
在这些操作实现之后,会进入 retry
的流程,这里其实就是依照某种逻辑从新调用了 connect
办法,再次执行前边所形容的逻辑。
针对整个流程画图示意大略是这样的:
sendCommand
在实例创立结束后,那么下一步就会波及到调用命令了。
在前边实例化过程中不可避免的也提到了一些 sendCommand
的事件,Redis
在实例化的过程中,会有一个状态的变更,而每次触发 sendCommand
实际上都会去查看那个状态,如果以后还没有建设好连贯,那么这时的命令会被放入到 offlineQueue
中暂存的。
在 readyCheck
通过之后会依照程序来调用这些命令。
当然,在 sendCommand
办法中也存在了对以后实例状态的判断,如果是 wait
,那么能够认为实例开启了 lazyConnect
模式,这时会尝试与服务端建设连贯。
同时在 sendCommand
中也会对命令进行判断,一些 Pub/Sub 对应的命令,比方 publish
,会被转发到 ClusterSubscriber
对应的实例下来执行,而其余一般的命令则会放到 connectionPool
中去执行。
通过这样的形式将公布订阅与一般的命令进行了拆分。
同样,因为是 Cluster 模式,所以还会有主从之间的拆分逻辑,这个能够通过实例化 Redis Cluster
时传入的 scaleReads
参数来决定,默认的话是 master
,可选的还有 all
、slave
以及一个接管命令以及实例列表的自定义函数。
知识点来了
在 ioredis 中,默认状况下的配置是 master
,这也就意味着所有的申请都会发送到 master
节点,这就意味着如果你为了进步读取的性能所创立的一些从库,__基本不会被拜访到__。
详情见文档:https://www.npmjs.com/package/ioredis#user-content-read-write-splitting
如果想要应用从库,那么能够把 scaleReads
批改为 slave
,然而不须要放心说一些会对数据库造成批改的命令发送到从库,在 sendCommand
中会针对所发送的命令进行检测,如果不是只读的命令,且 scaleReads
设置的不是 master
会强行笼罩为 master
。
针对命令是否为只读的判断:https://github.com/luin/ioredis/blob/master/lib/cluster/index.ts#L599
而后对于那个自定义函数,其实就是须要本人依据 command
去评估到底应用哪个(些)实例,而后把对应的实例返回进来。
最终,咱们拿到了一个 Redis
实例,这时应用该 Redis
实例进行调用 sendCommand
即可。
而后后边的逻辑就和一般的 Redis
触发命令没有什么区别了。
总结
总的来看,在 ioredis 的实现中 Redis Cluster
是作为一个 Redis
的扩大来做的,在很多中央都会看到 Redis
的存在,并且同样都会继承自 Command
实例,这就让用户在应用的过程中并没有太多的差别,只有在实例化时传入的参数不太一样,在调用各种 Redis
命令时则没有区别,而在 Cluster
中则外部调用了 Redis
的 sendCommand
实现了逻辑上的复用。