All posts by 龙生

CentOS设置时区与时间同步

1.设置时间

  2.安装ntpdate工具

  3.设置系统时间与网络时间同步

 

龙生   15 Aug 2021
View Details

Git撤销对远程仓库的push&commit提交

撤销push 1. 执行  git log查看日志,获取需要回退的版本号 2. 执行 git reset –-soft <版本号> ,如 git reset --soft 4f5e9a90edeadcc45d85f43bd861a837fa7ce4c7 ,重置至指定版本的提交,达到撤销提交的目的 然后执行 git log 查看 此时,已重置至指定版本的提交,log中已经没有了需要撤销的提交  git reset 命令分为两种: git reset –-soft 与 git reset –-hard ,区别是: 前者表示只是改变了HEAD的指向,本地代码不会变化,我们使用git status依然可以看到,同时也可以git commit提交。后者直接回改变本地源码,不仅仅指向变化了,代码也回到了那个版本时的代码。 3. 执行 git push origin 分支名 –-force ,强制提交当前版本号。 至此,撤销push提交完成。 撤销commit 1. 执行 git log 查看需要撤销的commit的前面一个提交版本的id; 2. 执行 git reset --hard commit_id ,该commit_id为需要撤销的commit的提交的前面一个提交的版本,即需要恢复到的提交的id,重置至指定版本的提交,达到撤销提交的目的 3. 执行 git log 查看,commit提交已撤销   from:https://www.cnblogs.com/chaoxiZ/p/9714085.html

龙生   13 Aug 2021
View Details

MySQL事务与MVCC如何实现的隔离级别

前言 其实数据库章节基本上的知识点我都写过一遍了,包括这篇事务和MVCC的,但是国庆期间我翻阅资料的时候我发现之前写的还差点意思,例子举得也差点意思,那我就根据我自己最新的理解,加上之前的总结相当于重写了,希望你也有新的收获。   数据库事务介绍   事务的四大特性(ACID) 原子性(atomicity): 事务的最小工作单元,要么全成功,要么全失败。 一致性(consistency): 事务开始和结束后,数据库的完整性不会被破坏。 隔离性(isolation): 不同事务之间互不影响,四种隔离级别为RU(读未提交)、RC(读已提交)、RR(可重复读)、SERIALIZABLE (串行化)。 持久性(durability): 事务提交后,对数据的修改是永久性的,即使系统故障也不会丢失。   事务的隔离级别   读未提交(Read UnCommitted/RU) 又称为脏读,一个事务可以读取到另一个事务未提交的数据。这种隔离级别岁最不安全的一种,因为未提交的事务是存在回滚的情况。   读已提交(Read Committed/RC) 又称为不可重复读,一个事务因为读取到另一个事务已提交的修改数据,导致在当前事务的不同时间读取同一条数据获取的结果不一致。 举个例子,在下面的例子中就会发现SessionA在一个事务期间两次查询的数据不一样。原因就是在于当前隔离级别为 RC,SessionA的事务可以读取到SessionB提交的最新数据。 发生时间 SessionA SessionB 1 begin; 2 select * from user where id=1;(张三) 3 update user set name=’李四' where id=1;(默认隐式提交事务) 4 select * from user where id=1;(李四) 5 update user set name=’王二' where id=1;(默认隐式提交事务) 6 select * from user where id=1;(王二)   可重复读(Repeatable Read/RR) 又称为幻读,一个事物读可以读取到其他事务提交的数据,但是在RR隔离级别下,当前读取此条数据只可读取一次,在当前事务中,不论读取多少次,数据任然是第一次读取的值,不会因为在第一次读取之后,其他事务再修改提交此数据而产生改变。因此也成为幻读,因为读出来的数据并不一定就是最新的数据。 举个例子:在SessionA中第一次读取数据时,后续其他事务修改提交数据,不会再影响到SessionA读取的数据值。此为可重复读。 发生时间 SessionA SessionB 1 begin; 2 select * from user where id=1;(张三) 3 update user set […]

龙生   12 Aug 2021
View Details

微服务规范

