Vgbhfive's Blog

基础

AMQP

AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。

基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。

消息队列

MQ 全称为Message Queue, 消息队列。是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。

消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信。队列的使用除去了接收和发送应用程序同时执行的要求。

在项目中，将一些无需即时返回且耗时的操作提取出来，进行了异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高了系统的吞吐量。

问题再现

还是之前自己的项目，我改了一下架构，然后在引入新的组件时就爆出了ClassNotFoundException 的异常。

1

java.lang.ClassNotFoundException: org.mybatis.logging.LoggerFactory

解决过程

因为这个项目是之前就已经写好的架构，所以再出现这个问题时，我就想到了可能是依赖冲突的问题而导致的，在经过了MP 的Github 的issue 查询、StackOverFlow 之后，我找到了问题的答案那就是

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <exclusions>
        <exclusion>
            <artifactId>jsqlparser</artifactId>
            <groupId>com.github.jsqlparser</groupId>
        </exclusion>
    </exclusions>
	<version>3.3.2</version>
</dependency>

<!-- https://mvnrepository.com/artifact/org.mybatis.spring.boot/mybatis-spring-boot-autoconfigure -->
<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-autoconfigure</artifactId>
    <version>2.1.3</version>
</dependency>

<dependency>
    <groupId>com.github.pagehelper</groupId>
    <artifactId>pagehelper-spring-boot-starter</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.mybatis.spring.boot</groupId>
            <artifactId>mybatis-spring-boot-starter</artifactId>
        </exclusion>
    </exclusions>
    <version>1.2.10</version>
</dependency>

主要的冲突有两个，因为之前使用过分页，所以分页有一个依赖的冲突、然后就是MP 包里自带的sql 解析的组件有冲突，至此，这个问题就已经很清楚了。

个人备注

此博客内容均为作者学习所做笔记，侵删！
若转作其他用途，请注明来源！

前记

最近一直在看Spring 的官方文档，突然间发现自己平时用的很多东西都只是一知半解的，浏览器查询出来的解决办法也没有能表达出原作者的意思，并且用到了很多的Java 的基础内容。

要是现在突然再回去补习Java 的基础知识也不现实，所以现在都是根据看到的Spring 的原理所依赖的Java 基础再来进行弥补以前不会的Java 基础。

切记，学习一样东西，如果你没有深刻领悟作者的思路，那么你也仅仅只是学会了使用工具，而没有学会造工具。

基础

JNDI 即Java Naming and Directory Interface（JAVA 命名和目录接口），那么Java 命名的目的就是为了记录一些不方便记录的内容，就像DNS 中的域名与IP 的关系，存在一一对应的关系。

JNDI 被定义为独立于任何特定的目录服务实现。因此，可以以通用方式访问各种目录。

简介

SPI 全称为 Service Provider Interface，是一种服务发现机制。

SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。

这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。
SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。

基础

最近还是在弄片刻的东西，只是偶尔才有时间开始慢慢弄，但是还是在保持一直学习新的东西。其实片刻的1.0.0 版本已经做完了，但是我还不准备上线，因为我感觉这个片刻1.0.0 缺少一点东西，就感觉他跟我心中的那个系统有一点点不一样的地方。所以啊，还在打磨中，我自己也还在学习中。当然，这些不完美都是以我为标准的不完美，静候！

简介

前边说了那么多，其实还是为了学习一些新的东西，但是现在学习的也大都仅限于了解大致的运行原理，能够使用满足日常的开发需要即可，并没有很深入的去探究。

官方文档：https://prometheus.io

现在我基本上很少去看别人发的使用教程了，而是想学一个东西的时候，直接去找官方文档，虽然有时候需要翻译，但是在大部分的时候还是能够理解英文的意思即可。

如果你想看教程，在后面的引用中会放出来链接。

前言

最近还是在弄片刻的二次版本，在写后端服务的时候，因为考虑的比较多，一是想多学习学习其他的技术，二是想巩固现在已经会的技术，所以在写的时候束手束脚的，对于很多以前用的东西理解的都不是很透彻，导致了原本有简便的方法解决问题，现在却用了一种很麻烦的解决办法来解决问题。
所以我又给自己挖了一个坑。

简介

