凝岚_个人页_阿里云开发者社区

Docker 容器概念

不玩虚的, 当然更畅快 docker 与虚拟机(vm)对比: lark_01_vm_vs_docker 虚拟机运行在虚拟硬件上, 应用运行在虚拟机内核上。而 docker daemon 是宿主机上的一个进程, 应用只是 docker daemon 的一个子进程, 换句话说, 应用直接运行在宿主机内核上。虚拟机需要特殊硬件虚拟化技术支持, 因而只能运行在物理机上。docker 没有硬件虚拟化, 因而可以运行在物理机、虚拟机, 甚至 docker 容器内(嵌套运行)。因为没有硬件虚拟化及多运行一个 Linux 内核的开销, 应用运行在 docker 上比虚拟机上更轻、更快。那么, 使用 docker 和直接在宿主机上运行一个程序有什么区别呢?答案是 docker 容器使用 cgroup 名字空间实现了 CPU, 内存, 网络, 文件系统等资源隔离。了解 chroot 的同学可以认为 docker 就是一个更优雅的 chroot。说到隔离, docker 容器的文件系统在哪里呢? 答案就是镜像。 docker 镜像镜像描述了 docker 容器运行的初始文件系统, 包含运行应用所需的所有依赖。即可以是一个完整的操作系统, 也可以仅包含应用所需的最小 bin/lib 文件集合。一个问题: 假设一个 docker 容器文件系统大小为 10GiB, 创建 10 个容器需要多少磁盘空间？ 100 GiB？错，还是只要 10 GiB！因为 docker 镜像和容器采用分层文件系统结构, 每个容器包含一层薄薄的可写层, 只读部分是共享的。 docker 镜像存储引擎有 aufs, devicemapper, overlay 等多种实现, 请看 devicemapper 实现示意图如下: lark_01_dm_container 镜像是只读的, 创建容器时只是在镜像上面新建一个可写层, 不需要复制整个文件系统, 因而可以实现毫秒级创建。镜像存储在镜像 hub。每个镜像有一个 tag, 如 registry.hub.docker.com/library/ubuntu:14.04。镜像完整 tag 不仅包含镜像名字, 还指明了镜像从哪里来, 要到哪里去, 就像一个 URL。没错, registry.hub.docker.com 就是官方 docker 镜像 hub 的地址。使用官方 library 镜像时, 可省略前缀, 如以上镜像 tag 可简写为 ubuntu:14.04。 docker 为运行应用而生有了镜像，如何创建容器？docker 不加载 kernel (不同于 vm), 也不执行 init (不同于 vm 和 lxc)。“你不执行应用, 空跑一个 kernel 或者 init 有什么意义？”，docker 说。docker 容器为运行应用而生, 要创建 docker 容器, 必须指定镜像 tag 和启动应用的命令行 (或者镜像设置了默认命令行)。 so, 创建一个 docker 容器的命令行如下: sudo docker create -ti --name test ubuntu:14.04 bash 这只是创建了容器, 还没有运行, 要运行容器, 执行: sudo docker start test 通常我们把这两条命令合并成一条, 即 docker run: sudo docker run -dti --name test ubuntu:14.04 bash 在宿主机上看一下我们刚刚运行的 bash 命令的进程树: $pstree -sa 21811systemd --switched-root --system --deserialize 21 └─docker daemon ... ... └─bash 没错, 它只是 docker daemon 的一个子进程. 应用即 docker 主进程 attach 到容器内的应用, 本例中即为 bash 命令行: sudo docker attach test ps -ef 看一下: $sudo docker attach testroot@47c90c3dcbfa:/# ps -efUID PID PPID C STIME TTY TIME CMDroot 1 0 0 17:05 ? 00:00:00 bashroot 18 1 0 17:11 ? 00:00:00 ps -ef 加上 ps 自己, 容器中只有两个进程。 bash 在容器内 PID 为 1, 即是容器主进程。主进程退出后, 容器即自动退出。还是那句话, 容器为运行应用而生, 应用都退出了, 容器留着还有什么用。手动停止容器: sudo docker stop test 删除容器: sudo docker rm test 注意: 删除容器后在镜像上创建的可写层文件系统也将被删除, 所以日志、配置、数据等需要持久保存的文件需要挂接到外部储存。 docker 有多轻俗话说前人栽树, 后人乘凉, 我们通常是基于一个已有的镜像创建应用镜像。为了演示镜像有多轻，我们可以从 0 开始创建一个镜像。创建一个文件夹 hello-lark, 进入文件夹, 添加一个 Dockerfile 内容如下: FROM scratchCOPY Dockerfile hello.c hello / Dockerfile 描述如何创建镜像: FROM scratch 表示从 0 开始, 即从一个空白文件系统开始创建镜像。 COPY Dockerfile hello.c hello / 表示将本地 Dockerfile, hello.c, hello 3 个文件复制到镜像内根目录下。 hello.c 和 hello 是我们的应用源码及编译后的二进制文件。添加 hello.c 文件内容如下: #include <stdio.h>int main(int argc, char* argv[]) { printf("Hello, Lark!\n"); return 0;} 静态编译之: gcc -static hello.c -o hello 执行 docker build 创建镜像: $sudo docker build -t hello-lark:1.0 .Sending build context to Docker daemon 881.2 kBStep 1 : FROM scratch ---> Step 2 : COPY Dockerfile hello.c hello / ---> b52b3bd2799cRemoving intermediate container bc5dcd332026Successfully built b52b3bd2799c 镜像在本地仓库打包和存储, 不能直接看到实体文件。但是可以导出为一个 tar 包: sudo docker save -o ../hello-lark.tar hello-lark:1.0 看看有多大: $ll -h ../hello-lark.tar -rw-r--r-- 1 root root 870K Apr 12 13:41 ../hello-lark.tar 仅有 870K, 差不多就是 hello 这个二进制文件的大小。 docker 有多快这个镜像能跑吗？我们马上运行看看： $time sudo docker run --name hello --rm hello-lark:1.0 /helloHello, Lark!real 0m0.486suser 0m0.078ssys 0m0.016s 可看到, 这条命令一共经历了容器创建、运行、停止、销毁 4 个过程，共耗时不到 0.5 秒。--rm 表示容器结束后自动删除容器。如果只是创建: $time sudo docker create --name hello hello-lark:1.0 /hello16449a07a0f1377336a879f8136ec7369e07520da1f4a7516128b8d3ba314008real 0m0.075suser 0m0.064ssys 0m0.017s 不到 0.1 秒。毫秒级创建绝非虚言。当然, 只是 hello world 并没有什么用, 我们打一个 busybox 进去, 镜像大小只有 2MB, 然而已经具备一个基本的 linux shell 环境. sudo docker run -ti --rm lark-box:1.0 sh docker 的好处简单说: 标准化交付，微服务编排，提升资源利用率。校准化交付 docker 将应用及其所有依赖打包到镜像内, 包括二进制文件(包括底层基础库), 静态配置文件, 环境变量等。剥离了应用对操作系统和环境的依赖，松耦合。只需要拉取镜像, 启动容器即可完成应用部署, 方便。毫秒级创建销毁容器，从而可以实现快速部署、快速迁移、快速扩容缩容，一键快速回滚 (只依赖应用启动时间)。docker 镜像制定了应用交付标准, 开发人员对应用及其运行环境完全可控，并有效避免各种环境问题踩坑。微服务编排单机部署多应用时，应用之间完全解耦，可以任意部署编排, 完美支持微服务编排的需求。多个 C 应用混布时, docker 化实现 C 依赖隔离, 避免依赖冲突。提升资源利用率 docker 是轻量级的解决方案, 不做虚拟化, 不运行多余的 kernel 和 init 进程, 能有效提升资源利用率。

