我们的遗留系统广泛使用了性能最佳的IPC方式 – 共享内存，而且用到了两种共享内存的实现方式：System V共享内存(shmget、shmat、shmdt)以及Mmap映射Regular File。System V共享内存支持一定程度上的内存数据持久化，即当程序创建共享内存对象后，如果不显式删除或物理主机重启，该IPC对象会一直保留，其中的数据也不会丢 失；mmap映射Regular File的方式支持内存数据持久化到文件中，即便物理主机重启，这部分数据依旧不会丢失，除非显式删除文件。这两个共享内存机制，尤其是其持久化的特性是 我们的系统所依赖的。但是在Docker容器中，这两种共享内存机制依旧能被很好的支持吗？我们通过试验来分析一下。

一、System V共享内存

一个启动的Docker容器就是一个拥有了自己的内核名字空间的进程，其pid、net、ipc、mnt、uts、user等均与其他进程隔离，对于运行于该容器内的程序而言，它仿佛会觉得它独占了一台“主机”。对于这类“主机”，我们首先来测试一下其中的system v共享内存是否依旧能像物理主机上一样，在程序退出后依旧能保持持久化？在容器退出后能保持么？

我们先来写两个测试程序，一个用于创建system v共享内存，并写入一些数据，另外一个程序则映射该共享内存并尝试读出内存中的数据。由于Golang目前仍未提供对System V共享内存的高级封装接口，通过syscall包的Syscall调用又太繁琐，因此我们直接使用C代码与Go代码结合的方式实现这两个测试程序。之前写 过一篇名为《Go与C语言互操作》的博文，看不懂下面代码的朋友，可以先阅读一下这篇文章。

//systemv_shm_wr.go
package main

//#include <sys/types.h>
//#include <sys/ipc.h>
//#include <sys/shm.h>
//#include <stdio.h>
//
//#define SHMSZ     27
//
//int shm_wr() {
//    char c;
//    int shmid;
//    key_t key;
//    char *shm, *s;
//
//    key = 5678;
//
//    if ((shmid = shmget(key, SHMSZ, IPC_CREAT | 0666)) < 0) {
//        return -1;
//    }
//
//    if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) {
//        return -2;
//    }
//
//    s = shm;
//    for (c = 'a'; c <= 'z'; c++)
//        *s++ = c;
//    s = NULL;
//
//    return 0;
//}
import "C"

import "fmt"

func main() {
        i := C.shm_wr()
        if i != 0 {
                fmt.Println("SystemV Share Memory Create and Write Error:", i)
                return
        }
        fmt.Println("SystemV Share Memory Create and Write Ok")
}

//systemv_shm_rd.go

package main

//#include <sys/types.h>
//#include <sys/ipc.h>
//#include <sys/shm.h>
//#include <stdio.h>
//
//#define SHMSZ     27
//
//int shm_rd() {
//    char c;
//    int shmid;
//    key_t key;
//    char *shm, *s;
//
//    key = 5678;
//
//    if ((shmid = shmget(key, SHMSZ, 0666)) < 0) {
//        return -1;
//    }
//
//    if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) {
//        return -2;
//    }
//
//    s = shm;
//
//    int i = 0;
//    for (i = 0; i < SHMSZ-1; i++)
//        printf("%c ", *(s+i));
//    printf("\n");
//    s = NULL;
//
//    return 0;
//}
import "C"

import "fmt"

import "fmt"

func main() {
        i := C.shm_rd()
        if i != 0 {
                fmt.Println("SystemV Share Memory Create and Read Error:", i)
                return
        }
        fmt.Println("SystemV Share Memory Create and Read Ok")
}

我们通过go build构建上面两个程序，得到两个测试用可执行程序：systemv_shm_wr和systemv_shm_rd。下面我们来构建我们的测试用docker image，Dockerfile内容如下：

FROM centos:centos6
MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
COPY ./systemv_shm_wr /bin/
COPY ./systemv_shm_rd /bin/

构建Docker image：“shmemtest:v1”：

