邢栋博客

邢栋博客,Action博客,记录工作和生活中的点点滴滴

SpringBoot项目打包简记
项目目录 first-app-demo

模型层:model
持久层:persistence
表示层:web

把 jar 修改成 pom,默认是 jar
pom.xml(first-app-demo)

模型层:model
持久层:persistence
表示层:web
web 依赖于 persistence ,persistence 依赖于 model
web Controller ->UserRepository -> User


------------jar打包方式-------------

cd D:\JAVA_PROJECT\first-app-demo

在pom.xml(fisrt-app-demo)中加入 ,mainClass 复制接口 ,然后把下面这段话 剪贴 到 web 模块下的 pom.xml 里面
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
-----
<configuration>
<mainClass>com.imooc.firstappdemo.FirstAppDemoApplication</mainClass>
</configuration>
----
</plugin>
</plugins>
</build>

mvn -Dmaven.test.skip -U clean package

会显示如下::::
Building jar: D:\JAVA_PROJECT\first-app-demo\web\target\web-0.0.1-SNAPSHOT.jar

执行
cd web\target\
java -jar web-0.0.1-SNAPSHOT.jar 


-------------war打包方式-------------

在web pom.xml中加入下面这句话,在  <artifactId>web</artifactId> 之后
<!-- 将packaging 值(默认jar) 调整成 war -->
<packaging>war</packaging>

并在web/src/main/下新建 webapp/WEB-INF/web.xml 文件

cd D:\JAVA_PROJECT\first-app-demo //回到项目根目录
mvn -Dmaven.test.skip -U clean package
会显示如下::::
Building war: D:\JAVA_PROJECT\first-app-demo\web\target\web-0.0.1-SNAPSHOT.war
cd web\target\
java -jar web-0.0.1-SNAPSHOT.jar



-------------maven插件方式运行-------------
cd D:\JAVA_PROJECT\first-app-demo
cd web 
mvn -Dmaven.test.skip -U clean install
mvn spring-boot:run

---------------war打包方式并在tomcat下运行----------------------------------------
在web pom.xml中加入下面这句话,在  <artifactId>web</artifactId> 之后
<!-- 将packaging 值(默认jar) 调整成 war -->
<packaging>war</packaging>

并增加tomcat依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</dependency>

并在web/src/main/下新建 webapp/WEB-INF/web.xml 文件,不能为空
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
    <display-name>version</display-name>
</web-app>

修改启动文件,让其类集成 SpringBootServletInitializer,并重写configure方法

@SpringBootApplication
public class FirstAppDemoApplication extends SpringBootServletInitializer {
@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {
return builder.sources(FirstAppDemoApplication.class);
}
public static void main(String[] args) {
SpringApplication.run(FirstAppDemoApplication.class, args);
}
}
cd D:\JAVA_PROJECT\first-app-demo //回到项目根目录
mvn -Dmaven.test.skip -U clean package
会显示如下::::
Building war: D:\JAVA_PROJECT\first-app-demo\web\target\web-0.0.1-SNAPSHOT.war
复制 web-0.0.1-SNAPSHOT.war 此文件到 tomcat/webapp下面
然后运行tomcat即可

jar包和war包的介绍和区别

1.jar包的介绍

JAR(Java Archive,Java 归档文件)是与平台无关的文件格式,它允许将许多文件组合成一个压缩文件。JavaSE程序可以打包成Jar包(J其实可以理解为Java了)。

JAR 文件格式以流行的 ZIP 文件格式为基础。与 ZIP 文件不同的是,JAR 文件不仅用于压缩和发布,而且还用于部署和封装库、组件和插件程序,并可被像编译器和 JVM 这样的工具直接使用。在 JAR 中包含特殊的文件,如 manifests 和部署描述符,用来指示工具如何处理特定的 JAR。

简单来说,jar包就是别人已经写好的一些类,然后对这些类进行打包。可以将这些jar包引入到你的项目中,可以直接使用这些jar包中的类和属性,这些jar包一般放在lib目录下。

