控制 Quartz 只执行一次

• 纯 API 调用的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class ScheduleTest {

    private static final String JOB_NAME = "job";
    private static final String JOB_GROUP = "jobGroup";

    public void runOnceTime() throws Exception {
        Scheduler scheduler = schedulerFactory.getScheduler();
        JobDetail jobDetail = JobBuilder.newJob(ScheduleJob.class).withIdentity(JOB_NAME, JOB_GROUP).build();
        SimpleScheduleBuilder scheduleBuilder = SimpleScheduleBuilder.simpleSchedule().withIntervalInSeconds(0).withRepeatCount(0);
        Trigger trigger = TriggerBuilder.newTrigger().withIdentity(JOB_NAME, JOB_GROUP).withSchedule(scheduleBuilder).build();
        scheduler.scheduleJob(jobDetail, trigger);
        scheduler.start();
    }
}

Snap 介绍

Snap 是 Ubuntu 母公司 Canonical 于 2016 年 4 月发布 Ubuntu-16.04 时引入的一种全新的、安全的、易于管理的、沙盒化的软件包管理方式，与传统的 dpkg/apt 有着很大的区别，背后主要的动机是解决 Linux 平台的碎片化问题。Snap 的安装包扩展名是 .snap，类似于一个容器，它包含一个应用程序需要用到的所有文件和库（Snap 包里包含一个私有的 root 文件系统，里面包含了依赖的软件包）。不管底层系统如何，Snap 都可轻松安装、升级、降级和移除应用，因此 Snap 的应用程序很容易安装在任何基于 Linux 的系统上，而且支持用户在同一个系统中安装同一应用程序的多个版本。使用 Snap 包的好处就是它解决了应用程序之间的依赖问题，使应用程序之间更容易管理，但是由此带来的问题就是占用更多的磁盘空间。类似的应用程序容器技术还有大名鼎鼎的 Flatpak、AppImage。Snap 适用于 CentOS 7.6+ 和 Red Hat Enterprise Linux 7.6+，它很好地弥补了 Centos 桌面软件资源不多的缺点，可以从 Extra Packages for Enterprise Linux（EPEL）存储库安装。Snap 的工作原理如下图所示：

概述

读写分离要做的事情就是决定一条 SQL 该到哪个数据库去执行，至于谁来做决定数据库这件事，要么数据库中间件去做，要么应用程序自己去做。首先针对应用程序自己去做的场景，读写分离的职责应该属于数据访问层而不是业务层，其次读写分离不应该入侵到代码中。因此在 Service—DAO—ORM— 数据库驱动的调用链中，要想做到代码弱入侵性或者零入侵性，只能将读写分离写在 ORM 层或者数据库驱动层，写在 ORM 层就和具体 ORM 框架耦合，写在数据库驱动层，就和具体数据库耦合。至于在 ORM 层还是在数据库驱动层实现读写分离，主要看更换 ORM 框架和数据库哪个成本更高和实现的难易程度。一般来讲，读写分离的核心方案主要有以下几种：

• 第一种构建多套环境，优势是方便控制也容易集成一些简单的分布式事务，缺点是非动态同时代码量较多，配置难度大；
• 第二种是依靠数据库中间件（例如：MyCat），由中间件做读写分离，优势是对整个应用程序都是透明的，缺点是降低性能，不支持多数据源事务；
• 第三种是应用程序自己去做，例如使用支持读写分离的数据库驱动、使用 Spring 原生提供的 AbstractRoutingDataSource。后者需要控制只读事务和读写事务切换到主库，写操作切换到主库，读操作切换到从库；同时保证单个事务里面所有的 SQL 都是在同一个数据源里执行。缺点是多数据源的配置不灵活，不支持多数据源事务。具体实现方式可参考 基于 Service 层的 Spring 路由数据源 + AOP / Annotation、基于 ORM 层的 Spring 路由数据源 + Mybatis 插件 / Annotation。

大纲

• J2Cache 两级缓存框架介绍
• MyBatis 使用 J2Cache 作为二级缓存实现

相关资源

• J2Cache Gitee
• J2Cache Java Docs
• J2Cache 官方视频介绍
• J2Cache 官方 PDF 介绍
• J2Cache 的简单测试实验

缓存介绍

主流缓存框架

Ehcache、Caffeine 、Spring Cache、Guava Cache、JetCache、Hazelcast、Infinispan

主流缓存解决方案

• 内存缓存（如 Ehcache、Caffeine） — 速度快，进程内可用
• 集中式缓存（如 Redis、Memcached）— 可同时为多节点提供服务

大纲

• Docker 搭建 RabbitMQ 集群
• Centos 7 生产环境搭建 RabbitMQ 集群
• Debian 11 生产环境搭建 RabbitMQ 集群

前言

集群模式

RabbitMQ 是基于 Erang 开发的，集群模式分为两种，包括普通模式和镜像模式；可以说镜像模式是普通模式的升级版，其中 RabbitMQ 默认使用的是普通模式。

