Spring Boot Logging 配置(记录)

我用到的配置,贴个记录

logging:
  level:
    root: info
  file:
    path: ./log/${server.port}
  pattern:
    file: '%d{yyyy/MM/dd HH:mm:ss.SSS} %clr(%-5level) [%magenta(%thread)] %cyan(%logger{15}) : %msg%n'
    console: '%d{yyyy/MM/dd HH:mm:ss.SSS} %clr(%-5level) [%magenta(%thread)] %cyan(%logger{15}) : %msg%n'

百分号格式化解释:

  •  %d:日期,大括号里面为日期的显示格式;
  • %clr(): 根据内容显示不同颜色的的方法,一般是给“日志级别”这个信息使用的;
  • %level:日志级别,百分号和关键字中间的短杠和数字(-5)表示显示这么多个字符的宽度,内容不足则补充空格占位;
  • %magenta():将内容显示为品红色字体。显示为其他颜色可以参考这个图,注意看图中绿色字体;
  • (%thread):线程名;
  • %cyan:将内容显示为青色字体;
  • %logger:事件发生的位置的所在类的全类名;
  • %line:事件发生的位置的行号;
  • %msg:事件信息;
  • %n:换行,输出跨操作系统的换行符号;

配置参数:

  • logging.level.* : 作为package(包)的前缀来设置日志级别。
  • logging.file :配置日志输出的文件名,也可以配置文件名的绝对路径。
  • logging.path :配置日志的路径。如果没有配置logging.file,Spring Boot 将默认使用spring.log作为文件名。
  • logging.pattern.console :定义console中logging的样式。
  • logging.pattern.file :定义文件中日志的样式。
  • logging.pattern.level :定义渲染不同级别日志的格式。默认是%5p.
  • logging.exception-conversion-word :.定义当日志发生异常时的转换字
  • PID :定义当前进程的ID

logging.level

logging.level设置日志级别。我们可以使用TARCE , DEBUG , INFO , WARN , ERROR , FATAL , OFF 。可以使用root级别和package级别来控制日志的输入级别。创建一个具有以下依赖关系的应用程序。

logging.file

Spring Boot 默认把日志输入到console,如果我们要把日志输入到文件中,需要配置logging.file 或者logging.path属性性。logging.file属性用来定义文件名。他不仅仅可以配置文件名,也可以路径+文件名。

logging.path

配置logging.path或者logging.path属性将日志输出到文件夹中。logging.path属性用来定义日志文件路径。

logging.patter.console

通过设置logging.patter.console属性我们能改变输出到console的日志样式。日志样式包括时间,日志级别,线程名,日志名以及消息。我们可以按我们的喜好改变日志样式

logging.pattern.file

改变文件中的日志样式我们需要设置logging.pattern.file属性。首先通过logging.file或logging.path属性,把日志记录到文件中。

 

一文搞懂蓝绿发布、灰度发布和滚动发布

应用程序升级面临最大挑战是新旧业务切换,将软件从测试的最后阶段带到生产环境,同时要保证系统不间断提供服务。

长期以来,业务升级渐渐形成了几个发布策略:蓝绿发布、灰度发布和滚动发布,目的是尽可能避免因发布导致的流量丢失或服务不可用问题。

一、 蓝绿发布
项目逻辑上分为AB组,在项目系统时,首先把A组从负载均衡中摘除,进行新版本的部署。B组仍然继续提供服务。

1

当A组升级完毕,负载均衡重新接入A组,再把B组从负载列表中摘除,进行新版本的部署。A组重新提供服务。

2

最后,B组也升级完成,负载均衡重新接入B组,此时,AB组版本都已经升级完成,并且都对外提供服务。

特点

  • 如果出问题,影响范围较大;
  • 发布策略简单;
  • 用户无感知,平滑过渡;
  • 升级/回滚速度快。