微服务规范 前后端分离 数据库避免大量联合查询 服务设计无状态化 服务拆分最多三层,两次调用: 底层:基础服务层 中间层:组合服务层 上层:对外接口层 提供微服务关系图 统一维护微服务相互调用接口 配置统一到apollo 建议设计独立适配微服务以便调用外部服务 接口实现需幂等 定时任务建议实现在统一的单独微服务中,调用其它微服务接口来实现业务。否则和其它微服务实例一起部署的任务须加锁控制,以避免多实例冲突; 持续集成单元测试、接口测试 容器化并自动构建镜像、kubernetes部署 技术选型: 网关:spring cloud gateway 注册中心: consul 调用: feign 负载均衡:ribbon 熔断限流降级:hystrix 监控:cat, hystrix+trubine 容器:docker+kubernetes 微服务实战 环境准备 玩转Docker 服务注册发现Consul起步 实战课程 微服务概览 大话微服务 Provider微服务实战 Consumer微服务实战 Spring Cloud Gateway实战 Spring Cloud Gateway之Filter实战 微服务之网关——spring cloud gateway简单实践 掌医开放平台gateway服务设计及使用手册 契约测试实战 微服务监控-CAT Sleuth+Zipkin调用链监控实战 Hystrix熔断限流降级&Turbine API监控实战 微服务横向热扩展和自定义负载均衡策略 spring cloud gateway聚合swagger K8S创建服务实践小记 Google Jib:Java容器镜像构建新工具 微服务feign调用失败排查问题思路 微服务demo 微服务demo gitlab仓库

龙生   08 Aug 2021
View Details

MySQL自定义函数:身份证号15位转18位

 

龙生   06 Aug 2021
View Details

【mysql】 1292. Truncated incorrect INTEGER value: "

错误分析 一般来讲,找到对应的insert字段,然后看一下是否是由于字段类型不匹配导致的。 例如,表中声明的是bigInt类型,你传值传了个字符串进入。 另外,如果你是通过insert into select的方式,将查询结果导入到新的表中,可能你单独执行select中的内容,是可以查询到相应的结果,但是当你执行insert into语句时,会产生如下错误

在MySQL的论坛上找到一个哥们儿说的内容,也就是说这个1292的错误,有可能并不是错误,而是警告提示。可以通过ignore关键字进行警告屏蔽 所以,我把自己的代码前缀,改成如下格式,即可正常执行导入操作

  ———————————————— 版权声明:本文为CSDN博主「小魏的马仔」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/xuexiiphone/article/details/103426404

龙生   30 Jul 2021
View Details

MySQL处理JSON数组,数组转字符串

GROUP_CONCAT:group_concat( [distinct] 要连接的字段 [order by 排序字段 asc/desc  ] [separator '分隔符'] ) SUBSTRING_INDEX:substring_index(str,delim,count) str:要处理的字符串 delim:分隔符 count:计数 SUBSTRING:SUBSTRING(string,position) JSON_EXTRACT:取json字符串字段下的某个键的值

龙生   29 Jul 2021
View Details

请求资源报错 blocked:mixed-content

原因是https页面去发送http请求报错(浏览器阻止https发送http请求) 解决方法:页面中的http换成https   from:https://www.cnblogs.com/nonsec/p/13177387.html

龙生   16 Jul 2021
View Details

必须知道的SQL语句不走索引时的排查利器

