Nginx 是前后端开发工程师必须掌握的神器。该神器有很多使用场景：比如反向代理、负载均衡、动静分离、跨域等等。
把 Nginx 下载下来打开 conf 文件夹的 nginx.conf 文件，Nginx 服务器的基础配置和默认的配置都存放于此。

配置是让程序员非常头疼的事，比如 Java 后端框架 SSM，大量配置文件让不少人头皮发麻，所以才涌现了 Spring Boot 这样能简化配置的框架。
如果能够采用可视化的方式对 Nginx 进行配置，那该多好，后来在 GitHub 上发现了这款，可以一键生成 Nginx 配置的神器，相当给力
先来看看它都支持什么功能的配置：反向代理、HTTPS、HTTP/2、IPv6, 缓存、WordPress、CDN、Node.js 支持、 Python (Django) 服务器等等

如果你想在线进行配置，只需要打开网站：https://nginxconfig.io/，按照自己的需求进行操作就行了

选择你的场景，填写好参数，系统就会自动生成配置文件。

开源地址：github.com/digitalocean/nginxconfig.io

网站：digitalocean.com/community/tools/nginx

查询出来的数据库结束时间(字符串类型)：2020-03-07 23:55:00.0
DateUtils.parse使用"yyyy-MM-dd HH:mm:ss"解析的时候报错。
java.text.ParseException: Unable to parse the date: 2020-03-07 23:55:00.0

解决方法：

//先转换成时间戳类型，再转化成date
Timestamp date_time= (Timestamp) MapUtils.getObject(map,"date_time");
Date fmtDate= new Date(date_time.getTime());
log.error("转换后日期：{}",DateUtils.formatDate(fmtDate,"yyyy-MM-dd HH:mm:ss"));

用得最多的日期时间类型，就是 DATETIME。虽然 MySQL 也支持 YEAR（年）、 TIME（时间）、DATE（日期），以及 TIMESTAMP 类型，但是在实际项目中，尽量用 DATETIME 类型。因为这个数据类型包括了完整的日期和时间信息，取值范围也最大，使用起来比较方便。毕竟，如果日期时间信息分散在好几个字段，很不容易记，而且查询的时候，SQL 语句也会更加复杂。

此外，一般存注册时间、商品发布时间等，不建议使用DATETIME存储，而是使用时间戳，因为DATETIME虽然直观，但不便于计算。

~ 会匹配最近的小版本依赖包，比如~1.2.3会匹配所有1.2.x版本，但是不包括1.3.0
^ 会匹配最新的大版本依赖包，比如^1.2.3会匹配所有1.x.x的包，包括1.3.0，但是不包括2.0.0

• 这意味着安装最新版本的依赖包

结论
　　一、修改的package.json中的包版本号比package-lock.json中的版本号高时，npm install可以修改项目版本号；反之，如果版本号比package-lock中的版本号低时，该包的实际版本号保持不变
　　二、如需降低版本号，可以通过npm install packageName@packageVersion降低版本号

为了避免服务器崩溃，大家会通过负载均衡的方式来分担服务器压力。将对台服务器组成一个集群，当用户访问时，先访问到一个转发服务器，再由转发服务器将访问分发到压力更小的服务器。

Nginx负载均衡实现的策略有以下五种：

1 .轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端某个服务器宕机，能自动剔除故障系统。

upstream backserver {
server 192.168.0.12;
server 192.168.0.13;
}

2.权重 weight
weight的值越大，分配到的访问概率越高，主要用于后端每台服务器性能不均衡的情况下。其次是为在主从的情况下设置不同的权值，达到合理有效的地利用主机资源。

权重越高，在被访问的概率越大，如上例，分别是20%，80%。
upstream backserver {
server 192.168.0.12 weight=2;
server 192.168.0.13 weight=8;
} .

3.ip_hash( IP绑定)
每个请求按访问IP的哈希结果分配，使来自同一个IP的访客固定访问一台后端服务器，并且可以有效解决动态网页存在的session共享问题

upstream backserver {
ip_hash;
server 192.168.0.12:88;
server 192.168.0.13:80;
}

4.fair(第三方插件)
必须安装upstream_fair模块。

对比 weight、ip_hash更加智能的负载均衡算法，fair算法可以根据页面大小和加载时间长短智能地进行负载均衡，响应时间短的优先分配。

哪个服务器的响应速度快，就将请求分配到那个服务器上。
upstream backserver {
server server1;
server server2;
fair;
}

5.url_hash(第三方插件)
必须安装Nginx的hash软件包

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，可以进一步提高后端缓存服务器的效率。

upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}

概述

FastJson2是FastJson项目的重要升级，目标是为下一个十年提供一个高性能的JSON库。根据官方给出的性能来看，相比v1版本，确实有了很大的提升，本篇文章我们来看下究竟做了哪些事情，使得性能有了大幅度的提升。
本篇将采用代码测试 + 源码阅读的方式对FastJson2的性能提升做一个较为全面的探索。

使用测试

1.引入依赖

<dependency>

<groupId>com.alibaba.fastjson2</groupId>
<artifactId>fastjson2</artifactId>
<version>2.0.8</version>

</dependency>
在fastjson2当中，jsonArray.toJavaList方法转变成了jsonArray.toList。

常用方法

// 将字符串解析成JSONObject
static JSONObject parseObject(String str);

// 将字符串解析成JSONArray
static JSONArray parseArray(String str);

// 将字符串解析成Java对象
static T parseObject(byte[] utf8Bytes, Class<T> objectClass);

// 将Java对象输出成字符串
static String toJSONString(Object object);

// 将Java对象输出成UT8编码的byte[]
static byte[] toJSONBytes(Object object);

测试情况

fastjson2相比fastjson确实是有性能提升，但是取决于堆内存的大小。
堆空间小的情况下，fastjson的性能表现优于fastjson2。
在适当的情况先，对jvm进行调优，是对应用程序的性能有影响的
我们需要知道，堆空间并非越大越好，空间越大代表着GC处理时间会越长，其表现为应用响应时间的增加。