MyBatisPlus-03-自动填充及乐观锁

1. 自动填充功能

• 创建时间、修改时间！这些个操作一遍都是自动化完成的，我们不希望手动更新！

• 阿里巴巴开发手册：所有的数据库表：gmt_create、gmt_modified几乎所有的表都要配置上！而且需要自动化！

1.1 方式一 ： 数据库级别

1、在表中新增字段 create_time, update_time

2、再次测试插入方法，我们需要先把实体类同步！

1
2

private Date createTime;
private Date updateTime;

3. 再次更新查看结果即可

MyBatisPlus-01-概述及入门案例

前言

1. 为什么要学习MyBatis-Plus?

• MyBatisPlus可以节省我们大量工作时间，所有的CRUD代码它都可以自动化完成！

2. 类似的市场上的应用技术

• JPA 、 tk-mapper、MyBatisPlus

1. 简介

• MyBatis 本来就是简化 JDBC 操作的！
• 官网：https://mp.baomidou.com/
  • MyBatis Plus，简化 MyBatis ！

JUC-21-FutureTask 源码分析

• 废话不多收，直接手撕源码

开发笔记-06-DDD

前言

• 待后续补充

开发笔记-05-protal

前言

• Portal在英语中是入口的意思。Portal认证通常也称为Web认证，一般将Portal认证网站称为门户网站。
• 它提供了一种较为简单的用户认证方法，对用户而言，相对其它认证方式更易于使用。它有两大特色：
  • 免客户端 : 只需要网页浏览器（如IE）支持，即可为用户提供认证服务，不需要安装专门的客户端或者拨号程序。免客户端软件对于像宾馆、酒店等公共网络节点，免客户端软件是一个基本要求。
  • 新业务载体 : 利用Portal认证的门户功能，运营商可以将小区广播、广告、信息查询、网上购物等业务放到Portal上。用户上网时会强制地看到上述信息。
• Portal认证的基本方式是通过在Portal页面的显著位置设置认证窗口，用户开机获取IP地址后，通过登录Portal认证页面进行认证，认证通过后即可访问Internet。
• 对于用户来说有两种方式访问认证页面：
  • 主动Portal：用户必须知道PORTAL服务器的IP地址，主动登陆PORTAL服务器进行认证，之后才能访问网络。
  • 强制Portal：未认证用户访问网址，都会先强制定向到PORTAL服务器进行认证，用户不需要记忆Portal服务器的IP地址。

java8-新特性-接口中的方法

前言 : JDK1.8 之前的回顾

• 在jdk1.8之前，我们对接口的认知是这样的：

  1、方法：只能包含public和abstract的方法，即使定义为：

1
2
3
4
5
6

interface Shape {
   //获取几何图形的面积
   Double getArea(double length, double width);
}

 方法前面也默认加了public abstract修饰

2、字段：只能包含常量，即public static final 修饰的变量

1
2
3
4
5

interface Shape {
   int length = 0;
}

即使这样写，也是默认加上了public static final修饰。

问题展现

• 现在我们有很多类实现了该接口，有三角形trangle，有圆形circle······

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

class Trangle implements Shape {
 
    @Override
    public Double getArea(double length, double width) {
        return length * width / 2;
    }
}
 
class Circle implements Shape {
 
    @Override
    public Double getArea(double length, double width) {
        //调用方法时默认length传半径
        return 3.14 * length * length;
    }
}

• 有一天，我们发现接口功能不够用了，需要增加一个计算周长的方法。

• 这时候，JDK1.7及其之前版本该怎么办呢？

  • 管他三七二十一，往接口里直接加个方法，强迫所有实现该几何图形的接口的实现类（正方形、圆形、三角形······）都实现最新的接口方法
  • 把接口代码移到抽象类，添加一个有默认实现的计算周长的方法，但是所有实现类都要改为继承，遇到实现类继承别的父类就行不通了（java只有单继承）
  • 添加一个新接口，新接口里加上一个计算周长的方法，让所有实现了Shape接口的类再实现新的接口，看起来很美好，接口本身也是这么使用的，但是如果这个方法让所有的实现类再实现一遍，还是挺麻烦的。

• JDK1.8针对这种接口不易扩展的现象，在接口新增default方法，可以有效解决上述遇到的接口拓展新方法的问题。原先的实现类不用改任何代码就拥有了新的能力，有点像从接口继承了一个有实现的方法，可以直接调用。

java8-新特性-‘::’ 关键字

前言

