## 4.1 客户端通信协议

几乎所有的主流编程语言都有Redis的客户端（http://redis.io/clients），

不考虑Redis非常流行的原因，如果站在技术的角度看原因还有两个：



* 第一，客户端与服务端之间的通信协议是在TCP协议之上构建的。
* 第二，Redis制定了RESP（REdis Serialization Protocol，Redis序列化协议）实现客户端与服务端的正常交互，这种协议简单高效，既能够被机器解析，又容易
被人类识别。

例如客户端发送一条set hello world命令给服务端，按照RESP
的标准，客户端需要将其封装为如下格式（每行用\r\n分隔）：
```
*3
$3
SET
$5
hello
$5
world
```
这样Redis服务端能够按照RESP将其解析为set hello world命令，执行后
回复的格式如下：
```
+OK
```
可以看到除了命令（set hello world）和返回结果（OK）本身还包含了
一些特殊字符以及数字，下面将对这些格式进行说明。
### 1.发送命令格式
RESP的规定一条命令的格式如下，CRLF代表"\r\n"。
```
*<参数数量> CRLF
$<参数1的字节数量> CRLF
<参数1> CRLF
...
$<参数N的字节数量> CRLF
<参数N> CRLF
```
依然以set hell world这条命令进行说明。
参数数量为3个，因此第一行为：
```
*3
参数字节数分别是355，因此后面几行为：
$3
SET
$5
hello
$5
world
```
有一点要注意的是，上面只是格式化显示的结果，实际传输格式为如下
代码，整个过程如图4-1所示：
```
*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n
```
2.返回结果格式
Redis的返回结果类型分为以下五种，如图4-2所示：
* 状态回复：在RESP中第一个字节为"+"。
* 错误回复：在RESP中第一个字节为"-"。
* 整数回复：在RESP中第一个字节为"："。
* 字符串回复：在RESP中第一个字节为"$"。
* 多条字符串回复：在RESP中第一个字节为"*"。

![image.png](/static/img/83d824640cdee82e36f74bebba023893.image.webp)

我们知道redis-cli只能看到最终的执行结果，那是因为redis-cli本身就是
按照RESP进行结果解析的，所以看不到中间结果，redis-cli.c源码对命令结
果的解析结构如下：
```
static sds cliFormatReplyTTY(redisReply *r, char *prefix) {
sds out = sdsempty();
switch (r->type) {
case REDIS_REPLY_ERROR:
// 处理错误回复
case REDIS_REPLY_STATUS:
// 处理状态回复
case REDIS_REPLY_INTEGER:
// 处理整数回复
case REDIS_REPLY_STRING:
// 处理字符串回复
case REDIS_REPLY_NIL:
// 处理空
case REDIS_REPLY_ARRAY:
// 处理多条字符串回复
return out;
}
```
例如执行set hello world，返回结果是OK，并不能看到加号：
```
127.0.0.1:6379> set hello world
OK
```
为了看到Redis服务端返回的“真正”结果，可以使用nc命令、telnet命
令、甚至写一个socket程序进行模拟。

下面以nc命令进行演示，首先使用 nc127.0.0.16379连接到Redis：
```
nc 127.0.0.1 6379
```
状态回复：set hello world的返回结果为+OK：
```
set hello world
+OK
```
错误回复：由于sethx这条命令不存在，那么返回结果就是"-"号加上错误消息：
```
sethx
-ERR unknown command 'sethx'
```
整数回复：当命令的执行结果是整数时，返回结果就是整数回复，例如
incr、exists、del、dbsize返回结果都是整数，例如执行incr counter返回结果
就是“：”加上整数：
```
incr counter
:1
```
字符串回复：当命令的执行结果是字符串时，返回结果就是字符串回复。

例如get、hget返回结果都是字符串，例如get hello的结果为
```
“$5\r\nworld\r\n”：
get hello
$5
world
```
多条字符串回复：当命令的执行结果是多条字符串时，返回结果就是多条字符串回复。

例如mget、hgetall、lrange等命令会返回多个结果，例如下面操作：

首先使用mset设置多个键值对：
```
mset java jedis python redis-py
+OK
```
然后执行mget命令返回多个结果，第一个*\2代表返回结果的个数，后面的格式是和字符串回复一致的：
```
mget java python
*2
$5
252
jedis
$8
redis-py
```
有一点需要注意，无论是字符串回复还是多条字符串回复，如果有nil值，那么会返回$-1。

