中间组件

使用 maven docker 插件部署时，发现docker容器时间与本地时间相差8小时。 因为docker的时区与系统时区不同，docker容器默认的时区采用的UTC， 而中国时区为CTS，与之差8小时（东8区），可以进入容器使用date命令查看时区： root@pro-server-3:~/trainer# date Fri Mar 12 12:56:40 CST 2021 CST： China Standard Time，UTC+8:00 中国沿海时间（北京时间） UTC： Universal Time Coordinated 世界协调时间 所以设置一下Docker容器时区即可，我采用的docker maven插件，所以增加如下命令： 意思就是容器构建时执行 RUN 命令修改系统时间 /etc/timezone，将其设置为上海时间，问题解决。

Jenkins配置了Docker插件，结果发现不能远程调用远端的docker，原来是tcp端口没有打开。 ubuntu版本号：16.04 root@ubuntu:/etc/docker# cat /proc/version Linux version 4.4.0-62-generic (buildd@lcy01-30) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 ubuntu docker配置文件在 /etc/default/docker jenkins docker plugin链接远程docker时，需要docker开启tcp端口，编辑docker配置文件添加配置： vi /etc/default/docker 添加内容： DOCKER_OPTS="-H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock" 注意大小写，否则docker可能启动不起来。 重启docker： service docker restart 发现无效，查看docker进程，并未添加DOCKER_OPTS参数信息： root@ubuntu:/etc/docker# ps -ef | grep docker root 22829 1 0 14:28 ? 00:00:00 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock 编辑文件： vi /lib/systemd/system/docker.service 在[service]节点添加如下内容： EnvironmentFile=/etc/default/docker 然后修改ExecStart为： ExecStart=/usr/bin/dockerd -H fd:// $DOCKER_OPTS --containerd=/run/containerd/containerd.sock ...

在docker run创建并运行容器的时候，可以通过 -p 指定端口映射规则。但是，我们经常会遇到刚开始忘记设置端口映射或者设置错了需要修改。当docker start运行容器后并没有提供一个-p选项或设置，让你修改指定端口映射规则。那么这种情况我们该怎么处理呢？今天Docker君教你如何修改运行中的docker容器的端口映射？ 方法一：删除原有容器，重新建新容器 这个解决方案最为简单，把原来的容器删掉，重新建一个。当然这次不要忘记加上端口映射。 优缺点： 优点是简单快捷，在测试环境使用较多。缺点是如果是数据库镜像，那重新建一个又要重新配置一次，就比较麻烦了。 方法二：修改容器配置文件，重启docker服务 容器的配置文件路径： /var/lib/docker/containers/[hash_of_the_container]/hostconfig.json 其中的 hashofthecontainer 是docker镜像的hash值，可以通过 docker ps 或者 docker inspect containername 查看。（CONTAINER ID就可以看出来） 文件中其中有一项是PortBindings，其中8080/tcp对应的是容器内部的8080端口，HostPort对应的是映射到宿主机的端口9190。8361/tcp对应的是容器内部的8361端口，HostPort对应的是映射到宿主机的端口9191。按需修改端口，然后重启docker服务，再启动容器服务就可以了。 systemctl restart docker 优缺点： 这个方法的优点是没有副作用，操作简单。缺点是需要重启整个docker服务，如果在同一个宿主机上运行着多个容器服务的话，就会影响其他容器服务。 方法三：利用docker commit新构镜像 docker commit：把一个容器的文件改动和配置信息commit到一个新的镜像。这个在测试的时候会非常有用，把容器所有的文件改动和配置信息导入成一个新的docker镜像，然后用这个新的镜像重起一个容器，这对之前的容器不会有任何影响。 1、停止docker容器 docker stop container01 2、commit该docker容器 docker commit container01 new_image:tag 3、用前一步新生成的镜像重新起一个容器 docker run --name container02 -p 80:80 new_image:tag 优缺点： 这种方式的优点是不会影响统一宿主机上的其他容器，缺点是管理起来显得比较乱，没有第二种方法那么直观。

Dockfile就是一个文本文件，里边包含了一行行的指令，用来描述如何创建自定义镜像。 1. 使用 使用 docker build 命令来基于Dockerfile文件和上下文构建镜像，构建上下文指的是特定路径(PATH或URL)的文件集合，PATH用来指定本地文件系统目录，而URL用来指定Git仓库的地址，它们包含的所有文件(子目录或子模块)都会被递归处理。在大多数情况下，最好以空目录作为上下文，并将Dockerfile保存在该目录中。仅添加构建Dockerfile所需的文件。 docker build命令语法： docker build [OPTIONS] PATH | URL | - 例如： $ docker build . Sending build context to Docker daemon 6.51 MB ... 上边的命令会被docker daemon程序来处理而不是docker CLI，构建进程将发送指定路径下的Dockerfile文件到docker daemon。 Dockerfiie通过命令来关联构建上下文的文件，如 COPY、ADD 等命令。另外，可以通过 .dockerignore文件来排除文件或目录，以提高构建速度和性能。 一般而言，Dockerfile文件应该位于构建上下文的根目录中，但是，也允许使用 -f 选项来指定它的位置： $ docker build -f /path/to/a/Dockerfile . 也可以在镜像构建完成后指定tag： $ docker build -t shykes/myapp . 多次使用 -t 选项可以指定多个tag。 Docker daemon运行Dockfile之前会先进行校验，校验失败会输出错误信息： $ docker build -t test/myapp . Sending build context to Docker daemon 2.048 kB Error response from daemon: Unknown instruction: RUNCMD ...

1. 端口映射 1.1. 外部访问容器内的应用 如果外部要访问容器，需要将容器的端口开放出来，使用 -p 或 -P (大写)参数来映射容器端口和宿主机端口的关系： -p：明确指定端口映射，每个端口只能绑定一个容器，格式包括：IP:HOST_PORT:CONTAINER_PORT|IP:CONTAINER_PORT|HOST_PORT:COINTAINER_PORT 举例： docker run -p 8080:80 nginx 该命令表示启动容器是将宿主机的8080端口映射为容器的80端口，外部访问宿主机的8080端口就是在访问容器的80端口。 -P（大写）:随机映射一个宿主机的可用端口到容器 举例： docker run -P nginx 通过docker ps命令可以看到端口的映射结果： root@ubuntu:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 9e4cb770c5cc nginx "nginx -g 'daemon of…" 17 seconds ago Up 16 seconds 0.0.0.0:32768->80/tcp peaceful_robinson 可以看到，宿主机的32768端口映射到容器的80端口 1.2. 映射多个端口 多次使用 -p 参数，可以将容器的多个端口与宿主机的多个端口进行映射 例如： docker run -p 8080:80 -p 8081:80 nginx 1.3. 映射指定地址的指定端口 使用 IP:HOST_PORT:CONTAINER_PORT 格式来指定IP地址下的端口 例如： ...

