docker部署springboot（默认已经安装好docker） 第一步：构建镜像 创建Dockerfile文件，文件内容如下：
|
1 2 3 4 5 6 7 8 9 10 11 |
FROM frolvlad/alpine-oraclejdk8:slim VOLUME /tmp ADD index-1.5.10.RELEASE.jar app.jar RUN sh -c 'touch /app.jar' ENV JAVA_OPTS="" ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar" ] |
其中 index-1.5.10.RELEASE.jar是你要发布的jar包。 然后把Dockerfile和index-1.5.10.RELEASE.jar建个文件夹，放到服务器上面。 cd进入你的文件夹，运行以下命令向docker中添加镜像：
|
1 |
docker build -t jingxiangming . |
执行命令后，你的docker中就添加了名为jingxiangming的镜像。 查看镜像命令：
|
1 |
docker images //运行命令后，你就可以看到刚刚添加的镜像了 |
第二步：启动容器
|
1 |
docker run -d -p 8080:8080 jingxiangming |
关于上面的命令，我认为有必要具体讲解一下： -d: 后台运行容器，并返回容器ID； -p: 端口映射，格式为：主机(宿主)端口:容器端口；//意思是第一个访问服务器的端口，第二个8080是服务器本地占用访问的端口 jingxiangming：docker里面的镜像名称 当然除了上面基本的参数外，还有额外的参数，这个就需要大家自己去查阅资料了，我这里只列举比较重要的。 启动成功后，会返回一个容器id，然后就可以测试访问了！ 日志查看 查看运行的容器日志：
|
1 |
sudo docker logs -f -t --tail 行数 容器名 |
|
1 2 |
//查看容器名 docker ps |
from:https://blog.csdn.net/qq_29611427/article/details/81534037
View Details本文小秋熊介绍在Linux中使用命令启动SpringBoot生成的jar包，并且查看日志的方法。 1.首先将SpringBoot项目打包成JAR包,通过xFTP或者其他工具将JAR包上传到Linux上,然后执行如下命令启动项目: java -jar xxx.jar 该命令启动jar,一旦Xshell窗口关闭,JAR就停止运行了. 如果想让项目在后台一直运行,通过如下命令启动JAR: nohup java -jar xxx.jar > consoleMsg.log 2>&1 & 上面的2 和 1 的意思如下: 0 标准输入（一般是键盘） 1 标准输出（一般是显示屏，是用户终端控制台） 2 标准错误（错误信息输出） 注意:consoleMsg.log文件要先创建,执行命令: touch consoleMsg.log 查看项目运行日志: 1、tailf consoleMsg.log | grep --line-buffered findUserList 实时跟踪日志，这里是只要findUserList 这个方法被运行，就会将它的日志打印出来，用于跟踪特定的日志运行。 --line-buffered 是一行的缓冲区，只要这一行的缓冲区满了就会打印出来，所以可以用于实时监控日志。 2、 tailf -n 500 consoleMsg.log 打印最后500行日志，并且持续跟踪日志。 tail -n 2000 consoleMsg.log | less 分页查看最后2000行日志，并可以使用pageUp,pageDn滚动 3、tail -f consoleMsg.log （常用）直接查看日志末尾，有新日志会实时滚动更新。ctrl + c 退出 其它举例： （1）nohup java -jar xxx.jar >/data/log.log 2>/data/err.log & 解释：标准日志输出到/data/log.log文件，错误日志输出到/data/err.log文件。 （2）nohup java -jar xxx.jar >/data/log.log 2>&1 & 解释：标准日志输出到/data/log.log文件，错误日志重定向也输出到/data/log.log文件。 （3）nohup java -jar xxx.jar >/dev/null 2>/data/err.log & 解释：标准日志输出到/dev/null，也就是不输出标准日志，错误日志输出到/data/err.log文件。 一般采用上面（3）只输出错误日志就可以了，有需要的按照（1）、（2）进行输出。 命令后面加的 & ，可让命令在后台执行，否则关闭会话会停止程序。 […]
View DetailsJava NIO中的Files类（java.nio.file.Files）提供了多种操作文件系统中文件的方法。 Files.exists() Files.exits()方法用来检查给定的Path在文件系统中是否存在。 在文件系统中创建一个原本不存在的Payh是可行的。例如，你想新建一个目录，那么闲创建对应的Path实例，然后创建目录。 由于Path实例可能指向文件系统中的不存在的路径，所以需要用Files.exists()来确认。 下面是一个使用Files.exists()的示例：
|
1 2 3 4 5 |
Path path = Paths.get("data/logging.properties"); boolean pathExists = Files.exists(path, new LinkOption[]{ LinkOption.NOFOLLOW_LINKS}); |
这个示例中，我们首先创建了一个Path对象，然后利用Files.exists()来检查这个路径是否真实存在。 注意Files.exists()的的第二个参数。他是一个数组，这个参数直接影响到Files.exists()如何确定一个路径是否存在。在本例中，这个数组内包含了LinkOptions.NOFOLLOW_LINKS，表示检测时不包含符号链接文件。 Files.createDirectory() Files.createDirectory()会创建Path表示的路径，下面是一个示例：
|
1 2 3 4 5 6 7 8 9 10 |
Path path = Paths.get("data/subdir"); try { Path newDir = Files.createDirectory(path); } catch(FileAlreadyExistsException e){ // the directory already exists. } catch (IOException e) { //something else went wrong e.printStackTrace(); } |
第一行创建了一个Path实例，表示需要创建的目录。接着用try-catch把Files.createDirectory()的调用捕获住。如果创建成功，那么返回值就是新创建的路径。 如果目录已经存在了，那么会抛出java.nio.file.FileAlreadyExistException异常。如果出现其他问题，会抛出一个IOException。比如说，要创建的目录的父目录不存在，那么就会抛出IOException。父目录指的是你要创建的目录所在的位置。也就是新创建的目录的上一级父目录。 Files.copy() Files.copy()方法可以吧一个文件从一个地址复制到另一个位置。例如：
|
1 2 3 4 5 6 7 8 9 10 11 |
Path sourcePath = Paths.get("data/logging.properties"); Path destinationPath = Paths.get("data/logging-copy.properties"); try { Files.copy(sourcePath, destinationPath); } catch(FileAlreadyExistsException e) { //destination file already exists } catch (IOException e) { //something else went wrong e.printStackTrace(); } |
这个例子当中，首先创建了原文件和目标文件的Path实例。然后把它们作为参数，传递给Files.copy(),接着就会进行文件拷贝。 如果目标文件已经存在，就会抛出java.nio.file.FileAlreadyExistsException异常。类似的吐过中间出错了，也会抛出IOException。 覆盖已经存在的文件(Overwriting Existing Files) copy操作可以强制覆盖已经存在的目标文件。下面是具体的示例：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
Path sourcePath = Paths.get("data/logging.properties"); Path destinationPath = Paths.get("data/logging-copy.properties"); try { Files.copy(sourcePath, destinationPath, StandardCopyOption.REPLACE_EXISTING); } catch(FileAlreadyExistsException e) { //destination file already exists } catch (IOException e) { //something else went wrong e.printStackTrace(); } |
注意copy方法的第三个参数，这个参数决定了是否可以覆盖文件。 Files.move() Java NIO的Files类也包含了移动的文件的接口。移动文件和重命名是一样的，但是还会改变文件的目录位置。java.io.File类中的renameTo()方法与之功能是一样的。
|
1 2 3 4 5 6 7 8 9 10 |
Path sourcePath = Paths.get("data/logging-copy.properties"); Path destinationPath = Paths.get("data/subdir/logging-moved.properties"); try { Files.move(sourcePath, destinationPath, StandardCopyOption.REPLACE_EXISTING); } catch (IOException e) { //moving file failed. e.printStackTrace(); } |
首先创建源路径和目标路径的，原路径指的是需要移动的文件的初始路径，目标路径是指需要移动到的位置。 这里move的第三个参数也允许我们覆盖已有的文件。 Files.delete() Files.delete()方法可以删除一个文件或目录：
|
1 2 3 4 5 6 7 8 |
Path path = Paths.get("data/subdir/logging-moved.properties"); try { Files.delete(path); } catch (IOException e) { //deleting file failed e.printStackTrace(); } |
首先创建需要删除的文件的path对象。接着就可以调用delete了。 Files.walkFileTree() Files.walkFileTree()方法具有递归遍历目录的功能。walkFileTree接受一个Path和FileVisitor作为参数。Path对象是需要遍历的目录，FileVistor则会在每次遍历中被调用。 下面先来看一下FileVisitor这个接口的定义：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
public interface FileVisitor { public FileVisitResult preVisitDirectory( Path dir, BasicFileAttributes attrs) throws IOException; public FileVisitResult visitFile( Path file, BasicFileAttributes attrs) throws IOException; public FileVisitResult visitFileFailed( Path file, IOException exc) throws IOException; public FileVisitResult postVisitDirectory( Path dir, IOException exc) throws IOException { } |
FileVisitor需要调用方自行实现，然后作为参数传入walkFileTree().FileVisitor的每个方法会在遍历过程中被调用多次。如果不需要处理每个方法，那么可以继承他的默认实现类SimpleFileVisitor，它将所有的接口做了空实现。 下面看一个walkFileTree()的示例：
|
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 |
Files.walkFileTree(path, new FileVisitor<Path>() { @Override public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs) throws IOException { System.out.println("pre visit dir:" + dir); return FileVisitResult.CONTINUE; } @Override public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException { System.out.println("visit file: " + file); return FileVisitResult.CONTINUE; } @Override public FileVisitResult visitFileFailed(Path file, IOException exc) throws IOException { System.out.println("visit file failed: " + file); return FileVisitResult.CONTINUE; } @Override public FileVisitResult postVisitDirectory(Path dir, IOException exc) throws IOException { System.out.println("post visit directory: " + dir); return FileVisitResult.CONTINUE; } }); |
FileVisitor的方法会在不同时机被调用： preVisitDirectory()在访问目录前被调用。postVisitDirectory()在访问后调用。 visitFile()会在整个遍历过程中的每次访问文件都被调用。他不是针对目录的，而是针对文件的。visitFileFailed()调用则是在文件访问失败的时候。例如，当缺少合适的权限或者其他错误。 上述四个方法都返回一个FileVisitResult枚举对象。具体的可选枚举项包括： CONTINUE TERMINATE SKIP_SIBLINGS SKIP_SUBTREE 返回这个枚举值可以让调用方决定文件遍历是否需要继续。 CONTINE表示文件遍历和正常情况下一样继续。 TERMINATE表示文件访问需要终止。 SKIP_SIBLINGS表示文件访问继续，但是不需要访问其他同级文件或目录。 SKIP_SUBTREE表示继续访问，但是不需要访问该目录下的子目录。这个枚举值仅在preVisitDirectory()中返回才有效。如果在另外几个方法中返回，那么会被理解为CONTINE。 Searching For Files 下面看一个例子，我们通过walkFileTree()来寻找一个README.txt文件：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
Path rootPath = Paths.get("data"); String fileToFind = File.separator + "README.txt"; try { Files.walkFileTree(rootPath, new SimpleFileVisitor<Path>() { @Override public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException { String fileString = file.toAbsolutePath().toString(); //System.out.println("pathString = " + fileString); if(fileString.endsWith(fileToFind)){ System.out.println("file found at path: " + file.toAbsolutePath()); return FileVisitResult.TERMINATE; } return FileVisitResult.CONTINUE; } }); } catch(IOException e){ e.printStackTrace(); } |
Deleting Directies Recursively Files.walkFileTree()也可以用来删除一个目录以及内部的所有文件和子目。Files.delete()只用用于删除一个空目录。我们通过遍历目录，然后在visitFile()接口中三次所有文件，最后在postVisitDirectory()内删除目录本身。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
Path rootPath = Paths.get("data/to-delete"); try { Files.walkFileTree(rootPath, new SimpleFileVisitor<Path>() { @Override public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException { System.out.println("delete file: " + file.toString()); Files.delete(file); return FileVisitResult.CONTINUE; } @Override public FileVisitResult postVisitDirectory(Path dir, IOException exc) throws IOException { Files.delete(dir); System.out.println("delete dir: " + dir.toString()); return FileVisitResult.CONTINUE; } }); } catch(IOException e){ e.printStackTrace(); } |
from:https://www.cnblogs.com/liangblog/p/8920579.html
View Details原文链接 译者：章筱虎 Path接口是java NIO2的一部分。首次在java 7中引入。Path接口在java.nio.file包下，所以全称是java.nio.file.Path。 java中的Path表示文件系统的路径。可以指向文件或文件夹。也有相对路径和绝对路径之分。绝对路径表示从文件系统的根路径到文件或是文件夹的路径。相对路径表示从特定路径下访问指定文件或文件夹的路径。相对路径的概念可能有点迷糊。不用担心，我将在本文的后面详细介绍相关细节。 不要将文件系统的path和操作系统的环境变量path搞混淆。java.nio.file.Path接口和操作系统的path环境变量没有任何关系。 在很多方面，java.nio.file.Path接口和java.io.File有相似性，但也有一些细微的差别。在很多情况下，可以用Path来代替File类。 创建Path实例 为了使用java.nio.file.Path实例，必须首先创建它。可以使用Paths 类的静态方法Paths.get()来产生一个实例。以下是示例：
|
1 2 3 4 5 6 7 8 9 10 11 |
import java.nio.file.Path; import java.nio.file.Paths; public class PathExample { public static void main(String[] args) { Path path = Paths.get("c:\\data\\myfile.txt"); } } |
请注意例子开头的两个import语句。想要使用Paths类和Path接口，必须首先引入相应包。其次，注意Paths.get(“c:\\data\\myfile.txt”)的用法。其使用了Paths.get方法创建了Path的实例。它是一个工厂方法。 创建绝对路径Path 调用传入绝对路径当做参数的Paths.get()工厂方法，就可以生成绝对路径Path。示例如下：
|
1 |
Path path = Paths.get("c:\\data\\myfile.txt"); |
示例中的绝对路径是c:\data\myfile.txt。有两个\字符的原因是第一个\是转义字符，表示紧跟着它的字符需要被转义。\\表示需要向字符串中写入一个\字符。 上文示例的path是windows下的路径。在Unix系统(Linux,MacOS,FreeBSD等)中，上文中的path是这样的：
|
1 |
Path path = Paths.get("/home/jakobjenkov/myfile.txt"); |
/home/jakobjenkov/myfile.txt就称作绝对路径。 如果把以/开头path的格式运行在windows系统中，系统会将其解析为相对路径。例如：
|
1 |
/home/jakobjenkov/myfile.txt |
将会被解析为路径是在C盘。对应的绝对路径是： C:/home/jakobjenkov/myfile.txt 创建相对路径Path 相对路径指从一个已确定的路径开始到某一文件或文件夹的路径。将确定路径和相对路径拼接起来就是相对路径对应的绝对路径地址。 java NIO Path类也能使用相对路径。可以通过Paths.get(basePath, relativePath)创建一个相对路径Path。示例如下：
|
1 2 3 |
Path projects = Paths.get("d:\\data", "projects"); Path file = Paths.get("d:\\data", "projects\\a-project\\myfile.txt"); |
第一个例子创建了一个指向d:\data\projects文件夹的实例。第二个例子创建了一个指向 d:\data\projects\a-project\myfile.txt 文件的实例。 当使用相对路径的时候，可以使用如下两种特别的符号。它们是： . .. .表示当前路径。例如，如果以如下方式创建一个相对路径：
|
1 2 |
Path currentDir = Paths.get("."); System.out.println(currentDir.toAbsolutePath()); |
创建的Path实例对应的路径就是运行这段代码的项目工程目录。 如果.用在路径中，则其表示的就是当前路径下。示例： Path currentDir = Paths.get(“d:\\data\\projects\.\a-project”); 对应的就是如下路径 d:\data\projects\a-project ..表示父类目录。示例： Path parentDir = Paths.get(“..”); Path对应的路径是当前运行程序目录的上级目录。 如果在path中使用..，表示上级目录的含义。例如：
|
1 2 |
String path = "d:\\data\\projects\\a-project\\..\\another-project"; Path parentDir2 = Paths.get(path); |
对应的绝对路径地址为： d:\data\projects\another-project 在a-project目录后面的..符号，将指向的目录修改为projects目录，因此，最终path指向another-project目录。 .和..都可以在Paths.get()的双形参方法中使用。示例：
|
1 2 3 4 |
Path path1 = Paths.get("d:\\data\\projects", ".\\a-project"); Path path2 = Paths.get("d:\\data\\projects\\a-project", "..\\another-project"); |
下面介绍NIO 的Path类有关相对路径的其他使用方法。 Path.normalize() Path 的normalize()方法可以标准化路径。标准化的含义是路径中的.和..都被去掉，指向真正的路径目录地址。下面是Path.normalize()示例：
|
1 2 3 4 5 6 7 8 |
String originalPath = "d:\\data\\projects\\a-project\\..\\another-project"; Path path1 = Paths.get(originalPath); System.out.println("path1 = " + path1); Path path2 = path1.normalize(); System.out.println("path2 = " + path2); |
上文示例，首先创建了一个包含..字符的路径地址。之后输出此路径。 之后，调用normalize方法，返回一个新的path对象。输出新对象的路径。 输出结果如下：
|
1 2 |
path1 = d:\data\projects\a-project\..\another-project path2 = d:\data\projects\another-project |
如你所见，标准化后的路径不再包含 a-project\..部分，因为它是多余的。 from:https://ifeve.com/java-nio-path-2/
View Details一、环境搭建 安装好JDK环境 到groovy官网下载groovySDK，解压到合适位置 groovy官网：http://www.groovy-lang.org/ 安装后的文件如上图所示，我们需要关注的是bin和doc文件夹下的内容，其它文件夹下是一些配置和groovy自带的一些jar包 配置groovy环境变量 二、与Java的不同之处 1、默认 imports 所有这些包和类都是默认导入的，您不必使用显式import语句来使用它们：
|
1 2 3 4 5 6 7 8 |
java.io.* java.lang.* java.math.BigDecimal java.math.BigInteger java.net.* java.util.* groovy.lang.* groovy.util.* |
2、运行时分派 在Groovy中，将在运行时选择将被调用的方法。 这称为运行时分派或Multi-methods。 这意味着将基于运行时参数的类型来选择方法。 在Java中，则是根据声明的类型，在编译时选择方法。 下面的代码，以Java代码编写，可以在Java和Groovy中编译，但它的行为会有所不同：
|
1 2 3 4 5 6 7 8 |
int method(String arg) { return 1; } int method(Object arg) { return 2; } Object o = "Object"; int result = method(o); |
在Java中, 您将得到：2 而在Groovy中：1 这是因为Java将使用静态信息类型，即o被声明为Object，而Groovy将在运行时选择该方法被实际调用时。 因为它是用String调用的，所以调用String版本。 3、数组初始化 在Groovy中，{…}块是为闭包而保留的。 这意味着您不能使用以下语法创建数组：
|
1 |
int [] array = {1，2，3} |
你必须使用：
|
1 |
int [] array = [1,2,3] |
4、自动资源管理块 Groovy不支持Java 7中的ARM（自动资源管理）块。 相反，Groovy提供了依赖闭包的各种方法，它们具有相同的效果，同时更加方便。 例如：
|
1 2 3 4 5 6 7 8 9 10 11 |
Path file = Paths.get("/path/to/file"); Charset charset = Charset.forName("UTF-8"); try (BufferedReader reader = Files.newBufferedReader(file, charset)) { String line; while ((line = reader.readLine()) != null) { System.out.println(line); } } catch (IOException e) { e.printStackTrace(); } |
可以这样写：
|
1 2 3 |
new File('/path/to/file').eachLine('UTF-8') { println it } |
或者，如果你想要一个更接近Java的版本：
|
1 2 3 4 5 |
new File('/path/to/file').withReader('UTF-8') { reader -> reader.eachLine { println it } } |
5、Lambdas Java 8支持lambdas和方法引用：
|
1 2 |
Runnable run = () -> System.out.println("Run"); list.forEach(System.out::println); |
Java 8 lambdas可以或多或少被认为是匿名内部类。 Groovy不支持该语法，但是可以使用闭包：
|
1 2 |
Runnable run = { println 'run' } list.each { println it } // or list.each(this.&println) |
6、GStrings 由于双引号字符串字面量被解释为GString，Groovy将在GString和String之间自动转换 Groovy中的单引号用于String，双引号结果是String或GString，取决于文字中是否有插值。
|
1 2 3 |
assert 'c'.getClass()==String assert "c".getClass()==String assert "c${1}".getClass() in GString |
只有在赋给char类型的变量时，Groovy会自动将单字符String转换为char。 当调用类型为char的参数的方法时，我们需要显式转换或确保该值已预先转换。
|
1 2 3 4 5 6 7 8 9 |
char a='a' assert Character.digit(a, 16)==10 : 'But Groovy does boxing' assert Character.digit((char) 'a', 16)==10 try { assert Character.digit('a', 16)==10 assert false: 'Need explicit cast' } catch(MissingMethodException e) { } |
Groovy支持两种类型的转换，在转换为char的情况下，在转换multi-char 时存在微妙的差别。 Groovy风格的转换是更宽松的，将采取第一个字符，而C风格的转换将失败，异常。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
// for single char strings, both are the same assert ((char) "c").class==Character assert ("c" as char).class==Character // for multi char strings they are not try { ((char) 'cx') == 'c' assert false: 'will fail - not castable' } catch(GroovyCastException e) { } assert ('cx' as char) == 'c' assert 'cx'.asType(char) == 'c' |
7、原始和封装 因为Groovy使用Objects来做每一件事，它对原始的引用自动包装。 因此，它不遵循Java的扩展优先于装箱。 这里有一个使用int的例子
|
1 2 3 4 5 6 7 8 9 10 11 12 |
int i m(i) //这是Java将调用的方法，因为扩展优先于装箱。 void m(long l) { println "in m(long)" } //这是Groovy实际调用的方法，因为所有的基本引用都使用它们的包装类。 void m(Integer i) { println "in m(Integer)" } |
8、==的行为 在Java中==表示对象的原始类型或标识的相等性。 在Groovy ==翻译为a.compareTo(b)== 0，如果他们是可比较的，否则a.equals(b)。 如果要检查身份，有is方法，例如a.is(b) 三、基础语法 1、动态类型 Groovy定义变量时：可以用Groovy风格的def声明，不指定类型；也可以兼容Java风格，指定变量类型；甚至还可以省略def或类型。
|
1 2 3 |
def t1 = 't1' String t2 = 't2' t3 = 't3' |
[…]
View Details|
1 2 3 4 5 6 |
//使用File获取resources里面资源文件的相对路径 若文件名称为中文可能会报文件不存在 File file = new File(this.getClass().getResource("/province-city.josn").getPath()); //使用inputStream InputStream inputStream = this.getClass().getResourceAsStream("/province-city.json"); |
from:https://www.cnblogs.com/yang-xiansen/p/13529568.html
View DetailsDocker提供了重新启动策略 来控制容器在退出时或Docker重新启动时是否自动启动。重新启动策略可确保以正确的顺序启动链接的容器。Docker建议您使用重新启动策略，并避免使用进程管理器来启动容器。 重新启动策略--live-restore与dockerd 命令的标志不同。--live-restore尽管网络和用户输入中断，但使用允许您在Docker升级期间保持容器运行。 使用重启策略 要为容器配置重新启动策略，请--restart在使用该docker run命令时使用该标志。--restart标志的值可以是以下任何一种： 旗 描述 no 不要自动重启容器。（默认） on-failure 如果容器由于错误而退出，则重新启动容器，该错误表现为非零退出代码。 always 如果容器停止，请务必重启容器。如果手动停止，则仅在Docker守护程序重新启动或手动重新启动容器本身时才重新启动。（参见重启政策详情中列出的第二个项目） unless-stopped 类似于always，除了当容器停止（手动或其他方式）时，即使在Docker守护程序重新启动后也不会重新启动容器。 以下示例启动Redis容器并将其配置为始终重新启动，除非明确停止或重新启动Docker。
|
1 |
$ docker run -dit --restart unless-stopped redis |
重启政策详情 使用重启策略时请记住以下几点： 重启策略仅在容器成功启动后生效。在这种情况下，成功启动意味着容器启动至少10秒并且Docker已开始监视它。这可以防止根本不启动的容器进入重启循环。 如果手动停止容器，则会忽略其重新启动策略，直到Docker守护程序重新启动或手动重新启动容器。这是防止重启循环的另一种尝试。 重新启动策略仅适用于容器。群组服务的重新启动策略配置不同。请参阅与服务重新启动相关的 标志。 如果run时没有添加restart 可以通过update命令追加 docker update --restart=always web 1、先后台启动容器未加restart参数 2、docker ps 查看了当前运行的容器 3、重启docker 服务 4、再次docker ps 查看当前运行的容器，发现容器并没有运行 5、利用 update 设置 restart=always 6、重启docker 服务 7、再次docker ps 查看当前运行的容器，此时发现已经自动启动容器 ——————— 使用流程管理器 如果重新启动策略不适合您的需要，例如当Docker之外的进程依赖Docker容器时，您可以使用流程管理器，例如 upstart， systemd或supervisor。 警告：不要尝试将Docker重新启动策略与主机级进程管理器结合使用，因为这会产生冲突。 要使用进程管理器，请将其配置为使用您通常用于手动启动容器的相同docker start或docker service命令来启动容器或服务。有关更多详细信息，请参阅特定流程管理器的文档。 在容器内使用进程管理器 进程管理器也可以在容器内运行，以检查进程是否正在运行，如果没有则启动/重启进程 官方介绍在此，以上内容引用官网内容 https://docs.docker.com/engine/admin/start-containers-automatically/#use-a-process-manager from:https://www.cnblogs.com/wei9593/p/11192908.html
View Details从AMQP协议可以看出，MessageQueue、Exchange和Binding构成了AMQP协议的核心，下面我们就围绕这三个主要组件 从应用使用的角度全面的介绍如何利用Rabbit MQ构建消息队列以及使用过程中的注意事项。 1. 声明MessageQueue 在Rabbit MQ中，无论是生产者发送消息还是消费者接受消息，都首先需要声明一个MessageQueue。这就存在一个问题，是生产者声明还是消费者声明呢？要解决这个问题，首先需要明确： a)消费者是无法订阅或者获取不存在的MessageQueue中信息。 b)消息被Exchange接受以后，如果没有匹配的Queue，则会被丢弃。 在明白了上述两点以后，就容易理解如果是消费者去声明Queue，就有可能会出现在声明Queue之前，生产者已发送的消息被丢弃的隐患。如果应用能够通过消息重发的机制允许消息丢失，则使用此方案没有任何问题。但是如果不能接受该方案，这就需要无论是生产者还是消费者，在发送或者接受消息前，都需要去尝试建立消息队列。这里有一点需要明确，如果客户端尝试建立一个已经存在的消息队列，Rabbit MQ不会做任何事情，并返回客户端建立成功的。 如果一个消费者在一个信道中正在监听某一个队列的消息，Rabbit MQ是不允许该消费者在同一个channel去声明其他队列的。Rabbit MQ中，可以通过queue.declare命令声明一个队列，可以设置该队列以下属性: a) Exclusive：排他队列，如果一个队列被声明为排他队列，该队列仅对首次声明它的连接可见，并在连接断开时自动删除。这里需要注意三点：其一，排他队列是基于连接可见的，同一连接的不同信道是可以同时访问同一个连接创建的排他队列的。其二，“首次”，如果一个连接已经声明了一个排他队列，其他连接是不允许建立同名的排他队列的，这个与普通队列不同。其三，即使该队列是持久化的，一旦连接关闭或者客户端退出，该排他队列都会被自动删除的。这种队列适用于只限于一个客户端发送读取消息的应用场景。 b) Auto-delete:自动删除，如果该队列没有任何订阅的消费者的话，该队列会被自动删除。这种队列适用于临时队列。 c) Durable:持久化，这个会在后面作为专门一个章节讨论。 d) 其他选项，例如如果用户仅仅想查询某一个队列是否已存在，如果不存在，不想建立该队列，仍然可以调用queue.declare，只不过需要将参数passive设为true，传给queue.declare，如果该队列已存在，则会返回true；如果不存在，则会返回Error，但是不会创建新的队列。 2. 生产者发送消息 在AMQP模型中，Exchange是接受生产者消息并将消息路由到消息队列的关键组件。ExchangeType和Binding决定了消息的路由规则。所以生产者想要发送消息，首先必须要声明一个Exchange和该Exchange对应的Binding。可以通过 ExchangeDeclare和BindingDeclare完成。在Rabbit MQ中，声明一个Exchange需要三个参数：ExchangeName，ExchangeType和Durable。ExchangeName是该Exchange的名字，该属性在创建Binding和生产者通过publish推送消息时需要指定。ExchangeType，指Exchange的类型，在RabbitMQ中，有三种类型的Exchange：direct ，fanout和topic，不同的Exchange会表现出不同路由行为。Durable是该Exchange的持久化属性，这个会在消息持久化章节讨论。声明一个Binding需要提供一个QueueName，ExchangeName和BindingKey。下面我们就分析一下不同的ExchangeType表现出的不同路由规则。 生产者在发送消息时，都需要指定一个RoutingKey和Exchange，Exchange在接到该RoutingKey以后，会判断该ExchangeType: a) 如果是Direct类型，则会将消息中的RoutingKey与该Exchange关联的所有Binding中的BindingKey进行比较，如果相等，则发送到该Binding对应的Queue中。 b) 如果是 Fanout 类型，则会将消息发送给所有与该 Exchange 定义过 Binding 的所有 Queues 中去，其实是一种广播行为。 c)如果是Topic类型，则会按照正则表达式，对RoutingKey与BindingKey进行匹配，如果匹配成功，则发送到对应的Queue中。 3. 消费者订阅消息 在RabbitMQ中消费者有2种方式获取队列中的消息: a) 一种是通过basic.consume命令，订阅某一个队列中的消息,channel会自动在处理完上一条消息之后，接收下一条消息。（同一个channel消息处理是串行的）。除非关闭channel或者取消订阅，否则客户端将会一直接收队列的消息。 b) 另外一种方式是通过basic.get命令主动获取队列中的消息，但是绝对不可以通过循环调用basic.get来代替basic.consume，这是因为basic.get RabbitMQ在实际执行的时候，是首先consume某一个队列，然后检索第一条消息，然后再取消订阅。如果是高吞吐率的消费者，最好还是建议使用basic.consume。 如果有多个消费者同时订阅同一个队列的话，RabbitMQ是采用循环的方式分发消息的，每一条消息只能被一个订阅者接收。例如，有队列Queue，其中ClientA和ClientB都Consume了该队列，MessageA到达队列后，被分派到ClientA，ClientA服务器收到响应，服务器删除MessageA；再有一条消息MessageB抵达队列，服务器根据“循环推送”原则，将消息会发给ClientB，然后收到ClientB的确认后，删除MessageB；等到再下一条消息时，服务器会再将消息发送给ClientA。 这里我们可以看出，消费者再接到消息以后，都需要给服务器发送一条确认命令，这个即可以在handleDelivery里显示的调用basic.ack实现，也可以在Consume某个队列的时候，设置autoACK属性为true实现。这个ACK仅仅是通知服务器可以安全的删除该消息，而不是通知生产者，与RPC不同。 如果消费者在接到消息以后还没来得及返回ACK就断开了连接，消息服务器会重传该消息给下一个订阅者，如果没有订阅者就会存储该消息。 既然RabbitMQ提供了ACK某一个消息的命令，当然也提供了Reject某一个消息的命令。当客户端发生错误，调用basic.reject命令拒绝某一个消息时，可以设置一个requeue的属性，如果为true，则消息服务器会重传该消息给下一个订阅者；如果为false，则会直接删除该消息。当然，也可以通过ack，让消息服务器直接删除该消息并且不会重传。 4. 持久化： Rabbit MQ默认是不持久队列、Exchange、Binding以及队列中的消息的，这意味着一旦消息服务器重启，所有已声明的队列，Exchange，Binding以及队列中的消息都会丢失。通过设置Exchange和MessageQueue的durable属性为true，可以使得队列和Exchange持久化，但是这还不能使得队列中的消息持久化，这需要生产者在发送消息的时候，将delivery mode设置为2，只有这3个全部设置完成后，才能保证服务器重启不会对现有的队列造成影响。这里需要注意的是，只有durable为true的Exchange和durable为ture的Queues才能绑定，否则在绑定时，RabbitMQ都会抛错的。持久化会对RabbitMQ的性能造成比较大的影响，可能会下降10倍不止。 5. 事务： 对事务的支持是AMQP协议的一个重要特性。假设当生产者将一个持久化消息发送给服务器时，因为consume命令本身没有任何Response返回，所以即使服务器崩溃，没有持久化该消息，生产者也无法获知该消息已经丢失。如果此时使用事务，即通过txSelect()开启一个事务，然后发送消息给服务器，然后通过txCommit()提交该事务，即可以保证，如果txCommit()提交了，则该消息一定会持久化，如果txCommit()还未提交即服务器崩溃，则该消息不会服务器就收。当然Rabbit MQ也提供了txRollback()命令用于回滚某一个事务。 6. Confirm机制： 使用事务固然可以保证只有提交的事务，才会被服务器执行。但是这样同时也将客户端与消息服务器同步起来，这背离了消息队列解耦的本质。Rabbit MQ提供了一个更加轻量级的机制来保证生产者可以感知服务器消息是否已被路由到正确的队列中——Confirm。如果设置channel为confirm状态，则通过该channel发送的消息都会被分配一个唯一的ID，然后一旦该消息被正确的路由到匹配的队列中后，服务器会返回给生产者一个Confirm，该Confirm包含该消息的ID，这样生产者就会知道该消息已被正确分发。对于持久化消息，只有该消息被持久化后，才会返回Confirm。Confirm机制的最大优点在于异步，生产者在发送消息以后，即可继续执行其他任务。而服务器返回Confirm后，会触发生产者的回调函数，生产者在回调函数中处理Confirm信息。如果消息服务器发生异常，导致该消息丢失，会返回给生产者一个nack，表示消息已经丢失，这样生产者就可以通过重发消息，保证消息不丢失。Confirm机制在性能上要比事务优越很多。但是Confirm机制，无法进行回滚，就是一旦服务器崩溃，生产者无法得到Confirm信息，生产者其实本身也不知道该消息吃否已经被持久化，只有继续重发来保证消息不丢失，但是如果原先已经持久化的消息，并不会被回滚，这样队列中就会存在两条相同的消息，系统需要支持去重。 其他： Broker：简单来说就是消息队列服务器实体。 Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。 Queue：消息队列载体，每个消息都会被投入到一个或多个队列。 Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。 Routing Key：路由关键字，exchange根据这个关键字进行消息投递。 vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。 producer：消息生产者，就是投递消息的程序。 consumer：消息消费者，就是接受消息的程序。 channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。 消息队列的使用过程大概如下： （1）客户端连接到消息队列服务器，打开一个channel。 （2）客户端声明一个exchange，并设置相关属性。 （3）客户端声明一个queue，并设置相关属性。 （4）客户端使用routing key，在exchange和queue之间建立好绑定关系。 （5）客户端投递消息到exchange。 Exchanges, queues, and bindings […]
View Details重新Rubuild Project 停止在 运行时错误： 试着的解决方式 运行clean 、install 、运行。 运行正常！！ 解决方法 删除 .idea ，重新打开项目 ，重新建立工程Rebuild Project ,信息如下： java: /E:/JPADemo/src/main/java/com/example/jpademo/JpaDemoApplication.java使用了未经检查或不安全的操作。 要取消这种告警信息，可在 public class JpaDemoApplication 类面前加@SuppressWarnings("unchecked") 原因：JAVA是一门安全性比较高的语言，它在编译之类要进行类型等一系列的检查。如果你使用了注解就可以告诉编译器不用检查，这样子就可以避过编译时期间的安全检查，这样子的效率会提高 。但同时 安全性就大打折扣了。 但是运行正常！！ from:https://www.cnblogs.com/wfy680/p/15014376.html
View Details