例如，对一个不存在的键执行get操作，返回结果为：
```
get not_exist_key
$-1
```
如果批量操作中包含一条为nil值的结果，那么返回结果如下：
```
mget hello not_exist_key java
*3
$5
world
$-1
$5
jedis
```
有了RESP提供的发送命令和返回结果的协议格式，各种编程语言就可以利用其来实现相应的Redis客户端，后面两节将介绍Java和Python两个编程
语言的Redis客户端。

## 4.3 Python客户端redis-py
### 4.3.1 获取redis-py
Redis官网提供了很多Python语言的客户端
（http://redis.io/clients#python），但最被广泛认可的客户端是redis-py。
redis-py需要Python2.7以上版本，有关Python的安装本书不会介绍，主要介绍
一下如何获取安装redis-py，方法有三种：
> 第一，使用pip进行安装：
```
pip install redis
```
> 第二，使用easy_install进行安装：
```
easy_install redis
```
>第三，使用源码安装：以2.10.5版本为例子进行说明，只需要如下四
步：
```
wget https:// github.com/andymccurdy/redis-py/archive/2.10.5.zip
unzip redis-2.10.5.zip
cd redis-2.10.5
#安装redis-py
python setup.py install
```
### 4.3.2 redis-py的基本使用方法
redis-py的使用方法也比较简单，下面将逐步骤介绍。
1) 导入依赖库：
```
import redis
```
2) 生成客户端连接：需要Redis的实例IP和端口两个参数：
```
client = redis.StrictRedis(host='127.0.0.1', port=6379)
```
3) 执行命令：redis-py的API保留了Redis API的原始风格，所以使用起来不会有不习惯的感觉：
```
# True
client.set(key, "python-redis")
# world
client.get(key)
```
整个实例代码如下：
```python
import redis
client = redis.StrictRedis(host='127.0.0.1', port=6379)
key = "hello"
setResult = client.set(key, "python-redis")
print setResult
value = client.get(key)
print "key:" + key + ", value:" + value
输出结果为：
True
key:hello, value:python-redis
```
下面代码给出redis-py操作Redis五种数据结构的示例，输出结果写在注释中：
```
#1.string
#输出结果：True
client.set("hello","world")
#输出结果：world
client.get("hello")
#输出结果：1
client.incr("counter")
#2.hash
client.hset("myhash","f1","v1")
client.hset("myhash","f2","v2")
#输出结果：{'f1': 'v1', 'f2': 'v2'}
client.hgetall("myhash")
#3.list
client.rpush("mylist","1")
client.rpush("mylist","2")
client.rpush("mylist","3")
#输出结果：['1', '2', '3']
client.lrange("mylist", 0, -1)
#4.set
client.sadd("myset","a")
client.sadd("myset","b")
client.sadd("myset","a")
#输出结果：set(['a', 'b'])
client.smembers("myset")
#5.zset
client.zadd("myzset","99","tom")
client.zadd("myzset","66","peter")
client.zadd("myzset","33","james")
#输出结果：[('james', 33.0), ('peter', 66.0), ('tom', 99.0)]
client.zrange("myzset", 0, -1, withscores=True)
```
### 4.3.3 redis-py中Pipeline的使用方法
redis-py支持Redis的Pipeline功能，下面用一个简单的示例进行说明。
1) 引入依赖，生成客户端连接：
```
import redis
client = redis.StrictRedis(host='127.0.0.1', port=6379)
```
2) 生成Pipeline：注意client.pipeline包含了一个参数，如果
```
transaction=False代表不使用事务：
pipeline = client.pipeline(transaction=False)
```
3) 将命令封装到Pipeline中，此时命令并没有真正执行：
```
pipeline.set("hello","world")
pipeline.incr("counter")
```
4) 执行Pipeline：
```
#[True, 3]
result = pipeline.execute()
```
和4.2.4小节一样，将用redis-py的Pipeline实现mdel功能：
```
import redis
def mdel( keys ):
client = redis.StrictRedis(host='127.0.0.1', port=6379)
pipeline = client.pipeline(transaction=False)
for key in keys:
print pipeline.delete(key)
return pipeline.execute();
```
### 4.3.4 redis-py中的Lua脚本使用方法
redis-py中执行Lua脚本和redis-cli十分类似，redis-py提供了三个重要的
函数实现Lua脚本的执行：
```
eval(String script, int keyCount, String... params)
script_load(String script)
evalsha(String sha1, int keyCount, String... params：
```
eval函数有三个参数，分别是：
* script：Lua脚本内容。
* keyCount：键的个数。
* params：相关参数KEYS和ARGV。
以一个最简单的Lua脚本为例进行说明：
```
return redis.call('get',KEYS[1])
```
在redis-py中执行，方法如下：
```
import redis
client = redis.StrictRedis(host='127.0.0.1', port=6379)
script = "return redis.call('get',KEYS[1])"
#输出结果为world
print client.eval(script,1,"hello")
```
script_load和evalsha函数要一起使用，首先使用script_load将脚本加载到
Redis中，代码如下：
```
scriptSha = client.script_load(script)
```
evalsha函数用来执行脚本的哈希值，它需要三个参数：
* scriptSha：脚本的SHA1。
* keyCount：键的个数。
* params：相关参数KEYS和ARGV。
执行效果如下：
```
print jedis.evalsha(scriptSha, 1, "hello");
```
完整代码如下：
```python
import redis
client = redis.StrictRedis(host='127.0.0.1', port=6379)
script = "return redis.call('get',KEYS[1])"
scriptSha = client.script_load(script)
print client.evalsha(scriptSha, 1, "hello");
```

