0%

什么是事务?

事务是逻辑上的一组操作,要么都执行,要么都不执行。

事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账1000元,这个转账会涉及到两个关键操作就是:将小明的余额减少1000元,将小红的余额增加1000元。万一在这两个操作之间突然出现错误比如银行系统崩溃,导致小明余额减少而小红的余额没有增加,这样就不对了。事务就是保证这两个关键操作要么都成功,要么都要失败。

事物的特性(ACID)

  1. 原子性: 事务是最小的执行单位,不允许分割。事务的原子性确保动作要么全部完成,要么完全不起作用;
  2. 一致性: 执行事务前后,数据保持一致,多个事务对同一个数据读取的结果是相同的;
  3. 隔离性: 并发访问数据库时,一个用户的事务不被其他事务所干扰,各并发事务之间数据库是独立的;
  4. 持久性: 一个事务被提交之后。它对数据库中数据的改变是持久的,即使数据库发生故障也不应该对其有任何影响。

并发事务带来的问题

在典型的应用程序中,多个事务并发运行,经常会操作相同的数据来完成各自的任务(多个用户对统一数据进行操作)。并发虽然是必须的,但可能会导致以下的问题。

  • 脏读(Dirty read): 当一个事务正在访问数据并且对数据进行了修改,而这种修改还没有提交到数据库中,这时另外一个事务也访问了这个数据,然后使用了这个数据。因为这个数据是还没有提交的数据,那么另外一个事务读到的这个数据是“脏数据”,依据“脏数据”所做的操作可能是不正确的。
  • 丢失修改(Lost to modify): 指在一个事务读取一个数据时,另外一个事务也访问了该数据,那么在第一个事务中修改了这个数据后,第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失,因此称为丢失修改。 例如:事务1读取某表中的数据A=20,事务2也读取A=20,事务1修改A=A-1,事务2也修改A=A-1,最终结果A=19,事务1的修改被丢失。
  • 不可重复读(Unrepeatableread): 指在一个事务内多次读同一数据。在这个事务还没有结束时,另一个事务也访问该数据。那么,在第一个事务中的两次读数据之间,由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况,因此称为不可重复读。
  • 幻读(Phantom read): 幻读与不可重复读类似。它发生在一个事务(T1)读取了几行数据,接着另一个并发事务(T2)插入了一些数据时。在随后的查询中,第一个事务(T1)就会发现多了一些原本不存在的记录,就好像发生了幻觉一样,所以称为幻读。

不可重复度和幻读区别:

不可重复读的重点是修改,幻读的重点在于新增或者删除。

例1(同样的条件, 你读取过的数据, 再次读取出来发现值不一样了 ):事务1中的A先生读取自己的工资为 1000的操作还没完成,事务2中的B先生就修改了A的工资为2000,导 致A再读自己的工资时工资变为 2000;这就是不可重复读。

例2(同样的条件, 第1次和第2次读出来的记录数不一样 ):假某工资单表中工资大于3000的有4人,事务1读取了所有工资大于3000的人,共查到4条记录,这时事务2 又插入了一条工资大于3000的记录,事务1再次读取时查到的记录就变为了5条,这样就导致了幻读。

事务隔离级别

SQL 标准定义了四个隔离级别:

  • READ-UNCOMMITTED(读取未提交): 最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读
  • READ-COMMITTED(读取已提交): 允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生
  • REPEATABLE-READ(可重复读): 对同一字段的多次读取结果都是一致的,除非数据是被本身事务自己所修改,可以阻止脏读和不可重复读,但幻读仍有可能发生
  • SERIALIZABLE(可串行化): 最高的隔离级别,完全服从ACID的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读

隔离级别 脏读 不可重复读 幻影读
READ-UNCOMMITTED
READ-COMMITTED ×
REPEATABLE-READ × ×
SERIALIZABLE × × ×

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ(可重读)。我们可以通过SELECT @@tx_isolation;命令来查看

1
2
3
4
5
6
mysql> SELECT @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+

这里需要注意的是:与 SQL 标准不同的地方在于InnoDB 存储引擎在 REPEATABLE-READ(可重读)事务隔离级别下使用的是Next-Key Lock 锁算法,因此可以避免幻读的产生,这与其他数据库系统(如 SQL Server)是不同的。所以说InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ(可重读) 已经可以完全保证事务的隔离性要求,即达到了 SQL标准的SERIALIZABLE(可串行化)隔离级别。

因为隔离级别越低,事务请求的锁越少,所以大部分数据库系统的隔离级别都是READ-COMMITTED(读取提交内容):,但是你要知道的是InnoDB 存储引擎默认使用 REPEATABLE-READ(可重读)并不会有任何性能损失。

InnoDB 存储引擎在 分布式事务 的情况下一般会用到SERIALIZABLE(可串行化)隔离级别。

实际情况演示

在下面我会使用 2 个命令行mysql ,模拟多线程(多事务)对同一份数据的脏读问题。

MySQL 命令行的默认配置中事务都是自动提交的,即执行SQL语句后就会马上执行 COMMIT 操作。如果要显式地开启一个事务需要使用命令:START TARNSACTION

我们可以通过下面的命令来设置隔离级别。

1
SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL [READ UNCOMMITTED|READ COMMITTED|REPEATABLE READ|SERIALIZABLE]

我们再来看一下我们在下面实际操作中使用到的一些并发控制语句:

  • START TARNSACTION |BEGIN:显式地开启一个事务。
  • COMMIT:提交事务,使得对数据库做的所有修改成为永久性。
  • ROLLBACK:回滚会结束用户的事务,并撤销正在进行的所有未提交的修改。

脏读(读未提交)

避免脏读(读已提交)

不可重复读

还是刚才上面的读已提交的图,虽然避免了读未提交,但是却出现了,一个事务还没有结束,就发生了 不可重复读问题。

可重复读

防止幻读(可重复读)

一个事务对数据库进行操作,这种操作的范围是数据库的全部行,然后第二个事务也在对这个数据库操作,这种操作可以是插入一行记录或删除一行记录,那么第一个是事务就会觉得自己出现了幻觉,怎么还有没有处理的记录呢? 或者 怎么多处理了一行记录呢?