Tair介绍

1.1 系统架构一个Tair集群主要包括3个必选模块：configserver、dataserver和client，一个可选模块：invalidserver。通常情况下，一个集群中包含2台configserver及多台dataServer。两台configserver互为主备并通过维护和dataserver之间的心跳获知集群中存活可用的dataserver，构建数据在集群中的分布信息（对照表）。dataserver负责数据的存储，并按照configserver的指示完成数据的复制和迁移工作。client在启动的时候，从configserver获取数据分布信息，根据数据分布信息和相应的dataserver交互完成用户的请求。invalidserver主要负责对等集群的删除和隐藏操作，保证对等集群的数据一致。从架构上看，configserver的角色类似于传统应用系统的中心节点，整个集群服务依赖于configserver的正常工作。但实际上相对来说，tair的configserver是非常轻量级的，当正在工作的服务器宕机的时候另外一台会在秒级别时间内自动接管。而且，如果出现两台服务器同时宕机的最恶劣情况，只要应用服务器没有新的变化， tair依然服务正常。而有了configserver这个中心节点，带来的好处就是应用在使用的时候只需要配置configserver的地址（现在可以直接配置Diamond key），而不需要知道内部节点的情况。 1.1.1 ConfigServer的功能 1) 通过维护和dataserver心跳来获知集群中存活节点的信息 2) 根据存活节点的信息来构建数据在集群中的分布表。 3) 提供数据分布表的查询服务。 4) 调度dataserver之间的数据迁移、复制。 1.1.2 DataServer的功能 1) 提供存储引擎 2) 接受client的put/get/remove等操作 3) 执行数据迁移，复制等 4) 插件：在接受请求的时候处理一些自定义功能 5) 访问统计 1.1.3 InvalidServer的功能 1) 接收来自client的invalid/hide等请求后，对属于同一组的集群（双机房独立集群部署方式）做delete/hide操作，保证同一组集群的一致。 2) 集群断网之后的，脏数据清理。 3) 访问统计。 1.1.4 client的功能 1) 在应用端提供访问Tair集群的接口。 2) 更新并缓存数据分布表和invalidserver地址等。 3) LocalCache，避免过热数据访问影响tair集群服务。 4) 流控 1.2 存储引擎与应用场景 Tair经过这两年的发展演进，除了应用于cache缓存外，在存储（持久化）上支持的应用需求也越来越广泛。现在主要有mdb，rdb，ldb三种存储引擎。 1.2.1 mdb 定位于cache缓存，类似于memcache。支持k/v存取和prefix操作 1.2.1.1 mdb的应用场景在实际业务中，大部分当缓存用（后端有DB之类的数据源）。也可用做大访问少量临时数据的存储（例如session登录，防攻击统计等）。集团内绝对多数cache服务都是采用的tair mdb。 1.2.2 rdb 定位于cache缓存，采用了redis的内存存储结构。支持k/v，list，hash，set，sortedset等数据结构。 1.2.2.1 rdb的应用场景适用于需要高速访问某些数据结构的应用，例如SNS中常见的的粉丝存储就可以采用set等结构；或者存储一个商品的多个属性（hashmap）；高效的消息队列（list）等。现在有30个左右的应用在使用rdb服务。 1.2.3 ldb 定位于高性能存储，并可选择内嵌mdb cache加速，这种情况下cache与持久化存储的数据一致性由tair进行维护。支持k/v，prefix等数据结构。今后将支持list，hash，set，sortedset等redis支持的数据结构。 1.2.3.1 ldb的应用场景存储，里面可以细分如下场景： 1) 持续大数据量的存入读取，类似淘宝交易快照。 2) 高频度的更新读取，例如计数器，库存等。 3) 离线大批量数据导入后做查询。参见fastdump 也可以用作cache：数据量大，响应时间敏感度不高的cache需求可以采用。例如天猫实时推荐。 1.3 基本概念 1.3.1 configID 唯一标识一个tair集群，每个集群都有一个对应的configID，在当前的大部分应用情况下configID是存放在diamond中的，对应了该集群的configserver地址和groupname。业务在初始化tairclient的时候需要配置此ConfigID。 1.3.2 namespace 又称area，是tair中分配给应用的一个内存或者持久化存储区域，可以认为应用的数据存在自己的namespace中。同一集群（同一个configID）中namespace是唯一的。通过引入namespace，我们可以支持不同的应用在同集群中使用相同的key来存放数据，也就是key相同，但内容不会冲突。一个namespace下是如果存放相同的key，那么内容会受到影响，在简单K/V形式下会被覆盖，rdb等带有数据结构的存储引擎内容会根据不同的接口发生不同的变化。 1.3.3 quota配额对应了每个namespace储存区的大小限制，超过配额后数据将面临最近最少使用（LRU）的淘汰。持久化引擎（ldb）本身没有配额，ldb由于自带了mdb cache，所以也可以设置cache的配额。超过配额后，在内置的mdb内部进行淘汰。 1.3.3.1 配额是怎样计算的配额大小直接影响数据的命中率和资源利用效率，业务方需要给出一个合适的值，通常的计算方法是评估在保证一定命中率情况下所需要的记录条数，这样配额大小即为：记录条数 * 平均单条记录大小。 1.3.3.2 管理员如何配置配额单份数据情况下，业务提供的配额就是需要配置在Tair系统中的配额。但对于多备份，在系统中实际计算的配额为：业务配额 *　备份数 1.3.4 expireTime:过期时间 expiredTime 是指数据的过期时间，当超过过期时间之后，数据将对应用不可见，这个设置同样影响到应用的命中率和资源利用率。不同的存储引擎有不同的策略清理掉过期的数据。调用接口时，expiredTime单位是秒，可以是相对时间（比如：30s），也可以是绝对时间（比如：当天23时,转换成距1970-1-1 00:00:00的秒数）。小于0，不更改之前的过期时间如果不传或者传入0，则表示数据永不过期；大于0小于当前时间戳是相对时间过期；大于当前时间戳是绝对时间过期； 1.3.5 version Tair中存储的每个数据都有版本号，版本号在每次更新后都会递增，相应的，在Tair put接口中也有此version参数，这个参数是为了解决并发更新同一个数据而设置的，类似于乐观锁。很多情况下，更新数据是先get，修改get回来的数据，然后put回系统。如果有多个客户端get到同一份数据，都对其修改并保存，那么先保存的修改就会被后到达的修改覆盖，从而导致数据一致性问题,在大部分情况下应用能够接受，但在少量特殊情况下，这个是我们不希望发生的。比如系统中有一个值”1”, 现在A和B客户端同时都取到了这个值。之后A和B客户端都想改动这个值，假设A要改成12，B要改成13，如果不加控制的话，无论A和B谁先更新成功，它的更新都会被后到的更新覆盖。Tair引入的version机制避免了这样的问题。刚刚的例子中，假设A和B同时取到数据，当时版本号是10，A先更新，更新成功后，值为12，版本为11。当B更新的时候，由于其基于的版本号是10，此时服务器会拒绝更新，返回version error，从而避免A的更新被覆盖。B可以选择get新版本的value，然后在其基础上修改，也可以选择强行更新。 1.3.5.1 如何获取到当前key的version get接口返回的是DataEntry对象，该对象中包含get到的数据的版本号，可以通过getVersion()接口获得该版本号。在put时，将该版本号作为put的参数即可。如果不考虑版本问题，则可设置version参数为0，系统将强行覆盖数据，即使版本不一致。 1.3.5.2 version是如何改变的 Version改变的逻辑如下： 1) 如果put新数据且没有设置版本号，会自动将版本设置成1。 2) 如果put是更新老数据且没有版本号，或者put传来的参数版本与当前版本一致，版本号自增1。 3) 如果put是更新老数据且传来的参数版本与当前版本不一致，更新失败，返回VersionError。 4) put时传入的version参数为0，则强制更新成功，版本号自增1。 1.3.5.3 version返回不一致的时候，该如何处理如果更新所基于的version和系统中当前的版本不一致，则服务器会返回ResultCode.VERERROR。这时你可以重新get数据，然后在新版本的数据上修改；或者设置version为0重新请求，以达到强制更新的效果，应用可以根据自身对数据一致性的要求在这两种策略间进行选择。 1.3.5.4 version具体使用案例如果应用有10个client会对key进行并发put，那么操作过程如下： 1) get key。如果get key成功，则进入步骤2；如果数据不存在，则进入步骤3. 2) 在调用put的时候将get key返回的verison重新传入put接口。服务端根据version是否匹配来返回client是否put成功。 3) get key数据不存在，则新put数据。此时传入的version必须不是0和1，其他的值都可以（例如1000，要保证所有client是一套逻辑）。因为传入0，tair会认为强制覆盖；而传入1，第一个client写入会成功，但是新写入时服务端的version以0开始计数啊，所以此时version也是1，所以下一个到来的client写入也会成功，这样造成了冲突 1.3.5.5 version分布式锁 Tair中存在该key，则认为该key所代表的锁已被lock；不存在该key，在未加锁。操作过程和上面相似。业务方可以在put的时候增加expire，已避免该锁被长期锁住。当然业务方在选择这种策略的情况下需要考虑并处理Tair宕机带来的锁丢失的情况。 1.3.5.6 什么情况下需要使用version 业务对数据一致性有较高的要求，并且访问并发高，那么通过version可以避免数据的意外结果。如果不关心并发，那么建议不传入version或者直接传0。 1.4 集群部署方式 Tair通过多种集群部署方式，来满足各类应用的容灾需求。下面所述的双机房可以扩展到多机房，现阶段基本还是采用的双机房。现总共有4种方式： mdb存储引擎适用于双机房单集群单份，双机房独立集群，双机房单集群双份。 rdb存储引擎适用于双机房单集群单份。 ldb存储引擎适用于双机房主备集群，双机房单集群单份。 1.4.1 双机房单集群单份双机房单集群单备份数是指，该Tair集群部署在两个机房中（也就是该Tair集群的机器分别在两个机房），数据存储份数为1，该类型集群部署示意图如下所示。数据服务器（Dataserver）分布在两个机房中，他们都属于同一集群。使用场景： 1) 后端有无数据源都可。 2) 后端有数据源，且更新比例很高的场景。优点： 1) 服务器存在于双机房，任一机房宕机保持可用。 2) 单份数据，无论应用在哪个机房，看到的都是同一个数据。缺点： 1) 应用服务器会跨机房访问。如上图，并假设应用服务器在cm3和cm4，那么cm3的应用服务器也可能调用到cm4的tair机器，cm4的亦然。 2) 当一边机房出现故障时，tair中的数据会失效一半（一半这个数值是按两边机房tair机器数相同估计的，如果不相同，则按对应比例估算）该部署方式，应用在删除数据时，只需要调用delete即可，无需调用invalid。当然，调用invalid也可，这种方式下会直接退化到delete。 1.4.2 双机房独立集群双机房独立集群是指，在两个机房中同时部署2个独立的Tair集群，这两个集群没有直接关系。下图是一个典型的双机房独立集部署示意图，可以看到，cm3和cm4各有一个完整的tair集群（2个configserver+多个dataserver）。图中还多了一个invalidserver的角色， invalidserver接收客户端的invalid或者hide请求后，会对各机房内的集群进行delete或者hide操作，以此保障Tair中的数据和后端数据源保持一致的。适用场景： 1) 后端必须要有数据源，否则则退化成单机房集群，Tair集群本身不做同步。 2) 读写比不能过小，不然可能会带来Tair命中率降低。例如某个key，在数据库中被频繁更新，那么此时应用必须调用invalid来确保Tair和DB的一致性。此时应用读Tair一直会不命中，导致整体命中率低，可能造成DB压力比较大。如果依然有疑问的话，请联系 tair答疑。优点： 1) 每个机房拥有独立Tair集群，应用在哪个机房就访问相同机房的Tair集群，不会出现跨机房调用和流量。 2) 单边机房故障，不会影响业务访问tair命中率。缺点： 1) 后端必须要有数据源，也就是这种部署方式下，Tair必然是当作传统意义上的cache存在的。因为Tair mdb集群之间本身不会做数据同步，多集群间一致性保证依赖于后端数据源，如DB。 2) 当后端数据源数据发生更新后，业务不能直接把数据put到Tair，而是先需要调用invalid接口来失效这些对等集群中的数据（来保持各Tair集群的数据和后端数据源的一致性）。之后业务可以把数据put到当前Tair集群（注意：只会put到本机房的Tair集群，不会put到对端集群）或者在读Tair时发生not exist的时候从后端数据源取来放入Tair。 1.4.3 双机房单集群双份双机房单集群双份，是指一个Tair集群部署在2个机房中，数据保存2份，并且同一数据的2个备份不会放在同一个数据服务器上。根据数据分布策略的不同，还可以将同一份数据的不同备份分布到不同的机房上。该类型的集群部署方式与双机房单集群单份数据的部署方式一样。其不同之处，数据保存份数不一样。该类型集群部署方式示意图如下图所示，数据服务器分别部署在两个不同的机房里，所有的数据服务器都被相同的配置服务器管理，在逻辑上，他们构成一个独立的集群。现只有tbsession集群使用了这种部署方式。适用场景：后端无数据源，临时数据的存放，非cache。 cache类应用推荐使用双机房独立集群和双机房单集群单份部署方式。优点： 1) 数据存放两份，数据安全性有一定保障。但由于存储引擎是mdb，数据存放在内存中，无法绝对保证数据不丢失。 2) 当一边机房故障时，另外一边机房依然可以服务，并且数据不丢失。缺点： 1) 如果机房间网络出现异常情况，依然有较小几率丢失数据。 1.4.4 双机房主备集群这种部署方式中，存在一个主集群和一个备份集群，分别在两个机房中。如下图所示，不妨假设CM3中部署的是主集群，CM4中部署的是备份集群。那么，在正常情况下，用户只使用主集群，读写数据都与主集群交互。主备集群会自动同步数据（不需要业务去更新两边），保证两个机房数据的最终一致性。当一个机房发生故障后，备集群会自动切换成主集群，提供服务，保证系统可用性。适用场景：该方式只在ldb存储引擎中存在，也就是业务将Tair当作最终存储使用。我们会在当前主集群存两份数据，并由Tair异步将数据更新到备集群，确保数据安全和服务可用。优点： 1) 数据安全和服务可用性高。 2) 用户调用方便，无需考虑多集群间数据一致性的问题。

