Linux进程间通信方式对比

参考：

Linux进程间通信总结-百度开发者中心

Linux操作系统提供了多种进程间通信（IPC）的方式，每种方式都有其独特的应用场景和优缺点。下面将对Linux下的进程间通信方式进行总结和比较。

管道（Pipe）

管道是最早的进程间通信方式之一，它通过将一个进程的输出连接到另一个进程的输入来实现通信。管道可以分为匿名管道和有名管道两种。匿名管道只能在具有亲缘关系的进程之间使用，有名管道则可以在任意两个进程之间使用。

优点：

1. 实现简单：管道是Linux操作系统自带的一种通信方式，使用起来比较简单。
2. 无须第三方支持：管道不需要第三方软件的支撑，因此性能较高。

缺点：

1. 通信能力有限：管道只能单向传输数据，且数据量较小，不适合传输大量数据。
2. 通信双方必须事先存在：管道只能在具有亲缘关系的进程之间使用，且通信双方必须事先存在。

通常所说的管道，一般指的就是匿名管道。

匿名管道是一种用于进程间通信的机制，它允许具有亲缘关系的进程（如父子进程）之间进行单向通信。在Linux系统中，匿名管道通过pipe系统调用来创建，创建一个无名管道，该管道存在于内存中，不需要指定路径来标识。匿名管道的实现原理是通过fork函数创建子进程，使得子进程能够继承父进程的文件描述符表，从而通过相同的文件描述符指向同一个页缓冲区，进而实现父子进程之间的通信。

有名管道又叫FIFO。

FIFO（First In First Out，先进先出）是一种特殊类型的文件，它允许没有亲缘关系的进程之间进行通信。与无名管道不同，FIFO存在于文件系统中，具有独立的文件名和文件属性，可以通过路径名访问，这使得无关联的进程能够通过打开和读写这个文件来进行数据交换，因此即使创建它的进程已经退出，其他进程仍然可以通过这个路径名访问它。这种机制使得FIFO在多生产者和多消费者的场景中非常有用。

FIFO很多地方都是指队列，应当要和这里的FIFO管道场景进行名称和概念上的区分。

有名管道之所以被称为FIFO，是因为FIFO代表“First In First Out”，即先进先出。

由于FIFO中的数据遵循先进先出的原则，即最早写入的数据会最先被读取，因此得名“FIFO”。这种机制确保了数据的顺序性和一致性，使得FIFO成为一种简单而强大的进程间通信方式。

消息队列（Message Queue）

消息队列是一种基于消息的通信方式，它允许进程之间发送和接收消息。消息队列可以实现异步通信，即发送和接收消息的进程可以不同时运行。

优点：

1. 支持异步通信：消息队列可以实现异步通信，提高系统的并发性能。
2. 数据持久化：消息队列可以将数据持久化存储，保证数据的安全性。

缺点：

1. 性能开销较大：消息队列需要维护消息的存储和转发，因此性能开销较大。
2. 可能会引起死锁：在多进程访问同一个消息队列时，可能会引起死锁问题。

• 缺点：如果a给b发送的数据过大，并且通信频繁，那消息队列就不合适了，因为数据过大，a发送数据的时间长，b去拷贝数据花费时间也长，效率就会变低。
• 优点：管道一旦相关进程退出，那里面的数据也就没有了，但消息队列不一样，一个进程向里面写入数据后退出，另一个进程仍然可以取数据。

参考：https://www.cnblogs.com/feily/articles/14160817.html

消息队列不适合比较大数据的传输，因为在内核中每个消息体都有一个最大长度的限制，同时所有队列所包含的全部消息体的总长度也是有上限。在 Linux 内核中，会有两个宏定义 MSGMAX 和 MSGMNB，它们以字节为单位，分别定义了一条消息的最大长度和一个队列的最大长度。

消息队列通信过程中，存在用户态与内核态之间的数据拷贝开销，因为进程写入数据到内核中的消息队列时，会发生从用户态拷贝数据到内核态的过程，同理另一进程读取内核中的消息数据时，会发生从内核态拷贝数据到用户态的过程。

Linux的消息队列是由内核维护的。

消息队列是Linux中的一种进程间通信（IPC）机制，它允许不同进程之间通过发送和接收消息来进行通信。这种通信机制提供了一种异步的通信方式，意味着发送者和接收者不需要同时存在或者同时执行。

