NSQ 源码阅读(一) 相关概念理解

NSQ是由知名短连接服务商bitly用Go语言开发的实时消息处理系统，具备高性能、高可靠、无视单点故障等优势，是一个很是不错的新兴的消息队列解决方案。

相关概念

提到消息队列，咱们先看一下消息队列的相关概念。
如下主要参考 消息队列设计精要，我提取一些我认为重要的要点

1. 当你须要使用消息队列时，首先须要考虑它的必要性。可使用mq的场景有不少，最经常使用的几种，是作业务解耦/最终一致性/广播/错峰流控等。反之，若是须要强一致性，关注业务逻辑的处理结果，则RPC显得更为合适。

2. 解耦是消息队列要解决的最本质问题。所谓解耦，简单点讲就是一个事务，只关心核心的流程。而须要依赖其余系统但不那么重要的事情，有通知便可，无需等待结果。换句话说，基于消息的模型，关心的是“通知”，而非“处理”。

3. 关于强一致性和最终一致性
   强一致性：系统中的某个数据被成功更新后，后续任何对该数据的读取操做都将获得更新后的值。
   最终一致性指的是两个系统的状态保持一致，要么都成功，要么都失败。固然有个时间限制，理论上越快越好，但实际上在各类异常的状况下，可能会有必定延迟达到最终一致状态，但最后两个系统的状态是同样的。

4. 咱们来看看若是须要数据落地的状况下各类存储子系统的选择。理论上，从速度来看，文件系统>分布式KV（持久化）>分布式文件系统>数据库，而可靠性却截然相反。

5. 市面上的消息队列定义了一堆让人晕头转向的名词，如JMS 规范中的Topic/Queue，Kafka里面的Topic/Partition/ConsumerGroup，RabbitMQ里面的 Exchange等等。抛开现象看本质，无外乎是单播与广播的区别。所谓单播，就是点到点；而广播，是一点对多点。固然，对于互联网的大部分应用来讲，组间广播、组内单播是最多见的情形。

nsq关注点

1. 如何实现消息的广播，单播等

2. 通讯协议

3. 如何保证消息不丢失？存储

4. 如何尽量减少消息重复，如何处理消息重复？

5. 服务发现

6. 如何消除单点故障？

nsq 文档

对于nsq的基本介绍这里不作搬运了，可参考官方文档，网上也有很多介绍nsq的文章