求小伙伴们，推荐一款 c/c++成熟高性能的队列，谢谢

[duanhui8]

场景：200-400 线程同时向队列中写入消息，每秒写入次数大概 7000+，每次写入 100 byte 左右
消费端，由多线程消费，将消息取出并通过 socket 发送出去。

小伙伴有没有高性能的队列推荐啊？要支持多线程读写，并且要安全,性能尽量好点，c/c++代码
另外这种场景非阻塞队列更适合吧？
不想去百度，怕被坑，求小伙伴们推荐，谢谢

[cholerae]

https://github.com/cameron314/concurrentqueue 线上有服务用了一阵子了，还是挺靠谱的

[duanhui8]

@gabon 好的，我了解一下，谢谢

[duanhui8]

@cholerae ok，回去后看看，谢了

[duanhui8]

@gabon 嗯嗯，好的

[shilyx]

正在开发，基于 websocket++，发布 /订阅，服务端 C++跨平台，客户端支持 C++、node、js （ web ）、python、golang

[nroskill]

http://dpdk.org/doc/guides/prog_guide/ring_lib.html
可以抄一个

[hxndg]

dpdk 那个也是 ringbuf,用的原子操作

[fakevam]

...7000 要啥这么复杂的东西, 起个 unix domain socket, N 个线程打一个线程, 那边 recv 完事

[hardwork]

什么场景要跑 200 到 400 线程，这本身就是低性能吧？请教一下各位

[noli]

@cholerae

#21 扫了一遍终于有人推荐这个了。同推荐给楼主。

[duanhui8]

@noli 谢谢

[fakevam]

@noli 大哥们, 这个不适合线程不确定的场景, 会死锁...你们有认真看过他代码么?

[noli]

@fakevam #32

有看过，并且仿写过。做不到比他的更好。

会死锁百分之九十的情况不是 Queue 的问题吧？
什么叫做 “线程不确定的场景”？

[fakevam]

@noli 线程数量无法确定的情况下, 这货的代码不能用...他只能用于线程数固定的场景, 否则会触发死锁, 因为他的 bucket 分配的问题

[fakevam]

@noli 另外, 7000 的并发, 要这么复杂的方案做啥, 谁维护? 单线程代码写得稍微好点, libevent 随便路路, 不是随便 10W 的 qps 么...为什么要搞这么复杂的设计...

[noli]

@fakevam #34 #35

他不是在 issue 里面提供了 work around 吗？ 我觉得这基本不是问题。

一开始我并没有太多关注题主的应用情景。
我甚至不确定他说的 7000 是指整个 queue 的负荷还是单个 producer   的负荷。

如果是 7000 是指整个 Queue 的负荷，那么直接用系统锁就足够了，
但如果是指单个 producer 7000 ops，那确实只能用 这种基于 spinlock 的。

如果题主不太介意局部写入延迟比较大的话，我本人倒是试过不用靠预先分配的解法。

[fakevam]

@noli 200 * 7000 是 140W 的 qps, 通过 socket 打网络出去, 你算过带宽么, 单核 socket 小包 15Wqps 很好了, 千兆网卡的话, 100W 就已经是瓶颈了, cpu 再多也不怎么上的去了..万兆网卡的话, 另说...

[noli]

@fakevam #37

说不定楼主是土豪金融公司，连光纤延迟都要考虑在内的那种，万兆是标配。

不过按理，如果真的这么大的工作负荷，应该会考虑多个转发点的设计吧？
又或者这种负荷就是要求单个转发点的性能标准？

[duanhui8]

@fakevam 不使用队列，由用户线程发送审计信息，会增加用户访问延时，并且降低数据库性能

[duanhui8]

@noli 确实是金融公司，但是不需要记录查询操作，所以，记录量少很多。高峰估计几 W 的 TPS