0%

写代码久了,一直在用别人提供的第三方包依赖,有时是不是也会想着有一天别人能够使用自己的开源出去的项目。让我们从最简单的开始,提取一个小项目,将其开源并发布到中央仓库让大伙可以直接通过配置 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 追求消息的大量快速处理,默认都是异步,整合成一批来消费生产的。

阅读全文 »