在前一篇，我们开启了Mysql的binlog，当Mysql在进行数据更改操作时会自动记录binlog日志，以便进行主从服务，或者恢复丢失的数据。Binlog的日志内容可以设置不同的格式，以满足不同的需求。 1. Binlog格式 Binlog有三种格式(format)，包括STATEMENT、ROW和MIXED，根据Mysql版本的不同，有着不同的默认值，它们的设置方式和默认值见下表： 属性 值 命令行格式 --binlog-format=format 系统变量 binlog_format 范围 GLOBAL, SESSION 动态 是 类型 列举 默认值（>= 5.7.7） ROW 默认值（⇐ 5.7.6） STATEMENT 有效值 ROWS TATEMENT MIXED 1.1. STATEMENT 基于SQL语句的日志记录，每一条修改数据的sql语句都会被记录在binlog中，但是不会记录数据前后的变化。 优点 只需要记录执行语句的细节和上下文环境，避免了记录每一行的变化，在一些修改记录较多的情况下相比ROW level能大大减少binlog日志量，节约IO，提高性能；还可以用于实时的还原；同时主从版本可以不一样，从服务器版本可以比主服务器版本高 缺点 为了保证sql语句能在slave上正确执行，必须记录上下文信息，以保证所有语句能在slave得到和在master端执行时候相同的结果；另外，主从复制时，存在部分函数（如sleep）及存储过程(procedure、function、及trigger)在slave上会出现与master结果不一致的情况，而相比Row level记录每一行的变化细节，绝不会发生这种不一致的情况 1.2. ROW 基于行的日志记录，不记录SQL语句，仅记录被修改的行的数据信息。 优点 能非常清晰的记录下每行数据的修改细节，不需要记录上下文相关信息，因此不会发生某些特定情况下的procedure、function、及trigger的调用触发无法被正确复制的问题，任何情况都可以被复制，且能加快从库重放日志的效率，保证从库数据的一致性 缺点 由于所有的执行的语句在日志中都将以每行记录的修改细节来记录，因此，可能会产生大量的日志内容，干扰内容也较多；比如一条update语句，如修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中，实际等于重建了表。 row模式生成的sql编码需要解码，不能用常规的办法去生成，需要加上相应的参数(--base64-output=decode-rows -v)才能显示出sql语句; 新版本(5.7.7以后)binlog默认为ROW，且5.6新增了一个参数：binlog_row_image；把binlog_row_image设置为minimal以后，binlog记录的就只是影响的列，大大减少了日志内容 1.3. MIXED STATEMENT和ROW格式的混合，默认使用STATEMENT来记录binlog，当其无法实现主从复制的操作(例如函数操作)时，会切换到ROW格式来记录binlog。 2. 对比 接下来，我们使用mysql5.7.22版本来对比一下三种格式下的日志输出情况。 ...

某些时候，一不小心删除了数据库的数据甚至某些表、库，顿时慌得一P，是不是想死的心都有了？尤其是在小公司或者小项目中，没有遵循严格的规章制度，每个开发人员都有测试数据库甚至生产库的权限，一些没有经验的程序员一顿胡乱操作，导致数据库的数据丢失的情况时有发生。此时，我们就需要用到Mysql的binlog了。 1. Binlog简介 Binlog，即binary log、二进制日志，记录了描述数据库更改的“事件”（EVENT），例如表创建操作或对表数据的更改(DELETE、UPDATE、INSERT)，通俗的说，binlog主要用来记录对mysql数据更新或潜在发生更新的SQL语句(例如DELETE语句没有删除任何行也会记录)，并以”事务”的形式保存在磁盘中Binlog；另外，它还包含有关每个语句获取更新数据的时间长度的信息。 二进制日志有两个重要目的： 数据同步：mysql master上的更改数据，通过binlog发送给slave节点，然后达到主从数据一致的目的 数据恢复：binlog为数据恢复提供了有效的手段，因为binlog记录了数据操作的内容、时间等关键信息，可以根据binlog来恢复数据 Binlog仅记录了DML和DDL，并不包括查询(SELECT和SHOW)语句。Binlog会稍微降低性能，但是对于其数据同步和数据恢复等优势而言，牺牲些许性能是值得的。 2. 开启binlog 可以在启动mysql是添加--log-bin[=base_name] 参数来启用binlog，base_name为日志文件的基础名称（base_name为空则默认使用pid-file选项的名称，该选项默认是主机名），通常建议自己设置base_name而不是使用默认的名称，或者通过修改mysql配置文件来开启。 我们看看如何修改mysql配置文件来开启binlog，环境使用的是ubuntu： 1、查看是否开启binlog 登录mysql，进入mysql命令行，输入如下命令查看： mysql> show variables like 'log_bin%' 结果如下： mysql> show variables like 'log_bin%'; +---------------------------------+--------------------------------+ | Variable_name | Value | +---------------------------------+--------------------------------+ | log_bin | ON | | log_bin_basename | /var/log/mysql/mysql-bin | | log_bin_index | /var/log/mysql/mysql-bin.index | | log_bin_trust_function_creators | OFF | | log_bin_use_v1_row_events | OFF | +---------------------------------+--------------------------------+ 5 rows in set (0.00 sec) 如果log_bin为OFF则未开启，ON则为已开启。另外有两个重要的信息： log_bin_basename：binlog存储的文件基础名称，完整的日志文件后缀会递增为形如0000x的格式，例如mysql-bin.00001 log_bin_index: binlog索引文件的名称，该文件存储了所有的binlog日志文件的位置 ...

容器的数据管理有两种方式： 数据卷（Data Volumes）：容器内数据直接映射到本地主机环境 数据卷容器（Data Volume Containers）：使用特定容器维护数据卷 1. 数据卷 数据卷是一个可供容器使用的特殊目录，将主机的目录映射进容器，类似于Linux中的mount行为。 特点： 可在容器间共享和重用，容器间传输数据变得高效 对数据卷内数据的修改会立即生效，容器和本地操作都可以 数据卷的更新不会影响镜像，应用和数据解耦 卷会一直存在，直到没有容器使用，就可以安全地卸载它 1.1. 数据卷管理 volume命令： root@ubuntu:~# docker volume --help Usage: docker volume COMMAND Manage volumes Commands: create Create a volume inspect Display detailed information on one or more volumes ls List volumes prune Remove all unused local volumes rm Remove one or more volumes 1.1.1. 创建数据卷 docker volume create -d local test 数据卷创建后存放在/var/lib/docker/volumes下。e.g. root@ubuntu:~# docker volume create -d local test test root@ubuntu:~# cd /var/lib/docker root@ubuntu:/var/lib/docker# ls builder buildkit containers image network overlay2 plugins runtimes swarm tmp trust volumes root@ubuntu:/var/lib/docker# cd volumes/ root@ubuntu:/var/lib/docker/volumes# ls metadata.db test root@ubuntu:/var/lib/docker/volumes# cd test/ root@ubuntu:/var/lib/docker/volumes/test# ls _data root@ubuntu:/var/lib/docker/volumes/test# ...

docker 仓库的概念与java的maven仓库非常类似，它们都用来存储数据，maven仓库存储的是 jar 包，docker 仓库存储的是镜像。许多第三方私有仓库工具如 nexus 既可以构建 maven 仓库，也支持 docker 仓库。 1. 镜像仓库和注册表 1.1. Registry 镜像注册表，用来存储镜像数据的地方，官方的Docker hub就是一个公共的Registry，另外，还可以通过官方的registry镜像搭建私有的镜像注册表。通常所说的镜像仓库是泛指Registry，但并不完全准确，一个Registry可以包含多个Repository。 例如，拉取镜像：docker pull registry.hub.docker.com/ubuntu:18.04，这里的registry.hub.docker.com就是官方提供的镜像注册表，可以省略不写。 1.2. Repository 镜像库，包含多个镜像，存储于Registry中。在仓库搜索镜像时，按名称搜索在registry中查找repository。例如，我们所说的nginx镜像，一般就是指的nginx的Repository，它包含多个nginx镜像，它们通过tag来区分。 镜像的类别： 根镜像：Docker官方提供的基础镜像，单名字，如centos、ubuntu等 用户的镜像：由docker用户创建并维护的镜像，带有用户名前缀，表明是某用户下的仓库，例如：ansible/centos7-ansible，belonk/mynginx等 第三方镜像市场：阿里云、腾讯云、网易云等等 2. 搭建本地私有仓库 执行如下命令： docker run -d -p 5000:5000 registry:2 它会下载并启动一个registry容器，registry对应的是仓库镜像，版本为2。 上传镜像到本地私有仓库： 标记镜像: docker tag ubuntu IP:端口/镜像 上传镜像: docker push IP:端口/镜像 3. 基本操作 登录Docker hub Docker Hub是官方的公共镜像仓库，注册账号，然后在命令行进行登录： docker login 输入账号和密码登录即可，登录信息保存在 ~/.docker/config.json 下载镜像 docker [image] pull 搜索镜像 docker search IMAGE 上传镜像 docker [image] push [REGISTRY_HOST[:REGISTRY_PORT] / ]NAME[:TAG] ...

