我有一个简单的C ++服务（API端点），每调用一次API就增加一个计数器。 当调用者将数据发送到http://10.0.0.1/add时 ，计数器必须加1，并将计数器的值返回给调用者。
当服务被docker化时，事情变得更加复杂。 当同一个服务的两个实例运行时，必须以primefaces方式完成添加操作，即将计数器值存储在数据库中，并且每个docker实例都必须获取一个锁，获取旧值，添加一个，返回给调用者并解锁。
当实例是同一台Linux机器上的进程时，我们使用共享内存来高效地locking，读取，写入和解锁共享数据，并且性能被接受。 但是，当我们使用docker和数据库时，性能很低。 结果是好的，但性能低下。
dockerized属性的实例之间执行像上面描述的操作之间的规范方式是什么？ 容器化过程是否有“共享内存”function？
它看起来像你的情况数据库是开销。 您只需要一些分布式轻量级键值存储和共享键锁定支持。 这里有一些候选人：
--ipc docker run的--ipc选项启用容器之间的共享内存访问：
IPC设置（–ipc）
--ipc=""：设置容器的IPC模式，
'container:<name|id>'：重用另一个容器的IPC命名空间
'host'：在容器内使用主机的IPC命名空间默认情况下，所有容器都启用了IPC命名空间。
IPC（POSIX / SysV IPC）命名空间提供了命名共享内存段，信号量和消息队列的分离。
共享内存段用于以内存速度加速进程间通信，而不是通过管道或通过网络堆栈。 共享内存通常被数据库和定制（通常是C / OpenMPI，C ++ /使用boost库）用于科学计算和金融服务行业的高性能应用程序所使用。 如果这些类型的应用程序分成多个容器，则可能需要共享容器的IPC机制。
本文提供了一些使用示例。
我正面临类似的问题，并决定把它挖到头上。
唯一快速的是域套接字。 所以我创建了一个小型的c程序，在共享卷/套接字上的域套接字上侦听。
在gitlab.com上查看测试的工作概念。
counter.c完成这个工作，监听socket / count.sock并在数据报中收到一个字符：
进行概念测试：
counter --interval=1000000 =>启动计数器 test_counter --repeats=100000 stress =>向套接字发送100k请求 test_counter reset set的计数器清零 test_counter --quiet --strip result返回没有\n的计数器 test_counter [count]递增计数器并返回结果。 2码头容器建立： count和test 回购
并测试，我在gitlab运行器中使用docker-compose.yml：
my-test: image: dockregi.gioxa.com/dgoo2308/dockersocket:test links: - counter entrypoint: - /test_counter - --repeats=${REPEATS} - --timeout=200 - stress volumes: - './sockets:/sockets' counter: image: dockregi.gioxa.com/dgoo2308/dockersocket:count volumes: - './sockets:/sockets' entrypoint: - /counter - --start_delay=100 - --interval=${TARGET}
开始测试：
mkdir sockets docker-compose pull --parallel docker-compose up -d docker-compose scale my-test=$SCALE
概念测试成功完整！ 看测试作业
cavecat：
对于客户端实现，客户端套接字不能被绑定为auto，但是需要给出一个名字，在测试中我们使用主机名，映射在同一个/ sockets卷中。 他们也需要为每个客户不同。