2.war包的介绍

war是一个可以直接运行的web模块,通常用于网站,打成包部署到容器中。以Tomcat来说,将war包放置在其\webapps\目录下,然后启动Tomcat,这个包就会自动解压,就相当于发布了。

war包是Sun提出的一种web应用程序格式,与jar类似,是很多文件的压缩包。war包中的文件按照一定目录结构来组织。根据其根目录下包含有html和jsp文件,或者包含有这两种文件的目录,另外还有WEB-INF目录。通常在WEB-INF目录下含有一个web.xml文件和一个classes目录,web.xml是这个应用的配置文件,而classes目录下则包含编译好的servlet类和jsp,或者servlet所依赖的其他类(如JavaBean)。通常这些所依赖的类也可以打包成jar包放在WEB-INF下的lib目录下。

简单来说,war包是JavaWeb程序打的包,war包里面包括写的代码编译成的class文件,依赖的包,配置文件,所有的网站页面,包括html,jsp等等。一个war包可以理解为是一个web项目,里面是项目的所有东西。

3.区别:(WAR文件代表了一个Web应用程序,JAR是类的归档文件。)

如果一个Web应用程序的目录和文件非常多,那么将这个Web应用程序部署到另一台机器上,就不是很方便了,这时可以将Web应用程序打包成Web 归档(WAR)文件,这个过程和把Java类文件打包成JAR文件的过程类似。利用WAR文件,可以把Servlet类文件和相关的资源集中在一起进行发布。在这个过程中,Web应用程序就不是按照目录层次结构来进行部署了,而是把WAR文件作为部署单元来使用。

一个WAR文件就是一个Web应用程序,建立WAR文件,就是把整个Web应用程序(不包括Web应用程序层次结构的根目录)压缩起来,指定一个.war扩展名。

要注意的是,虽然WAR文件和JAR文件的文件格式是一样的,并且都是使用jar命令来创建,但就其应用来说,WAR文件和JAR文件是有根本区别的。JAR文件的目的是把类和相关的资源封装到压缩的归档文件中,而对于WAR文件来说,一个WAR文件代表了一个Web应用程序,它可以包含 Servlet、HTML页面、Java类、图像文件,以及组成Web应用程序的其他资源,而不仅仅是类的归档文件。

那么什么时候应该使用WAR文件呢?在开发阶段不适合使用WAR文件,因为在开发阶段,经常需要添加或删除Web应用程序的内容,更新 Servlet类文件,而每一次改动后,重新建立WAR文件将是一件浪费时间的事情。在产品发布阶段,使用WAR文件是比较合适的,因为在这个时候,几乎不需要再做什么改动了。

在开发阶段,我们通常将Servlet源文件放到Web应用程序目录的src子目录下,以便和Web资源文件区分。在建立WAR文件时,只需要将src目录从Web应用程序目录中移走,就可以打包了。

4.部署war包到Tomcat

1). 我这里工作中一般是开发打war包给测试,比如说现在测试拿到一个war包,名字叫test.war。

2). 打开Tomcat的安装路径 ,假设是“D:\Tomcat\apache-tomcat-7.0.68”,然后进入到 webapps文件夹中,把 test.war放到 webapps文件夹。

3). 启动Tomcat。如果不需要更改配置文件:到这一步就可以了。在浏览器输入“http:localhost:tomcat_port/test即可打开test项目的 index.jsp页面(port是自己的端口号)。如果test项目没有index.jsp页面,那就需要打开其他相应的页面。如果需要更改配置文件:

4). 关闭 Tomcat。

5). 删除 test.war文件(如果在tomcat启动的状态下删去war包,解压好的文件夹也会被一并删除,所以需要在解压后停止tomcat, 然后删掉war包,这时再启动。这时项目文件夹就会被认为不是war解压而来。)。

6). 由于刚刚启动过Tomcat,Tomcat会自动解压缩test.war为 test文件夹。所以我们在webapps下面可以看到test文件夹。打开test文件夹更改配置文件即可。