幻读和不可重复读有些相似之处 ,但是不可重复读的重点是修改,幻读的重点在于新增或者删除。

停机扩容(不推荐)

这个方案就跟停机迁移一样,步骤几乎一致,唯一的一点就是那个导数的工具,是把现有库表的数据抽出来慢慢倒入到新的库和表里去。但是最好别这么玩儿,有点不太靠谱,因为既然分库分表就说明数据量实在是太大了,可能多达几亿条,甚至几十亿,你这么玩儿,可能会出问题。

从单库单表迁移到分库分表的时候,数据量并不是很大,单表最大也就两三千万。那么你写个工具,多弄几台机器并行跑,1小时数据就导完了。这没有问题。

如果 3 个库 + 12 个表,跑了一段时间了,数据量都 1~2 亿了。光是导 2 亿数据,都要导个几个小时,6 点,刚刚导完数据,还要搞后续的修改配置,重启系统,测试验证,10 点才可以搞完。所以不能这么搞。

优化后的方案

一开始上来就是 32 个库,每个库 32 个表,那么总共是 1024 张表。

我可以告诉各位同学,这个分法,第一,基本上国内的互联网肯定都是够用了,第二,无论是并发支撑还是数据量支撑都没问题。

每个库正常承载的写入并发量是 1000,那么 32 个库就可以承载32 * 1000 = 32000 的写并发,如果每个库承载 1500 的写并发,32 * 1500 = 48000 的写并发,接近 5 万每秒的写入并发,前面再加一个MQ,削峰,每秒写入 MQ 8 万条数据,每秒消费 5 万条数据。

有些除非是国内排名非常靠前的这些公司,他们的最核心的系统的数据库,可能会出现几百台数据库的这么一个规模,128个库,256个库,512个库。

1024 张表,假设每个表放 500 万数据,在 MySQL 里可以放 50 亿条数据。

每秒 5 万的写并发,总共 50 亿条数据,对于国内大部分的互联网公司来说,其实一般来说都够了。

谈分库分表的扩容,第一次分库分表,就一次性给他分个够,32 个库,1024 张表,可能对大部分的中小型互联网公司来说,已经可以支撑好几年了。

一个实践是利用 32 * 32 来分库分表,即分为 32 个库,每个库里一个表分为 32 张表。一共就是 1024 张表。根据某个 id 先根据 32 取模路由到库,再根据 32 取模路由到库里的表。

orderId id % 32 (库) id / 32 % 32 (表)
259 3 8
1189 5 5
352 0 11
4593 17 15

刚开始的时候,这个库可能就是逻辑库,建在一个数据库上的,就是一个mysql服务器可能建了 n 个库,比如 32 个库。后面如果要拆分,就是不断在库和 mysql 服务器之间做迁移就可以了。然后系统配合改一下配置即可。

比如说最多可以扩展到32个数据库服务器,每个数据库服务器是一个库。如果还是不够?最多可以扩展到 1024 个数据库服务器,每个数据库服务器上面一个库一个表。因为最多是1024个表。

这么搞,是不用自己写代码做数据迁移的,都交给 dba 来搞好了,但是 dba 确实是需要做一些库表迁移的工作,但是总比你自己写代码,然后抽数据导数据来的效率高得多吧。

哪怕是要减少库的数量,也很简单,其实说白了就是按倍数缩容就可以了,然后修改一下路由规则。

这里对步骤做一个总结:

  1. 设定好几台数据库服务器,每台服务器上几个库,每个库多少个表,推荐是 32库 * 32表,对于大部分公司来说,可能几年都够了。
  2. 路由的规则,orderId 模 32 = 库,orderId / 32 模 32 = 表
  3. 扩容的时候,申请增加更多的数据库服务器,装好 mysql,呈倍数扩容,4 台服务器,扩到 8 台服务器,再到 16 台服务器。
  4. 由 dba 负责将原先数据库服务器的库,迁移到新的数据库服务器上去,库迁移是有一些便捷的工具的。
  5. 我们这边就是修改一下配置,调整迁移的库所在数据库服务器的地址。
  6. 重新发布系统,上线,原先的路由规则变都不用变,直接可以基于 n 倍的数据库服务器的资源,继续进行线上系统的提供服务。

镜像作为 Docker 三大核心概念中,最重要的一个关键词,它有很多操作,是您想学习容器技术不得不掌握的。本文将带您一步一步,图文并重,上手操作来学习它。

一 Docker 下载镜像

如果我们想要在本地运行容器,就必须保证本地存在对应的镜像。所以,第一步,我们需要下载镜像。当我们尝试下载镜像时,Docker 会尝试先从默认的镜像仓库(默认使用 Docker Hub 公共仓库)去下载,当然了,用户也可以自定义配置想要下载的镜像仓库。

1.1 下载镜像

镜像是运行容器的前提,我们可以使用 docker pull[IMAGE_NAME]:[TAG]命令来下载镜像,其中 IMAGE_NAME 表示的是镜像的名称,而 TAG 是镜像的标签,也就是说我们需要通过 “镜像 + 标签” 的方式来下载镜像。

注意: 您也可以不显式地指定 TAG, 它会默认下载 latest 标签,也就是下载仓库中最新版本的镜像。这里并不推荐您下载 latest 标签,因为该镜像的内容会跟踪镜像的最新版本,并随之变化,所以它是不稳定的。在生产环境中,可能会出现莫名其妙的 bug, 推荐您最好还是显示的指定具体的 TAG。

举个例子,如我们想要下载一个 Mysql 5.7 镜像,可以通过命令来下载:

1
docker pull mysql:5.7

会看到控制台输出内容如下:

Docker 下载镜像

注意: 由于官方 DockerHub 仓库服务器在国外,下载速度较慢,所以我将仓库的地址更改成了国内的 docker.io 的镜像仓库,所以在上图中,镜像前面会有 docker.io 出现。