前一篇我们介绍了Docker的核心概念–镜像，知道了镜像是只读的创建容器的指令模板，由不同的层组成，也提到了镜像运行后就成为了容器，容器启动后回家镜像上增加一个可写的容器层，容器和镜像最主要的区别就在于容器层，容器层可读写，新写入或者修改的数据都存储在容器层上。在本篇，我们再来详细了解一下Docker的容器。 1. 简介 容器是镜像的可运行实例。您可以使用Docker API或CLI创建，启动，停止，移动或删除容器。您可以将容器连接到一个或多个网络，附加存储，甚至可以根据其当前状态创建新镜像。默认情况下，容器与其他容器及其主机相对隔离。您可以控制容器的网络，存储或其他基础子系统与其他容器或主机的隔离程度。容器由其镜像以及在创建或启动时为其提供的配置选项定义。删除容器后，其未持久存储的状态数据都将消失。 简单而言，容器可以看作是一个或一组独立运行的应用，以及这些应用必须的运行环境的一个整体。镜像是只读的，而容器则是在镜像上层添加了一个可写的容器层，镜像运行的实例就是容器。容器都有唯一的CONTAINER ID和名称(NAME)，还包括该容器对应的镜像(IMAGE)、状态(STATUS)等属性，另外，容器可以被创建、启动、停止和删除。 例如，ubuntu是一个镜像，运行后，就得到了容器，多次运行则得到多个容器。 2. 容器操作 现在我们看看操作容器的一些基本命令。 2.1. 查看容器 查看容器列表 1、命令 docker container ls [OPTIONS] 改命令等同于： docker ps [OPTIONS] 选项： -a, --all：显示所有的容器（不加此选项则仅显示运行中的） -f, --filter：按照条件过滤查询 --format string: 格式化输出信息 -n, --last int: 仅显示最后的n个容器(所有状态) -l, --latest: 仅显示最近创建的容器(所有状态) --no-trunc: 不截断输出信息 -q, --quiet: 仅输出容器id -s, --size: 设置显示的总数 2、举例 查看本机运行的容器： root@ubuntu:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1dd6cb8df75d ubuntu "/bin/bash" 24 hours ago Up 24 hours dbdata2 d428c1240bc8 ubuntu "/bin/bash" 25 hours ago Up 25 hours db2 2442cb173404 ubuntu "/bin/bash" 25 hours ago Up 25 hours db1 db3ac83e2531 ubuntu "/bin/bash" 26 hours ago Up 25 hours dbdata ...

上一篇介绍了如何在Windows、macOS、Ubuntu上安装docker，安装完成后，我们将开始正式学习docker。Docker的三大核心概念分为是：镜像、容器和仓库，在本篇，我们将介绍第一个核心概念----镜像。 1. 简介 Docker镜像(Image)，一个镜像是一个只读的用于创建docker容器(container)的指令模板，包括了程序运行所需的全部依赖包（包括程序、库、资源、配置等）。通常，镜像基于另一个镜像，并进行自定义。镜像是只读的、可运行的，运行后的镜像即为容器（Container）。 1.1. 镜像的几个概念 通过docker images查询本地的镜像列表时，可以看到镜像有REPOSITORY、ID、TAG等字段，镜像包含几个概念，首先需要弄清楚它们间的关系： Registry 镜像注册表，用来存储镜像数据的地方，官方的Docker hub就是一个公共的Registry，另外，还可以通过官方的registry镜像搭建私有的镜像注册表。通常所说的镜像仓库是泛指Registry，但并不完全准确，一个Registry可以包含多个Repository。 例如，拉取镜像：docker pull registry.hub.docker.com/ubuntu:18.04，这里的registry.hub.docker.com就是官方提供的镜像注册表，可以省略不写。 Repository 镜像库，包含多个镜像，存储于Registry中。在仓库搜索镜像时，按名称搜索在registry中查找repository。例如，我们所说的nginx镜像，一般就是指的nginx的Repository，它包含多个nginx镜像，它们通过tag来区分。 Tag 镜像的标签，一般用来作为版本区分，默认不写Tag为latest，一个Image有多个Tag。 Image 具体的镜像，有唯一的GUID和多个Tag。 简单而言，一个Registry包含多个Repository，每个Repository包含多个Image，每个Image有多个Tag，但是ID是唯一的。 1.2. 镜像层 镜像由不同的层（layer）组成。一般而言，Dockerfile每一个指令都会创建一个层，每层只是与之前图层的一组差异，它们都有自己的GUID，并且堆叠在彼此之上。当创建新容器时，将会在基础层的顶部添加新的可写层，称为“容器层”，对正在运行的容器所做的所有更改（例如，写入新文件、修改现有文件和删除文件）都将写入此可写容器层。 Figure 1. 镜像层示意 以镜像ubuntu15.04为例，运行一个容器，下图展示了其基本结构： Figure 2. 基于ubuntu15.04镜像的容器结构 上图展示了一个容器层（container layer）和镜像的多个镜像层（image layer）。其实，容器和镜像最主要的区别就在于容器层，容器层可读写，新写入或者修改的数据都存储在容器层上。基于同一镜像的不同容器都有自己的不同容器层，但是对于底层的各个镜像层，各个容器是共享的。当容器被删除后，只需删除该容器的容器层即可。可以看到，Docker通过层的设计极大地复用了资源，这也是docker轻量和快速的主要原因。 Figure 3. 基于ubuntu15.04镜像创建的多个容器结构 2. 镜像基本操作 接下来，我们看看镜像的一些基本操作。 2.1. 拉取镜像 拉取镜像意思是从镜像的Registry中将镜像下载到本地，类似于Git的pull拉取代码，命令如下： docker image pull [OPTIONS] NAME[:TAG|@DIGEST] 选项包括： -a, --all-tags: 拉取镜像的所有标签 --disable-content-trust: 是否跳过镜像验证，默认为true 例如：docker pull registry.hub.docker.com/ubuntu:18.04 2.2. 镜像查询 1、查询列表 查询本地的所有镜像： docker image ls 等同于docker images，例如： root@ubuntu:~# docker images REPOSITORY TAG IMAGE ID CREATED SIZE local/mynginx latest 4d24e58d851d 26 hours ago 108MB python 1.0 22a7b6b93718 5 days ago 131MB nginx latest f68d6e55e065 2 weeks ago 109MB python 2.7-slim ca96bab3e2aa 5 weeks ago 120MB hello-world latest fce289e99eb9 6 months ago 1.84kB ubuntu 14.10 a8a2ba3ce1a3 4 years ago 194MB ...

