实现与后台进程实时通信控制运行实例的惯用方式是什么？

典型实现方案 #

这类需求的标准实现是客户端-服务端（C/S）架构：

• 执行foo start时实际启动的是后台守护进程（服务端），负责运行业务逻辑，同时监听控制请求
• 后续执行的foo refresh bar,baz等都是轻量化的客户端命令，仅负责把控制请求发给后台服务端，拿到结果后打印输出即可
• 二者之间通过进程间通信（IPC）机制传输命令和返回结果，本地场景最常用Unix域套接字（UDS），跨主机场景可以用TCP端口。

如何定位运行中的实例 #

常用的定位方式有两种，可搭配使用：

• 固定路径的PID文件：守护进程启动时把自身进程ID写入约定好的固定路径文件（比如/run/foo.pid），客户端命令执行时先读取该文件，再校验对应PID的进程是否存活、是否是目标程序，避免PID复用导致的误判。
• 固定路径的Unix域套接字文件：守护进程启动时在固定路径（比如/tmp/foo.sock）创建UDS并监听，客户端直接尝试连接该套接字，能连上就说明实例正常运行，连不上就代表无运行中的实例，这种方式同时完成了实例存活校验和通信通道建立，比PID文件更便捷。

不同实例能否共享channel #

不能。
不管是Go语言的channel还是其他语言里类似的进程内通信结构，都属于当前进程的用户态内存数据，而不同进程的虚拟地址空间完全隔离，无法直接访问对方的内存空间，因此不存在跨进程共享channel的可能性。如果需要多个实例之间通信，直接用UDS、管道、消息队列、共享内存等标准IPC机制即可。

最简实现流程参考 #

1. foo start执行逻辑：
   1. 检查是否已有运行中的实例（尝试连接UDS或者校验PID文件），如果已存在直接报错退出
   2. 无运行实例则fork子进程作为守护进程，父进程退出，子进程启动业务逻辑同时监听UDS
2. foo refresh bar,baz等控制命令执行逻辑：
   1. 连接约定路径的UDS，连不上则报错提示无运行实例
   2. 按预先约定的格式把命令和参数发送给守护进程
   3. 接收守护进程返回的执行结果，打印到终端
3. 守护进程退出时主动删除PID文件和UDS文件，启动时如果发现残留的无效套接字/PID文件，先清理再启动。

内容的提问来源于stack exchange，提问作者nebulaeandstars