很多朋友可能知道Go语言的优势在哪，却不知道Go语言适合用于哪些地方。
创新互联-云计算及IDC服务提供商，涵盖公有云、IDC机房租用、西部信息机房、等保安全、私有云建设等企业级互联网基础服务，联系电话：18980820575
1、 Go语言作为服务器编程语言，很适合处理日志、数据打包、虚拟机处理、文件系统、分布式系统、数据库代理等；网络编程方面。Go语言广泛应用于Web应用、API应用、下载应用等；除此之外，Go语言还可用于内存数据库和云平台领域，目前国外很多云平台都是采用Go开发。
2、 其实Go语言主要用作服务器端开发。其定位是用来开发"大型软件"的，适合于很多程序员一起开发大型软件，并且开发周期长，支持云计算的网络服务。Go语言能够让程序员快速开发，并且在软件不断的增长过程中，它能让程序员更容易地进行维护和修改。它融合了传统编译型语言的高效性和脚本语言的易用性和富于表达性。
3、 Go语言成功案例。Nsq：Nsq是由Go语言开发的高性能、高可用消息队列系统，性能非常高，每天能处理数十亿条的消息；
4、 Docker：基于lxc的一个虚拟打包工具，能够实现PAAS平台的组建。
5、 Packer：用来生成不同平台的镜像文件，例如VM、vbox、AWS等，作者是vagrant的作者
6、 Skynet：分布式调度框架。
7、 Doozer：分布式同步工具，类似ZooKeeper。
8、 Heka：mazila开源的日志处理系统。
9、 Cbfs：couchbase开源的分布式文件系统。
10、 Tsuru：开源的PAAS平台，和SAE实现的功能一模一样。
11、 Groupcache：memcahe作者写的用于Google下载系统的缓存系统。
12、 God：类似redis的缓存系统，但是支持分布式和扩展性。
13、 Gor：网络流量抓包和重放工具。
以上的就是关于go语言能做什么的内容介绍了。
golangchannel和mq的区别
我是一个着迷于产品和运营的技术人，乐于跨界的终身学习者。欢迎关注我哟～
每周五12点 按时送达～
我的第「218」篇原创敬上
大家好，我是Z哥。
最近在项目中遇到了一个使用 RabbitMQ 时的问题，这个问题我觉得还是有一定普适性的，和大家分享一下，避免大家后续在同一个问题上犯错。
消息队列（MQ）是在软件开发中很常用的中间件，如果一个程序需要协调另一个程序进行数据的“write”操作，并且不关心“write”的结果，则便会选择它。它是一个保存消息（数据）的容器，由它来确保消息一定被送达到目标程序。
打个比喻来说，消息队列就是一个邮差，它负责将信件（消息）从源头送往目的地，并且根据信件重要性的不同，提供当面签收确认或者直接投放两种服务。
RabbitMQ 就是一个典型的消息队列，以 AMQP 为标准。历史也比较悠久，大概是从 2007年研发出来的，用的编程语言Erlang也同样具有年代感。
需要简单介绍一下 Erlang 的特点，它对我们理解 RabbitMQ 有很大的帮助。
Erlang 是一种运行于“虚拟机”（类似 JVM）的解释性语言。是一个结构化，动态类型编程语言，内建并行计算支持。使用 Erlang 编写出的应用运行时通常由成千上万个轻量级“进程”（并非传统意义上的进程）组成，并通过消息传递相互通讯。进程间上下文切换对于 Erlang 来说仅仅 只是一两个环节，比起 C 程序的线程切换要高效得多得多了。
——整理于百度百科的资料
不管是什么 MQ 中间件，作为消息的生产方和消费方都需要和 MQ 的服务端建立连接进行通讯。

一般这个连接都会使用 TCP 协议，在 RabbitMQ 里也不例外。大多数 RabbitMQ 的 SDK 都会将连接封装为一个「Connection」对象。
还没完，大多数的 MQ 中间件还会在「Connection」的基础上增加一个「Channel」的概念，以通过复用的方式提高 TCP 连接的利用率，因为建立和销毁 TCP 连接是非常昂贵的开销。在 RabbitMQ 中的复用 TCP 连接方式是「Non-blocking I/O」的模式。
关于NIO，「Non-blocking I/O」的概念，有感兴趣的话可以跳转去看之前写的这篇文章。（用最通俗的话讲明白阻塞/非阻塞/异步/同步，到底啥区别？）

多说一句，任何方案都不是“银弹”。当每个 Channel 的流量不是很大时，复用单一的 Connection 可以在产生性能瓶颈的情况下有效地节省 TCP 连接资源。但是 Channel 本身的流量很大时，这时候多个 Channel 复用一个 Connection 就会产生性能瓶颈，进而使整体的流量被限制了。此时就需要开辟多个 Connection，将这些 Channel 均摊到这些 Connection 中，至于哪些 Channel 使用那个 Connection 以及Connection 与 Channel 之间的数量关系是多少，需要根据业务自身的实际情况进行调节。
Channel 在 AMQP 中是一个很重要的概念，大多数操作都是在信道这个层面展开的。比如, channel.exchangeDeclare、channel.queueDeclare、channel.basicPublish、channel.basicConsume 等方法。RabbitMQ 相关的 API 与 AMQP 紧密相连，比如 channel.basicPublish 对应 AMQP 的 Basic.Publish 命令。
可能你要问了，Channel 是不是也能像 Connection 一样被复用？这是个好问题，也是我们这次遇到问题的关键点。
结论是：可以，但是需要自己保证客户端对 Channel 访问的线程安全问题，因为在 Channel 的另一端，在 RabbitMQ 的服务端，每个 Channel 由一个单独的“进程”所管理，如果由于多线程复用Channel 导致数据帧乱序了，RabbitMQ 的服务端会主动关闭整个 Connection 。
因此，我们这次犯的错误就是多线程复用了同一个 Channel 导致的问题。所以，如果你也用到 streadway/amqp 这个库的话，需要特别注意这点。
不过，不同语言的SDK内部实现不同，我们分别使用 Golang 的 AMQP 库 streadway/amqp，和 RabbitMQ 官方提供的 C# 版本的库分别模拟过同样的场景，前者出现问题，后者却没有问题。
受限于时间原因，没有具体去核实 C# 库的源码，主观猜测是 C# 库内部多做了一些对于单个 Channel 的线程安全处理。
最后，我整理了三点使用 streadway/amqp 库的最佳实践，你可以看看：
01
golang 中使用 streadway/amqp 时，需要保证每一个线程单独一个 Channel。
streadway/amqp 库中的获取一个 Channel 的方法「Connection.channel()」是线程安全的。但是内部有一个 defaultChannelMax 的参数对 Channel 的数量进行了限制，默认是 (2 10) - 1，2047。这个需要注意：

