ARTS
ARTS 是陈浩（网名左耳朵耗子）在极客时间专栏里发起的一个活动，目的是通过分享的方式来坚持学习。
每人每周写一个 ARTS：Algorithm 是一道算法题，Review 是读一篇英文文章，Technique/Tips 是分享一个小技术，Share 是分享一个观点。
本周内容
本周的 ARTS 你将看到:
- Redis 作者是如何评价 Redis 的持久化的.
- 使用 golint 和 go vet 规范你的代码.
Algorithm
本周竟然没有算法题, 看来博主坚持不下去了.
Review 文章推荐
本周的文章推荐是 Redis 作者写的一篇关于数据库持久化的科普文章 [](http://oldblog.antirez.com/po...
文中分析了 DB 数据持久化过程中的一般流程, 以及一般流程中可能出现不稳定的点. 通过对一会化的持久化流程的分析, 作者得出了大部分数据库系统在持久化这件事上, 所能控制的两个关键步骤.
- 将数据从应用层写入内核的 buffer 中, 即通常调用 POSIX 的
write接口; - 数据从内核的 buffer 刷新到磁盘中, 即通常调用 POSIX 的
fsync接口.
除了写入持久化存储设备这个过程之外, 数据库系统还需要提供在服务重启后恢复数据状态的功能, 比如 innoDB 需要维护索引结构. 要解决这个问题, 数据库系统要么就要提供将持久化到磁盘的数据恢复到某种 "运行态" 结构的功能, 要么就要使用类似 Redis 的 AOF 文件这种类型的持久化存储方式.
然后介绍了 Redis 中 RDB 和 AOF 的一些特点, 以及 Redis 和 PostrgreSQL 在存储方面的对比.
Tip 编程技巧
上周看了 Uber 的 Golang 编程规范 Uber Go Style Guide 之后, 一两天之内还能记得一些点, 但是一周过去之后基本上忘得差不多了. 一直想找个方式提醒自己, 正好发现了 golint 和 go vet 这两个工具. 虽然不能完全覆盖规范中的内容, 但也算是可以通过自动化的方式快速熟悉一些代码规范.
我目前的使用方式是: 给 Goland 配置了自动保存文件的时候触发 golint 和 go vet 的 trigger, 可以快速发现项目中存在的不符合推荐的语法规则或者命名规范的地方.
Share 灵光一闪
本周也没有闪过.
本周阅读列表
极客时间-深入剖析kubernetes 白话容器
- 对 Docker 项目来说，它最核心的原理实际上就是为待创建的用户进程：启用 Linux Namespace 配置；设置指定的 Cgroups 参数；切换进程的根目录（chroot）。
- rootfs 只是一个操作系统所包含的文件、配置和目录，并不包括操作系统内核。在 Linux 操作系统中，这两部分是分开存放的，操作系统只有在开机启动时才会加载指定版本的内核镜像。
- 容器是一个“单进程”模型。
由于一个容器的本质就是一个进程，用户的应用进程实际上就是容器里 PID=1 的进程，也是其他后续创建的所有进程的父进程。这就意味着，在一个容器中，你没办法同时运行两个不同的应用，除非你能事先找到一个公共的 PID=1 的程序来充当两个不同应用的父进程，这也是为什么很多人都会用 systemd 或者 supervisord 这样的软件来代替应用本身作为容器的启动进程。但使用一个进程来管理更多进程的方式并不是容器的最佳实践. 这是因为容器本身的设计，就是希望容器和应用能够同生命周期，这个概念对后续的容器编排非常重要。否则，一旦出现类似于“容器是正常运行的，但是里面的应用早已经挂了”的情况，编排系统处理起来就非常麻烦了。
Dockerfile 中的 ENTRYPOINT 和 CMD
默认情况下，Docker 会为你提供一个隐含的 ENTRYPOINT，即：/bin/sh -c。CMD 是 ENTRYPOINT 的参数
docker exec 命令的原理
一个进程，可以选择加入到某个进程已有的 Namespace 当中，从而达到“进入”这个进程所在容器的目的，这正是 docker exec 的实现原理。而这个操作所依赖的，乃是一个名叫 setns() 的 Linux 系统调用。
通过 setns() 这个系统调用, 实际上是启动了另外一个进程然后共享了 docker 进程的 Namespace 文件.
Docker Volume 机制
docker 命令中的 volume 挂载命令
docker run -v /test ...或者docker run -v /home:/test .... 其中第一种方式因为没有指定宿主机目录, 所以会在宿主机上创建一个临时目录/var/lib/docker/volumes/[VOLUME_ID]/_data, 然后再把临时目录挂载到 docker 的/test目录.具体实现方面, 因为容器创建成功之后已经开启了 Mount Namespace, 并且容器本身的文件系统(rootfs)也是基于 aufs.
所以，我们只需要在 rootfs 准备好之后，在执行 chroot 之前，把 Volume 指定的宿主机目录（比如 /home 目录），挂载到指定的容器目录（比如 /test 目录）在宿主机上对应的目录（即 /var/lib/docker/aufs/mnt/[可读写层 ID]/test）上，这个 Volume 的挂载工作就完成了。更重要的是，由于执行这个挂载操作时，“容器进程”已经创建了，也就意味着此时 Mount Namespace 已经开启了。所以，这个挂载事件只在这个容器里可见。你在宿主机上，是看不见容器内部的这个挂载点的。这就保证了容器的隔离性不会被 Volume 打破。
最终的数据修改都会保留在上述挂载操作的目标目录, 即该容器在宿主机上的临时目录(
/var/lib/docker/volumes/[VOLUME_ID]/_data)中. 在宿主机上，容器对应的镜像可读写层中, 上述的挂载和挂载之后的数据修改是不可见的, 但如果挂载到一个新的目录的话, 还是会在可读写层创建这个目录.
极客时间-深入剖析kubernetes 容器编排与Kubernetes作业管理
Pod 存在的意义
Pod 是一个逻辑的概念, 并不存在一个 Pod 的边界或者隔离环境.
Pod 里的所有容器，共享的是同一个 Network Namespace，并且可以声明共享同一个 Volume。在 Kubernetes 项目里，Pod 的实现需要使用一个中间容器，这个容器叫作 Infra 容器。在这个 Pod 中，Infra 容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过 Join Network Namespace 的方式，与 Infra 容器关联在一起。
sidecar 模式
容器的性能优势，必然伴随着相应缺陷，即：它不能像虚拟机那样，完全模拟本地物理机环境中的部署方法。
实际上，一个运行在虚拟机里的应用，哪怕再简单，也是被管理在 systemd 或者 supervisord 之下的一组进程，而不是一个进程。这跟本地物理机上应用的运行方式其实是一样的。这也是为什么，从物理机到虚拟机之间的应用迁移，往往并不困难。关于 Pod 的本质:
Pod，实际上是在扮演传统基础设施里“虚拟机”的角色；而容器，则是这个虚拟机里运行的用户程序。
当我们考虑应不应该在数据库中使用外键时，需要关注的核心我们的数据库承担这部分计算任务后会不会影响系统的可用性，在使用时也不应该一刀切的决定用或者不用外键，应该根据具体的场景做决策，我们在这里介绍了两个使用外键时可能遇到的问题：RESTRICT 外键会在更新和删除关系表中的数据时对外键约束的合法性进行检查，保证外键不会引用到不存在的记录；CASCADE 外键会在更新和删除关系表中的数据时触发对关联记录的更新和删除，在数据量较大的数据库中可能会有数量级的放大效果；
- Effective Go
关于代码注释的一些风格和规范, 如果你使用 Goland 的话, 可以通过设置 FileWatcher 通过文件自动保存时触发
golint来帮助你检查是否符合相关的规范.
有疑问加站长微信联系（非本文作者）