7). 更新完配置之后,启动Tomcat。

8). 浏览器打开即可。


原文链接:https://www.jianshu.com/p/3b5c45e8e5bd


yii2设置默认时间时区(基础模板和高级模板)
基本模板
config/web.php
在$config中加入  'timeZone'=>'Asia/Shanghai',


高级模板
common/config/main.php
在return中加入  'timeZone'=>'Asia/Shanghai',

nginx中fastcgi_param参数说明
fastcgi_param  QUERY_STRING       $query_string;  #请求的参数;如?app=123
fastcgi_param  REQUEST_METHOD     $request_method; #请求的动作(GET,POST)
fastcgi_param  CONTENT_TYPE       $content_type; #请求头中的Content-Type字段
fastcgi_param  CONTENT_LENGTH     $content_length; #请求头中的Content-length字段。

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name; #脚本名称
fastcgi_param  REQUEST_URI        $request_uri; #请求的地址不带参数
fastcgi_param  DOCUMENT_URI       $document_uri; #与$uri相同。
fastcgi_param  DOCUMENT_ROOT      $document_root; #网站的根目录。在server配置中root指令中指定的值 
fastcgi_param  SERVER_PROTOCOL    $server_protocol; #请求使用的协议,通常是HTTP/1.0或HTTP/1.1
fastcgi_param  REQUEST_SCHEME     $scheme;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1; #cgi 版本
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version; #nginx 版本号,可修改、隐藏

fastcgi_param  REMOTE_ADDR        $remote_addr; #客户端IP
fastcgi_param  REMOTE_PORT        $remote_port; #客户端端口
fastcgi_param  SERVER_ADDR        $server_addr; #服务器IP地址
fastcgi_param  SERVER_PORT        $server_port; #服务器端口
fastcgi_param  SERVER_NAME        $server_name; #服务器名,域名在server配置中指定的server_name

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;
redis底层数据结构总结
redis有五种对象的类型

REDIS_STRING  字符串对象
REDIS_LIST 列表对象
REDIS_HASH 哈希对象
REDIS_SET 集合对象
REDIS_ZSET 有序集合对象


底层数据结构共有八种
编码常量 编码对应的底层数据结构
1、REDIS_ENCODING_INT long类型的整数
2、REDIS_ENCODING_EMBSTR embstr编码的简单动态字符串
3、REDIS_ENCODING_RAW 简单动态字符串
4、REDIS_ENCODING_HT 字典
5、REDIS_ENCODING_LINKEDLIST 双端链表
6、REDIS_ENCODING_ZIPLIST 压缩列表
7、REDIS_ENCODING_INTSET 整数集合
8、REDIS_ENCODING_SKIPLIST 跳跃表和字典


1.字符串对象
编码可以为 int、embstr或者raw。
如果一个字符串的内容可以转换为long,那么该字符串就会被转换成为long类型,对象的ptr就会指向该long,并且对象类型也用int类型表示。
普通的字符串有两种,embstr和raw。embstr应该是Redis3.0新增的数据结构,在2.8中是没有的。如果字符串对象的长度小于39字节,就用embstr对象。否则用传统的raw对象。

2.列表对象
编码可以是ziplist或者linkedlist。
ziplist是一种压缩链表,它的好处是更能节省内存空间,因为它所存储的内容都是在连续的内存区域当中的。当列表对象元素不大,每个元素也不大的时候,就采用ziplist存储。但当数据量过大时就ziplist就不是那么好用了。因为为了保证他存储内容在内存中的连续性,插入的复杂度是O(N),即每次插入都会重新进行realloc。
linkedlist是一种双向链表。它的结构比较简单,节点中存放pre和next两个指针,还有节点相关的信息。当每增加一个node的时候,就需要重新malloc一块内存。