02
我们可以通过调用 amqp.DialConfig(url string, config Config) 来调整个限制。

但是，并不是你调整了多少就是多少，还需要和 RabbitMQ 服务端的配置进行 min() 函数的处理，最终为两者的最小值。
Tips：特别是用云厂商的 MQ 产品，因为阶梯收费的原因会对很多性能参数做限制，需要格外关注这点，比如某版本的阿里云 RabbitMQ 实例限制是单个 Connection 最多 64 个 Channel）
03
正如前面对 Erlang 的简单介绍，Erlang 是一个天然支持多“进程”设计的语言，所以在 RabbitMQ 的服务端设计中，每一个 Queue，每一个 Connection 都是单独的一个“进程”。因此如果你想尽可能地压榨 RabbitMQ 性能，可以通过建立更多的 Connection 或者创建更多的 Queue 来实现，当然需要注意到 Connection 的创建和销毁的性能开销问题。
推荐阅读：
减少联调、高效集成，试试这个工具
golang使用3周总结
也可以「关注」我，带你以技术思维看世界～
想更进一步和我一起玩耍，欢迎「搜索微信公号：跨界架构师」。
内容包括：架构设计丨分布式系统丨产品丨运营丨个人深度思考。
最近一直在寻找一个高性能，高可用的消息队列做内部服务之间的通讯。一开始想到用zeromq，但在查找资料的过程中，意外的发现了Nsq这个由golang开发的消息队列，毕竟是golang原汁原味的东西，功能齐全，关键是性能还不错。其中支持动态拓展，消除单点故障等特性， 都可以很好的满足我的需求
下面上一张Nsq与其他mq的对比图，看上去的确强大。下面简单记录一下Nsq的使用方法
图片来自golang2017开发者大会
在使用Nsq服务之前，还是有必要了解一下Nsq的几个核心组件
整个Nsq服务包含三个主要部分
先看看官方的原话是怎么说：
nsqlookupd是守护进程负责管理拓扑信息。客户端通过查询 nsqlookupd 来发现指定话题（topic）的生产者，并且 nsqd 节点广播话题（topic）和通道（channel）信息
简单的说nsqlookupd就是中心管理服务，它使用tcp(默认端口4160)管理nsqd服务，使用http(默认端口4161)管理nsqadmin服务。同时为客户端提供查询功能
总的来说，nsqlookupd具有以下功能或特性
官方原话：是一套 WEB UI，用来汇集集群的实时统计，并执行不同的管理任务
总的来说，nsqadmin具有以下功能或特性
nsqadmin默认的访问地址是
官方原话：nsqd 是一个守护进程，负责接收，排队，投递消息给客户端
简单的说，真正干活的就是这个服务，它主要负责message的收发，队列的维护。nsqd会默认监听一个tcp端口(4150)和一个http端口(4151)以及一个可选的https端口
总的来说，nsqd 具有以下功能或特性
这是官方的图，第一个channel(meteics)因为有多个消费者，所以触发了负载均衡机制。后面两个channel由于没有消费者，所有的message均会被缓存在相应的队列里，直到消费者出现
这里想到一个问题是，如果一个channel只有生产者不停的在投递message，会不会导致服务器资源被耗尽？也许nsqd内部做了相应处理，但还是要避免这种情况的出现
了解nsqlookupd，nsqd与客户端中消费者和生产者的关系
消费者有两种方式与nsqd建立连接
生产者必须直连nsqd去投递message(网上说，可以连接到nsqlookupd，让nsqlookupd自动选择一个nsqd去完成投递，但是我用Producer的tcp是连不上nsqlookupd的，不知道http可不可以…)，
这里有一个问题就是如果生产者所连接的nsqd炸了，那么message就会投递失败，所以在客户端必须自己实现相应的备用方案
执行完后检查godep是否已经安装在bin目录下，一般都会自动安装，如果没有，用go install手动安装下
如果安装成功，bin目录里就会出现一大堆nsq_…开头的可执行文件
nsqd是一个独立的服务，启动一个nsqd就可以完成message的收发，启动一个单机的nsqd，很简单
客户端可以使用http，也可以使用tcp，这里我使用是官方的go-nsq包做客户端，使用tcp进行message的收发
//Nsq发送测试
//Nsq接收测试
重点提示:
这样我们就启动了一个 nsqd 的实例
编写一个消息生产者
nsq_single_product.go
编写一个消息消费者
nsq_single_consumer.go
添加第一个实例
添加第二个实例
消息生产者
nsq_cluster_product.go
消息消费者
nsq_cluster_consumer.go