缺点

  • 需要准备正常业务使用资源的两倍以上服务器,防止升级期间单组无法承载业务突发;
  • 短时间内浪费一定资源成本;
  • 基础设施无改动,增大升级稳定性。

蓝绿发布在早期物理服务器时代,还是比较昂贵的,由于云计算普及,成本也大大降低。

二、 灰度发布

灰度发布只升级部分服务,即让一部分用户继续用老版本,一部分用户开始用新版本,如果用户对新版本没什么意见,那么逐步扩大范围,把所有用户都迁移到新版本上面来。

3

特点

  • 保证整体系统稳定性,在初始灰度的时候就可以发现、调整问题,影响范围可控;
  • 新功能逐步评估性能,稳定性和健康状况,如果出问题影响范围很小,相对用户体验也少;
  • 用户无感知,平滑过渡。

缺点

  • 自动化要求高

部署过程

  • 从LB摘掉灰度服务器,升级成功后再加入LB;
  • 少量用户流量到新版本;
  • 如果灰度服务器测试成功,升级剩余服务器。

灰度发布是通过切换线上并存版本之间的路由权重,逐步从一个版本切换为另一个版本的过程。

三、 滚动发布

滚动发布是指每次只升级一个或多个服务,升级完成后加入生产环境,不断执行这个过程,直到集群中的全部旧版本升级新版本。

4

  • 红色:正在更新的实例
  • 蓝色:更新完成并加入集群的实例
  • 绿色:正在运行的实例

特点

  • 用户无感知,平滑过渡;
  • 节约资源。

缺点

  • 部署时间慢,取决于每阶段更新时间;
  • 发布策略较复杂;
  • 无法确定OK的环境,不易回滚。

部署过程

  • 先升级1个副本,主要做部署验证;
  • 每次升级副本,自动从LB上摘掉,升级成功后自动加入集群;
  • 事先需要有自动更新策略,分为若干次,每次数量/百分比可配置;
  • 回滚是发布的逆过程,先从LB摘掉新版本,再升级老版本,这个过程一般时间比较长;
  • 自动化要求高。

小结

综上所述,三种方式均可以做到平滑式升级,在升级过程中服务仍然保持服务的连续性,升级对外界是无感知的。那生产上选择哪种部署方法最合适呢?这取决于哪种方法最适合你的业务和技术需求。如果你们运维自动化能力储备不够,肯定是越简单越好,建议蓝绿发布,如果业务对用户依赖很强,建议灰度发布。如果是K8S平台,滚动更新是现成的方案,建议先直接使用。

  • 蓝绿发布:两套环境交替升级,旧版本保留一定时间便于回滚。
  • 灰度发布:根据比例将老版本升级,例如80%用户访问是老版本,20%用户访问是新版本。
  • 滚动发布:按批次停止老版本实例,启动新版本实例。

原文:https://www.cnblogs.com/nulige/articles/10929182.html 1

MySQL的四种事务隔离级别

一、事务的基本要素(ACID)

1、原子性(Atomicity):事务开始后所有操作,要么全部做完,要么全部不做,不可能停滞在中间环节。事务执行过程中出错,会回滚到事务开始前的状态,所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体,就像化学中学过的原子,是物质构成的基本单位。

2、一致性(Consistency):事务开始前和结束后,数据库的完整性约束没有被破坏 。比如A向B转账,不可能A扣了钱,B却没收到。

3、隔离性(Isolation):同一时间,只允许一个事务请求同一数据,不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱,在A取钱的过程结束前,B不能向这张卡转账。

4、持久性(Durability):事务完成后,事务对数据库的所有更新将被保存到数据库,不能回滚。

二、事务的并发问题

1、脏读:事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据

2、不可重复读:事务 A 多次读取同一数据,事务 B 在事务A多次读取的过程中,对数据作了更新并提交,导致事务A多次读取同一数据时,结果 不一致。