在上一篇 Docker简介中，我们介绍了Docker的概念、优势以及Docker结构，也提到了Docker是基于Linux系统的cgroup技术实现的，既然如此，那么Docker是否支持非Linux系统上使用呢？答案是肯定的。Docker官方提供了Docker Machine工具，用于在非Linux系统上构建虚拟机并在其上安装Docker；Docker官方还提供了Docker Toolbox工具包，用来在旧版本的操作系统上安装Docker；另外，Docker还专门针对Windows和Mac OS，提供了更简单易用的Docker Desktop，用来一键安装Docker及其相关组件。\n 在本篇，我们将来看看如何在Linux、Mac OS和Windows上安装Docker。\n 本篇安装的docker版本在最新的18.09版本，后续的docker入门系列文章都是基于该版本。 1. Ubuntu上安装Docker 1.1. 系统要求 Docker要求安装与64位的Ubuntu，版本要求如下： Cosmic 18.10 Bionic 18.04 (LTS) Xenial 16.04 (LTS) Docker支持的架构包括：x86_64 (或amd64), armhf, arm64, s390x (IBM Z), and ppc64le (IBM Power)。 测试Linux服务器为Ubuntu，版本为16.04，Ubuntu发布代码为xenial，其他版本的Linux就不做实践了： root@ubuntu:~# cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" 1.2. 准备工作 1、卸载旧版本 如果原来安装过旧版本的docker，需要先卸载之： $ sudo apt-get remove docker docker-engine docker.io containerd runc 旧版本的docker在Ubuntu的镜像仓库中名为docker.io，docker-io包是Debian/Ubuntu用于官方docker发布的名称，不叫docker的原因在于，避免与Ubuntu的docker system-tray二进制文件发生名称冲突。在新版本的docker中，docker已经区分为docker-ce和docker-ee版本，在安装新版本的docker时，需要先卸载旧版本docker。 2、添加仓库地址 安装前，需要先将docker官方安装地址加入到Ubuntu apt地址库中。 （1）更新package索引 apt-get update ...

1. 简介 容器化技术，是对Linux容器的一种封装，将程序打包为镜像文件，运行该文件创建容器，最终达到使用容器进行快速、简单、高效的开发、部署、运行软件程序的目的。相对于虚拟化技术 [1]，容器化技术有着更高的资源利用率、更高的性能、更低的开发和维护成本。 容器化技术有以下特点： 灵活性：绝大部分应用程序都可以使用容器化技术进行开发和运维，并且可及时部署和更新应用 轻量级：共享宿主机内核资源，仅将程序和其依赖打包到镜像文件，运行于容器，占用资源少、性能高 可移植：一次构建，到处运行；本地一次构建，然后可部署到各个平台或云端docker环境中，强移植性 可扩展：可以自定义镜像文件，扩展功能满足不同需要 可堆叠：您可以垂直和即时堆叠服务 Docker就是一种容器化技术。 Docker是一个开发、运输和运行应用程序的开放平台，基于Linux内核的 cgroup [2] 技术实现，根据开源Apache 2.0许可证授权。使用Docker，您可以将应用程序与基础架构分离，以便快速交付软件，并且像管理应用程序一样管理基础架构。通过Docker快速发布、测试和部署代码，可以显着减少编码和部署程序的工作量，大大提高工作效率。 Figure 1. Docker场景示意图 1.1. 容器和虚拟机 容器运行在宿主机并且和其他容器共享宿主机内核资源，运行于独立的进程，不消耗更多内存及CPU资源，这使得容器很轻量级。 虚拟机也是运行在宿主机上，但是虚拟机有自己完全独立的操作系统，通过虚拟管理程序与宿主机交换资源，各个虚拟机共用宿主机的资源很少，导致虚拟机占用资源高、资源利用率低。 Figure 2. docker容器化技术结构 Figure 3. 虚拟化技术结构 如图2所示，Docker下层是其基础服务层，上层是docker容器，多个容器之间相互隔离，docker共享宿主机(Host OS)的系统资源。 而虚拟化技术结构如图3所示，底层是hypervisor [3] 层，用来协调多个虚拟机(VM)和宿主机(物理机)的资源共享，上层的多个虚拟机都有单独的操作系统，他们之间不进行资源共享。 不难看出，虚拟机提供给运行其上的程序过量的资源，资源利用不充分，性能低；而容器技术，很好的解决了这一问题。 1.2. Docker可以做什么 1、快速，一致地交付您的应用程序 Docker允许开发人员使用提供应用程序和服务的本地容器在标准化环境中工作，从而简化了开发生命周期。容器非常适合持续集成和持续交付（CI / CD）工作流程。 2、响应式部署和扩展 Docker基于容器的平台允许高度可移植的工作负载。Docker容器可以在开发人员的本地笔记本电脑，数据中心的物理或虚拟机，云提供商或混合环境中运行。 Docker的可移植性和轻量级特性还使得可以轻松地动态管理工作负载，按照业务需求即时扩展或拆除应用程序和服务。 3、在同一硬件上运行更多工作负载 Docker轻巧而快速。它为基于管理程序的虚拟机提供了一种可行且经济高效的替代方案，因此您可以使用更多的计算容量来实现业务目标。Docker非常适合高密度环境以及需要用更少资源完成更多工作的中小型应用部署，譬如现非常流行的微服务架构。 2. Docker核心概念 Docker有三大核心概念，分别是镜像、容器和仓库。 Docker镜像 Docker镜像(Image)，一个镜像是一个只读的用于创建docker容器(container)的指令模板。通常，镜像基于另一个镜像，并进行自定义。一般而言，通过定义Dockerfile文件来创建镜像。 Docker容器 Docker容器(Container)，容器是镜像的运行实例，Docker的容器间是相互隔离的，可以将容器看做是简化版的Linux系统和运行在其中的应用打包而成的沙箱。您可以使用Docker API或CLI创建、启动、停止、移动或删除容器，也可以将容器连接到一个或多个网络，附加数据卷，甚至可以根据其当前状态创建新镜像。 Docker仓库 Docker仓库指的是镜像文件存储的地方。Docker还有一个镜像注册表(Registry)的概念，它是存放镜像仓库的地方，有许多的仓库存放于其中。仓库有公共仓库和私有仓库之分，最大的公共仓库是Docker hub，用户也可以搭建自有的私有镜像仓库。用户创建了镜像过后，通过push命令将其推送到镜像仓库中，使用时再从镜像仓库pull到本地运行，这设计类似于Git的代码仓库。 3. Docker结构 Figure 4. docker的整体结构 Docker整体结构如图4所示。一般而言，我们所说的docker，均指docker引擎(Docker Engine)。 3.1. Docker引擎 Docker Engine是一个客户端 - 服务器架构的应用程序，我们常说的docker指的就是docker engine，它包含以下主要组件： 服务器，是一种长时间运行的程序，称为守护进程（ dockerd命令） REST API，程序与守护进程通信的接口 CLI，命令行界面，即docker客户端（docker命令），负责接收用户指令并通过REST API请求守护程序，完成与守护进程交互 ...

