我们为什么需要了解RESP协议?
本篇文章目的为探究RESP
协议,而非编写读写中间件,这点要清楚。
关于这个问题,我想通过一个实例来解释,我们编写Redis
中间件,为什么需要了解RESP
协议。
以上代码是编写了一个非常简单的TCP
服务器,我们监听8888
端口,尝试使用redis-cli -p 8888
连接服务器后,而后查看打印出来的应用层报文。
我们尝试执行下该代码,并且输入redis-cli -p 8888
进行连接。
我们编写的服务器获取redis
客户端的报文为:
*1
$7
COMMAND
上面这个就是RESP
协议的内容了,所以说,我们要编写一个Redis
的中间件,我们需要先了解一下RESP
协议才行。
什么是RESP协议
官网有相关的解释: https://redis.io/docs/reference/protocol-spec/
RESP
协议创建之初是专门为了Redis
服务器和客户端的通信而设计的,该协议在Redis 1.2
中引入,并且在Redis 2.0
中,成为Redis
通信的标准协议。该协议有如下优点:
- 实现简单
- 快速解析
- 直接可阅读
RESP
根据其协议前缀,可以序列化不同的数据类型,例如: 整数、字符串、数组 等,还能标注 正常输出 和 错误输出等。除了流水线和发布订阅以外,RESP
协议应该是最简单的请求-响应协议了。关于更多介绍,大佬们可以看看上面注释的官方文档。
RESP协议规范
RESP
协议不同的部分使用\r\n
(换行符)来进行分割,其支持5种数据类型,分别为: 简单字符串、错误、整数、复杂字符串 和 数组组成,我们列个表格来讲下。
类型 | 前缀 | 备注 |
---|---|---|
简单字符串 | + | 简单字符串以+开头 |
错误数据 | - | 错误数据以-开头 |
整数 | : | 整数以:开头 |
复杂字符串 | $ | 复杂字符串以$开头 |
数组 | * | 数组以*开头 |
我当初看到这个的时候,也是迷迷糊糊的,到底什么意思呢? 哎,我们举个例子你就明白了。
若我们想执行
set juejinName pdudo
若使用RESP
协议应当如何编写呢?应当编写如下:
*3
$3
set
$10
juejinName
$5
pdudo
那我们来解释一下*3
代表有3个数组,而$3
代表复杂字符串有长度为3,值为set
, $10
代表复杂字符串长度为10,值为juejinName
, $5
代表复杂字符串长度为5,值为pdudo
。
我们结合上述信息,可以画一张图。
这就是协议的内容了。
而协议前缀+
、-
、:
则要简单的多,直接跟数据即可,
例如:
+
+OK
-
-ERR syntax error
:
:3
如何使用该协议请求Redis
我们已经学习了相关的RESP
协议,那么我们如何学习呢? 我们可以使用telnet
命令来操作即可。
在此,我们准备几条命令,我们会将其转换为RESP
格式,且将其发送到redis
服务器。
命令
set name pdudo
get name
lpush pn 1
llen pn
转换为RESP
格式
*3
$3
set
$4
name
$5
pdudo
*2
$3
get
$4
name
*3
$5
lpush
$2
pn
$1
1
*2
$4
llen
$2
pn
我们将其放置到telnet
中执行一下呢
现在回头看看官网文档所提及的,该协议实现简单,直接可阅读,是不是理解的更加深刻了呢?
使用go编写Redis中间件实现读写分离
本篇暂不解释代码,而后单独开一篇谈论中间件代码。
实现该功能,其实本质上是区分命令是查询还是写入,若是查询,则直接转发到从库,而写入,则转发到主库即可,其架构图可以理解为如下:
我们已经有了目前的架构。
主机 | 端口 | 密码 | 角色 |
---|---|---|---|
127.0.0.1 | 6379 | 无 | 主库 |
127.0.0.1 | 7380 | 无 | 从库 |
相关代码已经放到了 gitee.com/pdudo/golea…
我们来看看实际效果呢:
总结
其实本篇文章核心的点是探究RESP
协议,而我们使用go
编写了一个软件,用于解析RESP
协议,从而获取执行的命令,再根据命令属性,从而转发从库或者主库,以此来达到读写分离的效果。再次提及一下核心点是拆解RESP
协议。
怎么样,好玩吧,动动你的小手指,快来试试吧。
以上就是go实现Redis读写分离示例详解的详细内容,更多关于go Redis读写分离的资料请关注我们其它相关文章!