3、幻读:系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级,但是系统管理员B就在这个时候插入了一条具体分数的记录,当系统管理员A改结束后发现还有一条记录没有改过来,就好像发生了幻觉一样,这就叫幻读。

小结:不可重复读的和幻读很容易混淆,不可重复读侧重于修改,幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行,解决幻读需要锁表

三、MySQL事务隔离级别

事务隔离级别 脏读 不可重复读 幻读
读未提交(read-uncommitted)
不可重复读(read-committed)
可重复读(repeatable-read)
串行化(serializable)

 

 

Spring事务管理中@Transactional的propagation参数

所谓事务传播性,就是被调用者的事务与调用者的事务之间的关系。举例说明。

//in A.java
Class A {
    @Transactional(propagation=propagation.REQUIRED)
    public void aMethod {
        B b = new B();
        b.bMethod();
    }
}
//in B.java
Class B {
    @Transactional(propagation=propagation.REQUIRED)
    public void bMethod { //something }
}

在上面这个例子中,传播性被设为了REQUIRED,注意,这是默认值,也即不进行该参数配置等于配置成REQUIRED。

REQUIRED的含义是,支持当前已经存在的事务,如果还没有事务,就创建一个新事务。在上面这个例子中,假设调用aMethod前不存在任何事务,那么执行aMethod时会自动开启一个事务,而由aMethod调用bMethod时,由于事务已经存在,因此会使用已经存在的事务(也就是执行aMethod之前创建的那个事务)。

对于这样的配置,如果bMethod过程中发生异常需要回滚,那么aMethod中所进行的所有数据库操作也将同时被回滚,因为这两个方法使用了同一个事务。

MANDATORY的含义是,支持当前已经存在的事务,如果还没有事务,就抛出一个异常。如果上例中aMethod的传播性配置为MANDATORY,我们就无法在没有事务的情况下调用aMethod,因此,传播性为MANDATORY的方法必定是一个其他事务的子事务,当逻辑上独立存在没有意义或者可能违反数据、事务完整性的时候,就可以考虑设置这样的传播性设置。

NESTED的含义是,在当前事务中创建一个嵌套事务,如果还没有事务,那么就简单地创建一个新事务。

REQUIRES_NEW的含义是,挂起当前事务,创建一个新事务,如果还没有事务,就简单地创建一个新事务。

请注意以上两者的区别,大多数情况下一上两种传播性行为是类似的,不过在事务回滚的问题上,以上两者有很大的区别。

首先,REQUIRES_NEW会创建一个与原事务无关的新事务,尽管是由一个事务调用了另一个事务,但却没有父子关系。

如果bMethod的传播性是REQUIRES_NEW,而抛出了一个异常,则bMethod一定会被回滚,而如果aMethod捕获并处理了这个bMethod抛出的异常,那么aMethod仍有可能成功提交。当然,如果aMethod没有处理这个异常,那么aMethod也会被回滚。

如果aMethod在bMethod完成后出现了异常,那么bMethod已经提交而无法回滚,只有aMethod被回滚了。

而对于NESTED,虽然也会创建一个新事务,但是这个事务与调用者是有父子关系的相互依存的。

如果bMethod的传播性是NESTED,而抛出了一个异常,事务的回滚行为与REQUIRES_NEW是一致的。

但是如果aMethod在bMethod完成后出现了异常,bMethod同样也会被回滚。因为事实上,EJB中没有对于NESTED传播性的类似实现,NESTED并不是真正启动了一个事务,而是开启了一个新的savepoint。

NEVER的含义很简单,就是强制要求不在事务中运行,如果当前存在一个事务,则抛出异常,因此如果bMethod传播性是NEVER,则一定抛出异常。

NOT_SUPPORTED的含义是,强制不在事务中运行,如果当前存在一个事务,则挂起该事务。

SUPPORTS的含义是,支持当前事务,如果没有事务那么就不在事务中运行。SUPPORTS传播性的逻辑含义比较模糊,因此一般是不推荐使用的。

123104