04 客户端

03 小功能大用处 02

除了标准的使用Dockerfile生成镜像的方法外，由于各种特殊需求和历史原因，还提供了一些其他方法用以生成镜像

## 从rootfs压缩包导入
格式：docker import 选项<文件>|URL|-[<仓库名>[:<标签>]]



压缩包可以是本地文件、远程web文件，甚至是从标准输入中得到。压缩包将会在镜像/目录展开，并直接作为镜像第一层提交
    
比如我们想要创建一个 OpenVZ (opens new window)的 Ubuntu 16.04 模板 (opens new window)的镜像：
```
$ docker import \
    http://download.openvz.org/template/precreated/ubuntu-16.04-x86_64.tar.gz \
    openvz/ubuntu:16.04

Downloading from http://download.openvz.org/template/precreated/ubuntu-16.04-x86_64.tar.gz
sha256:412b8fc3e3f786dca0197834a698932b9c51b69bd8cf49e100c35d38c9879213
```
这条命令自动下载了 ubuntu-16.04-x86_64.tar.gz 文件，并且作为根文件系统展开导入，并保存为镜像 openvz/ubuntu:16.04。

导入成功后，我们可以用 docker image ls 看到这个导入的镜像：
```
$ docker image ls openvz/ubuntu
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
openvz/ubuntu       16.04               412b8fc3e3f7        55 seconds ago      505MB
```

如果我们查看其历史的话，会看到描述中有导入的文件链接：
```
$ docker history openvz/ubuntu:16.04
IMAGE               CREATED              CREATED BY          SIZE                COMMENT
f477a6e18e98        About a minute ago                       214.9 MB            Imported from http://download.openvz.org/template/precreated/ubuntu-16.04-x86_64.tar.gz

```

## 导入docker save 和导出镜像 docker load
Docker 还提供了 docker save 和 docker load 命令，用以将镜像保存为一个文件，然后传输到另一个位置上，再加载进来。这是在没有 Docker Registry 时的做法，现在已经不推荐，镜像迁移应该直接使用 Docker Registry，无论是直接使用 Docker Hub 还是使用内网私有 Registry 都可以。

### 保存镜像
```
$ docker image ls alpine
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
alpine              latest              baa5d63471ea        5 weeks ago         4.803 MB

$ docker save alpine -o filename
$ file filename
filename: POSIX tar archive
```
这里的filename可以为任意名称甚至任意后缀名，但文件的本质都是归档文件

若使用gzip压缩
```
$ docker save alpine | gzip > alpine-latest.tar.gz
```
加载镜像
```
$ docker load -i alpine-latest.tar.gz
Loaded image: alpine:latest
```

如果我们结合这两个命令以及 ssh 甚至 pv 的话，利用 Linux 强大的管道，我们可以写一个命令完成从一个机器将镜像迁移到另一个机器，并且带进度条的功能：
```
docker save <镜像名> | bzip2 | pv | ssh <用户名>@<主机名> 'cat | docker load'
```

其他制作镜像的方式

:::warning{title="注意"}
注意：docker commit 命令除了学习之外，还有一些特殊的应用场合，比如被入侵后保存现场等。

但是，不要使用docker commit定制镜像，定制镜像应该使用Dockerfile来完成
:::




现在我们定制一个web服务器的例子，来说明镜像是如何构建的：
```
$ docker run --name webserver -d -p 80:80 nginx
```
如果是在本机运行的docker，那么可以直接访问：http://localhost

![image.png](/static/img/1fdf2c852ec4f12df9ea20f0e010d272.image.png)

