进程间通信有如下的目的：1、数据传输，一个进程需要将它的数据发送给另一个进程，发送的数据量在一个字节到几M之间；2、共享数据，多个进程想要操作共享数据，一个进程对数据的修改，其他进程应该立刻看到；3、通知事件，一个进程需要向另一个或一组进程发送消息，通知它们发生了某件事情；4、资源共享，多个进程之间共享同样的资源。为了做到这一点，需要内核提供锁和同步机制；5、进程控制，有些进程希望完全控制另一个进程的执行（如Debug进程），此时控制进程希望能够拦截另一个进程的所有陷入和异常，并能够及时知道它的状态改变。
进程间通信（interprocess communication，简称 IPC）指两个进程之间的通信。系统中的每一个进程都有各自的地址空间，并且相互独立、隔离，每个进程都处于自己的地址空间中,因此相互通信比较难，Linux 内核提供了多种进程间通信的机制。
这篇文章讨论如何使用CRIU迁移使用了共享内存的程序，主要讨论其中的前两种共享内存方法，最终介绍一种支持热迁移的C程序共享内存使用方法。
Linux下的进程通信手段基本上是从Unix平台上的进程通信手段继承而来的。而对Unix发展做出重大贡献的两大主力AT&T的贝尔实验室及BSD（加州大学伯克利分校的伯克利软件发布中心）在进程间通信方面的侧重点有所不同。前者对Unix早期的进程间通信手段进行了系统的改进和扩充，形成了“system V IPC”，通信进程局限在单个计算机内；后者则跳过了该限制，形成了基于套接口（socket）的进程间通信机制。Linux则把两者继承了下来，如图示：
消息队列 消息队列是Linux IPC中很常用的一种通信方式，它通常用来在不同进程间发送特定格式的消息数据。 消息队列和之前讨论过的管道和FIFO有很大的区别，主要有以下两点(管道请查阅我的另一篇文章：https://cloud.tencent.com/developer/article/1021159)： Ø 一个进程向消息队列写入消息之前，并不需要某个进程在该队列上等待该消息的到达，而管道和FIFO是相反的，进程向其中写消息时，管道和FIFO必须已经打开来读，否则写进程就会阻塞（默认情况下）。 Ø IP
共享内存可以说是最有用的进程间通信方式，也是最快的IPC形式。两个不同进程A、B共享内存的意思是，同一块物理内存被映射到进程A、B各自的进程地址空间。进程A可以即时看到进程B对共享内存中数据的更新，反之亦然。由于多个进程共享同一块内存区域，必然需要某种同步机制，互斥锁和信号量都可以。采用共享内存通信的一个显而易见的好处是效率高，因为进程可以直接读写内存，而不需要任何数据的拷贝。因此，采用共享内存的通信方式效率是非常高的。
共享内存的优势 采用共享内存通信的一个显而易见的好处是效率高，因为进程可以直接读写内存，而不需要任何数据的拷贝。对于像管道和消息队列等通信方式，则需要在内核和用户空间进行四次的数据拷贝，而共享内存则只拷贝两次数据：一次从输入文件到共享内存区，另一次从共享内存区到输出文件。实际上，进程之间在共享内存时，并不总是读写少量数据后就解除映射，有新的通信时，再重新建立共享内存区域。而是保持共享区域，直到通信完毕为止，这样，数据内容一直保存在共享内存中，并没有写回文件。共享内存中的内容往往是在解除映射时才写回文件的。因
信号量是一种计数器，用来控制对多个进程/线程共享的资源进行访问。常和锁一同使用。 在某个进程/线程正在对某个资源进行访问时，信号量可以阻止另一个进程/线程去打扰。 生产者和消费者模型是信号量的典型使用。
Linux对Namespace的操作，主要是通过clone、setns和unshare这3个系统调用来完成的，clone创建新进程时，接收一个叫flags的参数，这些flag包括CLONE_NEWNS、CLONE_NEWIPC、CLONE_NEWUTS、CLONE_NEWNET（Mount namespace）、CLONE_NEWPID和CLONE_NEWUSER，用于创建新的namespace，这样clone创建出来新进程之后就属于新的namespace了，后续新进程创建的进程默认属于同一namespace。
几种进程间的通信方式：管道，FIFO，消息队列，他们的共同特点就是通过内核来进行通信（假设POSIX消息队列也是在内核中实现的，因为POSIX标准并没有限定它的实现方式）。向管道，FIFO，消息队列写入数据需要把数据从进程复制到内核，从这些IPC读取数据的时候又需要把数据从内核复制到进程。所以这种IPC方式往往需要2次在进程和内核之间进行数据的复制，即进程间的通信必须借助内核来传递。如下图所示：
本文介绍了Linux系统下共享内存的概念、实现方法以及相关的应用，包括共享内存的读写、同步和调试等方面。
我也经常被咨询Linux C++后台开发的学习路线。然而当谈到Linux C++后台开发时，无论Linux还是C++都是一个很大的话题，聪明的程序员需要学会做减法
信号灯概述 什么是信号灯 信号灯用来实现同步，用于多线程，多进程之间同步共享资源（临界资源）。 PV原语：信号灯使用PV原语 P原语操作的动作是： u sem减1。 u sem减1后仍大于或等于零，则进程继续执行。 u 若sem减1后小于零，则该进程被阻塞后进入与该信号相对应的队列中，然后转进程调度。 V原语操作的动作是： u sem加1。 u 若相加结果大于零，则进程继续执行。 u 若相加结果小于或等于零，则从该信号的等待队列中唤醒一等待进程，然后再返回原进程继续执行或转进程调度。 信号灯分类 按信号灯实
PostgreSQL某些时候会耗尽操作系统的各种资源限制，当同一个系统上运行着多个拷贝的服务器或在一个非常大的安装中时尤其如此。本节解释了PostgreSQL使用的内核资源以及你可以采取的用于解决内核资源消耗相关问题的步骤。
你是否经常会遇到这样的困难：处理不同进程的应用程序时，需求方会要求包含所有进程以实现更多隔离。在这种情况下，一个常见的问题是：如何在同一 Node 中的 Pod 间实现共享内存。王涛是腾讯云的高级工程师，在本文中，他将阐述一种在 Pod 间利用 Posix/SystemV 来实现共享内存的解决方案，一起来看看吧。
目前我们所提到的容器技术、虚拟化技术（不论何种抽象层次下的虚拟化技术）都能做到资源层面上的隔离和限制。
说到共享内存，有过操作系统学习的童靴应该十分熟悉，往往聊到进程之间通信的4种方式时就能脱口而出（面试最常见的问题之一啊，哈哈哈~~）：
本文介绍了Linux信号量、POSIX信号量、Linux条件变量和Linux线程同步基本概念，并通过代码示例展示了如何使用这些技术进行线程同步。
我学习一个东西，喜欢先从整体上了解框架，然后再了解所学习的东西是框架中的哪一细分部分。今天就聊一聊Linux系统进程之间的通信。
继上节使用原生多进程并行运行，基于Redis作为消息队列完成了圆周率的计算，本节我们使用原生操作系统消息队列来替换Redis。
一些公共服务组件在追求性能过程中，与业务耦合太紧，造成在制作基础镜像时，都会把这些基础组件都打包进去，因此当业务镜像启动后，容器里面一大堆进程，这让Kubernetes对Pod的管理存在很大隐患。为了让业务容器瘦身，更是为了基础组件自身的管理更独立和方便，将基础组件从业务镜像中剥离并DaemonSet容器化部署。然而一些基础组件Agent与业务Pod之间通过共享内存的方式进行通信，同一Node中跨Pod的共享内存方案是首先要解决的问题。
Linux 3.8 合并窗口接受了 Eric Biederman 的大量用户命名空间及相关的补丁。尽管仍有一些细节待完成，例如，许多 Linux 文件系统还不知道用户命名空间，但用户命名空间的实现已经在功能上完成了。
自研的公共基础组件，比如服务路由组件、安全组件等，通常以进程方式部署在Node上并同时为Node上所有的业务提供服务，微服务及容器化之后，服务数量成百上千的增长，如果以sidecar或者打包到业务Image中继续Per Pod Per Agent的方式部署, 那么基础组件的Server端的压力可能也会成百上千的增长，风险是很大的。因此，我们希望能以DaemonSet方式部署这些组件的Agents。
Docker通过namespace(命名空间)实现资源隔离。Namespace是Linux系统提供的资源隔离机制，只有在同一个namespace下的进程可以互相联系，但无法感受外部进程的存在，从而实现资源隔离。
Envoy Proxy 在大多数情况下都是作为 Sidecar 与应用部署在同一网络环境中，每个应用只需要与 Envoy（localhost）交互，不需要知道其他服务的地址。然而这并不是 Envoy 仅有的使用场景，它本身就是一个七层代理，通过模块化结构实现了流量治理、信息监控等核心功能，比如流量治理功能就包括自动重连、熔断、全局限速、流量镜像和异常检测等多种高级功能，因此 Envoy 也常常被用于边缘代理，比如 Istio 的 Ingress Gateway、基于 Envoy 实现的 Ingress Controller（Contour、Ambassador[1]、Gloo[2] 等）。
This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 17667276800 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
Posix IPC共有三种类型： Posix消息队列 Posix信号灯 Posix共享内存区
版权声明：本文为博主原创文章，转载请注明博客地址： https://blog.csdn.net/zy010101/article/details/83790850
在某些情况下，我们可能需要在两个Python程序之间共享数据，其中一个程序将数据写入计算机内存，然后退出，另一个程序启动后读取第一个程序保存的内存数据。这乍听之下似乎不太可能实现，但在某些操作系统中，可以使用共享内存段来实现这一目标。
消息队列是Linux IPC中很常用的一种通信方式，它通常用来在不同进程间发送特定格式的消息数据。
Unix domain socket 又叫 IPC(inter-process communication 进程间通信) socket，用于实现同一主机上的进程间通信。socket 原本是为网络通讯设计的，但后来在 socket 的框架上发展出一种 IPC 机制，就是 UNIX domain socket。虽然网络 socket 也可用于同一台主机的进程间通讯(通过 loopback 地址 127.0.0.1)，但是 UNIX domain socket 用于 IPC 更有效率：不需要经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答等，只是将应用层数据从一个进程拷贝到另一个进程。这是因为，IPC 机制本质上是可靠的通讯，而网络协议是为不可靠的通讯设计的。
《UNIX环境高级编程（第3版）》是被誉为UNIX编程“圣经”的Advanced Programming in the UNIX Environment一书的第3版。在本书第2版出版后的8年中，UNIX行业发生了巨大的变化，特别是影响UNIX编程接口的有关标准变化很大。本书在保持前一版风格的基础上，根据最新的标准对内容进行了修订和增补，反映了最新的技术发展。书中除了介绍UNIX文件和目录、标准I/O库、系统数据文件和信息、进程环境、进程控制、进程关系、信号、线程、线程控制、守护进程、各种I/O、进程间通信、网络IPC、伪终端等方面的内容，还在此基础上介绍了众多应用实例，包括如何创建数据库函数库以及如何与网络打印机通信等。此外，还在附录中给出了函数原型和部分习题的答案。
前言 互联网公司一般都会运行着几千到几万的服务器。一般的监控会采用类似ganglia/falcon类似的工具，在本地启动一个agent，把数据统计上报到集中式的服务器中，用来监控和分析系统的问题。 另外，有atop这样的工具，可以运行在服务器上，在本地写下record文件，atop命令本身也可以分析record文件，其中保存的数据的粒度更加细致，可以精确到线程级别，还有IPC，主频等等。 经验来看，atop每天生成的record文件大约500M左右，保存最近的一段时间，似乎也不是问题。用集中式的监控，配合上atop，对于问题分析来说，会有一些帮助。 分析 1,atop的改进 atop的代码量本身并不大，官方的代码在： https://github.com/Atoptool/atop.git 在使用atop的过程中，遇到了一些问题，作者也做了相应的修改： https://github.com/bytedance/atop 在bytedance-features分支上。作者把patch发送给maintainer，但是maintainer一直没有回复。在这里，列举一下改动的内容，如下。 2,smaps的优化 尝试使用smaps_rollup代替smaps，用来提高atop收集进程的PSS内存使用的效率。这个patch会在4.14上有所提升。一般情况下，建议在atop收集的时候不要加上-R选项。因为在atop读/proc/PID/smaps的时候，会walk整个PID进程的页表，期间会lock住内存页表的锁。如果在这期间PID进程发生了page fault，也需要lock，就会造成锁的进程。影响PID进程的性能。 3,数据破损问题 atop使用裸数据的方式保存record文件，其中包括三部分：raw record，就是头信息; scompbuf，是系统状态信息的数据; pcompbuf，是task级的状态信息数据，大小和task数量有关系。为了减小record文件的大小，对于 scompbuf和pcompbuf还采用了压缩。所以，数据必须完整的 rr,scompbuf,pcompbuf顺序写下去的，否则atop无法识别数据。 good case : ... rr,scompbuf,pcompbuf ... rr,scompbuf,pcompbuf ... bad case : ... rr,scompbuf[missing] ... rr,scompbuf,pcompbuf … 例如上面的例子，在写完rr,scompbuf之后，atop发生了crash，再重新启动，就会丢失后面的 pcompbuf，造成了整个record文件的不可用。 在patch中，作者使用writev进行写入数据，要么都写入成功，要么都写入不成功，用来防止这种case发生。 4,IPC造成的虚拟机性能抖动 IPC,instructions per cycle。可以用来衡量CPU运行的效率。通常是通过perf采集的数据。 提到perf，就要说明一下它的工作原理：intel的CPU上集成了PMU，用来采集硬件的信息。可以收集的硬件信息很多，可以通过perf list | grep Hardware来看。但是硬件的寄存器有数量限制，所以需要通过wrmsr指令告诉CPU收集哪些具体的事件，再通过rdpmc指令来读取对应的数据。 在虚拟化场景下，在虚拟机中使用PMU又复杂了一下，在虚拟机中执行wrmsr和rdpmc的时候，都需要虚拟机从none-root模式退出，影响了虚拟机的性能。 在patch中，作者让atop支持perfevents的配置，支持三种模式：enable模式，启用perf收集IPC。disable模式，禁用perf收集IPC。auto模式，在启动的时候，atop自动检查是否在虚拟机中运行，如果在虚拟机中，禁用;在物理级中，启用。默认是auto模式。 5,减小record文件 如果是大规格的服务器，40CPU，甚至到96CPU，通常运行大量的docker，里面运行了很多的task。其中很多task占用资源很少，但是依然会占用atop的record文件。 在patch中，支持了配置参数recordcputop & recordmemtop。用来配置收集cpu和内存的topN。其他的task可以忽略。作者测试线上的服务器36CPU, about 500 processes的场景，大约节省了40%的磁盘空间。 6,加速读record 一般在ganglia上看到系统抖动，例如下午三点十分，在对应的服务器上执行： atop -r / var/log/atop/atop_xxxx -b 15:10 如前文所述，因为rawrecord的原因，则会从头读到尾，直到匹配到对应的时间。对于log盘的使用，尤其是虚拟化场景，会限制IOPS。这
IPC的意思是“ 进程间通信机制”，Linux内核有三种常用IPC对象可以拿来做进程间通信--消息队列，共享内存，信号量。这三种IPC对象在Linux内核中都以链表的形式存储，它们都有特定的ID来标识（消息队列标识符msqid、共享内存标识符shmid，信号量标识符semid）。
用了这么久的docker，对docker的实现原理挺感兴趣的，在对Linux下docker的实现原理了解之后，我没有用过Windows下的docker，更加好奇Windows下的docker是如何实现的（它并不开源），问了问owefsad师傅，说是可能用到了hyperV，那么可能类似Vmware吗？不知道啊。
本文主要理解的一个核心点，什么是Pod？我们先不关注Pod怎么使用，怎么调度，如何实现最佳实践。这些问题后续继续讨论，在不懂为什么k8s要有Pod的情况下，去先深究最佳实践没有实际意义。
一、在前面介绍了system v 消息队列的相关知识，现在来稍微看看posix 消息队列。 posix消息队列的一个可能实现如下图： 其实消息队列就是一个可以让进程间交换数据的场所，而两个标准的消息队
PID,IPC,Network等系统资源不再是全局性的，而是属于特定的Namespace。每个Namespace里面的资源对其他Namespace都是透明的。要创建新的Namespace，只需要在调用clone时指定相应的flag。 Linux Namespaces机制为实现基于容器的虚拟化技术提供了很好的基础，LXC（Linux containers）就是利用这一特性实现了资源的隔离。不同Container内的进程属于不同的Namespace，彼此透明，互不干扰。下面我们就从clone系统调用的flag出发，来介绍各个Namespace。
本文主要探讨了Linux消息队列的发送、接收以及异步通知机制。首先介绍了消息队列的发送和接收过程，然后详细描述了异步通知的方式，最后通过一个示例展示了如何使用epoll机制实现异步通知。
共享内存是一个非常有意思的话题，一方面共享内存避免了通讯过程中的内存复制问题，是 Linux IPC 通讯中效率最高的一种。另一方面，因为可以直接对内存甚至其他进程的内存进行修改，利用共享内存可以实现一些常规操作无法做到的奇技淫巧。
程磊，某手机大厂系统开发工程师，阅码场荣誉总编辑，最大的爱好是钻研Linux内核基本原理。 一、进程间通信的本质
• Provide environment for co-kernel real-time drivers
二值信号灯：值为0或1的信号灯。资源如果被锁住就是0，如果可用为1 计数信号灯：值在0到某个限制值之间的信号灯。信号灯的值就是可用资源数
一位同学曾给我打比方：宿主机就好比一间大房子，docker把它成了N个小隔断。在这些小隔断之间，有独立的卫生间、小床、电视...
Docker容器本质上是宿主机上的进程。Docker通过namespaces实现了资源隔离，通过cgroups实现了资源限制，通过写时复制机制（copy-on-write）实现了高效的文件操作。
管道可用于具有亲缘关系进程间的通信，有名管道克服了管道没有名字的限制，因此，除具有管道所具有的功能外，它还允许无亲缘关系进程间的通信；
1.管道（Pipe）及有名管道（namedpipe）:管道可用于具有亲缘关系进程间的通信,有名管道克服了管道没有名字的限制,因此,除具有管道所具有的功能外,它还允许无亲缘关系进程间的通信 2.信号（Signal）:信号是比较复杂的通信方式,用于通知接受进程有某种事件发生,除了用于进程间通信外,进程还可以发送信号给进程本身;linux除了支持Unix早期信号语义函数sigal外,还支持语义符合Posix.1标准的信号函数sigaction（实际上,该函数是基于BSD的,BSD为了实现可靠信号机制,又能够统一对外接口,用sigaction函数重新实现了signal函数） 3.消息队列:消息队列是消息的链接表,包括Posix消息队列systemV消息队列.有足够权限的进程可以向队列中添加消息,被赋予读权限的进程则可以读走队列中的消息.消息队列克服了信号承载信息量少,管道只能承载无格式字节流以及缓冲区大小受限等缺点. 共享内存:使得多个进程可以访问同一块内存空间,是最快的可用IPC形式.是针对其他通信机制运行效率较低而设计的.往往与其它通信机制,如信号量结合使用,来达到进程间的同步及互斥. 4.信号量（semaphore）:主要作为进程间以及同一进程不同线程之间的同步手段。 5.套接口（Socket）:更为一般的进程间通信机制,可用于不同机器之间的进程间通信.起初是由Unix系统的BSD分支开发出来的,但现在一般可以移植到其它类Unix系统上:Linux和SystemV的变种都支持套接字. PHP版本实现:https://www.jianshu.com/p/08bcf724196b
在本文中，传统UNIX fork之后，我给出传统的UNIX fork在Linux内核中的变体clone系统调用的精彩。
NameSpace Namespace又称为命名空间（也可翻译为名字空间），它是将内核的全局资源做封装，使得每个Namespace都有一份独立的资源，因此不同的进程在各自的Namespace内对同一种资源的使用不会互相干扰。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
