解决 fatal: refusing to merge unrelated histories

Git 的报错

一、fatal: refusing to merge unrelated histories

新建了一个仓库之后,把本地仓库进行关联提交、拉取的时候,出现了如下错误:

ankobot@DESKTOP-9IUDMKP MINGW64 /e/workspace/firmware_upload/firmware_upload (master)
$ git pull
fatal: refusing to merge unrelated histories

二、解决方案

在你操作命令后面加 –allow-unrelated-histories
例如:

git merge master --allow-unrelated-histories
$ git pull --allow-unrelated-histories
CONFLICT (add/add): Merge conflict in .gitignore
Auto-merging .gitignore
Automatic merge failed; fix conflicts and then commit the result.

我这里由于使用了官方的 .gitignore 自动合并失败,需要手动合并之后再进行 add、commit 即可

如果你是git pull或者git push报fatal: refusing to merge unrelated histories
同理:
git pull origin master –allow-unrelated-histories / git pull –allow-unrelated-histories
等等,就是这样完美的解决!

Spring boot jackson序列化实体类属性大小写问题

查了一下,原来com.fasterxml.jackson搞的鬼,我的问题是实体类有一个属性叫UDID,但是接口返回的JSON变成了小写udid。

使用@JsonProperty(“UDID”)注解可以完美解决调这个问题,例子:

@JsonProperty("UDID")
private String UDID;

放在geter方法同样有效:

@JsonProperty("UDID")
public String getUDID() {
    return UDID;
}

建议是放在geter方法上,如果放在属性上,它会出现两个UDID,一个是大写的,一个小写的。

那么放在方法上呢,就不会出现这个问题。

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)

 

 

167891032
 
Copyright © 2008-2021 lanxinbase.com Rights Reserved. | 粤ICP备14086738号-3 |