zeromq 是否稳定 -- 用过的人来说说

宏哥 发布于 2016/08/15 12:11
阅读 2K+
收藏 1

遇到C++做的东西, 心里有障碍了

就是担心不稳定

用过的来说说

加载中
1
bastetwang
bastetwang
别用在严肃的场合。看过代码调试过的结论。
bastetwang
bastetwang
@冯绪兴 再说了,管道通信在本机性能不比localhost网络快多少,线程通信?我用个队列就行...
bastetwang
bastetwang
回复 @冯绪兴 : 因为他基本上除了拆包和转发什么也不做,所以当然性能可以大幅领先于对手。 他不是不怎么好用,而是不完善,不是说没人用得好,而是在很多场合不适合用他。我用asio写个简单的也非常快。zeromq+protobuf虽然开发起来容易,但说实话,你只能当他是个udp来用,对吧。
撕纸王啊
撕纸王啊
回复 @bastetwang : zmq不仅仅是网络通信,还可以管道通信,线程通信,各项性能测试大幅领先于对手。缺点就是不怎么好用啊。我不是说你用不好,是没几个人用的好,我自己一样栽在坑里,最后还是自己写socket,但是zmq仍然是一个很不错的类库,非常适合有性能需要,又不能接口太过简单,又没时间自己封装一堆socket的用户。zeromq+protobuf开发起来不要太快。
宏哥
宏哥
回复 @bastetwang : DB这种可靠性是第一位的, 我们生产环境几乎永不重启数据库,OLTP, 24小时工作的
bastetwang
bastetwang
回复 @冯绪兴 : 我知道你的意思是我用不好,我项目要求可靠,出了问题知道哪里的问题,丢包了我也需要知道在哪里丢。 zeromq说白了不就起了一个转发和拆包吗?这种功能写起来复杂?
下一页
1
乌龟壳
乌龟壳
脱离数据库(数据库的底层架构)谈可靠性就是耍流氓,和语言无关。
0
Feng_Yu
Feng_Yu
建议kafka
0
石头哥哥
石头哥哥

很多消息中间件都会存在这样的问题,提供多语言的接口 是最基本的特性,c++有心里障碍这个 根本不是问题 ,最好的方式 直接用,只有自己知道坑。

既然存在 那就必然有存在的价值,动不动就考虑太多 ,是自己作死的节奏,见过某些公司自己搞,自己定制,也见过直接被装逼的CTO直接pass, 这类型的东西 接口保持一致就可以了,迁移到任何一种( nsq,rabbitmq,kafka)什么的 都可以,不管语言。如果自己有充分调研之后建议直接用,ps:之前用rabbitmq 线上跑的妥投的

0
宏哥
宏哥

引用来自“bastetwang”的评论

别用在严肃的场合。看过代码调试过的结论。

我已经将你的意见反馈给PipelineDB了, 非常惊讶他们采用库的时候,这样随意。

Open source 的库,大多质量不高的。

何况是C++的

乌龟壳
乌龟壳
回复 @bastetwang : 不是图像识别,是多边形运算,几万行的工作量
bastetwang
bastetwang
回复 @乌龟壳 : 嗯,再回来开始的问题,你们图形处理如果不用库,工作量不是一般的大。
乌龟壳
乌龟壳
回复 @bastetwang : 每个人因为个人经历,站的角度不同,无所谓对错,解决问题就好。每次改库前我的心情也是想哭的,但是没办法要实现功能,库不行就只能自己上。最近在做图形处理,一开始我用库都解决了,除了针对异常多边形的还原,这个库支持不了,只能自己做了。
乌龟壳
乌龟壳
回复 @bastetwang : 我只说着重在项目最终的状态上,比如nginx,redis等,还有微软的那些东西,基本都很少用第三方的,全部自己造轮子,知乎轮子哥以前是做office的,基本全部轮子自己造,不为别的,就是质量问题。但实际情况是,不是所有项目都需要做到这个程度,偶尔出问题,重启下停止服务几秒都不成问题,所以该用啥用啥,自己喜欢就好。
bastetwang
bastetwang
回复 @乌龟壳 : 那你直接把别人的代码过一遍就行了,我用库一般也会这么做的。自定义功能为了更好的质量,我很少碰到,说实话,可以换个库...或者在原有的库外面做扩展。boost的库设计得还是很不错的,耦合不是那么强。
下一页
0
宏哥
宏哥

引用来自“乌龟壳”的评论

脱离数据库(数据库的底层架构)谈可靠性就是耍流氓,和语言无关。

现在的问题不是我用这个

而是 pipelinedb(数据库)在新版当中采用了 zeromq, 个人认为, 麻烦比解决的问题多多

宏哥
宏哥
回复 @乌龟壳 : 我的看法就是pipelineDB(postgresql衍生)是关键软件, 不应该随便引入 zmq这样大而全的东西, 对系统破坏性太强了
乌龟壳
乌龟壳
之前我写过一个博客,把在项目中如何应用mq谈了一下个人看法,其实用zmq还是redis还是啥的都不是重点。
0
bastetwang
bastetwang
这个软件的作者癌症复发昨天安乐死了。
返回顶部
顶部