当列表对象可以同时满足以下两个条件时, 列表对象使用 ziplist 编码:
列表对象保存的所有字符串元素的长度都小于 64 字节;
列表对象保存的元素数量小于 512 个;
不能满足这两个条件的列表对象需要使用 linkedlist 编码。
ps:
因为压缩列表比双端链表更节约内存, 并且在元素数量较少时, 在内存中以连续块方式保存的压缩列表比起双端链表可以更快被载入到缓存中;
随着列表对象包含的元素越来越多, 使用压缩列表来保存元素的优势逐渐消失时, 对象就会将底层实现从压缩列表转向功能更强、也更适合保存大量元素的双端链表上面


3.哈希对象
编码可以是ziplist或者hashtable。
ziplist中的哈希对象是按照key1,value1,key2,value2这样的顺序存放来存储的。当对象数目不多且内容不大时,这种方式效率是很高的。
hashtable的是由dict这个结构来实现的,dict是一个字典,其中的指针dicht ht[2] 指向了两个哈希表。dicht[0]是用于真正存放数据,dicht[1]一般在哈希表元素过多进行rehash的时候用于中转数据。
dictht中的table用语真正存放元素了,每个key/value对用一个dictEntry表示,放在dictEntry数组中


4.集合对象
编码可以是intset或者hashtable。
intset是一个整数集合,里面存的为某种同一类型的整数,支持如下三种长度的整数:
#define INTSET_ENC_INT16 (sizeof(int16_t))  
#define INTSET_ENC_INT32 (sizeof(int32_t))  
#define INTSET_ENC_INT64 (sizeof(int64_t))  
intset是一个有序集合,查找元素的复杂度为O(logN),但插入时不一定为O(logN),因为有可能涉及到升级操作。比如当集合里全是int16_t型的整数,这时要插入一个int32_t,那么为了维持集合中数据类型的一致,那么所有的数据都会被转换成int32_t类型,涉及到内存的重新分配,这时插入的复杂度就为O(N)了。是intset不支持降级操作。

当集合对象可以同时满足以下两个条件时, 对象使用 intset 编码:
集合对象保存的所有元素都是整数值;
集合对象保存的元素数量不超过 512 个;
不能满足这两个条件的集合对象需要使用 hashtable 编码。
ps:
第二个条件的上限值是可以修改的, 具体请看配置文件中关于 set-max-intset-entries 选项的说明。


5.有序集合对象
有序集合的编码可能两种,一种是ziplist,另一种是skiplist与dict的结合。
ziplist作为集合和作为哈希对象是一样的,member和score顺序存放。按照score从小到大顺序排列。
skiplist是一种跳跃表,它实现了有序集合中的快速查找,在大多数情况下它的速度都可以和平衡树差不多。但它的实现比较简单,可以作为平衡树的替代品。
当有序集合对象可以同时满足以下两个条件时, 对象使用 ziplist 编码:
有序集合保存的元素数量小于 128 个;
有序集合保存的所有元素成员的长度都小于 64 字节;
不能满足以上两个条件的有序集合对象将使用 skiplist 编码。
ps:
以上两个条件的上限值是可以修改的, 具体请看配置文件中关于 zset-max-ziplist-entries 选项和 zset-max-ziplist-value 选项的说明。
mysql索引之聚簇索引和非聚簇索引

(一)各种树结构
1 搜索二叉树:每个节点有两个子节点,数据量的增大必然导致高度的快速增加,显然这个不适合作为大量数据存储的基础结构。

2 B树:一棵m阶B树是一棵平衡的m路搜索树。最重要的性质是每个非根节点所包含的关键字个数 j 满足:┌m/2┐ - 1 <= j <= m - 1;一个节点的子节点数量会比关键字个数多1,这样关键字就变成了子节点的分割标志。一般会在图示中把关键字画到子节点中间,非常形象,也容易和后面的B+树区分。由于数据同时存在于叶子节点和非叶子结点中,无法简单完成按顺序遍历B树中的关键字,必须用中序遍历的方法。