$ sudo docker build -t="shmemtest:v1" ./
Sending build context to Docker daemon 16.81 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
 —> 68edf809afe7
Step 1 : MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
 —> Using cache
 —> c617b456934a
Step 2 : COPY ./systemv_shm_wr /bin/
 —> ea59fb767573
Removing intermediate container 4ce91720897b
Step 3 : COPY ./systemv_shm_rd /bin/
 —> 1ceb207b1009
Removing intermediate container 7ace7ad53a3f
Successfully built 1ceb207b1009

启动一个基于该image的容器：
$ sudo docker run -it "shmemtest:v1" /bin/bash

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
0a2f37bee6eb        shmemtest:v1        "/bin/bash"         28 seconds ago      Up 28 seconds                           elegant_hawking

进入容器，先后执行systemv_shm_wr和systemv_shm_rd，我们得到如下结果：

bash-4.1# systemv_shm_wr
SystemV Share Memory Create and Write Ok
bash-4.1# systemv_shm_rd
a b c d e f g h i j k l m n o p q r s t u v w x y z
SystemV Share Memory Create and Read Ok

在容器运行过程中，SystemV共享内存对象是可以持久化的。systemv_shm_wr退出后，数据依旧得以保留。我们接下来尝试一下重启container后是否还能读出数据：

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
0a2f37bee6eb        shmemtest:v1        "/bin/bash"         8 minutes ago       Up 8 minutes                            elegant_hawking    
$ sudo docker stop 0a2f37bee6eb
0a2f37bee6eb
$ sudo docker start 0a2f37bee6eb
0a2f37bee6eb
$ sudo docker attach 0a2f37bee6eb
bash-4.1# systemv_shm_rd
SystemV Share Memory Create and Read Error: -1

程序返回-1，显然在shmget时就出错了，系统已经没有了key为"5678"的这个共享内存IPC对象了。也就是说当容器stop时，就好比我们的物理主机关机，docker将该容器对应的共享内存IPC对象删除了。

从原理上分析，似乎我们也能得出此结论：毕竟Docker container是通过kernel namespace隔离的，容器中的进程在IPC资源申请时需要加入namespace信息。打个比方，如果我们启动容器的进程pid(物理主机视角)是 1234，那么这容器内进程申请的共享内存IPC资源（比如key=5678）的标识应该类似于“1234:5678”这样的形式。重启容器 后，Docker Daemon无法给该容器分配与上次启动相同的pid，因此pid发生了变化，之前容器中的"1234:5678"保留下来也是毫无意义的，还无端占用系 统资源。因此，System V IPC在Docker容器中的运用与物理机有不同，这方面要小心，目前似乎没有很好的方法，也许以后Docker会加入全局IPC，这个我们只能等待。

二、Mmap映射共享内存

接下来我们探讨mmap共享内存在容器中的支持情况。mmap常见的有两类共享内存映射方式，一种映射到/dev/zero，另外一种则是映射到 Regular Fiile。前者在程序退出后数据自动释放，后者则保留在映射的文件中。后者对我们更有意义，这次测试的也是后者。

同样，我们也先来编写两个测试程序。

//mmap_shm_wr.go
package main

//#include <stdio.h>
//#include <sys/types.h>
//#include <sys/mman.h>
//#include <fcntl.h>
//
//#define SHMSZ     27
//
//int shm_wr()
//{
//      char c;
//      char *shm = NULL;
//      char *s = NULL;
//      int fd;
//      if ((fd = open("./shm.txt", O_RDWR|O_CREAT, S_IRUSR|S_IWUSR)) == -1)  {
//              return -1;
//      }
//
//      lseek(fd, 500, SEEK_CUR);
//      write(fd, "\0", 1);
//      lseek(fd, 0, SEEK_SET);
//
//      shm = (char*)mmap(shm, SHMSZ, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
//      if (!shm) {
//              return -2;
//
//      }
//
//      close(fd);
//      s = shm;
//      for (c = 'a'; c <= 'z'; c++) {
//              *(s+(int)(c – 'a')) = c;
//      }
//      return 0;
//}
import "C"