凝岚_个人页

个人介绍

擅长的技术

是时候考虑怎么用好云了——第二期阿里云企业云上治理沙龙举行

注意啦！重新组队后新队员需要进行再次赋权！

【阿里中间件性能挑战赛】天池“西行游学”启动报名！

【重要消息】第一赛季评测次数增至三次！

【重要消息】中间件大赛提前开放试跑（7月3日截止）

Docker 容器概念

阿里巴巴集团宣布正式加入Apache基金会

Tair介绍

给你机会挑战双十一实时计算，你敢来吗？【阿里中间件性能挑战赛来袭】

【6.27更新】你不能错过的：阿里中间件性能挑战赛重要学习资料

【持续更新】工单常见问题看这里！可能会有你想知道的！

谁说这道题太难玩？看完师哥秘籍，你再试试？

【天池选手故事】阿里移动推荐算法竞赛经验分享

是时候考虑怎么用好云了——第二期阿里云企业云上治理沙龙举行

Docker 容器概念

阿里巴巴集团宣布正式加入Apache基金会

Tair介绍

给你机会挑战双十一实时计算，你敢来吗？【阿里中间件性能挑战赛来袭】

为什么没有成绩呢？

算法平台的IP白名单问题

求助 白名单问题

如何上传大于10M的数据

注意啦！重新组队后新队员需要进行再次赋权！

请问中间件证书上写的校招绿色通道该怎么使用呢？

没有下文了么

【阿里中间件性能挑战赛】天池“西行游学”启动报名！

【阿里中间件性能挑战赛】把第1赛季代码放出大家共同学习

【重要消息】第一赛季评测次数增至三次！

【重要消息】中间件大赛提前开放试跑（7月3日截止）

寻找队友

第一赛季的奖品粮票能用来点外卖吗？

支付宝实名制的一些疑惑

问个关于参赛队伍的问题。

我昨天提交了新的结果，排名确没有更新，咋回事

对菜鸟物流比赛的几点建议

关于团队成员同时提交结果的疑问

请问如果新人平台赛能够正常参加，是不是就说明认证已通过

管理员请进，需要您帮我做实名认证

求助白名单问题