MyBatis 在内部提供了查询缓存的机制，用于减轻数据库压力，提高数据库性能。
MyBatis 可以提供一级缓存和二级缓存，一级缓存的主要作用域在Sqlsession，而二级缓存的作用域在Mapper 。

一级缓存的作用域在SqlSession，在操作数据库时需要构造SqlSession 对象，在对象中有一个数据结构用于存储缓存数据，不同的SqlSession 之间的缓存数据区域是互不影响。
Mybatis 默认开启一级缓存。
一级缓存在同一个SqlSession 下执行两次相同的sql 语句，第一次执行sql 语句会将从数据库查询到的数据写入到缓存中去，而第二次会直接从缓存中去取数据，不再去数据库查询数据，从而提高查询效率。
从上述德尔描述中，大致能明白在SqlSession 中进行sql 语句执行，遇到插入、更新、删除操作时，一级缓存中的数据会被删除，直到下一次查询，数据才会重新被放到缓存中。

二级缓存的作用域在Mapper ，多个SqlSession 去操作同一个Mapper 中的sql 语句，多个SqlSession 操作数据库会获得二级缓存，而SqlSession 之间是可以共享二级缓存的，也就是说二级缓存是跨SqlSession的。
MyBatis 默认不开启二级缓存。

前言

每天学习一点新东西，今天准备来看看Redis 内部的这些策略，也算是补了前段时间给自己挖的坑（坑在上一篇博客中），这个坑得慢慢的填啊。🙃

内容

• 键过期删除策略
• 内存淘汰策略

前言

今天在回顾之前做的支付的部分代码的时候，突然间发现了一个问题，那就是循环依赖。

代码本身没有报错，系统也可以正常运行，但是对于理解这一块的业务来说不是很容易，所以准备仔细来看看这一块的东西。

简介

循环依赖

循环依赖其实就是循环引用，也就是两个或者两个以上的Bean 互相持有对方，最终形成闭环。 这里有点类似于死锁的意思。

原理

说到Spring 的事务，大部分可能都会想到数据库对事务的支持所以才有了Spring 的事务机制，同时通过使用JDBC 的事务管理，那么你就得到了可以在Spring 中使用事务。

使用事务的示例：

1
2
3
4
5
6
7
8
9
10
11

Connection conn = DriverManager.getConnection();
try {  
    conn.setAutoCommit(false);  // 将自动提交设置为false                         
    执行CRUD操作 
    conn.commit();      // 当两个操作成功后手动提交  
} catch (Exception e) {  
    conn.rollback();    // 一旦其中一个操作出错都将回滚，所有操作都不成功
    e.printStackTrace();  
} finally {
    conn.colse();
}

从上面的示例中，我们就能看出来，事务是一系列的操作的集合，当集合中的某一部操作失败或者失误，那么在这之前的操作要全部回滚，并且终止后边的所有操作，避免出现由于数据不一致导致的一系列的错误。
事务的出现就是为了数据的完整性和一致性，目前在大部分的计算流程中，事务管理都是必不可少的。

前提

什么是消息系统

消息系统负责将数据从一个应用程序传输到另一个应用程序，因此应用程序可以专注于数据，但不担心如何共享它。 而分布式消息传递是基于可靠消息队列的概念，消息在客户端应用程序和消息传递系统之间异步排队。 有两种类型的消息模式可用 - 一种是点对点，另一种是发布 - 订阅(pub-sub)消息系统。 他们大多数消息模式都遵循 pub-sub 模式。

点对点消息系统

在点对点系统中，消息被保留在队列中。 一个或多个消费者可以消耗队列中的消息，但是特定消息只能由最多一个消费者消费。 一旦消费者读取队列中的消息，它就从该队列中消失。 该系统的典型示例是订单处理系统，其中每个订单将由一个订单处理器处理，但多个订单处理器也可以同时工作。

发布 - 订阅消息系统

在发布 - 订阅系统中，消息被保留在主题中。 与点对点系统不同，消费者可以订阅一个或多个主题并使用该主题中的所有消息。 在发布 - 订阅系统中，消息生产者称为发布者，消息使用者称为订阅者。 一个现实生活的例子是Dish电视，它发布不同的渠道，如运动，电影，音乐等，任何人都可以订阅自己的频道集，并获得他们订阅的频道时可用。