import "fmt"

func main() {
        i := C.shm_wr()
        if i != 0 {
                fmt.Println("Mmap Share Memory Create and Write Error:", i)
                return
        }
        fmt.Println("Mmap Share Memory Create and Write Ok")
}

//mmap_shm_rd.go
package main

//#include <stdio.h>
//#include <sys/types.h>
//#include <sys/mman.h>
//#include <fcntl.h>
//
//#define SHMSZ     27
//
//int shm_rd()
//{
//      char c;
//      char *shm = NULL;
//      char *s = NULL;
//      int fd;
//      if ((fd = open("./shm.txt", O_RDONLY)) == -1)  {
//              return -1;
//      }
//
//      shm = (char*)mmap(shm, SHMSZ, PROT_READ, MAP_SHARED, fd, 0);
//      if (!shm) {
//              return -2;
//      }
//
//      close(fd);
//      s = shm;
//      int i = 0;
//      for (i = 0; i < SHMSZ – 1; i++) {
//              printf("%c ", *(s + i));
//      }
//      printf("\n");
//
//      return 0;
//}
import "C"

import "fmt"

func main() {
        i := C.shm_rd()
        if i != 0 {
                fmt.Println("Mmap Share Memory Read Error:", i)
                return
        }
        fmt.Println("Mmap Share Memory Read Ok")
}

我们通过go build构建上面两个程序，得到两个测试用可执行程序：mmap_shm_wr和mmap_shm_rd。下面我们来构建我们的测试用docker image，Dockerfile内容如下：

FROM centos:centos6
MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
COPY ./mmap_shm_wr /bin/
COPY ./mmap_shm_rd /bin/

构建Docker image：“shmemtest:v2”：

$ sudo docker build -t="shmemtest:v2" ./
Sending build context to Docker daemon 16.81 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
 —> 68edf809afe7
Step 1 : MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
 —> Using cache
 —> c617b456934a
Step 2 : COPY ./mmap_shm_wr /bin/
 —> Using cache
 —> 01e2f6bc7606
Step 3 : COPY ./mmap_shm_rd /bin/
 —> 0de95503c851
Removing intermediate container 0c472e92809f
Successfully built 0de95503c851

启动一个基于该image的容器：
$ sudo docker run -it "shmemtest:v2" /bin/bash

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
1182f9eca367        shmemtest:v2        "/bin/bash"         11 seconds ago      Up 11 seconds                           distracted_elion

进入容器，先后执行mmap_shm_wr和mmap_shm_rd，我们得到如下结果：

bash-4.1# mmap_shm_wr
Mmap Share Memory Create and Write Ok
bash-4.1# mmap_shm_rd
a b c d e f g h i j k l m n o p q r s t u v w x y z
Mmap Share Memory Read Ok

我们接下来尝试一下重启container后是否还能读出数据：

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
1182f9eca367        shmemtest:v2        "/bin/bash"         About a minute ago   Up About a minute                       distracted_elion   
$ sudo docker stop 1182f9eca367
1182f9eca367
$ sudo docker start 1182f9eca367
1182f9eca367
$ sudo docker attach 1182f9eca367

bash-4.1# mmap_shm_rd
a b c d e f g h i j k l m n o p q r s t u v w x y z
Mmap Share Memory Read Ok

通过执行结果可以看出，通过mmap映射文件方式，共享内存的数据即便在容器重启后依旧可以得到保留。从原理上看，shm.txt是容器内 的一个文件，该文件存储在容器的可写文件系统layer中，从物理主机上看，其位置在/var/lib/docker/aufs/mnt /container_full_id/下，即便容器重启，该文件也不会被删除，而是作为容器文件系统的一部分：

$ sudo docker inspect -f '{{.Id}}' 1182f9eca367
1182f9eca36756219537f9a1c7cd1b62c6439930cc54bc69e87915c5dc8f7b97
$ sudo ls /var/lib/docker/aufs/mnt/1182f9eca36756219537f9a1c7cd1b62c6439930cc54bc69e87915c5dc8f7b97
bin  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  sbin    selinux  shm.txt  srv  sys  tmp  usr  var