在Linux内核中，消息队列以链表的形式实现，每个消息都是一个数据块，包含消息类型和内容。消息队列由操作系统内核维护，每个消息队列都有一个唯一的标识符（msgid），用于区分不同的消息队列。当进程向消息队列发送消息时，实际上是向这个数据结构中插入一个新结点；从消息队列读取数据时，则是从这个数据结构中删除一个结点。

共享内存（Shared Memory）

共享内存允许多个进程共享一段内存空间，从而实现快速的数据交换。共享内存可以是全共享内存或段共享内存，其中全共享内存允许多个进程同时读写同一段内存空间，而段共享内存则只允许一个进程读写某一段内存空间。

优点：

1. 速度快：共享内存允许多个进程直接访问同一段内存空间，因此速度非常快。
2. 数据共享：共享内存可以实现多个进程之间的数据共享。

缺点：

1. 同步问题：多个进程同时访问共享内存时，需要解决同步问题，以避免出现竞态条件。
2. 可能导致死锁：在多进程访问共享内存时，可能会引起死锁问题。

针对消息队列的缺点，共享内存允许多个进程共享一个给定的存储区，由于他们是共享一块内存数据，减少了内存拷贝的时间，因此速度非常快。

但这里我们可能会问：每个进程不是独立的吗？怎么可以共享内存呢？

其实，系统加载一个进程时，分配给进程的内存并不是实际的物理内存，而是虚拟内存空间，我们可以让两个进程各自拿出一块虚拟地址空间来，然后映射到相同的物理内存中，这样虽然两个进程有独立的虚拟地址空间，但有一部分是映射的相同的物理内存，这样就完成了内存共享机制，如下图所示：

缺点：多进程竞争内存，类似于我们平常说的线程安全。

进程间的共享内存类似于进程中的全局变量，只不过，共享内存是供多个进程使用，全局变量是供多个线程使用。 

信号量（Semaphore）

信号量是一种用于控制多个进程对共享资源的访问的机制。它通过维护一个计数器来记录可用资源的数量，当一个进程需要访问资源时，需要先获取信号量。如果信号量的值为0，则表示资源不可用；如果信号量的值大于0，则表示资源可用，该进程可以获取资源并减少信号量的值。

优点：

1. 可以控制并发访问：信号量可以控制多个进程对共享资源的并发访问，避免出现竞态条件。
2. 实现简单：信号量的实现比较简单，使用起来也比较方便。

缺点：

1. 可能会导致死锁：在多进程访问共享资源时，如果不合理地使用信号量，可能会导致死锁问题。
2. 无法传递大量数据：信号量只能用于控制资源的访问，无法传递大量数据。

套接字（Socket）

前面提到的管道、消息队列、共享内存以及信号量都是在同一台主机上进行进程间通信，那要想跨网络与不同主机上的进程之间通信，就需要 Socket 通信了。

实际上，Socket 通信不仅可以跨网络与不同主机的进程间通信，还可以在同主机上进程间通信。

套接字基于网络协议进行数据传输，可以用于不同操作系统之间的通信。套接字可以分为流套接字和数据报套接字两种类型。流套接字提供可靠的、双向的、面向连接的数据传输服务；数据报套接字提供不可靠的、无连接的数据传输服务。

优点：

1. 支持跨平台通信：套接字适用于不同主机之间的进程间通信，可以实现跨平台通信。
2. 其实也可以用于同一个主机上不同进程间的数据通信，也就是unix域Socket。

参考：https://www.cnblogs.com/feily/articles/14160817.html

根据创建 socket 类型的不同，通信的方式也就不同：

• 实现 TCP 字节流通信：socket 类型是 AF_INET 和 SOCK_STREAM；
• 实现 UDP 数据报通信：socket 类型是 AF_INET 和 SOCK_DGRAM；
• 实现本地进程间通信：「本地字节流 socket 」类型是 AF_LOCAL 和 SOCK_STREAM，「本地数据报 socket 」类型是 AF_LOCAL 和 SOCK_DGRAM。另外，AF_UNIX 和 AF_LOCAL 是等价的，所以 AF_UNIX 也属于本地 socket；