现在，假设非常不喜欢这个页面，我们希望改成欢迎docker的文字，可以使用docker exec命令进入容器，修改其内容：
```
$ docker exec -it webserver bash
root@3729b97e8226:/# echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
root@3729b97e8226:/# exit
exit
```
通过docker diff 命令看到具体的改动：
```
 docker diff webserver
C /root
A /root/.bash_history
C /run
C /usr
C /usr/share
C /usr/share/nginx
C /usr/share/nginx/html
C /usr/share/nginx/html/index.html
C /var
C /var/cache
C /var/cache/nginx
A /var/cache/nginx/client_temp
A /var/cache/nginx/fastcgi_temp
A /var/cache/nginx/proxy_temp
A /var/cache/nginx/scgi_temp
A /var/cache/nginx/uwsgi_temp
```

现在我们定制好了变化，我们希望能将其保存下来形成镜像

docker commit：可以将容器的存储层保存下来称为镜像。换句话说，就是在原有镜像的基础上，再叠加上容器的存储层，并构成新的镜像。

以后我们运行这个镜像的时候，就会拥有容器最后的文件变化

语法：
```
docker commit [选项] <容器ID或容器名> [<仓库名>[:<标签>]]
```
例如：
```
$ docker commit \
    --author "Tao Wang <twang2218@gmail.com>" \
    --message "修改了默认网页" \
    webserver \
    nginx:v2
sha256:07e33465974800ce65751acc279adc6ed2dc5ed4e0838f8b86f0c87aa1795214
```
* --author 是指定修改的作者
* --message 是记录本次修改的内容

docker images 查看新定制的镜像

---
我们还可以用docker history 具体查看镜像内的历史记录，如果比较nginx:latest的历史记录，我们会发现新增了我们刚刚提交的这一层
```
$ docker history nginx:v2
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
07e334659748        54 seconds ago      nginx -g daemon off;                            95 B                修改了默认网页
e43d811ce2f4        4 weeks ago         /bin/sh -c #(nop)  CMD ["nginx" "-g" "daemon    0 B
<missing>           4 weeks ago         /bin/sh -c #(nop)  EXPOSE 443/tcp 80/tcp        0 B
<missing>           4 weeks ago         /bin/sh -c ln -sf /dev/stdout /var/log/nginx/   22 B
<missing>           4 weeks ago         /bin/sh -c apt-key adv --keyserver hkp://pgp.   58.46 MB
<missing>           4 weeks ago         /bin/sh -c #(nop)  ENV NGINX_VERSION=1.11.5-1   0 B
<missing>           4 weeks ago         /bin/sh -c #(nop)  MAINTAINER NGINX Docker Ma   0 B
<missing>           4 weeks ago         /bin/sh -c #(nop)  CMD ["/bin/bash"]            0 B
<missing>           4 weeks ago         /bin/sh -c #(nop) ADD file:23aa4f893e3288698c   123 MB
```

运行
```
docker run --name web2 -d -p 81:80 nginx:v2
```

## 慎用dockercommit
使用 docker commit 命令虽然可以比较直观的帮助理解镜像分层存储的概念，但是实际环境中并不会这样使用。

首先，如果仔细观察之前的 docker diff webserver 的结果，你会发现除了真正想要修改的 /usr/share/nginx/html/index.html 文件外，由于命令的执行，还有很多文件被改动或添加了。这还仅仅是最简单的操作，如果是安装软件包、编译构建，那会有大量的无关内容被添加进来，将会导致镜像极为臃肿。

此外，使用 docker commit 意味着所有对镜像的操作都是黑箱操作，生成的镜像也被称为 黑箱镜像，换句话说，就是除了制作镜像的人知道执行过什么命令、怎么生成的镜像，别人根本无从得知。而且，即使是这个制作镜像的人，过一段时间后也无法记清具体的操作。这种黑箱镜像的维护工作是非常痛苦的。

而且，回顾之前提及的镜像所使用的分层存储的概念，除当前层外，之前的每一层都是不会发生改变的，换句话说，任何修改的结果仅仅是在当前层进行标记、添加、修改，而不会改动上一层。如果使用 docker commit 制作镜像，以及后期修改的话，每一次修改都会让镜像更加臃肿一次，所删除的上一层的东西并不会丢失，会一直如影随形的跟着这个镜像，即使根本无法访问到。这会让镜像更加臃肿。

4.1 客户端通信协议

3.3 Pipeline

3.3.1 Pipeline概念

从rootfs压缩包导入