RabbitMQ有用一套专门的权限控制系统，用来控制不同用户对不同虚拟主机的访问控制。基本思路同大多系统一样：先创建用户，然后为用户授予权限。 大多数系统并没有严格区分认证和鉴权，但是在RabbitMQ中，对这两个概念做了明确的区分： 认证：识别用户身份，即：识别当前用户，认证其身份信息 鉴权：明确了用户身份，那么授权就是要检查该用户是否拥有相应的权限，即：检查授予用户的权限 1. 虚拟主机和guest用户 在 RabbitMQ基础（七）----虚拟主机vhost一篇，我们已经详细介绍了虚拟主机。我们说过，首次安装好RabbitMQ时，会拥有一个默认的虚拟主机“/”。同时，还有一个默认的用户“guest”，密码也为“guest”，该用户有用默认虚拟主机的全部权限。 如果你得RabbitMQ需要公网访问，出于安全性考虑，官方建议删掉该用户或者修改其密码。默认情况下，RabbitMQ禁止guest用户远程访问，只可以访问本地的mq服务。这个是通过loopback_users配置项决定的，如果需要取消该限制，仅需将该选项配置为none即可： loopback_users = none 如果是3.7之前的版本，还不支持这样key=value的配置格式，那么你需要配置成这样： ``[{rabbit, [{loopback_users, []}]}].`` 该配置想的意思是，取消所有用户的本地访问限制。按照 官方的示例配置文件，如果仅需要取消guest用户本地访问限制，那么进行以下配置： loopback_users.guest = false 否则设置为true即可。 关于MQ的配置文件，我们将在后续博文中详细讨论，官方文档见 这里。 2. 权限工作机制 当客户端与服务端建立连接时，第一级权限控制将会执行：服务器会检查连接的用户是否有用访问其连接的虚拟主机的权限，没有则会拒绝连接，否则连接建立成功。 用户操作虚拟主机的资源（路由器、队列、绑定等）时，RabbitMQ会启用第二级权限控制，验证用户是否具有访问虚拟机的资源的权限。 2.1. 权限定义 具体而言，在RabbitMQ中，对资源的操作定义了三种权限： 配置：创建和删除资源，或者改变它们的行为； 写：发布消息到资源； 读：从资源获取消息； 下表显示了对执行权限检查的所有AMQP命令所需的资源类型的权限： AMQP 0-9-1 Operation configure write read exchange.declare (passive=false) exchange exchange.declare (passive=true) exchange.declare (with AE) exchange exchange (AE) exchange exchange.delete exchange queue.declare (passive=false) queue queue.declare (passive=true) queue.declare (with DLX) queue exchange (DLX) queue queue.delete queue exchange.bind exchange (destination) exchange (source) exchange.unbind exchange (destination) exchange (source) queue.bind queue exchange queue.unbind queue exchange basic.publish exchange basic.get queue basic.consume queue queue.purge queue 说明： ...

在本篇，我们将在ubuntu上安装RabbitMQ，其他操作系统类似。 我们知道，RabbitMQ使用Erlang语言开发，所以需要先安装Erlang语言，在实践过程中，linux安装RabbitMQ还比较麻烦，涉及到很多依赖包的安装，官方的安装文档见 这里。 1. 正确的安装步骤 简单而言，正确的安装步骤如下： 1、安装erlang依赖包 wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb sudo dpkg -i erlang-solutions_1.0_all.deb 编辑/etc/apt/sources.list，添加以下地址的任意一个 deb https://packages.erlang-solutions.com/ubuntu trusty contrib deb https://packages.erlang-solutions.com/ubuntu saucy contrib deb https://packages.erlang-solutions.com/ubuntu precise contrib 然后执行： wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb sudo dpkg -i erlang-solutions_1.0_all.deb 2、安装erlang sudo apt-get update sudo apt-get install esl-erlang（或erlang） 3、下载RabbitMQ wget https://github.com/rabbitmq/rabbitmq-server/releases/download/v3.7.12/rabbitmq-server_3.7.12-1_all.deb 4、安装RabbitMQ依赖包 apt-get install socat get-get install init-system-helpers get-get install adduser get-get install logrotate 5、安装RabbitMQ dpkg -i rabbitmq-server_3.7.12-1_all.deb 具体我的安装流程以及遇到的问题记录如下： 2. 安装过程 2.1. 下载安装包 ubuntu系统基于debian，所以我们要下载官方给的deb安装包： wget https://dl.bintray.com/rabbitmq/all/rabbitmq-server/3.7.4/rabbitmq-server_3.7.4-1_all.deb 等待下载完成。 2.2. 尝试安装 下载安装后，尝试直接安装: ...

1. 简介 RabbitMQ是一个多租户系统：连接、交换器、队列、绑定、用户权限、策略和其他的东西都属于虚拟主机（virtual hosts，v_host），他们是整个RabbitMQ的逻辑分组。 虚拟主机类似于 Apache的虚拟主机和 Nginx的server块，最重要的区别是：Apache的虚拟主机通过配置文件定义，然而在RabbitMQ中，RabbitMQ只能通过rabbitmqctl控制台工具或者HTTP API来创建。 1.1. 逻辑和物理分隔 如果没有虚拟主机，当RabbitMQ中的数据越来越庞大，队列越来越多，随之而来的是令人头痛的管理问题，比如队列、交换器命名冲突，它们相互影响等等。虚拟主机能够解决这些问题，而不需要我们部署多个RabbitMQ来负责不同的业务。 虚拟主机提供了资源的逻辑分组和分隔，每一个虚拟主机本质上是mini版的RabbitMQ服务器，他们有用自己的连接、队列、绑定、交换器，更重要的是有用自己的权限机制，这有点类似服务器和运行在服务器上的虚拟机一样。 1.2. 客户端连接 通队列、交换器一样，虚拟主机必须定义名称。当AMQP 0-9-1的客户端连接到RabbitMQ时，需要指定虚拟主机名称，同时还需要提供用户名和密码，只有用户具有相关的权限才能建立连接（关于权限控制的详细信息可以看 这里）。 通常，一个虚拟主机的连接只能操作属于该虚拟主机的交换器、队列和绑定等等内容。但是，当客户端同时连接了多个虚拟主机时，可能产生多个虚拟主机内的交换器、队列相互连接的情况，这种情景典型的例子是虚拟主机处于不同的RabbitMQ集群或者同一个集群中， RabbitMQ Shovel plugin就是一个这种场景应用的实例。 1.3. 虚拟主机和STOMP、MQTT 同AMQP 0-9-1一样，STOMP协议也有虚拟主机的概念，具体参见 这里。 相反，MQTT并不支持虚拟主机，MQTT连接默认使用单一的RabbitMQ主机，有MQTT特定的约定和特性，使客户机能够连接到特定的虚拟主机，而无需修改任何客户端lib库。有关详细信息，请参阅 MQTT指南。 2. 虚拟主机管理 RabbitMQ包含一个默认的虚拟主机：“/”，我们默认操作的都是这个虚拟主机，其用户名和密码默认都是guest，为了安全起见我们应该修改其密码（后续文章将详细介绍权限管理）。 2.1. 查询 命令： rabbitmqctl list_vhosts 该命令会查询当前RabbitMQ服务中所有的虚拟机，由于我没有创建任何虚拟机，所以只能看到默认的： rabbitmqctl list_vhosts 2.2. 创建 命令： rabbitmqctl list_vhosts 创建时必须指定名称： rabbitmqctl list_vhosts 创建完成后，查询： rabbitmqctl list_vhosts 可以看到刚创建的虚拟主机。 2.3. 删除 命令： rabbitmqctl list_vhosts 同样必须指定要删除的vhost的名称： rabbitmqctl list_vhosts 查询： rabbitmqctl list_vhosts ...

