我们都知道，无论是Python还是Ruby，甚至Java， 都是在解决业务层的问题， 属于应用型语言， 以解决业务逻辑为主， 但还有一个领域是系统领域，偏网络层和底层操作，在这一块我一直在寻找一种优雅的方案， C++被我首先给淘汰掉了， C的开发效率太低， Java倒是比较合适， 就是太臃肿，而且缺少系统编程的基因，毕竟它是企业级开发出身的
最后我选择了Erlang， 因为它在网络层方面表现优秀， 同时容错性和健壮性都很不错， 它的虚拟机是唯一可以跟JVM媲美的， 而且还有OTP的超重量级武器， 几乎可以是通杀网络层应用， 但根据我的总结它有一个硬伤和一个软肋，这一点后面展开，可以说选择Erlang是我目前所知道的方案里面是最优的
直到有一天我了解了Golang， 我知道Golang其实也蛮早的， 大概08年的时候就知道Google在搞一门奇怪的语言， 之后的几年，一直有不少以老莫为代表的人在嘀咕Golang， 其实我一直没太关注，我从ROR中吸取的经验是，成熟度对于商用很重要， 后来基于Golang开发的产品越来越多，让我不得不去研究一下， 这我才知道， 这就是我梦想中的Python， 效率和性能达到了最佳的平衡，对Go了解越多， 就越不愿意用Erlang写代码，主要原因：
1、Erlang的硬伤在于代码的可读性、表现力， 让我来举个小例子， 比如你为你的系统软件构建一个RESTFUL的接口，我们大致了解一下代码风格，先不说Erlang， 无论是你c/c++/python/ruby/java 出身， 对Go是不是有种很久违的感觉, 为什么说是硬伤？ 因为对一门语言来说，语法是不大可能会大幅度变更的， 而且不会出现大的变化， 我不知道有没有人读过《松本行弘的编程世界》，里面阐述的道理很明白， 真正好的编程方式是人去主宰计算机而不是计算机主宰人， 我感觉Erlang就有点主宰我的编程思维的感觉(我的视力本身就不好，它还在不断的扼杀我的眼睛！)， 编程首先是门逻辑学，其次是工程学，最后才是数学， 又让我想起吴军的《数学之美》所说的， 人工智能上个世纪一直在走弯路， 期望机器的高度图灵完备， 而忽视人类本身已有的文明，统计归纳的应用
2、Erlang的软肋在于高质量的库少，尽管有不少杀手级应用， 同样Go在这方面也是软肋， 这一点对于一个不到五年的语言有情可原， 但对于一个20多年的语言是不是有点说不过去， 比如你用json解析库，很多人都是从mochiweb这个基本不更新的库中去抽取， 而我认为对于类似json这种东西可以考虑融入到语言标准库中， 因为未来的商业软件的api化趋势越来越明显，说的难听点 ， 一个倚老卖老一个与时俱进，反正我对Golang的库一点也不担心， 目前的成绩易经非常棒了， 远远优于Ruby/Python的前五年， 可参见已有的高质量的库列表
3、Erlang不合群， 这主要体现在跟其他语言的交互性上， 当然这也有深层次的原因， Erlang本身有自己的哲学， 如出错恢复机制， 你融入一个其他语言的东西进去， 这帐就不好算，就好比你硬要让一个喝咖啡的跟一个吃大蒜的坐在一起， 总之你写一个Erlang的port远远比Go复杂， 甚至比Python/Java还要复杂， 这就造成了Erlang在底层编程上效果不是很好， 没法利用linux已有的很多优秀成果，我一直认为Erlang的什么的mysql/pg/oracle驱动都没有必要存在， Erlang一定是一个self-container应用， 你只要用到了其他东西， 根据木桶理论， 你就不敢号称9个9，以系统的眼光看问题， 我觉得一个系统的鲁棒性不能依赖于某一组件， 这也是为什么爱立信本身的Erlang应用并不广泛
4、说说数据类型吧， 我不止听到1个人说Erlang对字符串的处理不有好， 它把string当做list来处理，其实本质上是该这么，但，还是那句话， 违背了面向人的哲学， 应该做一些DSL， 比如Golang里面的 := 就是一个糖衣， 等价于 var xx yyy = zzzz， 大大方便的程序员少敲不少字符, Golang里面对字符转可以说基本和python差不多， slice map函数很强大， 支持lambda条件，虽然Erlang的基本类型很少， 但有很多构造， 所谓构造等价于Golang里面复杂的struct， 也奇怪了，我就是感觉Erlang构造伤眼睛好吗？可能是各种括号的比对的原因吧， 而且我认为这是不必要的， 显然Erlang缺少DSL的基因， 当然跟Erlang出身的年代有关， 我不夸张的说， 自打用Erlang以后我的视力又下降了100度左右， 我不是很喜欢lisp所说的符号也是一种语法， 可能这又跟函数式编程有关吧：形式推导远大于逻辑演绎
5、其实我最不关注的是性能问题， 因为随着摩尔定律， 单位计算单元的性价比会无限高，但Golang既然提出它的性能逼近C， 那我还是提一下吧， 当然， Erlang也还可以， 虽然比Java慢， 但跟Python一个档次吧
6、再谈谈报错机制， 因为Erlang的的报错信息太让人纠结了， 起初以为我不会看出错信息， 后来也使用了Sasl， 还是不够直观，甚至有时要用工具分析crash文件来定位问题，还是跟Erlang的哲学有关， 在Erlang中一切都是并行的， 所以它根本不care是物理哪一行出错， 只跟Actor绑定， 然后告诉你Actor的ID和出错代号， 你自己凭经验去分析吧，这样做的好处是可以很方便定位出并行中出现的问题，但凡事都是相对的， 在这一点上有点纠枉过正，根据我的经验， 绝大部分时候我只希望先给我明确的指出哪一行出错了好吗？ 甚至把顺序的backtrace用完整的英文句子打印出来好吗？至于并行中的错误及时在命令式多线程语言中是不常见的，虽然并不是没有， 但遇到错误我再费劲去调试好了， 但并不是所有的逻辑都用并行的思维去定位问题， 我甚至认为， 对于一个系统不完全是并行也不完全是串行，跟好比我们衡量世界不能单纯的唯物也不能完全的唯心一样， 这一点Golang就做了很好的折中， 不需要并行的时候你老老实实的写串行代码， 需要并行的时候也有较复杂的机制来应对， 合乎情理
7、再说说招人吧， 以前招过好几个C出来的人，说实话水平很好， 可以一周就完成一个小组件， libevent用的熟的很，后来我逼人家用Erlang，结果把人家逼走了，至今我还很后悔， 自己的一厢情愿强加在别人身上真是太不合适了，但我招纯Erlang出来的人，可以说比招objc的人还难， 没有人，空谈技术的优雅性首先就是不靠谱的，再看看邮件列表， Golang的活跃度明显比Erlang高很多， 基本逼近Ruby，更重要的是， 我根本不担心Golang的人才，因为只要熟悉Python/C/Ruby/或者C++， 基本可以实现半天入门， 之后就可以噼里啪啦边搜资料边干活了，虽然有足够的深度，但门槛极其平缓，工程人员也可以复用很多已有的知识。 Erlang在这一点其实跟第一点硬伤有关，大部分人学一周都摸不着头脑，不是每个人的抽象思维和世界观都是一样的好吗， 所以函数式编程尽管不比命令式语言起步晚，但始终学的人很少，这就是历史， 对于大部分人， 更希望解决问题，创造价值， 而不是数学来推导去
8、最后我建议， 如果你是玩c/c++的， 现在开始学Golang，是最好的时机， 跟一门靠谱的语言一起成长， 这种感觉非常棒， 你用Erlang折腾1个应用， 用Go恐怕都完成了10个开源项目， 当然，也要结合自己的口味， Golang就是Sublime Text， Erlang就是Emacs
相信自己的判断，相信自己的逻辑， 赢就是赢，输就是输
转载仅供参考，版权属于原作者。祝你愉快，满意请采纳哦
1. 介绍
最近在研究一些消息中间件，常用的MQ如RabbitMQ,ActiveMQ,Kafka等。NSQ是一个基于Go语言的分布式实时消息平台，它基于MIT开源协议发布，由bitly公司开源出来的一款简单易用的消息中间件。
官方和第三方还为NSQ开发了众多客户端功能库，如官方提供的基于HTTP的nsqd、Go客户端go-nsq、Python客户端pynsq、基于Node.js的JavaScript客户端nsqjs、异步C客户端libnsq、Java客户端nsq-java以及基于各种语言的众多第三方客户端功能库。
1.1 Features
1). Distributed
NSQ提供了分布式的，去中心化，且没有单点故障的拓扑结构，稳定的消息传输发布保障，能够具有高容错和HA（高可用）特性。
2). Scalable易于扩展
NSQ支持水平扩展，没有中心化的brokers。内置的发现服务简化了在集群中增加节点。同时支持pub-sub和load-balanced 的消息分发。
3). Ops Friendly
NSQ非常容易配置和部署，生来就绑定了一个管理界面。二进制包没有运行时依赖。官方有Docker image。
4.Integrated高度集成
官方的 Go 和 Python库都有提供。而且为大多数语言提供了库。
1.2 组件
1.3 拓扑结构
NSQ推荐通过他们相应的nsqd实例使用协同定位发布者，这意味着即使面对网络分区，消息也会被保存在本地，直到它们被一个消费者读取。更重要的是，发布者不必去发现其他的nsqd节点，他们总是可以向本地实例发布消息。
NSQ
首先，一个发布者向它的本地nsqd发送消息，要做到这点，首先要先打开一个连接，然后发送一个包含topic和消息主体的发布命令，在这种情况下，我们将消息发布到事件topic上以分散到我们不同的worker中。
事件topic会复制这些消息并且在每一个连接topic的channel上进行排队，在我们的案例中，有三个channel，它们其中之一作为档案channel。消费者会获取这些消息并且上传到S3。
nsqd
每个channel的消息都会进行排队，直到一个worker把他们消费，如果此队列超出了内存限制，消息将会被写入到磁盘中。Nsqd节点首先会向nsqlookup广播他们的位置信息，一旦它们注册成功，worker将会从nsqlookup服务器节点上发现所有包含事件topic的nsqd节点。
nsqlookupd
2. Internals
2.1 消息传递担保
1）客户表示已经准备好接收消息
2）NSQ 发送一条消息，并暂时将数据存储在本地（在 re-queue 或 timeout）
3）客户端回复 FIN（结束）或 REQ（重新排队）分别指示成功或失败。如果客户端没有回复, NSQ 会在设定的时间超时，自动重新排队消息
这确保了消息丢失唯一可能的情况是不正常结束 nsqd 进程。在这种情况下，这是在内存中的任何信息（或任何缓冲未刷新到磁盘）都将丢失。
如何防止消息丢失是最重要的，即使是这个意外情况可以得到缓解。一种解决方案是构成冗余 nsqd对（在不同的主机上）接收消息的相同部分的副本。因为你实现的消费者是幂等的，以两倍时间处理这些消息不会对下游造成影响，并使得系统能够承受任何单一节点故障而不会丢失信息。
2.2 简化配置和管理
单个 nsqd 实例被设计成可以同时处理多个数据流。流被称为“话题”和话题有 1 个或多个“通道”。每个通道都接收到一个话题中所有消息的拷贝。在实践中，一个通道映射到下行服务消费一个话题。
在更底的层面，每个 nsqd 有一个与 nsqlookupd 的长期 TCP 连接，定期推动其状态。这个数据被 nsqlookupd 用于给消费者通知 nsqd 地址。对于消费者来说，一个暴露的 HTTP /lookup 接口用于轮询。为话题引入一个新的消费者，只需启动一个配置了 nsqlookup 实例地址的 NSQ 客户端。无需为添加任何新的消费者或生产者更改配置，大大降低了开销和复杂性。
2.3 消除单点故障
NSQ被设计以分布的方式被使用。nsqd 客户端（通过 TCP ）连接到指定话题的所有生产者实例。没有中间人，没有消息代理，也没有单点故障。
这种拓扑结构消除单链，聚合，反馈。相反，你的消费者直接访问所有生产者。从技术上讲，哪个客户端连接到哪个 NSQ 不重要，只要有足够的消费者连接到所有生产者，以满足大量的消息，保证所有东西最终将被处理。对于 nsqlookupd，高可用性是通过运行多个实例来实现。他们不直接相互通信和数据被认为是最终一致。消费者轮询所有的配置的 nsqlookupd 实例和合并 response。失败的，无法访问的，或以其他方式故障的节点不会让系统陷于停顿。
2.4 效率
对于数据的协议，通过推送数据到客户端最大限度地提高性能和吞吐量的，而不是等待客户端拉数据。这个概念，称之为 RDY 状态，基本上是客户端流量控制的一种形式。
efficiency
2.5 心跳和超时
组合应用级别的心跳和 RDY 状态，避免头阻塞现象，也可能使心跳无用（即，如果消费者是在后面的处理消息流的接收缓冲区中，操作系统将被填满，堵心跳）为了保证进度，所有的网络 IO 时间上限势必与配置的心跳间隔相关联。这意味着，你可以从字面上拔掉之间的网络连接 nsqd 和消费者，它会检测并正确处理错误。当检测到一个致命错误，客户端连接被强制关闭。在传输中的消息会超时而重新排队等待传递到另一个消费者。最后，错误会被记录并累计到各种内部指标。
2.6 分布式
因为NSQ没有在守护程序之间共享信息，所以它从一开始就是为了分布式操作而生。个别的机器可以随便宕机随便启动而不会影响到系统的其余部分，消息发布者可以在本地发布，即使面对网络分区。
这种“分布式优先”的设计理念意味着NSQ基本上可以永远不断地扩展，需要更高的吞吐量？那就添加更多的nsqd吧。唯一的共享状态就是保存在lookup节点上，甚至它们不需要全局视图，配置某些nsqd注册到某些lookup节点上这是很简单的配置，唯一关键的地方就是消费者可以通过lookup节点获取所有完整的节点集。清晰的故障事件——NSQ在组件内建立了一套明确关于可能导致故障的的故障权衡机制，这对消息传递和恢复都有意义。虽然它们可能不像Kafka系统那样提供严格的保证级别，但NSQ简单的操作使故障情况非常明显。
2.7 no replication
不像其他的队列组件，NSQ并没有提供任何形式的复制和集群，也正是这点让它能够如此简单地运行，但它确实对于一些高保证性高可靠性的消息发布没有足够的保证。我们可以通过降低文件同步的时间来部分避免，只需通过一个标志配置，通过EBS支持我们的队列。但是这样仍然存在一个消息被发布后马上死亡，丢失了有效的写入的情况。
2.8 没有严格的顺序
虽然Kafka由一个有序的日志构成，但NSQ不是。消息可以在任何时间以任何顺序进入队列。在我们使用的案例中，这通常没有关系，因为所有的数据都被加上了时间戳，但它并不适合需要严格顺序的情况。
2.9 无数据重复删除功能
NSQ对于超时系统，它使用了心跳检测机制去测试消费者是否存活还是死亡。很多原因会导致我们的consumer无法完成心跳检测，所以在consumer中必须有一个单独的步骤确保幂等性。
3. 实践安装过程
本文将nsq集群具体的安装过程略去，大家可以自行参考官网，比较简单。这部分介绍下笔者实验的拓扑，以及nsqadmin的相关信息。
3.1 拓扑结构
topology
实验采用3台NSQD服务，2台LOOKUPD服务。
采用官方推荐的拓扑，消息发布的服务和NSQD在一台主机。一共5台机器。
NSQ基本没有配置文件，配置通过命令行指定参数。
主要命令如下:
LOOKUPD命令
NSQD命令
工具类，消费后存储到本地文件。
发布一条消息
3.2 nsqadmin
对Streams的详细信息进行查看，包括NSQD节点，具体的channel，队列中的消息数，连接数等信息。
nsqadmin
channel
列出所有的NSQD节点:
nodes
消息的统计:
msgs
lookup主机的列表:
hosts
4. 总结
NSQ基本核心就是简单性，是一个简单的队列，这意味着它很容易进行故障推理和很容易发现bug。消费者可以自行处理故障事件而不会影响系统剩下的其余部分。
事实上，简单性是我们决定使用NSQ的首要因素，这方便与我们的许多其他软件一起维护，通过引入队列使我们得到了堪称完美的表现，通过队列甚至让我们增加了几个数量级的吞吐量。越来越多的consumer需要一套严格可靠性和顺序性保障，这已经超过了NSQ提供的简单功能。
结合我们的业务系统来看，对于我们所需要传输的发票消息，相对比较敏感，无法容忍某个nsqd宕机，或者磁盘无法使用的情况，该节点堆积的消息无法找回。这是我们没有选择该消息中间件的主要原因。简单性和可靠性似乎并不能完全满足。相比Kafka，ops肩负起更多负责的运营。另一方面，它拥有一个可复制的、有序的日志可以提供给我们更好的服务。但对于其他适合NSQ的consumer，它为我们服务的相当好，我们期待着继续巩固它的坚实的基础。
