Vioao's Blog

写代码久了，一直在用别人提供的第三方包依赖，有时是不是也会想着有一天别人能够使用自己的开源出去的项目。让我们从最简单的开始，提取一个小项目，将其开源并发布到中央仓库让大伙可以直接通过配置 Maven 依赖来使用。

寻找项目方案

我相信应该是有不少人都有过开源并发布自己项目的想法的，但是其中最大的一个问题可能就是不知道该写点什么了、不知道有什么东西可以开源出去让别人使用的。没有关系，这边带你慢慢来提取出一个可行的项目方案。

开源项目的种类多种多样，来源更是不用多说，我们这里不整这些这么广泛复杂的项目，我们就是想体验下将自己的项目构建发布到 Maven 中央仓库的快感。那么其实有一个特别容易的项目可以立马自己就着手设计的：实现 API。

最近工作中又有可能需要写 Node.js 应用了，距离上次写 Node.js 应用也有好些年了，所以就开始 重新熟悉下 Node.js 了。刚好最近又在学 Go，其最大的特点就是简单、轻量级的并发模型。非常容易 用它编写一个能够充分利用硬件资源的高性能应用。于是不免想起以前学习 Node.js 时会遇到的问题：如何 让 Node.js 充分利用多核 CPU 的资源。于是，让我发现了，Node.js 从 v10.5.0 开始引入 worker_threads 模块来解决该问题。并让我发现了这篇文章。

此文为译文，原文如下。

译自 Deep Dive into Worker Threads in Node.js

多年来，Node.js 一直都不是实现 CPU 密集型应用的最佳选择。其中最主要的原因就是 Node.js 仅仅 是 Javascript 而 JavaScript 是单线程的。作为该问题一个解决方法，Node.js 从 v10.5.0 开 始引入了实验性的 Worker Threads 概 念，并将其体现在 worker_threads 模块，该模块从 Node.js v12 LTS 开始作为一个稳定功能 模块提供出来。在这边文章中，我将会说明它们是如何工作的，怎样使用 worker threads 才能获取最好 的性能。假如你对 Node.js worker threads 还不了解的话，我建议你查看它们的 官方文档 。

注：文中引用的 Node.js 代码片段版本为 921493e 。

前言

最近工作有个小项目，其场景主要是封装内部的接口请求，然后做个转换之后，就请求外部请求，之后再 将外部响应转换成内部的统一格式，其实有点类似一个简单网关的应用，虽然也有一些业务逻辑在里面， 但是主要场景还是请求的转发处理，是一个 IO 密集型的应用，而且外部请求的延迟相对比较大而且不可控。 我想，这不正合适 Spring 5 出来的那个新特性的一个应用场景么。于是决定探究下 Spring Web on Reactive Stack: Spring WebFlux.

Spring WebFlux

Spring WebFlux 作为一个响应式(reactive-stack) web 框架补充，在 5.0 的版本开始加入到 Spring 全家桶。这是一个完全非阻塞的，支持 Reactive Streams, 运行在诸如 Netty, Undertow, 以及 Servlet 3.1+ 容器上的。Spring WebFlux 可以让你使用更少的线程去处理并发请求，同时能够让你使用更少的硬件资源来拓展 你的应用。

下图是他们的一个区别。

简介

Apache Kakfa 是一个分布式流处理平台，既可以当做普通的消息中间件用于消息发布订阅，也可以存储并处理流式数据，其分布式设计使得其有较好的容错性，水平拓展性等。 通常可以用于当做消息订阅发布用于业务系统中，或者用于大数据方向，接受存储大量的流式数据并和对应的大数据处理框架结合使用，eg. Kafka + Samza

从物理部署层面来讲，其主要有如下几个模块：

1. ZooKeeper 用于元数据保存以及事件通知
2. Broker Kafka 的核心部分，用 scala 实现，负责处理客户端请求，持久化消息数据等
3. Client（Consumer & Producer） 客户端，Java 实现。生产者消费者实现

下面分别从这几个模块来讲解 Kafka 相关的实现[基于 Kafka 2.4]。

简介

Apache RocketMQ 是阿里开源的一款高性能、高吞吐量的分布式消息中间件。相比于 Kafka，其拥有更好的实时性和消息可靠性。更适用于和 Money 相关的系统。它支持如下特性：

• 订阅/发布模式的消息

  支持消费组模式的消费，即一个消费组集群内只有一个实例会收到那一条消息。

• 延时消息

  只支持特定 Level 的延时设置，默认有 “1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h” 18个 Level。先扔到对应的延时队列，后台线程根据延时再将其挪到实际的 Topic 中。

• 顺序消息

  只保证在单个 Broker 的单个 Queue 内是有序的，全局不保证有序。和 Kafka 一样.。

• 消息持久化

  [主从同步 + 同步刷盘] 模式保证了持久数据的安全性。4.5 版本后加入 Dleger 更是支持了 主从自动切换。

• 消息过滤

  RocketMQ的消费者可以根据Tag进行消息过滤，也支持自定义属性过滤。消息过滤目前是在Broker端实现，减少了r无用消息的网络传输。

• 消息回溯

  已消费过的消息，可以根据时间或 key 等维度来重新消费。在处理系统环境异常时很有用。

• 事务消息

  先发送到一个特殊的系统 Topic 中，然后利用 2PC + 事务回查机制，判断将消息转到真正的 Topic 还是抛弃。

• 死信队列

  消费失败并重试一定次数还是失败的的消息会先放到死信队列，需要手动进行重发

• 消息重试

  每个消费组有一个 “%RETRY%+consumerGroup” 的重试队列。重试的消息会按照延迟的时间先放到 “SCHEDULE_TOPIC_XXXX” 队列中，然后才会被保存至 “%RETRY%+consumerGroup” 的重试队列中。

• At-Least-Once

  消息消费有 ACK 机制，消费结束才返回对应的 ACK 相应。和 Kafka 不太一样，Kafka 追求消息的大量快速处理，默认都是异步，整合成一批来消费生产的。