当有 Downloaded 字符串输出的时候,说明下载成功了!!

1.2 验证

让我们来验证一下,本地是否存在 Mysql5.7 的镜像,运行命令:

1
docker images

验证本地镜像是否存在

可以看到本地的确存在该镜像,确实是下载成功了!

1.3 下载镜像相关细节

再说说上面下载镜像的过程:

Docker 镜像下载

通过下载过程,可以看到,一个镜像一般是由多个层( layer) 组成,类似 f7e2b70d04ae这样的串表示层的唯一 ID(实际上完整的 ID 包括了 256 个 bit, 64 个十六进制字符组成)。

您可能会想,如果多个不同的镜像中,同时包含了同一个层( layer),这样重复下载,岂不是导致了存储空间的浪费么?

实际上,Docker 并不会这么傻会去下载重复的层( layer),Docker 在下载之前,会去检测本地是否会有同样 ID 的层,如果本地已经存在了,就直接使用本地的就好了。

另一个问题,不同仓库中,可能也会存在镜像重名的情况发生, 这种情况咋办?

严格意义上,我们在使用 docker pull 命令时,还需要在镜像前面指定仓库地址( Registry), 如果不指定,则 Docker 会使用您默认配置的仓库地址。例如上面,由于我配置的是国内 docker.io 的仓库地址,我在 pull 的时候,docker 会默认为我加上 docker.io/library 的前缀。

如:当我执行 docker pull mysql:5.7 命令时,实际上相当于 docker pull docker.io/mysql:5.7,如果您未自定义配置仓库,则默认在下载的时候,会在镜像前面加上 DockerHub 的地址。

Docker 通过前缀地址的不同,来保证不同仓库中,重名镜像的唯一性。

1.4 PULL 子命令

命令行中输入:

1
docker pull --help

会得到如下信息:

1
2
3
4
[root@iZbp1j8y1bab0djl9gdp33Z ~]# docker pull --help
Usage: docker pull [OPTIONS] NAME[:TAG|@DIGEST]
Pull an image or a repository from a registry
Options: -a, --all-tags Download all tagged images in the repository --disable-content-trust Skip image verification (default true) --help Print usage

我们可以看到主要支持的子命令有:

  1. -a,--all-tags=true|false: 是否获取仓库中所有镜像,默认为否;
  2. --disable-content-trust: 跳过镜像内容的校验,默认为 true;

二 Docker 查看镜像信息

2.1 images 命令列出镜像

通过使用如下两个命令,列出本机已有的镜像:

1
docker images

或:

1
docker image ls

如下图所示:

Docker 查看镜像信息

对上述红色标注的字段做一下解释:

  • REPOSITORY: 来自于哪个仓库;
  • TAG: 镜像的标签信息,比如 5.7、latest 表示不同的版本信息;
  • IMAGE ID: 镜像的 ID, 如果您看到两个 ID 完全相同,那么实际上,它们指向的是同一个镜像,只是标签名称不同罢了;
  • CREATED: 镜像最后的更新时间;
  • SIZE: 镜像的大小,优秀的镜像一般体积都比较小,这也是我更倾向于使用轻量级的 alpine 版本的原因;

注意:图中的镜像大小信息只是逻辑上的大小信息,因为一个镜像是由多个镜像层( layer)组成的,而相同的镜像层本地只会存储一份,所以,真实情况下,占用的物理存储空间大小,可能会小于逻辑大小。

2.2 使用 tag 命令为镜像添加标签

通常情况下,为了方便在后续工作中,快速地找到某个镜像,我们可以使用 docker tag 命令,为本地镜像添加一个新的标签。如下图所示:

Docker tag 添加标签

docker.io/mysql 镜像,添加新的镜像标签 allen_mysql:5.7。然后使用 docker images 命令,查看本地镜像:

Docker tag 添加标签

可以看到,本地多了一个 allen_mysql:5.7 的镜像。细心的你一定还会发现, allen_mysql:5.7docker.io/mysql:5.7 的镜像 ID 是一模一样的,说明它们是同一个镜像,只是别名不同而已。

docker tag 命令功能更像是, 为指定镜像添加快捷方式一样。

2.3 使用 inspect 命令查看镜像详细信息

通过 docker inspect 命令,我们可以获取镜像的详细信息,其中,包括创建者,各层的数字摘要等。

1
docker inspect docker.io/mysql:5.7

Docker inspect 查看镜像详细信息

docker inspect 返回的是 JSON 格式的信息,如果您想获取其中指定的一项内容,可以通过 -f 来指定,如获取镜像大小:

1
docker inspect -f {{".Size"}} docker.io/mysql:5.7

Docker inspect 查看镜像详细信息

2.4 使用 history 命令查看镜像历史

前面的小节中,我们知道了,一个镜像是由多个层(layer)组成的,那么,我们要如何知道各个层的具体内容呢?

通过 docker history 命令,可以列出各个层(layer)的创建信息,如我们查看 docker.io/mysql:5.7 的各层信息:

1
docker history docker.io/mysql:5.7

Docker history 各层信息

可以看到,上面过长的信息,为了方便展示,后面都省略了,如果您想要看具体信息,可以通过添加 --no-trunc 选项,如下面命令:

1
docker history --no-trunc docker.io/mysql:5.7

三 Docker 搜索镜像

3.1 search 命令

您可以通过下面命令进行搜索:

1
docker search [option] keyword

比如,您想搜索仓库中 mysql 相关的镜像,可以输入如下命令:

1
docker search mysql

Docker 搜索镜像

3.2 search 子命令

命令行输入 docker search--help, 输出如下:

1
2
3
Usage:  docker search [OPTIONS] TERM
Search the Docker Hub for images
Options: -f, --filter filter Filter output based on conditions provided --help Print usage --limit int Max number of search results (default 25) --no-index Don't truncate output --no-trunc Don't truncate output

可以看到 search 支持的子命令有:

  • -f,--filter filter: 过滤输出的内容;
  • --limitint:指定搜索内容展示个数;
  • --no-index: 不截断输出内容;
  • --no-trunc:不截断输出内容;

