我有一个简单的C ++服务(API端点),每次调用API时都会增加一个计数器。当调用者将数据发布到http://10.0.0.1/add时,计数器必须递增1并将计数器的值返回给调用者。
当服务进入dockerized时,事情变得更加复杂。当同一服务的两个实例运行时,必须以原子方式完成添加,即计数器值存储在数据库中,并且每个docker实例必须获取一个锁获取旧值,添加一个,返回调用者并解锁。
当实例是同一Linux机器中的进程时,我们使用共享内存来有效地锁定,读取,写入和解锁共享数据,并且接受了性能。但是,当我们使用泊坞窗和数据库时,性能很低。结果还可以,但性能很低。
用于执行上述操作的dockerized属性实例之间的规范方法是什么?是否有共享内存"集装箱化流程的特点?
答案 0 :(得分:4)
看起来您的案例数据库是开销。您只需要一些具有共享密钥锁支持的轻量级键值存储。以下是一些候选人:
答案 1 :(得分:1)
--ipc
option of docker run
启用容器之间的共享内存访问:
IPC设置(--ipc)
--ipc=""
:设置容器的IPC模式,
'container:<name|id>'
:重用另一个容器的IPC命名空间
'host'
:在容器中使用主机的IPC命名空间默认情况下,所有容器都启用了IPC命名空间。
IPC(POSIX / SysV IPC)命名空间提供了命名共享的分离 内存段,信号量和消息队列。
共享内存段用于加速进程间 以记忆速度进行通信,而不是通过管道或通过 网络堆栈。共享内存通常由数据库使用 定制(通常是C / OpenMPI,C ++ /使用boost库)高 科学计算和财务的性能应用 服务业。如果这些类型的应用程序被分解 多个容器,您可能需要共享IPC机制 容器
This article提供了一些使用示例。
答案 2 :(得分:1)
我遇到了类似的问题,并决定继续深入研究。
唯一快速的是域套接字。所以我创建了一个小型的c程序,它在共享卷/套接字上侦听域套接字。
在gitlab.com上查看test上的工作概念。
counter.c
完成工作,侦听socket / count.sock和
在收到数据报中的单个字符时:
用于概念测试:
counter --interval=1000000
=&gt;启动计数器test_counter --repeats=100000 stress
=&gt;向插座发送100k请求test_counter reset
将计数器设为0 test_counter --quiet --strip result
返回没有\n
test_counter [count]
递增计数器并返回结果。构建了2个泊坞窗容器:count
&amp; test
repo
为了测试,我在gitlab-runner中使用了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
概念测试成功全面!!!见test Job
cavecat:
对于客户端实现,客户端套接字不能绑定为auto,但需要给出一个名称,请参阅测试我们使用的主机名,映射在相同的/套接字卷中。 每个客户也需要有所不同。