• Java 8中我们可以通过 :: 关键字来访问类的构造方法，对象方法，静态方法。
• 方法的引用的语法，主要有三类:

1.指向静态方法的方法引用，例如Integer的parseInt方法 ，可以写成Integer::parseInt

类：：静态方法名

2.指向任意类型实例方法的方法引用，例如String的length方法，写成String::length

类：：实例方法名

3.指向现有对象的实例方法的方法引用

对象：：实例方法名

4.构造器的引用：对于一个现有构造函数，你可以利用它的名称和关键字new来创建它的一个引用ClassName::new

• 在java8中的函数式接口，提供了无参构造函数，以及有参构造函数创建实例的方式；构造器的参数列表，需要与函数式接口中参数列表保持一致！

• 方法的引用让你可以重复使用现有的方法定义，并像lambda一样传递他们，在一些情况下，比起使用lambda表达式，它们似乎更易读，感觉也更自然；

开发笔记-04-高并发慢查询

前言

• 慢查询是高并发之大忌

• 博客转载：https://www.cnblogs.com/donlianli/p/11068095.html

1. 问题描述

• 最近又遇到了一次慢查把db（mariadb10)几乎打挂的案例，作为一个核心支付系统的技术负责人，真是每日如履薄冰。因为之前支付系统经常出问题，现在各个BG对支付系统都盯得很紧。这次要不是我及时让DB给暴力清理数据，没准又提一个P2故障；
• 抱怨归抱怨，事后复盘，一丝都不能马虎。首先，描述一下故障的全过程。起因是我们支付系统有一个异步队列，这个队列使用的一张mysql表存储，异步回调业务线的任务（姑且表名称叫task)，都会首先放这里。同时这个task表还有其他的异步任务，不同的任务使用task_type字段来进行区分。然后应用系统有一个定时任务，扫描这张表是否有待消费的任务，如果有，则会取出来进行消费；典型的生产者消费者模型；

开发笔记-03-SpringBoot统一异常处理

前言

• 官方文档： https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/bind/annotation/RestControllerAdvice.html

• 在做前后端分离的项目时，后端通常都会拆分成多个独立的微服务，这时候就会涉及每个服务返回给前端的数据格式问题了。

• 下面就来实现一个比较常用的数据格式，统一所有服务的返回值格式。

• 一般返回的数据格式会包括4个部分

  • 第一部分：请求处理是否成功
  • 第二部分：服务处理结果编码
  • 第三部分：编码对应的文本信息
  • 第四部分：返回值

1
2
3
4
5
6
7
8
9
10

{
    "result": true,
    "code": 1000,
    "message": "SUCCESS",
    "data": {
        "lantian": 17,
        "qingfen": 16,
        "baiyun": 18
    }
}

• 对于异常处理情况，我们也需要统一成上面的格式:
  • 如果在controller中通过try catch来处理异常的话，会出现一个问题就是每个函数里都加一个Try catch,代码会变的很乱。
    • 这个全局异常拦截器的目的是要把异常转化为通用的json结构，给到前端，前端根据不同的状态码。做出不同的业务逻辑
    • 举例子，后端给前端未登录，前端跳登录页面
    • 后端给前端服务器异常，接口超时，前端重新调用，或者弹出提示给用户
    • 测试就是手动抛出这样一个异常，然后能看到对应的一个异常展示
  • 下面我们就通过spring boot的注解来省略掉controller中的try-catch帮助我们来封装异常信息并返回给前端，这样用户也不会得到一些奇奇怪怪的错误提示。

开发笔记-02-cola4.0

前言

• COLA的主要目的是为应用架构提供一套简单的可以复制、可以理解、可以落地、可以控制复杂性的”指导和约束”。
• 同样，好的应用架构，也遵循一些共同模式，都提倡以业务为核心，解耦外部依赖，分离业务复杂度和技术复杂度。
• 应用架构的本质，就是要从繁杂的业务系统中提炼出共性，找到解决业务问题的最佳共同模式，为开发人员提供统一的认知，治理混乱。帮助应用系统“从混乱到有序”
• COLA架构就是为此而生，其核心职责就是定义良好的应用结构，提供最佳实践。

开源项目地址 ： https://github.com/alibaba/COLA

1. Cola 分层架构

• 所有的复杂系统都会呈现出层级结构，应用系统处理复杂业务逻辑也应该是分层的，下层对上层屏蔽处理细节，每一层各司其职，分离关注点。
• 对于一个典型的业务应用系统来说，COLA会做如下层次定义，每一层都有明确的职责定义