5月22
通过IDE创建一个springboot项目
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>//这行红色
</plugin>
提示spring-boot-maven-plugin not found。在网上找了有说是通过添加<pluginRepositories>过解决，但是测试之后发觉不起作用。 经过多次尝试，最终spring-boot-maven-plugin指定版本后成功解决。 修改后的pom.xml文件
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.1.3.RELEASE</version>
</plugin>
其实说白了就是没有加上这些Maven插件的版本号，导致Maven无法自动下载插件到本地，基本上提示这个not found的错误都是这个问题引起的。
maven-surefire-plugin、maven-compiler-plugin
这些插件也会出现这种问题，解决方案同上。只要你本地有下这些插件，不管哪个版本，就不会提示这个错误，去掉版本号也无所谓。
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>//这行红色
</plugin>
提示spring-boot-maven-plugin not found。在网上找了有说是通过添加<pluginRepositories>过解决，但是测试之后发觉不起作用。 经过多次尝试，最终spring-boot-maven-plugin指定版本后成功解决。 修改后的pom.xml文件
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.1.3.RELEASE</version>
</plugin>
其实说白了就是没有加上这些Maven插件的版本号，导致Maven无法自动下载插件到本地，基本上提示这个not found的错误都是这个问题引起的。
maven-surefire-plugin、maven-compiler-plugin
这些插件也会出现这种问题，解决方案同上。只要你本地有下这些插件，不管哪个版本，就不会提示这个错误，去掉版本号也无所谓。
5月22
一般情况下我们springboot用Application的main方法启动 ，怎么配置成tomcat启动呢？
首先有几个步骤：
1、<packaging>jar</packaging> 改为=> <packaging>war</packaging>
2、 排除springboot内置和tomcat容器（注：这一步可选）
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<!-- 移除嵌入式tomcat插件-->
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- 移除内嵌Tomcat需要重新添加servlet -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>${servlet.version}</version>
<scope>provided</scope>
</dependency>
3、修改启动类，并重写初始化方法
我们平常用main方法启动的方式，都有一个App的启动类，代码如下：
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
首先有几个步骤：
1、<packaging>jar</packaging> 改为=> <packaging>war</packaging>
2、 排除springboot内置和tomcat容器（注：这一步可选）
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<!-- 移除嵌入式tomcat插件-->
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- 移除内嵌Tomcat需要重新添加servlet -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>${servlet.version}</version>
<scope>provided</scope>
</dependency>
3、修改启动类，并重写初始化方法
我们平常用main方法启动的方式，都有一个App的启动类，代码如下：
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
5月19
cnpm : 无法加载文件 C:\Users\hecks\AppData\Roaming\npm\cnpm.ps1，因为在此系统上禁止运行脚本。
win10搜索找到 powershell
右键以管理员身份运行，
然后输入
set-ExecutionPolicy RemoteSigned
选择 A
再输入 get-ExecutionPolicy就可以了。
win10搜索找到 powershell
右键以管理员身份运行，
然后输入
set-ExecutionPolicy RemoteSigned
选择 A
再输入 get-ExecutionPolicy就可以了。
4月21
首先我们来看看95后的生活和成长环境，这一代人很多是母亲做全职家庭主妇，每天接送孩子上学放学，陪伴写作业，吃饭请过来，水果送到面前。各种兴趣班，高强度补课，95后已经厌倦了学习。工作后家里给配车，几乎一线城市的父母都有房产留给他们，只要他们的工资能养活自己不用家里补贴就行了。
以上分析虽然不能代表所有95后家庭，但是绝大多数城市的孩子都在类似环境中成长的。
雇佣95后员工面临的问题是什么？
在95后的家庭中，父母充当了保姆和秘书的工作，长期在这种环境中生活，有些能力被扼杀了，有些95后进入社会后，可能意识到这些问题，并主动去改变自己，更多的人可能一辈子无法改变，这种情况从90后身上可能看到。一旦进入公司，就离开了“保姆和秘书”的舒适区，需要很长时间去适应，这与80后是放养的一代人，野蛮生长，经过优胜略汰（社会达尔文主义），最后胜出的人完全不同。
95后员工缺少什么：
自驱能力
主动能力
思考能力
创新能力
自学能力
工作中你会发现，95后员工几乎绝大多数都存在上面列出的问题。
以上分析虽然不能代表所有95后家庭，但是绝大多数城市的孩子都在类似环境中成长的。
雇佣95后员工面临的问题是什么？
在95后的家庭中，父母充当了保姆和秘书的工作，长期在这种环境中生活，有些能力被扼杀了，有些95后进入社会后，可能意识到这些问题，并主动去改变自己，更多的人可能一辈子无法改变，这种情况从90后身上可能看到。一旦进入公司，就离开了“保姆和秘书”的舒适区，需要很长时间去适应，这与80后是放养的一代人，野蛮生长，经过优胜略汰（社会达尔文主义），最后胜出的人完全不同。
95后员工缺少什么：
自驱能力
主动能力
思考能力
创新能力
自学能力
工作中你会发现，95后员工几乎绝大多数都存在上面列出的问题。
4月3
nginx的upstream目前支持的5种方式的分配
1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
upstream backserver {
server 192.168.0.14;
server 192.168.0.15;
}
2、指定权重
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
upstream backserver {
server 192.168.0.14 weight=8;
server 192.168.0.15 weight=10;
}
3、IP绑定 ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
upstream backserver {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
4、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream backserver {
server server1;
server server2;
fair;
}
5、url_hash（第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
upstream backserver {
server 192.168.0.14;
server 192.168.0.15;
}
2、指定权重
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
upstream backserver {
server 192.168.0.14 weight=8;
server 192.168.0.15 weight=10;
}
3、IP绑定 ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
upstream backserver {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
4、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream backserver {
server server1;
server server2;
fair;
}
5、url_hash（第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
4月3
1、水平切分：
通俗的来讲
例：QQ的用户表。假设QQ的用户有100亿，如果只有一张表，每个用户登录的时候数据库都要从这100亿中查找，会很慢很慢。如果将这一张表分成100份，每张表有1亿条，就小了很多，比如qq_user_0,qq_user_1,qq_user_2...qq_user_99表。
用户登录的时候，可以将用户的id%100，那么会得到0-99的数，查询表的时候，将表名qq跟取模的数连接起来，就构建了表名。比如123456789用户，取模的89，那么就到qq_user_89表查询，查询的时间将会大大缩短。
这就是水平切分。
2、垂直切分：
垂直切分指的是：表的记录并不多，但是字段却很长，表占用空间很大，检索表的时候需要执行大量的IO，严重降低了性能。这时需要把大的字段拆分到另一个表，并且该表与原表是一对一的关系。
例如学生答题表tt：有如下字段：
Id name 分数 题目 回答
其中题目和回答是比较大的字段，id name 分数比较小。
如果我们只想查询id为8的学生的分数：select 分数 from tt where id = 8;虽然知识查询分数，但是题目和回答这两个大字段也是要被扫描的，很消耗性能。但是我们只关心分数，并不想查询题目和回答。这就可以使用垂直分割。我们可以把题目单独放到一张表中，通过id与tt表建立一对一的关系，同样将回答单独放到一张表中。这样我们插叙tt中的分数的时候就不会扫描题目和回答了。
3、其他要点：
1)存放图片、文件等大文件用文件系统存储。数据库只存储路径，图片和文件存放在文件系统，甚至单独存放在一台服务器(图床)。
2)数据参数配置。
最重要的参数就是内存，我们主要用的innodb引擎，所以下面两个参数调的很大：
innodb_additional_mem_pool_size=64M
innodb_buffer_pool_size=1G
对于MyISAM，需要调整key_buffer_size，当然调整参数还是要看状态，用show status语句可以看到当前状态，以决定该调整哪些参数。
通俗的来讲
例：QQ的用户表。假设QQ的用户有100亿，如果只有一张表，每个用户登录的时候数据库都要从这100亿中查找，会很慢很慢。如果将这一张表分成100份，每张表有1亿条，就小了很多，比如qq_user_0,qq_user_1,qq_user_2...qq_user_99表。
用户登录的时候，可以将用户的id%100，那么会得到0-99的数，查询表的时候，将表名qq跟取模的数连接起来，就构建了表名。比如123456789用户，取模的89，那么就到qq_user_89表查询，查询的时间将会大大缩短。
这就是水平切分。
2、垂直切分：
垂直切分指的是：表的记录并不多，但是字段却很长，表占用空间很大，检索表的时候需要执行大量的IO，严重降低了性能。这时需要把大的字段拆分到另一个表，并且该表与原表是一对一的关系。
例如学生答题表tt：有如下字段：
Id name 分数 题目 回答
其中题目和回答是比较大的字段，id name 分数比较小。
如果我们只想查询id为8的学生的分数：select 分数 from tt where id = 8;虽然知识查询分数，但是题目和回答这两个大字段也是要被扫描的，很消耗性能。但是我们只关心分数，并不想查询题目和回答。这就可以使用垂直分割。我们可以把题目单独放到一张表中，通过id与tt表建立一对一的关系，同样将回答单独放到一张表中。这样我们插叙tt中的分数的时候就不会扫描题目和回答了。
3、其他要点：
1)存放图片、文件等大文件用文件系统存储。数据库只存储路径，图片和文件存放在文件系统，甚至单独存放在一台服务器(图床)。
2)数据参数配置。
最重要的参数就是内存，我们主要用的innodb引擎，所以下面两个参数调的很大：
innodb_additional_mem_pool_size=64M
innodb_buffer_pool_size=1G
对于MyISAM，需要调整key_buffer_size，当然调整参数还是要看状态，用show status语句可以看到当前状态，以决定该调整哪些参数。
3月25
分布式事务了解吗？你们是如何解决分布式事务问题的？
一般来说，分布式事务的实现主要有以下 5 种方案：
XA 方案
TCC 方案
本地消息表
可靠消息最终一致性方案
最大努力通知方案
两阶段提交方案/XA方案
所谓的 XA 方案，即：两阶段提交，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。
这种分布式事务方案，比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。如果要玩儿，那么基于 Spring + JTA 就可以搞定，自己随便搜个 demo 看看就知道了。
这个方案，我们很少用，一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。我可以给大家介绍一下， 现在微服务，一个大的系统分成几十个甚至几百个服务。一般来说，我们的规定和规范，是要求每个服务只能操作自己对应的一个数据库。
如果你要操作别的服务对应的库，不允许直连别的服务的库，违反微服务架构的规范，你随便交叉胡乱访问，几百个服务的话，全体乱套，这样的一套服务是没法管理的，没法治理的，可能会出现数据被别人改错，自己的库被别人写挂等情况。
如果你要操作别人的服务的库，你必须是通过调用别的服务的接口来实现，绝对不允许交叉访问别人的数据库。
TCC 方案
TCC 的全称是：Try、Confirm、Cancel。
Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留。
Confirm 阶段：这个阶段说的是在各个服务中执行实际的操作。
Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）
这种方案说实话几乎很少人使用，我们用的也比较少，但是也有使用的场景。因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿了，会造成补偿代码巨大，非常之恶心。
比如说我们，一般来说跟钱相关的，跟钱打交道的，支付、交易相关的场景，我们会用 TCC，严格保证分布式事务要么全部成功，要么全部自动回滚，严格保证资金的正确性，保证在资金上不会出现问题。
而且最好是你的各个业务执行的时间都比较短。
但是说实话，一般尽量别这么搞，自己手写回滚逻辑，或者是补偿逻辑，实在太恶心了，那个业务代码很难维护。
本地消息表
本地消息表其实是国外的 ebay 搞出来的这么一套思想。
这个大概意思是这样的：
A 系统在自己本地一个事务里操作同时，插入一条数据到消息表；
接着 A 系统将这个消息发送到 MQ 中去；
B 系统接收到消息之后，在一个事务里，往自己本地消息表里插入一条数据，同时执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样保证不会重复处理消息；
B 系统执行成功之后，就会更新自己本地消息表的状态以及 A 系统消息表的状态；
如果 B 系统处理失败了，那么就不会更新消息表状态，那么此时 A 系统会定时扫描自己的消息表，如果有未处理的消息，会再次发送到 MQ 中去，让 B 再次处理；
这个方案保证了最终一致性，哪怕 B 事务失败了，但是 A 会不断重发消息，直到 B 那边成功为止。
这个方案说实话最大的问题就在于严重依赖于数据库的消息表来管理事务啥的，会导致如果是高并发场景咋办呢？咋扩展呢？所以一般确实很少用。
一般来说，分布式事务的实现主要有以下 5 种方案：
XA 方案
TCC 方案
本地消息表
可靠消息最终一致性方案
最大努力通知方案
两阶段提交方案/XA方案
所谓的 XA 方案，即：两阶段提交，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。
这种分布式事务方案，比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。如果要玩儿，那么基于 Spring + JTA 就可以搞定，自己随便搜个 demo 看看就知道了。
这个方案，我们很少用，一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。我可以给大家介绍一下， 现在微服务，一个大的系统分成几十个甚至几百个服务。一般来说，我们的规定和规范，是要求每个服务只能操作自己对应的一个数据库。
如果你要操作别的服务对应的库，不允许直连别的服务的库，违反微服务架构的规范，你随便交叉胡乱访问，几百个服务的话，全体乱套，这样的一套服务是没法管理的，没法治理的，可能会出现数据被别人改错，自己的库被别人写挂等情况。
如果你要操作别人的服务的库，你必须是通过调用别的服务的接口来实现，绝对不允许交叉访问别人的数据库。
TCC 方案
TCC 的全称是：Try、Confirm、Cancel。
Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留。
Confirm 阶段：这个阶段说的是在各个服务中执行实际的操作。
Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）
这种方案说实话几乎很少人使用，我们用的也比较少，但是也有使用的场景。因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿了，会造成补偿代码巨大，非常之恶心。
比如说我们，一般来说跟钱相关的，跟钱打交道的，支付、交易相关的场景，我们会用 TCC，严格保证分布式事务要么全部成功，要么全部自动回滚，严格保证资金的正确性，保证在资金上不会出现问题。
而且最好是你的各个业务执行的时间都比较短。
但是说实话，一般尽量别这么搞，自己手写回滚逻辑，或者是补偿逻辑，实在太恶心了，那个业务代码很难维护。
本地消息表
本地消息表其实是国外的 ebay 搞出来的这么一套思想。
这个大概意思是这样的：
A 系统在自己本地一个事务里操作同时，插入一条数据到消息表；
接着 A 系统将这个消息发送到 MQ 中去；
B 系统接收到消息之后，在一个事务里，往自己本地消息表里插入一条数据，同时执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样保证不会重复处理消息；
B 系统执行成功之后，就会更新自己本地消息表的状态以及 A 系统消息表的状态；
如果 B 系统处理失败了，那么就不会更新消息表状态，那么此时 A 系统会定时扫描自己的消息表，如果有未处理的消息，会再次发送到 MQ 中去，让 B 再次处理；
这个方案保证了最终一致性，哪怕 B 事务失败了，但是 A 会不断重发消息，直到 B 那边成功为止。
这个方案说实话最大的问题就在于严重依赖于数据库的消息表来管理事务啥的，会导致如果是高并发场景咋办呢？咋扩展呢？所以一般确实很少用。
1月7
今天使用RequestBody接受前端传过来的参数，以前接受字符串数组非常成功，这次把形参改成了List，原本以为顺利接受参数并映射成User的list结构，结果竟然在我取user.getId()时报了com.alibaba.fastjson.JSONObject cannot be cast to xxx的错。
后端：
@RequestMapping("/insertUser")
public void insertBlank(@RequestBody List userList) {
User user = userList.get(0);
System.out.println(user.getId());
}
我的user对象没有转换成功，还是一个一个JSONObject，但是请观察，JSONArray转换成了ArrayList。
嗯，配置的映射转换器生效了，结果表明，RequestBody能直接将json对象映射成java对象，但仅限于第一层的对象，至于嵌套的对象，则需要开发者自己去转换。
@RequestMapping("/insertUser")
public void insertUser(@RequestBody List list) {
List userList = list.stream().map(json -> JSONObject.toJavaObject(json, User.class)).collect(Collectors.toList());
service.insertUser(userList);
}
后端：
@RequestMapping("/insertUser")
public void insertBlank(@RequestBody List
User user = userList.get(0);
System.out.println(user.getId());
}
我的user对象没有转换成功，还是一个一个JSONObject，但是请观察，JSONArray转换成了ArrayList。
嗯，配置的映射转换器生效了，结果表明，RequestBody能直接将json对象映射成java对象，但仅限于第一层的对象，至于嵌套的对象，则需要开发者自己去转换。
@RequestMapping("/insertUser")
public void insertUser(@RequestBody List
List
service.insertUser(userList);
}
12月30
在弹出窗口里刚开始不管点击什么都无法显示，后来点击表情的时候发现表情的选项框出现在了当前dialog的后面
然后猜测所有的选项框点击后，都出现在dialog的后面。
接着开始F12，发现当前dialog的z-index的值是1005。
返回看ueditor的z-index。
在ueditor.config.js里zIndex的默认值是900；将值改为1100
强行刷新页面，或者打开ueditor.config.js强刷，然就成功！
然后猜测所有的选项框点击后，都出现在dialog的后面。
接着开始F12，发现当前dialog的z-index的值是1005。
返回看ueditor的z-index。
在ueditor.config.js里zIndex的默认值是900；将值改为1100
强行刷新页面，或者打开ueditor.config.js强刷，然就成功！
12月20
首先从以下几点来介绍：
1.为什么要使用synchronized
在并发编程中存在线程安全问题，主要原因有：1.存在共享数据 2.多线程共同操作共享数据。关键字synchronized可以保证在同一时刻，只有一个线程可以执行某个方法或某个代码块，同时synchronized可以保证一个线程的变化可见（可见性），即可以代替volatile。
2.实现原理
synchronized可以保证方法或者代码块在运行时，同一时刻只有一个方法可以进入到临界区，同时它还可以保证共享变量的内存可见性
3.synchronized的三种应用方式
Java中每一个对象都可以作为锁，这是synchronized实现同步的基础：
普通同步方法（实例方法），锁是当前实例对象 ，进入同步代码前要获得当前实例的锁
静态同步方法，锁是当前类的class对象 ，进入同步代码前要获得当前类对象的锁
同步方法块，锁是括号里面的对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。
4.synchronized的作用
Synchronized是Java中解决并发问题的一种最常用最简单的方法 ，他可以确保线程互斥的访问同步代码
1.为什么要使用synchronized
在并发编程中存在线程安全问题，主要原因有：1.存在共享数据 2.多线程共同操作共享数据。关键字synchronized可以保证在同一时刻，只有一个线程可以执行某个方法或某个代码块，同时synchronized可以保证一个线程的变化可见（可见性），即可以代替volatile。
2.实现原理
synchronized可以保证方法或者代码块在运行时，同一时刻只有一个方法可以进入到临界区，同时它还可以保证共享变量的内存可见性
3.synchronized的三种应用方式
Java中每一个对象都可以作为锁，这是synchronized实现同步的基础：
普通同步方法（实例方法），锁是当前实例对象 ，进入同步代码前要获得当前实例的锁
静态同步方法，锁是当前类的class对象 ，进入同步代码前要获得当前类对象的锁
同步方法块，锁是括号里面的对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。
4.synchronized的作用
Synchronized是Java中解决并发问题的一种最常用最简单的方法 ，他可以确保线程互斥的访问同步代码