前言: 在索引优化时,经常会看到的一句话:如果索引字段出现隐式字符集转换的话,那么索引将失效,进而转为全表扫描,查询效率将大大降低,要避免出现隐式字符集转换; 在此我想问问同学们: 大家知道为什么隐式字符集转换会导致索引失效吗? 实际场景中有没有遇到过隐式字符集转换导致索引失效的场景,具体排查的过程; 本文主线: 由上面的两个问题牵引出了本文的主线; 简单描述下隐式字符集转换导致索引失效的原因 然后模拟实际场景排查隐式字符集转换导致索引失效的过程 隐式字符集转换导致索引失效的原因 MySQL索引的数据结构是 B+Tree,想要走索引查询必须要满足其 最左前缀原则 ,否则无法通过索引树进行查找,只能进行全表扫描; 例如:下面的这个SQL由于在 索引字段 上使用函数进行运算,导致索引失效

  上面的这个SQL怎么改造才能使索引生效呢?如下所示:

  通过上面的小例子可以知道,如果在索引字段上使用函数运算,则会导致索引失效,而索引字段的 隐式字符集转换 由于MySQL会自动的在索引字段上加上 转换函数 ,进而会导致索引失效; 那接下来我们就通过模拟的实际场景来具体看看是不是由于MySQL自动给加上了转换函数而导致索引失效的; 模拟场景 + 问题排查 由于导致索引失效的原因有很多,如果自己写的SQL怎么看都没问题,但是通过查看执行计划发现就是没有走索引查询,此时就会让很多人陷入困境,这到底是怎么导致的呢? 此时本文重点将要讲述的工具就要闪亮登场啦: explain extended + show warnings ; 使用这个工具可以将执行的SQL语句的一些扩展信息展示出来,这些扩展信息就包括:MySQL优化时可能会添加上字符集转换函数,使得字符集不匹配的SQL可以正确执行下去; 下面就来具体聊聊 explain extended + show warnings 的使用; 模拟隐式字符集转换的场景: 首先创建两个字符集不一样的表:

  然后使用存储过程构造数据:

  注意:在构造数据时,记得将 t_employees 表中的 de_no 字段值构造的 离散些 ,因为如果索引字段值的 区分度很低 的话,那么MyQSL优化器通过采样统计分析时,发现索引查询和全表扫描性能差不多,就会直接进行全表扫描了; 索引失效的查询SQL语句: 将表和数据构造完后,我们使用SQL语句进行查询下,然后再看看其执行计划;

  其执行计划如下: 发现 t_employees 表中的 de_no 字段有索引,但是没有走索引查询,type=ALL 走的全表扫描,但是通过查看SQL语句发现其没有问题呀,表面看上去都是满足走索引查询的条件呀,排查到这发现遇到了困境,苦恼啊! 还好,通过在网络世界上遨游,最终发现了 explain extended + show warnings 利器,利用它快速发现了索引失效的根本原因,然后快速找到了解决方案; 下面就来聊聊这个利器的具体使用,开森! 使用利器快速排查问题: 注意:explain 后面跟的关键字 EXTENDED(扩展信息) 在MySQL5.7及之后的版本中废弃了,但是该语法仍被识别为向后兼容,所以在5.7版本及后续版本中,可以不用在 explain 后面添加 EXTENDED 了; EXTENDED关键字的具体查阅资料:https://dev.mysql.com/doc/refman/5.7/en/explain-extended.html 具体使用方法如下: ①、首先在MySQL的可视化工具中打开一个 命令列介面 :工具 --> 命令列介面 ②、然后输入下面的SQL并按回车:

  ③、然后紧接着输入命令 show warnings; 并回车,会出现如下图所示内容: 通过展示出的执行SQL扩展信息,发现MySQL在字符集不一致时自动添加上字符集转换函数,因为是在 索引字段 de_no 上添加的转换函数,所以就导致了索引失效; 而如果我们没看扩展信息的话,那么可能直到我们查看表结构的时候才会发现是由于字符集不一致导致的,这样就会花费很多的时间; 扩展:隐式类型转换 咱们聊完上面的隐式字符集转换导致索引失效的情况,再来简单聊聊另一种 隐式类型转换 导致索引失效的情况; […]

龙生   09 Jul 2021
View Details

开发人员正从 Java 8 向 Java 11 转移

此前的 Java 社区报告曾指出,Java 8 仍是开发人员使用的主要版本,新版本并未“得宠”。但 Snyk 近期发布的  JVM Ecosystem Report 2021 则指出,开发人员已经逐渐从 Java 8 迁移到了 Java 11。 JVM Ecosystem Report 2021 展示了关于 JVM 生态系统状态的最大年度调查的结果。该调查在 2021 年 2 月和 3 月的六周时间里进行,收集了来自 2000 多名 Java 开发者的回复。 调查结果显示,有 44.1% 的受访者在生产中使用免费的 AdoptOpenJDK 发行版。但 Oracle 仍然是市场上的重要参与者,其 OpenJDK 构建占 28%,商业 Oracle JDK 占 23%。 40% 的调查参与者在生产中使用了一个以上的 Java 版本。升级到 8 版本以上的人也比预料的要多。目前,有 61.5% 的人在生产中使用 Java 11,近 12% 的人使用最新版本,即调查期间的 Java 15。 Snyk 方面在报告中指出,这表明开发人员确实将他们的 Java 版本升级到了 Java 8 以上的版本,有关大多数 Java 开发人员都乐于使用 Java 8 的现象似乎正在慢慢瓦解。不过值得注意的是,仍有一半的 Java 11 用户(目前使用最多的版本)在他们的生产堆栈中使用 Java 8。 从长远来看,虽然 JVM 语言的种类在过去几年中有所增长,但 Java 仍然是最受欢迎的语言。超过 90% 的开发者使用 Java;Kotlin 次之,为 17.7%。 而 JetBrains IntelliJ IDEA […]

龙生   08 Jul 2021
View Details
1 81 82 83 410