举个列子,比如我们想搜索官方提供的 mysql 镜像,命令如下:

1
docker search --filter=is-offical=true mysql

Docker 搜索官方镜像

再比如,我们想搜索 Stars 数超过 100 的 mysql 镜像:

1
docker search --filter=stars=100 mysql

Docker 搜索镜像

四 Docker 删除镜像

4.1 通过标签删除镜像

通过如下两个都可以删除镜像:

1
docker rmi [image]

或者:

1
docker image rm [image]

支持的子命令如下:

  • -f,-force: 强制删除镜像,即便有容器引用该镜像;
  • -no-prune: 不要删除未带标签的父镜像;

Docker 查看镜像信息Docker 查看镜像信息

例如,我们想删除上章节创建的 allen_mysql:5.7 镜像,命令如下:

1
docker rmi allen_mysql:5.7

Docker 删除镜像

从上面章节中,我们知道 allen_mysql:5.7docker.io/mysql:5.7 实际上指向的是同一个镜像,那么,您可以能会有疑问,我删除了 allen_mysql:5.7, 会不会将 docker.io/mysql:5.7 镜像也给删除了?

实际上,当同一个镜像拥有多个标签时,执行 docker rmi 命令,只是会删除了该镜像众多标签中,您指定的标签而已,并不会影响原始的那个镜像文件。

不信的话,我们可以执行 docker images 命令,来看下 docker.io/mysql:5.7 镜像还在不在:

Docker 查看镜像信息

可以看到, docker.io/mysql:5.7 镜像依然存在!

那么,如果某个镜像不存在多个标签,当且仅当只有一个标签时,执行删除命令时,您就要小心了,这会彻底删除镜像。

例如,这个时候,我们再执行 docker rmi docker.io/mysql:5.7 命令:

Docker 删除镜像

从上图可以看到,我们已经删除了 docker.io/mysql:5.7 镜像的所有文件层。该镜像在本地已不复存在了!

4.2 通过 ID 删除镜像

除了通过标签名称来删除镜像,我们还可以通过制定镜像 ID, 来删除镜像,如:

1
docker rmi ee7cbd482336

一旦制定了通过 ID 来删除镜像,它会先尝试删除所有指向该镜像的标签,然后在删除镜像本身。

4.3 删除镜像的限制

删除镜像很简单,但也不是我们何时何地都能删除的,它存在一些限制条件。

当通过该镜像创建的容器未被销毁时,镜像是无法被删除的。为了验证这一点,我们来做个试验。首先,我们通过 docker pull alpine 命令,拉取一个最新的 alpine 镜像, 然后启动镜像,让其输出 hello,docker!:

Docker run alpine

接下来,我们来删除这个镜像试试:

Docker 删除镜像

可以看到提示信息,无法删除该镜像,因为有容器正在引用他!同时,这段信息还告诉我们,除非通过添加 -f 子命令,也就是强制删除,才能移除掉该镜像!

1
docker rmi -f docker.io/alpine

但是,我们一般不推荐这样暴力的做法,正确的做法应该是:

  1. 先删除引用这个镜像的容器;
  2. 再删除这个镜像;

也就是,根据上图中提示的,引用该镜像的容器 ID ( 9d59e2278553), 执行删除命令:

1
docker rm 9d59e2278553

然后,再执行删除镜像的命令:

1
docker rmi 5cb3aa00f899

Docker 删除镜像Docker 删除镜像

这个时候,就能正常删除了!

4.4 清理镜像

我们在使用 Docker 一段时间后,系统一般都会残存一些临时的、没有被使用的镜像文件,可以通过以下命令进行清理:

1
docker image prune

它支持的子命令有:

  • -a,--all: 删除所有没有用的镜像,而不仅仅是临时文件;
  • -f,--force:强制删除镜像文件,无需弹出提示确认;

五 Docker 创建镜像

此小节中,您将学习 Docker 如何创建镜像?Docker 创建镜像主要有三种:

  1. 基于已有的镜像创建;
  2. 基于 Dockerfile 来创建;
  3. 基于本地模板来导入;

我们将主要介绍常用的 1,2 两种。

5.1 基于已有的镜像创建

通过如下命令来创建:

1
docker container commit

支持的子命令如下:

  • -a,--author=””: 作者信息;
  • -c,--change=[]: 可以在提交的时候执行 Dockerfile 指令,如 CMD、ENTRYPOINT、ENV、EXPOSE、LABEL、ONBUILD、USER、VOLUME、WORIR 等;
  • -m,--message=””: 提交信息;
  • -p,--pause=true: 提交时,暂停容器运行。

接下来,基于本地已有的 Ubuntu 镜像,创建一个新的镜像:

Docker 创建镜像

首先,让我将它运行起来,并在其中创建一个 test.txt 文件:

Docker 创建镜像

命令如下:

1
docker run -it docker.io/ubuntu:latest /bin/bashroot@a0a0c8cfec3a:/# touch test.txtroot@a0a0c8cfec3a:/# exit

创建完 test.txt 文件后,需要记住标注的容器 ID: a0a0c8cfec3a, 用它来提交一个新的镜像(PS: 你也可以通过名称来提交镜像,这里只演示通过 ID 的方式)。

执行命令:

1
docker container commit -m "Added test.txt file" -a "Allen" a0a0c8cfec3a test:0.1

提交成功后,会返回新创建的镜像 ID 信息,如下图所示:

Docker 提交新创建的镜像

再次查看本地镜像信息,可以看到新创建的 test:0.1 镜像了:

Docker 查看镜像信息

5.2 基于 Dockerfile 创建

通过 Dockerfile 的方式来创建镜像,是最常见的一种方式了,也是比较推荐的方式。Dockerfile 是一个文本指令文件,它描述了是如何基于一个父镜像,来创建一个新镜像的过程。

下面让我们来编写一个简单的 Dockerfile 文件,它描述了基于 Ubuntu 父镜像,安装 Python3 环境的镜像:

