写在前头

    对于redis这个中间件，想必对于java开发的同学都已经很是熟悉了，缓存？对了，你非常的棒！！！今天我们不扯这个东西，扯一点别的，假设有着这么一种场景，我们的redis部署在192.168.1.111上面，我们的web程序部署在192.168.1.112上面，然后来了客户端来了一个请求，而刚刚好，我们redis的应用场景也是做缓存，很假单嘛，不就是去redis里头拿下数据？恭喜你，又答对了。在这之前呢？是要和redis的服务器端建立连接，那么是怎么建立的呢？现在连接通道建立好了，相比就是使用redis提供的API，set,get方法啦，大家都知道，对于http请求使用的传输协议使用的是TCP，那么redis是使用什么协议做的数据格式约定呢？接下来通过源码跟踪   +   结合实际代码的方式一一揭晓！对，此处应该有掌声~

揭晓环节

1：创建Jedis客户端

2：源码跟踪

创建Jedis客户端

        

通过jedis向redis设置一个<K,V> 使用真正的客户端设置 再次进行set，使用安全的加码器进行加码 清楚的可以看到这里使用的是set 命令 连接服务器 是不是很是熟悉的味道，原来客户端是使用的socket和服务器进行通信的 然后使用协议进行命令发送

3：在源码中我们最后可以发现，客户端发送的报文是基于socket的，那么我们也可以去使用一个ServerSocket座位服务器端来接受这个socket发送的一些参数。

4：编写服务器端代码使用ServerSocket，并监听6379端口（这个可以自己设置），如下图，是不是so easy

启动服务器，发现一直在监听

5：编写客户端代码并执行

向redis里头设置值 客户端报错，没关系

6：观察服务端打印结果，发现竟然是这个样子的，没错这个就是resp的报文约定格式，也就是说，其实我们向redis发送的最终数据是这么一串东西，好像有点看不懂的样子

7：解释环节  

    "*" ： 本次发送请求里面有几组数据，这里演示的结果是 *3 代表着有三组数据

    "$"：  每组数据里面的字符的长度，$3 SET，$4 name，$5 zhucc

    对于resp到这里就结束了

8：拓展环节

如果我们开启了AOP备份的话，redis服务端会生成.AOP文件的，那我们看下

aop的备份文件

看下里面的格式，很是完美的遵循RESP，次数应该有掌声

总结

    RESP是redis的简单的这一种序列化协议，所谓的协议就是一种规范，一种双方通信的数据格式的约定，例如在http协议中有什么请求头，请求体，空行，Content-Type鸭什么款七八糟的，其实resp协议也是redis速度非常快的原因之一，是因为这种协议所约定的数据格式解析起来比较简单，后续会继续更新有关于redis的相关技术分享，欢迎大佬们一起交流~