英文:
Internal server based on nanomsg
问题
我最近正在学习使用Golang绑定的nanomsg和zeromq。我已经测试了Req-Rep，它可以工作，但是在处理高并发请求（但来自有限的客户端源<30）的可靠内部服务器时，使用这种机制是否是一个合适的想法？
一些伪代码可能如下所示：
for {
data, conn = socketRep.readData()
go func(data, conn){
result=process(data)
conn.sendReply(result)
conn.close()
}()
}
如何在nanomsg中实现类似的通信模式？是否有任何可用的示例（C语言为佳）？
====更新====
抱歉，问题看起来太宽泛了。对我来说最重要的问题是，“是否有任何可行的Req/Rep示例（C语言为佳）可用？”
英文:
I'm learning nanomsg and zeromq these days with Golang binding. I've tested with Req-Rep which can work, but is it a proper idea to use this mechanism to build reliable internal server for serving data under high concurrent requests (but from limited client sources < 30)?
Some pseudo code may looks like,
for {
data, conn = socketRep.readData()
go func(data, conn){
result=process(data)
conn.sendReply(result)
conn.close()
}()
}
How to achieve similar communication pattern in nanomsg? Is there any example (C is ok) available?
====UPDATE====
Sorry the question looks too broad. The most important question for me is, "Is there any workable Req/Rep example (C is ok) around?"
答案1
得分: 2
当决定“如何构建可靠的服务器以应对高并发负载”时，有一件非常重要的事情需要知道。
学习任何新的库都是令人兴奋的，会带来很多新的见解。
一个非常重要的见解是在自己的学习曲线轨迹上，承担合适大小和合理的挑战。
如果ZeroMQ的共同创始人Pieter Hintjens在进入任何关于设计可靠服务的章节之前，写下了以下的评论，他非常清楚为什么要在这些设计的前面加上类似的突出警告...
- 引用：“...我们将进入一个非常复杂的领域，让我不得不起身去冲杯咖啡。在跳入其中之前，你应该明白制作“可靠”的消息传递已经足够复杂，你总是需要问自己，“我们真的需要这个吗？”如果你可以接受不可靠的，或者“足够好”的可靠性，你可以在成本和复杂性方面获得巨大的收益。当然，你可能偶尔会丢失一些数据。这通常是一个很好的权衡...”
Nanomsg无疑是一个伟大而聪明的库项目。
从Pieter Hintjens关于高级设计的书籍中带来的高层次哲学思考，构建“超越基本ZeroMQ”的可扩展正式通信模式，仍然是相同的。
在进入任何编码之前，我认为最好花几个星期的时间来研究Pieter Hintjens的书中的思想、设计范式和故事。
一本400多页的书《ZeroMQ指南-面向Python开发者，第二部分，高级ZeroMQ》（特别是第6.2章、6.7章、7.1章和7.5章）
和
一本300多页的书《“代码连接第一卷”》（特别是第5章中关于添加可靠性的过程-无论是为了可靠性本身还是为了通过负载均衡解锁下一级性能水平的目的）
将帮助任何人开始探索这个伟大而令人兴奋的分布式系统架构领域，并帮助获得设计可生存方法所需的视角，而无需重新探索已经被证明是死胡同的许多死胡同。
英文:
The VERY first thing one shall know when deciding on "How to build Reliable Server ... for serving high concurrent load"
Learning any new library is thrilling and makes a lot of new insights.
One very important insight is to undertake just right-sized & REASONABLE challenges alongside one's own learning-curve trajectory.
If Pieter Hintjens, co-father of the ZeroMQ, has written [ almost in bold ] the following remarks right upon entering into a chapter on designing any RELIABLE SERVICE, he knew pretty well WHY to precede forthcoming paragraphs on such designs with a similar highlighted warning...
- (cit.:) " ... going to get into unpleasantly complex territory here
that has me getting up for another espresso. You should appreciate
that making "reliable" messaging is complex enough that you always
need to ask, "do we actually need this?" before jumping into it.
If you can get away with unreliable, or "good enough" reliability,
you can make a huge win in terms of cost and complexity. Sure,
you may lose some data now and then. It is often a good trade-off.
..."
Nanomsg is out of doubts a great & smart library Project
The high-level philosophy thoughts brought from Pieter Hintjens books on advanced designs, that build "beyond the elementary ZeroMQ" Scaleable Formal Communication Patterns remains much the same
IMHO it is best to spend a few more weeks on ideas and design-paradigms & stories in both Pieter Hintjens' books, before moving into any coding.
Both a 400+ pages book The ZeroMQ Guide - for Python Developers, Section II., Advanced ZeroMQ, ( namely Chapters 6.2, 6.7, 7.1 and 7.5 )
and
a 300+ pages book "Code Connected Volume 1", ( namely the process of adding reliability in Chapter 5 - be it for the sake of reliability per-se or also for the sake of unlocking next levels of performace via load-balancing over a pool-of-resources )
will help anyone to start exploring this great but thrilling field of distributed system architecture & will help get perspectives needed for designing surviveable aproaches without re-exploring many dead-ends, that have already been proved to be dead-ends.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论