3 B+树:一棵m阶B树是一棵平衡的m路搜索树。最重要的性质是每个非根节点所包含的关键字个数 j 满足:┌m/2┐ - 1 <= j <= m;子树的个数最多可以与关键字一样多。非叶节点存储的是子树里最小的关键字。同时数据节点只存在于叶子节点中,且叶子节点间增加了横向的指针,这样顺序遍历所有数据将变得非常容易。

4 B*树:一棵m阶B树是一棵平衡的m路搜索树。最重要的两个性质是1每个非根节点所包含的关键字个数 j 满足:┌m2/3┐ - 1 <= j <= m;2非叶节点间添加了横向指针

B+树适合作为数据库的基础结构,完全是因为计算机的内存-机械硬盘两层存储结构。内存可以完成快速的随机访问(随机访问即给出任意一个地址,要求返回这个地址存储的数据)但是容量较小。而硬盘的随机访问要经过机械动作(1磁头移动 2盘片转动),访问效率比内存低几个数量级,但是硬盘容量较大。典型的数据库容量大大超过可用内存大小,这就决定了在B+树中检索一条数据很可能要借助几次磁盘IO操作来完成。



(二)存储引擎和索引
有两种常见的方法可以解决多个B+树访问同一套表数据的问题,一种叫做聚簇索引(clustered index ),一种叫做非聚簇索引(secondary index)。这两个名字虽然都叫做索引,但这并不是一种单独的索引类型,而是一种数据存储方式。对于聚簇索引存储来说,行数据和主键B+树存储在一起,辅助键B+树只存储辅助键和主键,主键和非主键B+树几乎是两种类型的树。对于非聚簇索引存储来说,主键B+树在叶子节点存储指向真正数据行的指针,而非主键。

InnoDB使用的是聚簇索引,将主键组织到一棵B+树中,而行数据就储存在叶子节点上,若使用"where id = 14"这样的条件查找主键,则按照B+树的检索算法即可查找到对应的叶节点,之后获得行数据。若对Name列进行条件搜索,则需要两个步骤:第一步在辅助索引B+树中检索Name,到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操作,最终到达叶子节点即可获取整行数据。

MyISM使用的是非聚簇索引,非聚簇索引的两棵B+树看上去没什么不同,节点的结构完全一致只是存储的内容不同而已,主键索引B+树的节点存储了主键,辅助键索引B+树存储了辅助键。表数据存储在独立的地方,这两颗B+树的叶子节点都使用一个地址指向真正的表数据,对于表数据来说,这两个键没有任何差别。由于索引树是独立的,通过辅助键检索无需访问主键的索引树。


(三)聚簇索引的优势
1 由于行数据和叶子节点存储在一起,这样主键和行数据是一起被载入内存的,找到叶子节点就可以立刻将行数据返回了,如果按照主键Id来组织数据,获得数据更快。

2 辅助索引使用主键作为"指针" 而不是使用地址值作为指针的好处是,减少了当出现行移动或者数据页分裂时辅助索引的维护工作,使用主键值当作指针会让辅助索引占用更多的空间,换来的好处是InnoDB在移动行时无须更新辅助索引中的这个"指针"。也就是说行的位置(实现中通过16K的Page来定位,后面会涉及)会随着数据库里数据的修改而发生变化(前面的B+树节点分裂以及Page的分裂),使用聚簇索引就可以保证不管这个主键B+树的节点如何变化,辅助索引树都不受影响。


原文地址:http://www.admin10000.com/document/5372.html


nginx负载均衡 - 根据url做一致性hash
nginx负载均衡 - 根据url做一致性hash

目标:按照指定的参数(如分类/商品编号)做一致性hash,从而保证相同数据到一台机器上