其实市面上还有一些专门用于进程间或者线程间通信的三方库，这些库实现了一套自己的进程间通信机制（其实大都是基于基本的socket进程间通信方式来封装和改进的），我们移植这些库之后，再使用这些三方库提供的API，就能很方便地实现进程间的通信，更稳定更高效。 

Linux中有什么好用的消息三方库吗

参考：消息队列的介绍和常用开源消息队列的对比 - 清白之年980410 - 博客园 (cnblogs.com)

Linux中有许多好用且广泛使用的消息三方库，这些库为开发者提供了强大的工具来处理各种消息传递和通信需求。以下是一些值得推荐的消息三方库：

1. ZeroMQ

   1. 特点：ZeroMQ号称是“史上最快的消息队列”，基于C语言开发，可以在任何平台通过任何代码连接。它支持多种传输协议（如inproc、IPC、TCP、TIPC、多播）和消息模式（如发布-订阅、推-拉、共享队列等），具有高速异步I/O引擎，专为高吞吐量/低延迟的场景开发。

   2. 优势：简单灵活，性能高，可嵌入性强。

   3. 劣势：需要开发者自己实现消息的持久化和可靠性保证。

2. RabbitMQ

   1. 特点：RabbitMQ是一个在AMQP（高级消息队列协议）基础上完成的企业消息系统，是当前最主流的消息中间件之一。它提供了可靠性、灵活的路由、消息集群、队列高可用性等多种特性，并支持多种消息队列协议和编程语言。

   2. 优势：性能较好，高并发，健壮稳定，易用跨平台，支持多种语言，文档齐全。

   3. 劣势：不利于二次开发和维护，学习和维护成本较高。

3. ActiveMQ

   1. 特点：ActiveMQ被誉为消息中间件的“瑞士军刀”，介于ZeroMQ和RabbitMQ之间。它支持多种协议（如OpenWire、Stomp、AMQP v1.0、MQTT v3.1、REST、Ajax、Webservice等），并完全支持JMS1.1和J2EE 1.4规范。

   2. 优势：易于实现高级场景，功能丰富。

   3. 劣势：不够轻巧，对于队列较多的情况支持不好，可能有丢消息的情况。

4. Kafka

   1. 特点：Apache Kafka是一个分布式消息发布订阅系统，最初由LinkedIn公司基于独特的设计实现。它具有高吞吐量、可持久化、可扩展等优点，适用于大数据实时处理和日志收集等场景。

   2. 优势：高吞吐量，可持久化，可扩展性好。

   3. 劣势：配置相对复杂，对小文件处理效率不高。

5. RocketMQ

   1. 特点：RocketMQ是阿里巴巴开源的一款分布式消息中间件，具有高并发、高可靠、低延迟等特点。它支持多种消息模式（如发布-订阅、请求-回复等），并提供了丰富的管理监控功能。

   2. 优势：金融级的稳定性和可靠性，易于扩展和管理。

   3. 劣势：相对较新，社区生态可能不如RabbitMQ和Kafka成熟。

6. MetaMq

   1. 特点：MetaMq是一款分布式消息中间件，具有高性能、可扩展、易用等特点。它支持多种消息模式（如发布-订阅、请求-回复等），并提供了丰富的API接口供开发者使用。

   2. 优势：高性能，易用性好，社区活跃。

   3. 劣势：相对较新，知名度可能不如其他几款消息队列高。

总的来说，以上每个库都有其独特的优势和适用场景，开发者可以根据具体需求选择合适的库进行使用。在选择时，建议综合考虑性能、稳定性、易用性、社区支持等多个因素。

linux中三方消息库和传统的进程间通信方式有什么区别？

在Linux系统中，传统的进程间通信（IPC）方式与第三方消息库在实现机制、性能以及灵活性等方面存在区别，以下是详细的对比分析：

1. 实现机制

   1. 传统IPC：包括管道（匿名和命名管道）、信号、消息队列、共享内存和信号量等。这些方式通常由操作系统内核直接提供支持，通过系统调用接口进行操作。

   2. 第三方消息库：如ZeroMQ、RabbitMQ、Kafka等，这些库提供了更为高级的API和抽象层，隐藏了底层复杂的实现细节。它们通常基于TCP/IP或其他协议进行通信，并提供了丰富的功能和特性，如持久化、消息路由、负载均衡等。