第二篇中我们学习了如何在多个worker中使用工作队列来分配耗时的任务。现在，假设我们需要运行一个远程计算机上的一个方法并等待其返回结果，那么我们怎么实现？通常，这个过程被称为RPC（远程过程调用Remote Procedure Call）。 百度百科对RPC的介绍： RPC（Remote Procedure Call）--远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。 RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。 有多种 RPC模式和执行。最初由 Sun 公司提出。IETF ONC 宪章重新修订了 Sun 版本，使得 ONC RPC 协议成为 IETF 标准协议。现在使用最普遍的模式和执行是开放式软件基础的分布式计算环境（DCE）。 这里我们不过多讨论RPC相关的内容，有兴趣的可以查阅相关资料。 现在，我们将要使用RabbitMQ来构建一个RPC系统，包括可扩展的RPC客户端和服务端。由于我们并没有耗时的任务，所以们将模拟一些RPC服务。 1. Message properties Message properties即消息属性，AMQP-0-9-1预定义了14项消息属性，但是大部分都很少使用，常用的属性有如下几项： deliveryMode：标记消息是否持久化，值为2则持久化，其他为瞬态消息； contentType：描述编码的mime类型（mime-type），例如常用的JSON编码格式：application/json； replyTo：命名回调队列 correlationId：用于关联RPC的请求和响应 接下来，我们看看如何通过消息属性来设置回调队列和关联ID（correlationId）。 2. 回调队列 通常，在RabbitMQ上实现RPC很简单，客户端发送消息，而服务端响应消息即可。为了接收响应信息，客户端需要在请求中发送回调队列地址给服务端，告诉服务端我使用这个队列来接收消息，你将返回消息发送到这个队列即可。我们可以使用默认的队列（在java客户端中是独占的）。 callbackQueueName = channel.queueDeclare().getQueue(); BasicProperties props = new BasicProperties .Builder() .replyTo(callbackQueueName) .build(); channel.basicPublish("", "rpc_queue", props, message.getBytes()); 3. Correlation Id 上边的方法中，我们为每一个RPC客户端创建了回调队列，这是非常低效的。有没有更好的方式：为每一个客户端创建一个共享的回调队列？这样势必又带来新的问题：共享一个回调队列，请求和响应之间的对应关系并不明确。 CorrelationId属性解决了这个问题。 大致思路是这样：为每个请求设置一个 唯一的标识，然后通过回调队列接收响应消息时，获取这个唯一标识，如果这个标识和之前设定的相同，那么说明响应的确是当前请求的响应，可以获取请求的响应结果了。如果获取到的唯一标示并非我们所设定，说明它并不属于我们的任何请求，那么就可以丢弃这个消息。 为什么我们应该忽略回调队列中的未知消息，而不是进行失败处理?这是由于服务器端可能出现竞态条件。可能发生这样的情况，RPC服务器发送了响应消息后挂掉了，但是请求确认消息(ack)还没有发送，那么，重启后的RPC服务器将再次处理请求。这就是为什么在客户端我们必须优雅地处理重复的响应，保持RPC的幂等性。 消息定义correlationId代码： // 设置消息属性，响应后发送到回调队列中 final String correlationId = UUID.randomUUID().toString(); // 随机生成唯一标识 AMQP.BasicProperties properties = new AMQP.BasicProperties().builder() .correlationId(correlationId) // 每次请求都设定唯一标识，该标识用于将请求和响应进行匹配 .replyTo(callbackQueueName) // 回调队列 .build(); ...

在上一篇，我们将日志系统做了改造，按照日志级别进行消息路由。我们还认识了direct类型的交换器，它是直接按照bindingKey与routingKey进行精确匹配，这两者分别在队列绑定和消息发送时进行设置。 Direct交换器每次仅能匹配一个精确的条件（bindingKey），如果要实现按照多个条件进行路由，或者按照条件进行模糊匹配，那么它就无能为力了。例如：前一篇你的日志程序，我们既要按照日志级别进行采集，还要根据打印日志的类来进行过滤，使用direct或者fanout都难以实现。 Topic交换器就是专门来处理这种场景的。在本篇，我们不再使用日志的例子，而是以动物为例，来了解topic交换器。 1. Topic交换器 发送到topic交换器的消息所设定的routingKey必须是一系列的单词列表，他们使用"."分隔。通常，这些单词会根据消息内容进行特殊定义，最大长度为255字节，举例：“stock.usd.nyse”、"syse.vmw"、"quick.range.rabbit"。 BindingKey也必须拥有相同的格式和遵循相同的规则。topic交换器和direct交换器处理逻辑上类似：带有特定routingKey的消息将被分发到绑定了匹配bindingKey的所有队列。但是，bindingKey还有两种特殊的通配符： *：能够模糊匹配一个单词 #：能够模糊匹配零个或多个单词 简单而言，topic交换器能够将消息的routingKey和队列绑定的bindingKey进行模糊匹配。如果不使用上边的两种通配符，那么topic交换器跟direct交换器没什么区别。 通配符举例： *.test.*：仅能匹配中间为test的三个单词的routingKey，例如mq.test.topic。 lazy.#：能够匹配以lazy开头的所有routingKey，单词个数不限，例如：lazy能匹配，lazy.test也能匹配 2. 示例 现在，我们来编写一个能够按照动物信息进行消息分发的程序。我们从速度、颜色和种类三个维度来描述动物信息，这里我们的key也是由这三个词语的具体描述组成，格式为“速度.颜色.种类”整体结构大致如下： 首选创建了一个类型为topic的交换器；然后我们定义了三个key，用于绑定到Q1和Q2两个队列，Q1绑定的key为*.orange.，Q2绑定的key为..rabbit和lazy.；消费者C1希望从Q1获取消息，而C2则希望从Q2获取消息。 整个程序的含义如下： 1、C1对颜色为orange（橙色）的动物感兴趣，希望获取它们的信息； 2、C2除了希望接收物种为rabbit（兔子）的消息外，还希望订阅速度为lazy（缓慢）的所有动物的信息。 很明显，C1、C2获取到的消息肯定存在重复的，它们接收消息的维度不同。 2.1. 生产者 创建交换器 // 创建交换器 channel.exchangeDeclare(exchangeName, "topic"); 模拟数据 String[] msgs = { "quick.orange.rabbit", "lazy.orange.elephant", "lazy.brown.fox", // 能匹配 "lazy.black.male.cat", // 四个单词也可以匹配 "orange", "quick.orange.male.rabbit" // 不能匹配，消息被丢弃 }; 发送消息 for (String msg : msgs) { System.out.println("发送：" + msg); channel.basicPublish(exchangeName, msg, null, msg.getBytes("utf-8")); } 为了简便，我将消息内容直接作为routingKey。实际上，routingKey需要根据消息内容进行特殊定制。 2.2. 消费者 创建随机队列 ...

前一篇我们构建了一个简单的日志记录系统，能够广播日志消息到所有已绑定的接收者。但是这样有一定的局限性，我们能够按照一定的条件来进行日志分发呢？例如，按照日志级别来分发日志消息，某个消费者只收到error级别的日志？在本章，我们将实现这个功能。 1. Bindings 上一篇，绑定队列的代码如下： channel.queueBind(queueName, EXCHANGE_NAME, ""); 第三个参数为routingKey，为了便于区分消息发送时的routingKey，我们将队列绑定的routingKey称为bindingKey。 BindingKey允许在队列绑定时设置额外的条件，路由器会按照这个key与消息的routingKey进行条件匹配，成功匹配的消息才会发送到该绑定队列。这个路由器按照bindingKey进行过滤的过程，我们称为消息路由（Routing）。 不同类型的交换器，bindingKey的作用和规则都有所不同。在fanout类型中，bindingKey会被忽略，因为这个交换器类型本身就是为了用于广播消息。在接下来我们要介绍的direct类型的交换器中，设定bindingKey的值有着重要意义。 2. Direct交换器 现在我们对上一篇的日志系统进行扩展，使其可以根据日志的级别进行过滤，假设我们的日志级别有debug、info、warning和error，我们想把error级别的消息单独使用一个消费者来接收，其他的由另外的消费者接收。 上篇中，我们使用的fanout交换器并不能满足上述需求----因为它只会把消息进行简单地广播。 我们将要用到的是 direct类型的交换器，它会按照绑定时给定的bindingKey与消息发布时的routingKey进行 精确匹配。即：当bindingKey与routingKey完成相同时，消息才会被交换器分发给队列。 在开始改造我们的日志程序前，我们先看看多重绑定。 3. 多重绑定 多重绑定，即将相同的bindingKey绑定到多个队列上。RabbitMQ允许这么做，这样与fanout交换器作用类似，可以将消息发送到多个队列。例如： 如图所示，Q1和Q2队列都绑定了black key，那么所有与black匹配的消息都会分发到Q1和Q2中，看起来与消息广播类似。 4. 程序改造 现在，我们开始来改造我们的日志程序，来实现上述的需求。 4.1. 生产者 创建direct类型的交换器： // 创建direct交换器 channel.exchangeDeclare(EXCHANGE_NAME, "direct"); 准备日志数据： static Log[] logs = { new Log("error", "this is an error log."), new Log("error", "this is an error log."), new Log("error", "this is an error log."), new Log("error", "this is an error log."), new Log("warning", "this is a warning log."), new Log("info", "this is an info log."), new Log("info", "this is an info log."), new Log("info", "this is an info log."), new Log("debug", "this is a debug log."), new Log("debug", "this is a debug log.") }; ...