• 普通模式：

  • 以两个节点（rabbit01、rabbit02）为例来进行说明，rabbit01 和 rabbit02 两个节点仅有相同的元数据，即队列的结构，但消息实体只存在于其中一个节点 rabbit01（或者 rabbit02）中。当消息进入 rabbit01 节点的 Queue 后，Consumer 从 rabbit02 节点消费时，RabbitMQ 会临时在 rabbit01、rabbit02 间进行消息传输，把 A 中的消息实体取出并经过 B 发送给 Consumer。所以，对于同一个逻辑队列，要在多个节点上建立物理队列，比如使用镜像队列或者 Quorum。换言之，如果使用的是 RabbitMQ 默认队列，Consumer 一定要尽量直连到队列所在的节点，才能避免跨节点传输带来的性能问题。否则，无论 Consumer 连接 rabbit01 还是 rabbit02，出口总在 rabbit01，会产生性能瓶颈。另外，当 rabbit01 节点故障后，rabbit02 节点无法取到 rabbit01 节点中还未消费的消息实体。如果做了消息持久化，那么得等 rabbit01 节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。

• 镜像模式：

  • 在普通模式的基础上，通过镜像队列策略（HA Policy）将需要的队列配置成镜像队列，让队列存储在多个节点上，消息实体会主动在镜像节点之间同步，而不是在客户端取数据时临时拉取，也就是说有多少个镜像节点消息就会备份多少份。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉，所以在对业务可靠性要求较高的场合中适用。由于镜像队列之间消息自动同步，且内部有选举 Master 机制，即使 Master 节点宕机也不会影响整个集群的使用，达到去中心化的目的，从而有效的防止消息丢失及服务不可用等问题

集群节点

RabbitMQ 的集群节点分为磁盘节点、内存节点。RabbitMQ 支持消息的持久化，也就是数据写在磁盘上。在 RabbitMQ 集群中，必须至少有一个磁盘节点，否则队列元数据无法写入到集群中。当磁盘节点宕掉时，集群将无法写入新的队列元数据信息。如果 RabbitMQ 集群全部宕机，必须先启动磁盘节点，然后再启动内存节点。最合适的方案就是既有磁盘节点，又有内存节点；建议至少 2 个磁盘节点，其他节点可以作为内存节点来提高性能，比如采用 2 个 磁盘节点 + 1 个内存节点的集群搭建方式。

集群架构

RabbitMQ 集群的典型架构如下图所示，展示了如何通过多个节点实现高可用和负载均衡。这种架构可以有效地提高 RabbitMQ 的吞吐量和容错能力，适用于对消息可靠性和系统可用性要求较高的生产环境。架构说明如下：

• 客户端连接：​客户端通过虚拟 IP（VIP）连接到集群，VIP 由 Keepalived 管理，实现高可用性。
• 负载均衡：​HAProxy 作为负载均衡器，将客户端请求分发到后端的 RabbitMQ 节点。在 HAProxy 的配置中启用健康检查后，HAProxy 可以感知到 RabbitMQ 节点的宕机，并自动将其从负载均衡列表中剔除。
• RabbitMQ 节点：​多个 RabbitMQ 节点组成集群，节点之间通过镜像队列（Mirrored Queue）机制同步消息，确保消息的高可用性。

学习资源

• RabbitMQ 官网
• RabbitMQ 官方文档

RabbitMQ 的基础概念

AMQP（Advanced Message Queuing Protocol）高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布 / 订阅）、可靠性、安全。RabbitMQ 是一个开源的 AMQP 标准实现，服务器端用 Erlang 语言编写，支持多种客户端，如：Python、Ruby、C#、Java、PHP、GO、JavaScript 等。RabbitMQ 用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等方面表现不俗。

微服务与微服务架构

微服务的概述

微服务理论的提出者马丁。福勒（Martin Fowler） 在其博客中详细描述了什么是微服务。微服务强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题 / 提供落地对应服务的一个服务应用；狭意的看，可以看作 Eclipse 里面的一个个微服务工程 / 或者 Module。

微服务架构的概述

微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分为一组小服务，每个服务运行在自己的独立进程中，服务间通信采用轻量级通信机制 (通常是基于 HTTP 的 RESTful API)。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应该尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储技术。

前言

• Gradle Plugin 官网
• Gradle 官方英文文档
• Gradle W3School 中文教程

前言

本文适用于 CentOS/Debian/Ubuntu 等 Linux 发行版系统。

JDK 安装

由于 Gradle 的运行依赖于 JDK，但是安装 Oracle JDK 不是必需的，如果不想安装可以使用 Open-JDK 替代，而且大多数 Linux 发行版自带 Open-JDK。

大纲

• MyBatis 入门教程之一
• MyBatis 入门教程之二
• MyBatis 入门教程之三
• MyBatis 入门教程之四
• MyBatis 入门教程之五
• MyBatis 入门教程之六
• MyBatis 入门教程之七
• MyBatis 入门教程之八

MyBatis 实用场景

MyBatis 批量操作

调用不带参数的 openSession() 方法时，创建的 SqlSession 对象具有如下特性：

• 会开启一个事务（不会自动提交）
• 数据库连接对象会从由环境配置的数据源实例得到
• 事务隔离级别将会使用驱动或数据源的默认配置
• 预处理语句不会被复用，也不会批量处理更新

值得一提的是，openSession() 方法的 ExecutorType 类型的参数是枚举类型，取值如下：

• SIMPLE：这个执行器类型不做特殊的事情（默认执行器），它会为每个 SQL 语句的执行创建一个新的预处理语句。
• REUSE：这个执行器类型会复用预处理语句。
• BATCH：这个执行器会批量执行所有更新语句。