2. 性能

   1. 传统IPC：性能较高，因为数据拷贝次数较少，且无需网络传输。但共享内存需要同步机制来防止数据竞争，可能会影响性能。

   2. 第三方消息库：性能可能受到网络延迟和带宽的限制，但很多库都针对高吞吐量和低延迟进行了优化。例如，ZeroMQ号称是“史上最快的消息队列”，具有高性能的特点。

3. 灵活性

   1. 传统IPC：功能相对简单，主要满足基本的进程间通信需求。例如，管道只能用于父子进程或兄弟进程之间的通信，且数据传输是单向的。

   2. 第三方消息库：提供了更为灵活和强大的功能。例如，RabbitMQ支持多种消息模式（如发布-订阅、推-拉等），并且可以很容易地与其他系统集成。

4. 易用性

   1. 传统IPC：使用较为复杂，需要开发者对操作系统提供的API有深入的了解。同时，由于涉及系统调用，错误处理也较为繁琐。

   2. 第三方消息库：通常提供了易于使用的API和文档，简化了开发过程。例如，ZeroMQ提供了跨语言的API，使得不同编程语言的开发者都可以方便地使用。

5. 可扩展性

   1. 传统IPC：适用于本地进程间的通信，对于分布式系统的支持有限。例如，管道和共享内存只能在本地使用，无法跨网络传输数据。

   2. 第三方消息库：设计时就考虑了可扩展性和分布式系统的需求。例如，Kafka是一个分布式消息系统，可以轻松地扩展到多个节点上。

总的来说，传统的进程间通信方式在Linux系统中已经非常成熟和稳定，适用于大多数本地进程间的通信需求。而第三方消息库则提供了更为高级和灵活的功能，适用于构建复杂的分布式系统和需要高性能通信的场景。在选择时，应根据具体应用的需求和场景来决定使用哪种方式。

补充

通过文件是不是也可以实现进程间通信？

通过文件可以实现进程间通信（IPC）。以下是对通过文件实现进程间通信的详细介绍：

1. 共享文件：两个或多个进程可以通过共享同一个文件来进行数据交换。一个进程向文件中写入数据，另一个进程从文件中读取数据，从而实现通信。这种方式简单易行，但需要注意文件的读写同步问题。

2. 内存映射文件：内存映射文件允许进程将文件内容直接映射到其地址空间中，从而像操作内存一样访问文件内容。不同进程可以共享同一个内存映射文件，实现高效的数据交换。

总的来说，通过文件实现进程间通信是一种有效且常用的方法，适用于多种场景和需求。在实际应用中，可以根据具体需求选择合适的方式来实现进程间的通信和协作。

进程间通信（IPC）是操作系统中不同进程之间交换数据和信息的机制。在讨论进程间通信的方式时，共享文件作为一种潜在的通信手段，有时并未被广泛提及。这背后有多重原因，具体分析如下：

1. 同步问题：共享文件方式可能导致读写同步问题。当一个进程写入文件而另一个进程尝试读取时，如果两者的执行速度不匹配（如写操作慢于读操作），则读操作可能无法及时获取到最新数据。这种同步问题需要额外的机制来协调，增加了实现的复杂性。

2. 性能开销：使用共享文件进行进程间通信通常涉及磁盘I/O操作，这相对于内存中的通信方式（如共享内存、消息队列等）来说，性能开销较大。磁盘I/O操作比内存访问要慢得多，特别是在大量数据传输时，这种性能差异会更加明显。

3. 安全性考虑：共享文件作为进程间通信的方式，其安全性也是一个需要考虑的因素。文件系统通常对文件的读写权限有一定的控制，但在某些情况下，不当的文件权限设置可能导致安全漏洞。例如，一个恶意进程可能通过修改共享文件来影响其他进程的行为或窃取敏感信息。

4. 适用场景有限：共享文件方式更适用于需要持久化存储数据的场景，而不是实时的进程间通信。在需要快速、高效地交换数据的场合，如多线程编程或高性能计算中，共享文件并不是最佳选择。

综上所述，尽管共享文件在理论上可以用于进程间通信，但由于同步问题、性能开销、安全性考虑以及适用场景有限等原因，它在实践中并不常被提及或使用。相反，开发者更倾向于使用更为高效、安全且适合特定场景的进程间通信方式，如管道、消息队列、共享内存和套接字等。

更多待补充。