先说下nginx里$request_uri和$uri的区别
$request_uri
This variable is equal to the *original* request URI as received from the client including the args. It cannot be modified. Look at $uri for the post-rewrite/altered URI. Does not include host name. Example: "/foo/bar.php?arg=baz" 
这个变量等于从客户端发送来的原生请求URI,包括参数。它不可以进行修改。$uri变量反映的是重写后/改变的URI。不包括主机名。例如:"/foo/bar.php?arg=baz"
$uri
This variable is the current request URI, without any arguments (see $args for those). This variable will reflect any modifications done so far by internal redirects or the index module. Note this may be different from $request_uri, as $request_uri is what was originally sent by the browser before any such modifications. Does not include the protocol or host name. Example: /foo/bar.html 
这个变量指当前的请求URI,不包括任何参数(见$args)。这个变量反映任何内部重定向或index模块所做的修改。注意,这和$request_uri不同,因$request_uri是浏览器发起的不做任何修改的原生URI。不包括协议及主机名。例如:"/foo/bar.html"
 
$document_uri
The same as $uri. 
同$uri.

实现步骤
第一步:在nginx中做简单配置,先实现轮训,域名可以根据自己的来
server {
    listen       80;
    server_name  default www.test.com;
    location / {
        proxy_pass http://www_posts;
        index index.html index.htm;
    }
}

upstream www_posts {
    server 127.0.0.1:7001;
    server 127.0.0.1:7002;
    server 127.0.0.1:7003;
}

server {
    listen       7001;
    server_name  default www.test.com;
    location / {
        root   /data/www/post1/;
        index index.html index.htm;
    }
}
server {
    listen       7002;
    server_name  default www.test.com;
    location / {
        root   /data/www/post2/;
        index index.html index.htm;
    }
}
server {
    listen       7003;
    server_name  default www.test.com;
    location / {
        root   /data/www/post3/;
        index index.html index.htm;
    }
}

完成后 重启nginx

第二步创建程序文件
mkdir /data/www/post1; cd /data/www/post1;
vim 1.html //写入 1-1
vim 2.html //写入 1-2
vim 3.html //写入 1-3
mkdir /data/www/post2; cd /data/www/post2;
vim 1.html //写入 2-1
vim 2.html //写入 2-2
vim 3.html //写入 2-3
mkdir /data/www/post3; cd /data/www/post3;
vim 1.html //写入 3-1
vim 2.html //写入 4-2
vim 3.html //写入 3-3

通过浏览器访问 www.test.com/1.html,不断刷新,可分别出现1-1,2-1,3-1

第三步 自定义hash key

在server-location中加入
if ( $uri ~* "^\/(\d+).html$" ){ set $defurlkey $1; }
修改upstream,结果如下
upstream www_posts {
hash $defurlkey;
    server 127.0.0.1:7001;
    server 127.0.0.1:7002;
    server 127.0.0.1:7003;
}

可通过分别访问,测试结果
www.test.com/1.html
www.test.com/2.html
www.test.com/3.html


大小端模式
不同机器内部对变量的字节存储顺序不同,有的采用大端模式(big-endian),有的采用小端模式(little-endian)。

大端模式是指高位字节数据存放在低地址处,低位字节数据放在高地址处,也称为高尾端
小端模式是指低位字节数据存放在低地址处,高位字节数据放在高地址处,也称为低尾端


在网络上传输数据时,由于数据传输的两端可能对应不同的硬件平台,采用的存储字节顺序也可能不一致,因此 TCP/IP 协议规定了在网络上必须采用网络字节顺序(也就是大端模式)。
通过对大小端的存储原理分析可发现,对于 char 型数据,由于其只占一个字节,所以不存在这个问题,这也是一般情况下把数据缓冲区定义成 char 类型 的原因之一。对于 IP 地址、端口号等非 char 型数据,必须在数据发送到网络上之前将其转换成大端模式,在接收到数据之后再将其转换成符合接收端主机的存储模式。


举一个例子,比如 int n = 0x12345678 //16进制
1)大端模式:
内存地址:  低地址 -----------------> 高地址
n的字节序:0x12  |  0x34  |  0x56  |  0x78
2)小端模式:
内存地址:  低地址 ------------------> 高地址
n的字节序:0x78  |  0x56  |  0x34  |  0x12

优惠券
广告位-淘宝
最新微语