就在昨天，就在我们的项目要结项的时候，一个影响力不亚于’广岛原子弹’的bug出炉了，蒙蔽我近一个月的问题终于被澄清了，不过为时已晚，项目即将上线，如果想彻底地解决这个问题，需要对整个系统的实现架构作调整，目前能做的只是’亡羊补牢’了。

这里先简单的说一下问题的原因吧！熟悉Unix编程的人都知道有’共享内存映射’这回事儿，我们的问题恰巧就出在对’共享内存映射’的使用不当上。由于我们使用的底层库采用的是mmap的匿名共享内存映射，所以这里例子中的共享内存映射默认就指使用mmap的映射。我们可以利用下面的一个例子简单说明一下我在项目中遇到的问题，实际上看完这个’精简版’之后你会认为这很简单亚，怎么会让你困惑一个月，的确是这样不假，但是如果加上了繁杂的上下文后，找起来也并不是件容易的事情。

假设我们有这样的4个进程，它们的亲缘关系是这样的：A是爷爷，B、C是兄弟，并同为A的儿子，而D则是孙子，是B的儿子，用图表示如下：
A
| —- B
|         |—-D
| 
| —- C
问题就出在D利用mmap映射到匿名设备上后，将返回的起始地址赋值给一块由A创建，B、C、D都继承并能访问到的共享内存中的指针。C的任务是读写这块由D创建的这块儿共享内存中的数据。明眼人一眼就可以看出，C是访问不到这块D映射的共享内存的，即使C知道那块内存在D中的地址，但是由于C没有映射，在C进程空间中即使访问那个相同的地址，实际上访问的虚拟内存页也是不同的，最终的结果就是dump core。不光是C就连B、A也都无法访问D的那块共享内存，原因这里不详说，任一本质量上乘的有关Unix编程的书都会讲到这一点。

出现这样的问题，自己有推卸不掉的责任，先撇开责任不谈，反思自己在查找bug过程中的行为，我觉得有两个问题是今后需要改正的：
1、始终质疑别人的代码，导致在查找bug的时候戴上了’有色眼镜’，思维也发生了倾斜，把大部分时间和精力都花在查找别人的代码漏洞中，而忽略了对自己代码的细致地分析。不过这个过程到让我学了不少以前未接触的’知识领域’^_^。
2、测试时态度不够端正。其实项目负责人当初就对这块儿的可靠性有质疑，只是他当时也不能具体说明到底哪个地方的使用会出问题，回头看来自己在测试时测试用例不全，也是导致没有及时发现对症问题的一个重要原因，从而失去了走向查找出正确问题所在之道的机会！

问题既然发生了，那么我们如何来解决这个问题呢？我和leader一起想了若干种方法结果都被我们一一否决，最后拿出了一个折衷的方案，该方案虽然不存在上述问题了，但是它也让我们的系统不能完全满足用户的需求。这个方案说来也简单那就是采用’池策略’，而且这个池也是一个扩展性不好的池，也就是说我们在系统初始化的时候就预先映射完毕所有的内存，这样所有的A进程的子进程都会继承A的内存映射关系，从而解决上述问题，不过这样做实际上就给系统加了一个限制，容量上的限制。

在接下来的另一个类似需求的项目中我们还需要使用这样的架构，而且这个延续的项目需要的系统容量更大，在这个系统中我们需要对整体的系统架构进行改动了，否则一旦出问题，就不再是’亡羊’就可以’补牢’的了！

目前部门内所有项目的架构基本上都是基于’共享内存’的，虽然’共享内存’是最快的IPC对象，但是它同样给系统带来进程同步性能低下、亲缘关系错综复杂等弊端，甚至于对于我们目前项目这样的需求都不能很好的支持。程序庞大，动一发而牵全身。当然对架构的改造也不是一朝一夕之事，需要的是魄力、时间和耐心，起码让我们的Unix程序符合K.I.S.S这种最适合Unix的文化，目前我们采用的这种架构还是比较臃肿的。