前一篇，我们创建了工作队列，并将任务发布到队列，每一项任务都会发送给一个worker。接下来，我们将使用发布/订阅模式，将消息分发给多个消费者。 为了说明这一模式，我们将构建一个简单的日志记录系统。它将由两个程序组成----第一个将发出日志消息（生产者），第二个将接收并打印它们（消费者）。运行多个消费者，它们都可以接收消息。 1. 交换器 前边的部分我们都是通过消息队列来发布和接收消息，现在让我们看下RabbitMQ的全消息模型。让我们快速回顾一下 前边的内容： producer：用来发送消息 queue：用来缓存消息 consumer：用来接收消息 交换器，即Exchange，交换器是消息到达的第一站，所有的消息都先发送给交换器，交换器再按照不同的规则进行消息分发。RabbitMQ中的消息传递模型的核心思想是，生产者不会直接向队列发送任何消息。实际上，生产者甚至不知道消息是否会被传递到任何队列。相反，生产者只能发送消息给交换器。 交换器做的事情非常简单：一方面，它接收来自生产者的消息，另一边则将消息推送到队列中。交换器必须知道如何处理它接收到的消息。是否应该分发到特定的队列？是否应该分发到多个队列？或者应该被抛弃？其实，这些规则是由交换类型(exchange type)定义的。 交换类型：根据交换器的功能、用途和适用场景，将交换器进行类型定义，每种类型有各自的功能和适用场景。常见的交换类型有：direct、topic、headers、fanout。 接下来，我们学习下fanout类型的交换器。 fanout：将接收到的消息分发到所有能匹配的队列（广播）。简单而言，即：所有订阅了这些消息的队列，都能够收到消息。 创建名为logs的交换器，其类型为fanout： channel.exchangeDeclare("logs", "fanout"); 发送消息： String message = "中文日志信息"; channel.basicPublish("logs", "", null, message.getBytes("utf-8")); 注意，上边的代码队列名称为空。 2. 临时队列 对于队列，很重要的一点是，我们需要为其命名，因为生产者和消费者必须通过队列名称来定位到具体的队列，从中发送和获取消息（前几篇的"hello"队列和"task_queue"队列名称）。上边发送消息的代码中，我们并没有给队列命名，而是使用了""。 对于我们的日志记录系统，如果要每个消费者都能获取所有的日志消息，那么我们必须完成两点： 连接到RabbitMQ时，我们需要创建一个全新的队列，里边没有任何消息； 当消费者与RabbitMQ断开连接，那么队列应该被自动删除。 对于第1点，我们可以利用随机值来命名队列；对于第2点，我们只能检测断开连接后删除队列。但是，这都不是很好的做法。 其实，我们要做的是创建一个非持久的、独占的、自动删除的队列，这个队列的名称随机。RabbitMQ已经为我们提供了这个功能： String queueName = channel.queueDeclare().getQueue(); 如上边代码所示，我们创建了一个默认的队列，这队列具有上述特性，并且名称是随机生成的，格式为amq.gen-xxxx，例如amq.gen-JzTY20BRgKO-HjmUJj0wLg，我们称之为临时队列。 关键队列的非持久、独占和自动删除： 非持久（non-durable）：队列中的消息不会持久化 独占（exclusive）：队列为私有队列，只有当前应用程序能够消费队列 自动删除（autodelete ）：最后一个消费者取消订阅队列时，队列自动删除 3. 绑定 本文开头，我们创建一个名称为"logs"、类型为"fanout"的交换器。那么，交换器需要分发消息给队列，如果将队列与交换器进行关联呢？我们把交换器和队列之间的关联关系称为绑定（binding）。 绑定的代码如下： channel.queueBind(queueName, "logs", ""); queueName即为前边创建的临时队列，第三个参数为routingKey，这里为空。 4. 完整代码 生产者LogSender： public static final String EXCHANGE_NAME = "logs"; public static void main(String[] args) throws IOException, TimeoutException { ConnectionFactory factory = new ConnectionFactory(); factory.setHost("localhost"); Connection connection = factory.newConnection(); Channel channel = connection.createChannel(); // 创建exchange channel.exchangeDeclare(EXCHANGE_NAME, "fanout"); // 分发消息 String message = "中文日志信息"; channel.basicPublish(EXCHANGE_NAME, "", null, message.getBytes("utf-8")); channel.close(); connection.close(); } ...

大批量同步数据到MySQL中，涉及到更新和新增数据，如果仅仅循环一次次插入，不仅耗费过多的网络开销，性能低下，而且频繁的获取数据库连接、操作数据库，增加数据库压力，甚至严重影响数据库性能。因此，此时我们需要批量操作，来减轻数据库压力，提升应用性能。 1. 数据准备 首先创建一张测试表，插入一些初始数据： CREATE TABLE `hello` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, `age` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8; INSERT INTO `test`.`hello` (`id`, `name`, `age`) VALUES ('1', 'zhangsan', '30'); INSERT INTO `test`.`hello` (`id`, `name`, `age`) VALUES ('2', 'lisi', '18'); INSERT INTO `test`.`hello` (`id`, `name`, `age`) VALUES ('3', 'wangwu', '22'); INSERT INTO `test`.`hello` (`id`, `name`, `age`) VALUES ('4', 'zhaoliu', '25'); ...

上一篇，我们编写了从一个指定的队列发送和接收消息的程序。在本文中，我们将创建一个工作队列，用于将耗时的任务分配给多个工作人员。 Work Queues，称为工作队列(也称Task Queues，任务队列)，其主旨在于避免立即执行资源密集型任务，并且必须等待它完成。相反，我们把任务安排在后来执行。对此，我们将任务封装为消息并将其发送到队列中。在后台运行的工作进程会获取任务并最终执行任务。当你运行许多工作进程时，任务将在他们之间共享。 1. 轮询调度 使用任务队列的优点之一是能够轻松地并行工作。如果我们积累了大量的工作，我们就可以增加更多的任务消费者，这样就可以很容易地扩大规模。默认情况下，RabbitMQ将依次将每个消息发送给下一个使用者。平均每个消费者将得到相同数量的消息，这种分发消息的方式称为轮询。 2. 消息确认 完成一项任务可能需要几秒钟。你可能会想，如果其中一个消费者开始了一项很长的任务，并且只完成了部分任务，会发生什么。使用我们当前的代码，一旦RabbitMQ向客户传递消息，它立即标记为删除。在这种情况下，如果你关闭一个工作进程，我们将失去它正在处理的信息。我们也将丢失所有发送给这个特定工作进程并且还未处理消息。 通常，我们希望一个工作进程挂掉后，将其任务交给其他工作进程完成。为了保证消息不丢失，RabbitMQ支持消息确认机制：当消费者处理完消息后，其反馈给RabbitMQ，表明消息已经被接收和处理，RabbitMQ可以自由删除该消息。 如果一个消费者挂掉(其通道关闭，连接关闭，或者TCP连接丢失)，而没有发送ack，RabbitMQ将会知道一条消息没有被完全处理，并且将重新排队。如果同时有其他的消费者在线，那么它将很快把消息重新交给另一个消费者处理，这样就保证不会丢失任何信息。 消息不会超时：当消费者进程挂掉时，RabbitMQ将重新传递消息，即使处理消息需要很长时间。 RabbitMQ默认是开启手动消息确认的，我们可以通过autoAck=true标记明确地关闭，即采用系统自动确认消息。如果需要手动确认消息，那么将autoAck设置为false，一旦我们完成了任务，需要向工作进程发出确认消息，代码如下： // 处理完成，手动接收消息时，需要在处理成功后进行反馈，保证消息不丢失 channel.basicAck(envelope.getDeliveryTag(), false); 示例的部分关键代码如下： NewTask.java /** * 发布5条消息，每条消息的一个“.”表示消息执行时间需要1秒。 * * @param args * @throws IOException * @throws TimeoutException */ public static void main(String[] args) throws IOException, TimeoutException { ConnectionFactory factory = new ConnectionFactory(); factory.setHost("localhost"); Connection connection = factory.newConnection(); String[] msgs = new String[]{ "First Message.", // 1s "Second Message..", // 2s "Third Message...", // 3s "Fourth Message....", // 4s "Fifth Message....." // 5s }; Channel channel = connection.createChannel(); channel.queueDeclare(TASK_QUEUE_NAME, false, false, false, null); for (String msg : msgs) { // 发布消息 channel.basicPublish("", TASK_QUEUE_NAME, null, msg.getBytes("utf-8")); System.out.println("[x] Sent '" + msg + "'"); } channel.close(); connection.close(); } ...

1. 基本概念 RabbitMQ是一个消息代理，是一个erlang开发的AMQP（Advanced Message Queue ）的开源实现。 RabbitMQ是轻量级的，易于部署在premises和云中。它支持多种消息传递协议。RabbitMQ可以部署在分布式和联合配置中，以满足高级别、高可用性需求。 其主要思想非常简单:它接受并转发消息。你可以把它想象成邮局:当你把邮件寄到邮箱时，你很确定邮差先生最终会把邮件寄给你的收件人。使用这个比喻，RabbitMQ是一个邮筒，一个邮局和一个邮差。 RabbitMQ与邮局的主要区别在于，它不处理纸张，而是接受、存储和转发二进制数据。 官网地址： http://www.rabbitmq.com 2. AMQP AMQP，即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。Erlang中的实现有 RabbitMQ等。 目标是实现一种在全行业广泛使用的标准消息中间件技术，以便降低企业和系统集成的开销，并且向大众提供工业级的集成服务。通过AMQP，让消息中间件的能力最终被网络本身所具有，并且通过消息中间件的广泛使用发展出一系列有用的应用程序。 Broker: 中间件。接收和分发消息的应用，RabbitMQ Server就是Message Broker。 Virtual host: 虚拟主机。出于多租户和安全因素设计的，把AMQP的基本组件划分到一个虚拟的分组中，类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ server提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange／queue等。 Connection: 连接。publisher／consumer和broker之间的TCP连接。断开连接的操作只会在client端进行，Broker不会断开连接，除非出现网络故障或broker服务出现问题。 Channel: 渠道。如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP Connection的开销将是巨大的，效率也较低。Channel是在connection内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的channel进行通讯，AMQP method包含了channel id帮助客户端和message broker识别channel，所以channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。 Exchange: 路由。message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。 Queue: 队列。消息最终被送到这里等待consumer取走。一个message可以被同时拷贝到多个queue中。 Binding: 绑定。exchange和queue之间的虚拟连接，binding中可以包含routing key。Binding信息被保存到exchange中的查询表中，用于message的分发依据。 3. RabbitMQ术语 3.1. Producter 即生产者。Producing就是发送，发送消息的程序是生产者（Producter）。用P表示，如下图： 3.2. Exchange 交换器，RabbitMQ中，其实消息不会直接相队列发送，而是发送给交换器，然后交换器在按照一定的规则转发给不同的队列。交换器做的事情非常简单：一方面，它接收来自生产者的消息，另一边则将消息推送到队列中。交换必须知道如何处理它接收到的消息。是否应该附加到特定的队列?是否应该附加到许多队列?或者应该被抛弃。这些规则由交换类型(exchange type)定义。 3.3. Exchange Type 交换器类型，在创建交换器时指定，用于区分交换器的不同作用，实现不同的功能。RabbitMQ定义了四种交换器类型：direct、topic、headers、fanout，每种类型都有特定的应用场景（见后续文章的详细介绍）。 direct：bindingKey和routingKey进行精确匹配，适用于精确将消息发送给指定队列； topic：bindingKey和routingKey可以进行模糊匹配，通过使用通配符"*"和"#"分别来模糊匹配一个单词和多个单词；适用于将消息按照一定的规则发送到匹配的一个或多个队列； fanout：广播，这种交换器可以将消息广播给所有订阅的交换器； header：不常用，有兴趣的话可以自行了解。 3.4. Queue 即队列，队列是邮箱的名称，它处于RabbitMQ内部。尽管消息流通过RabbitMQ和您的应用程序，但它们只能存储在队列中。队列不受任何限制，它可以根据你的需要存储尽可能多的消息----它本质上是一个无限的缓冲区。许多生产者都可以发送消息到一个队列，许多消费者可以尝试从一个队列接收数据。队列上有它的名称，如下图表示： 3.5. Consumer 即消费者，Consuming跟receiving的含义类似。Consumer通常为等待接收消息的应用程序 。注意，生产者、消费者和消息代理不需要处于同一台主机上，事实上，在大多数应用场景都是如此。 ...

最近开发微信红包活动，并发量大概在100左右，数据库存储数据几十万条。活动上线后，遇到一个问题，服务启动起来后，在几分钟之内，服务变得很慢，通过分析tcp状态（ss -s）发现，处于timewait状态的TCP达到一千多个，然后从应用前台、后台到数据库逐步分析，最后发现，由于某一张表的数据量达到几十万，而某一个逻辑需要连接该表进行数据查询，导致SQL执行非常缓慢。于是整理下SQL慢查询分析的相关方法，以便查阅。 1. explain语句 explain命令在解决数据库性能上是第一推荐使用命令，大部分的性能问题可以通过此命令来简单的解决，explain可以用来查看 SQL 语句的执行效 果，可以帮助选择更好的索引和优化查询语句，写出更好的优化语句。 Explain语法： explain select … from … [where ...] 例如：explain select * from news; 输出： ---- ------------- ------- ------- ------------------- --------- --------- ------- ------ ------- | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | ---- ------------- ------- ------- ------------------- --------- --------- ------- ------ ------- 下面对各个属性进行了解： 1、id：这是SELECT的查询序列号 2、select_type：select_type就是select的类型，可以有以下几种： SIMPLE：简单SELECT(不使用UNION或子查询等) PRIMARY：最外面的SELECT UNION：UNION中的第二个或后面的SELECT语句 DEPENDENT UNION：UNION中的第二个或后面的SELECT语句，取决于外面的查询 UNION RESULT：UNION的结果。 SUBQUERY：子查询中的第一个SELECT DEPENDENT SUBQUERY：子查询中的第一个SELECT，取决于外面的查询 DERIVED：导出表的SELECT(FROM子句的子查询) ...