1
2
3
FROM docker.io/ubuntu:latest
LABEL version="1.0" maintainer="Allen <weiwosuo@github>"
RUN apt-get update && \ apt-get install -y python3 && \ apt-get clean && \ rm -rf /var/lib/apt/lists/*

创建完成后,通过这个 Dockerfile 文件,来构建新的镜像,执行命令:

1
docker image build -t python:3 .

注意: 命令的最后有个点,如果不加的话,会构建不成功 !

Docker 通过 Dockerfile 构建镜像

编译成功后,再次查看本地镜像信息,就可以看到新构建的 python:3 镜像了。

Docker 查看镜像信息

六 Docker 导出&加载镜像

此小节中,您将学习 Docker 如何导出&加载镜像。

通常我们会有下面这种需求,需要将镜像分享给别人,这个时候,我们可以将镜像导出成 tar 包,别人直接通过加载这个 tar 包,快速地将镜像引入到本地镜像库。

要想使用这两个功能,主要是通过如下两个命令:

  1. docker save
  2. docker load

6.1 导出镜像

查看本地镜像如下:

Docker 查看镜像信息

例如,我们想要将 python:3 镜像导出来,执行命令:

1
docker save -o python_3.tar python:3

执行成功后,查看当前目录:

Docker 导出文件Docker 导出文件

可以看到 python_3.tar 镜像文件已经生成。接下来,你可以将它通过复制的方式,分享给别人了!

6.2 加载镜像

别人拿到了这个 tar 包后,要如何导入到本地的镜像库呢?

通过执行如下命令:

1
docker load -i python_3.tar

或者:

1
docker load < python_3.tar

导入成功后,查看本地镜像信息,你就可以获得别人分享的镜像了!怎么样,是不是很方便呢!

七 Docker 上传镜像

我们将以上传到 Docker Hub 上为示例,演示 Docker 如何上传镜像。

7.1 获取 Docker ID

想要上传镜像到 Docker Hub 上,首先,我们需要注册 Docker Hub 账号。打开 Docker Hub 网址 https://hub.docker.com,开始注册:

Docker Hub 注册账号

填写您的 Docker ID (也就是账号),以及密码,Email, 点击继续。

接下来,Docker Hub 会发送验证邮件,到您填写的邮箱当中:

Docker Hub 验证邮件

点击验证即可,接下来,再次返回 Docker Hub 官网,用您刚刚注册的 Docker ID 和密码来登录账号!

Docker Hub 登录页面

7.2 创建镜像仓库

登录成功后,会出现如下页面:

欢迎来到 Docker Hub

选择创建一个镜像仓库:

创建 Python 仓库

填写仓库名称描述信息是否公开后,点击创建。

仓库镜像展示页仓库镜像展示页

我们看到,仓库已经创建成功了,但是里面还没有任何镜像,接下来开始上传镜像,到此新创建的仓库中。

7.3 上传镜像

进入命令行,用我们刚刚获取的 Docker ID 以及密码登录,执行命令:

1
docker login

命令行登录 Docker ID命令行登录 Docker ID

登录成功后,我们开始准备上传本地的 python:3 镜像:

python:3 镜像

首先,我们对其打一个新的标签,前缀与我们新创建的 Docker ID 、仓库名保持一致:

1
docker tag python:3 weiwosuoai1991/python:3

python:3 镜像打标签

查看本地信息,可以看到,标签打成功了。接下开,开始上传!执行命令:

1
docker push weiwosuoai1991/python:3

上传 python:3 镜像

上传成功!去 Docker Hub 官网,新创建的仓库的信息页面验证一下,是否真的成功了:

仓库镜像展示页仓库镜像展示页

大工告成!!!

八 总结

本文中,我们着重学习了 Docker 中下载镜像,、查看镜像信息、搜索镜像、删除镜像,、创建镜像、导出&加载镜像以及向 Docker Hub 上传镜像的相关操作。

本文只是对Docker的概念做了较为详细的介绍,并不涉及一些像Docker环境的安装以及Docker的一些常见操作和命令。

Docker 是世界领先的软件容器平台,所以想要搞懂Docker的概念我们必须先从容器开始说起。

一 先从认识容器开始

1.1 什么是容器?

先来看看容器较为官方的解释

一句话概括容器:容器就是将软件打包成标准化单元,以用于开发、交付和部署。

  • 容器镜像是轻量的、可执行的独立软件包 ,包含软件运行所需的所有内容:代码、运行时环境、系统工具、系统库和设置。
  • 容器化软件适用于基于Linux和Windows的应用,在任何环境中都能够始终如一地运行。
  • 容器赋予了软件独立性 ,使其免受外在环境差异(例如,开发和预演环境的差异)的影响,从而有助于减少团队间在相同基础设施上运行不同软件时的冲突。

再来看看容器较为通俗的解释

如果需要通俗的描述容器的话,我觉得容器就是一个存放东西的地方,就像书包可以装各种文具、衣柜可以放各种衣服、鞋架可以放各种鞋子一样。我们现在所说的容器存放的东西可能更偏向于应用比如网站、程序甚至是系统环境。

认识容器

1.2 图解物理机,虚拟机与容器

关于虚拟机与容器的对比在后面会详细介绍到,这里只是通过网上的图片加深大家对于物理机、虚拟机与容器这三者的理解。

物理机
物理机

虚拟机:

虚拟机

容器:

容器

通过上面这三张抽象图,我们可以大概可以通过类比概括出: 容器虚拟化的是操作系统而不是硬件,容器之间是共享同一套操作系统资源的。虚拟机技术是虚拟出一套硬件后,在其上运行一个完整操作系统。因此容器的隔离级别会稍低一些。


相信通过上面的解释大家对于容器这个既陌生又熟悉的概念有了一个初步的认识,下面我们就来谈谈Docker的一些概念。

二 再来谈谈 Docker 的一些概念

Docker的一些概念

2.1 什么是 Docker?

说实话关于Docker是什么并太好说,下面我通过四点向你说明Docker到底是个什么东西。

  • Docker 是世界领先的软件容器平台。
  • Docker 使用 Google 公司推出的 Go 语言 进行开发实现,基于 Linux 内核 的cgroup,namespace,以及AUFS类的UnionFS等技术,对进程进行封装隔离,属于操作系统层面的虚拟化技术。 由于隔离的进程独立于宿主和其它的隔离的进
    程,因此也称其为容器。Docke最初实现是基于 LXC.
  • Docker 能够自动执行重复性任务,例如搭建和配置开发环境,从而解放了开发人员以便他们专注在真正重要的事情上:构建杰出的软件。
  • 用户可以方便地创建和使用容器,把自己的应用放入容器。容器还可以进行版本管理、复制、分享、修改,就像管理普通的代码一样。

什么是Docker

2.2 Docker 思想

  • 集装箱
  • 标准化: ①运输方式 ② 存储方式 ③ API接口
  • 隔离

2.3 Docker 容器的特点

  • 轻量

    在一台机器上运行的多个 Docker 容器可以共享这台机器的操作系统内核;它们能够迅速启动,只需占用很少的计算和内存资源。镜像是通过文件系统层进行构造的,并共享一些公共文件。这样就能尽量降低磁盘用量,并能更快地下载镜像。

  • 标准

    Docker 容器基于开放式标准,能够在所有主流 Linux 版本、Microsoft Windows 以及包括 VM、裸机服务器和云在内的任何基础设施上运行。

  • 安全

    Docker 赋予应用的隔离性不仅限于彼此隔离,还独立于底层的基础设施。Docker 默认提供最强的隔离,因此应用出现问题,也只是单个容器的问题,而不会波及到整台机器。

2.4 为什么要用 Docker ?

  • Docker 的镜像提供了除内核外完整的运行时环境,确保了应用运行环境一致性,从而不会再出现 “这段代码在我机器上没问题啊” 这类问题;——一致的运行环境
  • 可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。——更快速的启动时间
  • 避免公用的服务器,资源会容易受到其他用户的影响。——隔离性
  • 善于处理集中爆发的服务器使用压力;——弹性伸缩,快速扩展
  • 可以很轻易的将在一个平台上运行的应用,迁移到另一个平台上,而不用担心运行环境的变化导致应用无法正常运行的情况。——迁移方便
  • 使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。——持续交付和部署

每当说起容器,我们不得不将其与虚拟机做一个比较。就我而言,对于两者无所谓谁会取代谁,而是两者可以和谐共存。

三 容器 VS 虚拟机

  简单来说: 容器和虚拟机具有相似的资源隔离和分配优势,但功能有所不同,因为容器虚拟化的是操作系统,而不是硬件,因此容器更容易移植,效率也更高。

3.1 两者对比图

  传统虚拟机技术是虚拟出一套硬件后,在其上运行一个完整操作系统,在该系统上再运行所需应用进程;而容器内的应用进程直接运行于宿主的内核,容器内没有自己的内核,而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便.

容器 VS 虚拟机

3.2 容器与虚拟机总结

容器与虚拟机 (VM) 总结

  • 容器是一个应用层抽象,用于将代码和依赖资源打包在一起。 多个容器可以在同一台机器上运行,共享操作系统内核,但各自作为独立的进程在用户空间中运行 。与虚拟机相比, 容器占用的空间较少(容器镜像大小通常只有几十兆),瞬间就能完成启动

  • 虚拟机 (VM) 是一个物理硬件层抽象,用于将一台服务器变成多台服务器。 管理程序允许多个 VM 在一台机器上运行。每个VM都包含一整套操作系统、一个或多个应用、必要的二进制文件和库资源,因此 占用大量空间 。而且 VM 启动也十分缓慢

  通过Docker官网,我们知道了这么多Docker的优势,但是大家也没有必要完全否定虚拟机技术,因为两者有不同的使用场景。虚拟机更擅长于彻底隔离整个运行环境。例如,云服务提供商通常采用虚拟机技术隔离不同的用户。而 Docker通常用于隔离不同的应用 ,例如前端,后端以及数据库。

3.3 容器与虚拟机两者是可以共存的

就我而言,对于两者无所谓谁会取代谁,而是两者可以和谐共存。

两者是可以共存的


Docker中非常重要的三个基本概念,理解了这三个概念,就理解了 Docker 的整个生命周期。

四 Docker基本概念

Docker 包括三个基本概念

  • 镜像(Image)
  • 容器(Container)
  • 仓库(Repository)

理解了这三个概念,就理解了 Docker 的整个生命周期

Docker 包括三个基本概念

4.1 镜像(Image):一个特殊的文件系统

  操作系统分为内核和用户空间。对于 Linux 而言,内核启动后,会挂载 root 文件系统为其提供用户空间支持。而Docker 镜像(Image),就相当于是一个 root 文件系统。

  Docker 镜像是一个特殊的文件系统,除了提供容器运行时所需的程序、库、资源、配置等文件外,还包含了一些为运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。 镜像不包含任何动态数据,其内容在构建之后也不会被改变。

  Docker 设计时,就充分利用 Union FS的技术,将其设计为 分层存储的架构 。 镜像实际是由多层文件系统联合组成。

  镜像构建时,会一层层构建,前一层是后一层的基础。每一层构建完就不会再发生改变,后一层上的任何改变只发生在自己这一层。 比如,删除前一层文件的操作,实际不是真的删除前一层的文件,而是仅在当前层标记为该文件已删除。在最终容器运行的时候,虽然不会看到这个文件,但是实际上该文件会一直跟随镜像。因此,在构建镜像的时候,需要额外小心,每一层尽量只包含该层需要添加的东西,任何额外的东西应该在该层构建结束前清理掉。

  分层存储的特征还使得镜像的复用、定制变的更为容易。甚至可以用之前构建好的镜像作为基础层,然后进一步添加新的层,以定制自己所需的内容,构建新的镜像。

4.2 容器(Container):镜像运行时的实体

  镜像(Image)和容器(Container)的关系,就像是面向对象程序设计中的 类 和 实例 一样,镜像是静态的定义,容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等

  容器的实质是进程,但与直接在宿主执行的进程不同,容器进程运行于属于自己的独立的 命名空间。前面讲过镜像使用的是分层存储,容器也是如此。

  容器存储层的生存周期和容器一样,容器消亡时,容器存储层也随之消亡。因此,任何保存于容器存储层的信息都会随容器删除而丢失。

  按照 Docker 最佳实践的要求,容器不应该向其存储层内写入任何数据 ,容器存储层要保持无状态化。所有的文件写入操作,都应该使用数据卷(Volume)、或者绑定宿主目录,在这些位置的读写会跳过容器存储层,直接对宿主(或网络存储)发生读写,其性能和稳定性更高。数据卷的生存周期独立于容器,容器消亡,数据卷不会消亡。因此, 使用数据卷后,容器可以随意删除、重新 run ,数据却不会丢失。

4.3仓库(Repository):集中存放镜像文件的地方

  镜像构建完成后,可以很容易的在当前宿主上运行,但是, 如果需要在其它服务器上使用这个镜像,我们就需要一个集中的存储、分发镜像的服务,Docker Registry就是这样的服务。

  一个 Docker Registry中可以包含多个仓库(Repository);每个仓库可以包含多个标签(Tag);每个标签对应一个镜像。所以说:镜像仓库是Docker用来集中存放镜像文件的地方类似于我们之前常用的代码仓库。

  通常,一个仓库会包含同一个软件不同版本的镜像,而标签就常用于对应该软件的各个版本 。我们可以通过<仓库名>:<标签>的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签,将以 latest 作为默认标签.。

这里补充一下Docker Registry 公开服务和私有 Docker Registry的概念:

  Docker Registry 公开服务 是开放给用户使用、允许用户管理镜像的 Registry 服务。一般这类公开服务允许用户免费上传、下载公开的镜像,并可能提供收费服务供用户管理私有镜像。

  最常使用的 Registry 公开服务是官方的 Docker Hub ,这也是默认的 Registry,并拥有大量的高质量的官方镜像,网址为:https://hub.docker.com/ 。在国内访问Docker Hub 可能会比较慢国内也有一些云服务商提供类似于 Docker Hub 的公开服务。比如 时速云镜像库网易云镜像服务DaoCloud 镜像市场阿里云镜像库等。

  除了使用公开服务外,用户还可以在 本地搭建私有 Docker Registry 。Docker 官方提供了 Docker Registry 镜像,可以直接使用做为私有 Registry 服务。开源的 Docker Registry 镜像只提供了 Docker Registry API 的服务端实现,足以支持 docker 命令,不影响使用。但不包含图形界面,以及镜像维护、用户管理、访问控制等高级功能。


Docker的概念基本上已经讲完,最后我们谈谈:Build, Ship, and Run。

五 最后谈谈:Build Ship and Run

如果你搜索Docker官网,会发现如下的字样:“Docker - Build, Ship, and Run Any App, Anywhere”。那么Build, Ship, and Run到底是在干什么呢?

build ship run

  • Build(构建镜像) : 镜像就像是集装箱包括文件以及运行环境等等资源。
  • Ship(运输镜像) :主机和仓库间运输,这里的仓库就像是超级码头一样。
  • Run (运行镜像) :运行的镜像就是一个容器,容器就是运行程序的地方。

Docker 运行过程也就是去仓库把镜像拉到本地,然后用一条命令把镜像运行起来变成容器。所以,我们也常常将Docker称为码头工人或码头装卸工,这和Docker的中文翻译搬运工人如出一辙。

六 总结

本文主要把Docker中的一些常见概念做了详细的阐述,但是并不涉及Docker的安装、镜像的使用、容器的操作等内容。这部分东西,希望读者自己可以通过阅读书籍与官方文档的形式掌握。如果觉得官方文档阅读起来很费力的话,这里推荐一本书籍《Docker技术入门与实战第二版》。

分析

其实面试官主要是想看看:

  • 第一,你知不知道你们系统里为什么要用消息队列这个东西?

    不少候选人,说自己项目里用了 Redis、MQ,但是其实他并不知道自己为什么要用这个东西。其实说白了,就是为了用而用,或者是别人设计的架构,他从头到尾都没思考过。

    没有对自己的架构问过为什么的人,一定是平时没有思考的人,面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿,不会自己思考。

  • 第二,你既然用了消息队列这个东西,你知不知道用了有什么好处&坏处?

    你要是没考虑过这个,那你盲目弄个 MQ 进系统里,后面出了问题你是不是就自己溜了给公司留坑?你要是没考虑过引入一个技术可能存在的弊端和风险,面试官把这类候选人招进来了,基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑,自己跳槽了,给公司留下无穷后患。

  • 第三,既然你用了 MQ,可能是某一种 MQ,那么你当时做没做过调研?

    你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ,比如 Kafka,甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ 没有绝对的好坏,但是就是看用在哪个场景可以扬长避短,利用其优势,规避其劣势

    如果是一个不考虑技术选型的候选人招进了团队,leader 交给他一个任务,去设计个什么系统,他在里面用一些技术,可能都没考虑过选型,最后选的技术可能并不一定合适,一样是留坑。

面试题剖析

为什么使用消息队列

其实就是问问你消息队列都有哪些使用场景,然后你项目里具体是什么场景,说说你在这个场景里用消息队列是什么?

面试官问你这个问题,期望的一个回答是说,你们公司有个什么业务场景,这个业务场景有个什么技术挑战,如果不用 MQ 可能会很麻烦,但是你现在用了 MQ 之后带给了你很多的好处。

先说一下消息队列常见的使用场景吧,其实场景有很多,但是比较核心的有 3 个:解耦异步削峰

解耦

看这么个场景。A 系统发送数据到 BCD 三个系统,通过接口调用发送。如果 E 系统也要这个数据呢?那如果 C 系统现在不需要了呢?A 系统负责人几乎崩溃……

mq-1

在这个场景中,A 系统跟其它各种乱七八糟的系统严重耦合,A 系统产生一条比较关键的数据,很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办?要不要重发,要不要把消息存起来?头发都白了啊!

如果使用 MQ,A 系统产生一条数据,发送到 MQ 里面去,哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据,直接从 MQ 里消费即可;如果某个系统不需要这条数据了,就取消对 MQ 消息的消费即可。这样下来,A 系统压根儿不需要去考虑要给谁发送数据,不需要维护这个代码,也不需要考虑人家是否调用成功、失败超时等情况。

mq-2

总结:通过一个 MQ,Pub/Sub 发布订阅消息这么一个模型,A 系统就跟其它系统彻底解耦了。

面试技巧:你需要去考虑一下你负责的系统中是否有类似的场景,就是一个系统或者一个模块,调用了多个系统或者模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果用 MQ 给它异步化解耦,也是可以的,你就需要去考虑在你的项目里,是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西,用 MQ 作解耦。

异步

再来看一个场景,A 系统接收一个请求,需要在自己本地写库,还需要在 BCD 三个系统写库,自己本地写库要 3ms,BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms,接近 1s,用户感觉搞个什么东西,慢死了慢死了。用户通过浏览器发起请求,等待个 1s,这几乎是不可接受的。

mq-3

一般互联网类的企业,对于用户直接的操作,一般要求是每个请求都必须在 200 ms 以内完成,对用户几乎是无感知的。

如果使用 MQ,那么 A 系统连续发送 3 条消息到 MQ 队列中,假如耗时 5ms,A 系统从接受一个请求到返回响应给用户,总时长是 3 + 5 = 8ms,对于用户而言,其实感觉上就是点个按钮,8ms 以后就直接返回了,爽!网站做得真好,真快!

mq-4

削峰

每天 0:00 到 12:00,A 系统风平浪静,每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ,每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的,大量的请求涌入 MySQL,每秒钟对 MySQL 执行约 5k 条 SQL。

一般的 MySQL,扛到每秒 2k 个请求就差不多了,如果每秒请求到 5k 的话,可能就直接把 MySQL 给打死了,导致系统崩溃,用户也就没法再使用系统了。

但是高峰期一过,到了下午的时候,就成了低峰期,可能也就 1w 的用户同时在网站上操作,每秒中的请求数量可能也就 50 个请求,对整个系统几乎没有任何的压力。

mq-5

如果使用 MQ,每秒 5k 个请求写入 MQ,A 系统每秒钟最多处理 2k 个请求,因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求,每秒钟就拉取 2k 个请求,不要超过自己每秒能处理的最大请求数量就 ok,这样下来,哪怕是高峰期的时候,A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来,就 2k 个请求出去,结果就导致在中午高峰期(1 个小时),可能有几十万甚至几百万的请求积压在 MQ 中。

mq-6

这个短暂的高峰期积压是 ok 的,因为高峰期过了之后,每秒钟就 50 个请求进 MQ,但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说,只要高峰期一过,A 系统就会快速将积压的消息给解决掉。

消息队列有什么优缺点

优点上面已经说了,就是在特殊场景下有其对应的好处解耦异步削峰

缺点有以下几个:

  • 系统可用性降低

    系统引入的外部依赖越多,越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了,人 ABCD 四个系统好好的,没啥问题,你偏加个 MQ 进来,万一 MQ 挂了咋整,MQ 一挂,整套系统崩溃的,你不就完了?如何保证消息队列的高可用,可以点击这里查看

  • 系统复杂度提高

    硬生生加个 MQ 进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?头大头大,问题一大堆,痛苦不已。

  • 一致性问题

    A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是 BCD 三个系统那里,BD 两个系统写库成功了,结果 C 系统写库失败了,咋整?你这数据就不一致了。

所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,做好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了 10 倍。但是关键时刻,用,还是得用的。

Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点?

特性 ActiveMQ RabbitMQ RocketMQ Kafka
单机吞吐量 万级,比 RocketMQ、Kafka 低一个数量级 同 ActiveMQ 10 万级,支撑高吞吐 10 万级,高吞吐,一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响 topic 可以达到几百/几千的级别,吞吐量会有较小幅度的下降,这是 RocketMQ 的一大优势,在同等机器下,可以支撑大量的 topic topic 从几十到几百个时候,吞吐量会大幅度下降,在同等机器下,Kafka 尽量保证 topic 数量不要过多,如果要支撑大规模的 topic,需要增加更多的机器资源
时效性 ms 级 微秒级,这是 RabbitMQ 的一大特点,延迟最低 ms 级 延迟在 ms 级以内
可用性 高,基于主从架构实现高可用 同 ActiveMQ 非常高,分布式架构 非常高,分布式,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
消息可靠性 有较低的概率丢失数据 基本不丢 经过参数优化配置,可以做到 0 丢失 同 RocketMQ
功能支持 MQ 领域的功能极其完备 基于 erlang 开发,并发能力很强,性能极好,延时很低 MQ 功能较为完善,还是分布式的,扩展性好 功能较为简单,主要支持简单的 MQ 功能,在大数据领域的实时计算以及日志采集被大规模使用

综上,各种对比之后,有如下建议:

一般的业务系统要引入 MQ,最早大家都用 ActiveMQ,但是现在确实大家用的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃,所以大家还是算了吧,我个人不推荐用这个了;

后来大家开始用 RabbitMQ,但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它,对公司而言,几乎处于不可控的状态,但是确实人家是开源的,比较稳定的支持,活跃度也高;

不过现在确实越来越多的公司会去用 RocketMQ,确实很不错,毕竟是阿里出品,但社区可能有突然黄掉的风险(目前 RocketMQ 已捐给 Apache,但 GitHub 上的活跃度其实不算高)对自己公司技术实力有绝对自信的,推荐用 RocketMQ,否则回去老老实实用 RabbitMQ 吧,人家有活跃的开源社区,绝对不会黄。

所以中小型公司,技术实力较为一般,技术挑战不是特别高,用 RabbitMQ 是不错的选择;大型公司,基础架构研发实力较强,用 RocketMQ 是很好的选择。

如果是大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范。