NATS--NATS Streaming持久化

前言

最近项目中需要使用到一个消息队列，主要用来将原来一些操作异步化。根据自己的使用场景和熟悉程度，选择了NATS Streaming。之所以，选择NATS Streaming。一，因为我选型一些中间件，我会优先选取一些自己熟悉的语言编写的，这样方便排查问题和进一步的深究。二，因为自己一直做k8s等云原生这块，偏向于cncf基金会管理的项目，毕竟这些项目从一开始就考虑了如何部署在k8s当中。三，是评估项目在不断发展过程中，引入的组件是否能够依旧满足需求。

消息队列的使用场景

如果问为什么这么做，需要说一下消息队列的使用场景。之前看知乎的时候，看到一些回答比较认同，暂时拿过来，更能形象表达。感谢ScienJus同学的精彩解答。

消息队列的主要特点是异步处理，主要目的是减少请求响应时间和解耦。所以主要的使用场景就是将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。同时由于使用了消息队列，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即解耦和。

使用场景的话，举个例子：

假设用户在你的软件中注册，服务端收到用户的注册请求后，它会做这些操作：

• 校验用户名等信息，如果没问题会在数据库中添加一个用户记录
• 如果是用邮箱注册会给你发送一封注册成功的邮件，手机注册则会发送一条短信
• 分析用户的个人信息，以便将来向他推荐一些志同道合的人，或向那些人推荐他
• 发送给用户一个包含操作指南的系统通知等等……

但是对于用户来说，注册功能实际只需要第一步，只要服务端将他的账户信息存到数据库中他便可以登录上去做他想做的事情了。至于其他的事情，非要在这一次请求中全部完成么？值得用户浪费时间等你处理这些对他来说无关紧要的事情么？所以实际当第一步做完后，服务端就可以把其他的操作放入对应的消息队列中然后马上返回用户结果，由消息队列异步的进行这些操作。

或者还有一种情况，同时有大量用户注册你的软件，再高并发情况下注册请求开始出现一些问题，例如邮件接口承受不住，或是分析信息时的大量计算使cpu满载，这将会出现虽然用户数据记录很快的添加到数据库中了，但是却卡在发邮件或分析信息时的情况，导致请求的响应时间大幅增长，甚至出现超时，这就有点不划算了。面对这种情况一般也是将这些操作放入消息队列（生产者消费者模型），消息队列慢慢的进行处理，同时可以很快的完成注册请求，不会影响用户使用其他功能。

所以在软件的正常功能开发中，并不需要去刻意的寻找消息队列的使用场景，而是当出现性能瓶颈时，去查看业务逻辑是否存在可以异步处理的耗时操作，如果存在的话便可以引入消息队列来解决。否则盲目的使用消息队列可能会增加维护和开发的成本却无法得到可观的性能提升，那就得不偿失了。

其实，总结一下消息队列的作用

• 削峰，形象点的话，可以比喻为蓄水池。比如elk日志收集系统中的kafka，主要在日志高峰期的时候，在牺牲实时性的同时，保证了整个系统的安全。
• 同步系统异构化。原先一个同步操作里的诸多步骤，可以考虑将一些不影响主线发展的步骤，通过消息队列异步处理。比如，电商行业，一个订单完成之后，一般除了直接返回给客户购买成功的消息，还要通知账户组进行扣费，通知处理库存变化，通知物流进行派送等，通知一些用户组做一些增加会员积分等操作等。

NATS Streaming 简介

NATS Streaming是一个由NATS驱动的数据流系统，用Go编程语言编写。 NATS Streaming服务器的可执行文件名是nats-streaming-server。 NATS Streaming与核心NATS平台无缝嵌入，扩展和互操作。 NATS Streaming服务器作为Apache-2.0许可下的开源软件提供。 Synadia积极维护和支持NATS Streaming服务器。

特点

除了核心NATS平台的功能外，NATS Streaming还提供以下功能：

• 增强消息协议

NATS Streaming使用谷歌协议缓冲区实现自己的增强型消息格式。这些消息通过二进制数据流在NATS核心平台进行传播,因此不需要改变NATS的基本协议。NATS Streaming信息包含以下字段:

　　- 序列 - 一个全局顺序序列号为主题的通道
　　- 主题 - 是NATS Streaming 交付对象
　　- 答复内容 - 对应"reply-to"对应的对象内容
　　- 数据 - 真是数据内容
　　- 时间戳 - 接收的时间戳，单位是纳秒
　　- 重复发送 - 标志这条数据是否需要服务再次发送
　　- CRC32 - 一个循环冗余数据校验选项，在数据存储和数据通讯领域里，为了保证数据的正确性所采用的检错手段，这里使用的是 IEEE CRC32 算法

　- 消息/事件的持久性
　　NATS Streaming提供了可配置的消息持久化，持久目的地可以为内存或者文件。另外，对应的存储子系统使用了一个公共接口允许我们开发自己自定义实现来持久化对应的消息

　- 至少一次的发送
　　NATS Streaming提供了发布者和服务器之间的消息确认(发布操作) 和订阅者和服务器之间的消息确认(确认消息发送)。其中消息被保存在服务器端内存或者辅助存储(或其他外部存储器)用来为需要重新接受消息的订阅者进行重发消息。

　- 发布者发送速率限定
　　NATS Streaming提供了一个连接选项叫 MaxPubAcksInFlight，它能有效的限制一个发布者可能随意的在任何时候发送的未被确认的消息。当达到这个配置的最大数量时，异步发送调用接口将会被阻塞，直到未确认消息降到指定数量之下。

-　每个订阅者的速率匹配／限制
　　NATS Streaming运行指定的订阅中设置一个参数为 MaxInFlight，它用来指定已确认但未消费的最大数据量，当达到这个限制时，NATS Streaming 将暂停发送消息给订阅者，直到未确认的数据量小于设定的量为止

• 以主题重发的历史数据

　　新订阅的可以在已经存储起来的订阅的主题频道指定起始位置消息流。通过使用这个选项,消息就可以开始发送传递了:

　　1. 订阅的主题存储的最早的信息
　　2. 与当前订阅主题之前的最近存储的数据，这通常被认为是 "最后的值" 或 "初值" 对应的缓存
　　3. 一个以纳秒为基准的 日期／时间
　　4. 一个历史的起始位置相对当前服务的 日期／时间，例如：最后30秒
　　5. 一个特定的消息序列号

• 持久订阅

　　订阅也可以指定一个“持久化的名称”可以在客户端重启时不受影响。持久订阅会使得对应服务跟踪客户端最后确认消息的序列号和持久名称。当这个客户端重启或者重新订阅的时候，使用相同的客户端ID 和 持久化的名称，对应的服务将会从最早的未被确认的消息处恢复。

docker 运行NATS Streaming

在运行之前，前面已经讲过NATS Streaming 相比nats，多了持久化的一个future。所以我们在接下来的demo演示中，会重点说这点。

运行基于memory的持久化示例：

docker run -ti -p 4222:4222 -p 8222:8222  nats-streaming:0.12.0

你将会看到如下的输出：

[1] 2019/02/26 08:13:01.769734 [INF] STREAM: Starting nats-streaming-server[test-cluster] version 0.12.0
[1] 2019/02/26 08:13:01.769811 [INF] STREAM: ServerID: arfYGWPtu7Cn8Ojcb1yko3
[1] 2019/02/26 08:13:01.769826 [INF] STREAM: Go version: go1