Springcloud+Seata+nacos 分布式事务项目搭建 AT模式

来自 Raye Wang 发表在 分布式事务 发表于

前言本文要求对Springcloud有一定了解，对分布式事务本身有一定认知，如果不了解微服务，建议先看看Spring Cloud的基本认识和使用Spring Cloud的基本教程,再回头学习本文 为什么会出现分布式事务开发过程中，随着项目模块的增加以及分库分表的出现，传统事务已经无法满足业务需求，如分库，由于有多个数据源，而数据库事务又是基于数据库层，所以如果只用数据库原生事务，会导致数据库A成功提交，数据库B回滚，导致数据不一致，又比如多模块下，常见的订单流程，订单服务成功提交订单，调用库存服务扣减库存，由于是链式调用，库存成功扣减，然后回到订单服务时，出现异常，导致订单回滚，但是此时库存却未回滚，也会导致数据不一致，所以这些情况都需要分布式事务来解决这个问题（当然一般开发中，我们常用的做法是能避免就尽量避免，实在避免不了才使用分布式事务，因为分布式事务不管怎么样，性能，一致性，原子性等都会收到影响） 分布式事务目前的几种方案2PC（二阶段提交） 3PC（三阶段提交） TCC(Try - Confirm - Cancel) 最终一致性（消息队列等方式） 最大努力通知（数据不要求强一致）…

Springboot Druid 自定义加密数据库密码

来自 Raye Wang 发表在 JavaEE 发表于

前言开发过程中，配置的数据库密码通常是明文形式，这样首先第一个安全性不好（相对来说），不符合一个开发规范（如项目中不能出现明文账号密码），其实就是当出现特殊需求时，比如要对非运维人员开方服务器部分权限，但是又涉及项目部署的目录时，容易泄漏数据库密码，虽然一般生产环境中，数据库往往放入内网，访问只能通过内网访问，但是不管怎么说账号密码直接让人知道总归不好，甚至有些项目需要部署到客户环境中，但是可能共用一个公共数据库（数据库只向指定服务器开放外网端口或组建内网环境），这样的情况下，如果数据库密码再以明文形式存在，就非常危险了，常见的避免这些方式据我了解有2种 第一种：通过网络获取密码 这种是让密码通过接口获取，当然接口中可以做加密认证，但是如果是把获取地址和认证放在了配置文件中，那么稍微用心也能获取到密码，不过也可以跟第二种方法配合使用 第二种：密码加密 通过对密码加密，使得配置文件中配置的密码为密文，从而提升安全性，当然网络获取密码也可以获取加密后的密码，而国内常用的数据库连接池是Druid，所以此文主要是针对Druid的数据库密码加密方案，Druid默认再带了一个密码加密，所以Druid加密密码也有2种方案 Druid加解密密码的2种方案第一种：自带加密 优点：简单快捷，配置方便，无需改动代码（只需要改动配置文件即可） 缺点：自欺欺人式加密，因为密码和公钥都需要配置到配置文件中，只要别人有了配置文件，看出来了你是用的Druid,…

Java 浮点型（Double,Float）精度丢失解决方案

来自 Raye Wang 发表在 JavaEE 发表于

前言最近公司某小伙子做了一个商城的微信支付相关的接口，其中包含退款，在测试过程中发现部分单据没有退款，微信支付提示退款金额跟支付金额不匹配（大于支付金额），检查数据库和调试过程中，发现商品的单价和手工计算出来的总价是跟订单金额匹配的，实在无法确认问题原因最终bug转向我来排查，于是有了此文 排查由于手工计算出来的金额跟实际支付的金额是能匹配上的，所以一开始我以为是订单已经进行了部分退款，再次全部退款的话肯定会被微信阻止，因为这样的话就会出现超退。 第一步：是否已经部分退款 去微信支付平台排查是否有退款，结果发现并没有退款 由于微信平台没有查询到此单的退款，那么说明不是超退的问题，可能是传入的订单金额有问题，但是大部分单据又可以退款，所以也暂时陷入了僵局，不过为了保险起见，还是去看了一下传参处 第二步：检查传参 检查微信退款方法传参时，看了传入参数，由于微信传参的单位是分，所以看到传参处传入退款总金额代码(int)(100)*商品单价*退货数量（这里只是伪代码，多个商品肯定还要相加计算的）,粗略一看没有问题，仔细一看不对，总价是直接double类型的乘以数量在乘以100再强转为int类型传入的，按照理论上来说是没有问题的，因为我们商品价格都是精确到分的，但是只是理论上，实际上就是Java的double类型有个大坑（不只是Java，JavaScript，c#等很多语言都有这个问题），最终在代码中进行总价计算，发现确定是因为这个原因，导致计算出来的退款金额比应退金额多了1分钱，…

一次抢口罩的负载优化

来自 Raye Wang 发表在 服务器 发表于

前言由于这次令人讨厌的疫情，导致口罩一罩难求，虽然各大厂商都在努力生产，但是毕竟僧多粥少，也幸好疫情快要结束了，也希望早点结束。因为口罩实在难以购买，所以很多地方的口罩采用统一调配，但是如何把口罩发放到大众手里，也成为了一个问题，所以预约购买成了最为安全的购买方式，购买后可以邮寄到家或者根据选择的时间段到店自提，但是由于购买人数过多，也带来了一个新的问题，服务器并发的问题，至少我在二月份参与了很多预约购买口罩的平台，没有一个平台不崩溃的，大多都是10几分钟了，就没有正常请求过服务器一次，不过幸好现在大部分平台已经调整为抽签的形式，而不是之前的先到先得规则，这样相对于先到先得更加公平，不受限于网络和运气，因为我们公司也做了相应的预约平台，不过由于客户要求先到先得原则，所以了本文。不过由于使用我们平台的用户并没有一线城市那么夸张，动不动几百万人同时抢购，而且我们平台的服务器也没有那么好的配置，所以本文的方式只是在几万人同时抢购的情况下测试过，当然其中思路还是可以参考的一下的，毕竟没有万金油，负载优化肯定是要根据实际情况来处理的 要求首先第一个要求是不能超发，第二个要求是尽可能提交成功的失败率不会太高，也就是说不要100人都提交成功了，但是最后只有一个人抢到了口罩，第三就是要求服务器不要崩溃，尽可能的不要出现请求服务器失败的情况。 首先一个要求解决方案：因为考虑到大并发的情况的，而且还做了负载均衡，所以要么采用分布式锁或者队列， 分布式锁分布式锁的优点是可以实时知道抢购结果，坏处就是性能低下，处理不好容易造成服务器压力过大。 分布式锁可以采用zookeeper，当然还有别的分布式中间件或者框架，千万别直接用语言自带的锁，做了负载均衡后，…

基于IDEA热部署更新服务器Tomcat类，服务器Tomcat热更新

来自 Raye Wang 发表在 JavaEE 发表于

前言在开发过程中，如果我们是使用的IDEA，就会知道IDEA有一个热更新的功能，何为热更新？就是在不重启Tomcat的情况下让服务器中的代码变更为最新的。这样既能快速的更新代码，又不用担心Tomcat重启session过期的问题，如同更新jsp一般的方便，当然IDEA里面的热更新还是没有更新jsp那么方便，具体限制本文后面有提（只是我目前了解到的限制）。如果说本地更新还算快捷，那么服务器更新就更加麻烦了，一般我们更新服务器上面的程序有2种情况，一是全量更新，就是打包war包去更新，二是部分更新，就是修改了那个class，就去服务器替换某个class文件，然后重启服务器（jsp文件不算，因为更新jsp是不需要重启Tomcat的，具体原因自己行百度）。这样常规的更新有2个弊端，第一：耗费时间长，不管是文件上传的时间，还是重启服务的时间，尤其是在项目很大启动很慢的时候，有时候只是更新一个简单的东西，却要等待数分钟，而且这数分钟还不是一个人的时间，是所有当时在用这台服务器的人的时间，第二：session失效的问题，服务器一旦重启，所有登录的用户就需要重新登录（当然如果session不是保存在Tomcat中的就另当别论了）。 基于以上种种，如果更新服务器能像我们本地IDEA一样方便，那么会节省我们很多的时间，加快各方人马的开发进度。幸好这种方式是有的，可以实现在IDEA中直接更新服务器代码，此方式是基于Tomcat远程调试的（不清楚远程调试的同学建议百度，也是一个挺好用的功能），而且不需要做其他配置，所以直接进入配置环节 Tomcat远程调试配置因为只要配置好了IDEA的远程调试，…

Springboot Druid 使用Slf4j输出可执行SQL

来自 Raye Wang 发表在 JavaEE 发表于

前言在开发中，为了数据安全，所有SQL语句肯定是用占位符的，但是在实际开发中，为了方便追踪问题，经常需要查看具体执行的SQL语句内容，而用了占位符之后，每次真实执行的语句只能靠自己根据参数拼接出来，耗时耗力，所以需要一个方法输出每次执行的SQL语句，并且还是有参数的（替换了占位符）,而Druid就支持此功能（Druid的主要功能可不是这个）,所以此文主要讲Springboot环境下使用Druid输出可执行SQL，并且是使用的Springboot的默认日志配置格式，因为一旦修改了Springboot的日志配置格式，输出来的日志一般是没有颜色区分的，如下： 而springboot默认配置的日志如下： 当然也可以自己配置出来颜色，只是我个人觉得springboot的默认配置已经很好看了，不用再配置了 当然Springboot配置Druid输出可执行的SQL文档太多了，只是他们都需要配置日志本身，也就是配置后日志输出的样子我不喜欢，所以各种研究后，才有了此文（之前百度是真没有找到用默认配置输出的方法） Druid 介绍Druid是Java语言中最好的数据库连接池。Druid能够提供强大的监控和扩展功能。以上是官方的自我介绍，也侧面说明了Druid是一个功能强大，自带监控扩展的数据库连接池，具体想了解Druid的话建议去全球最大的同性交友基地了解 配置使用Springboot默认的日志配置文件，意味着就没有log4j.properties之类的文件给我们配置了，那就只有在application.yml或者application.properties中配置springboot告诉它我们哪些地方需要打印日志，需要打印什么级别的日志 首先要配置连接池为Druid spring: application: name: admin-managee datasource: druid:…

SpringMVC,SpringBoot快速验证参数是否完整 基于@Valid注解

来自 Raye Wang 发表在 JavaEE 发表于

前言在接口开发中，经常是需要对传入参数完整性进行验证的，或者对手机号格式进行验证等，而一般不了解@Valid注解之前，都是通过自己封装方法来验证，都是一堆if else集合，这样判断对于代码结构很不友好，开发效率也不高，使用@Valid注解可以快速的对参数进行验证，并且可以通过抓取全局异常，从而实现统一返回 引用@Valid是使用hibernate validation的时候使用,其中java的jsr303声明了这类接口，hibernate-validator对其进行了实现 在进行maven整合时，需要引入的依赖 <dependency> <groupId>org.hibernate.validator</groupId> <artifactId>hibernate-validator</artifactId> <version>6.0.13.Final</version>…

Linux配置Tomcat日志轮转（切割）

来自 Raye Wang 发表在 服务器 发表于

服务器每天都会产生很多各种各样的日志，尤其是生产环境，因为很多日志需要保留一段时间，防止这段时间内出现了问题却没有找到日志文件,当然为了更好的查询日志和定位错误，推荐搭建EFK(ELK)日志分析系统（centos7搭建EFK日志分析系统），但是就算搭建了EFK，也还是需要定时删除原始的日志文件，而如果没有对原始日志文件进行分割的话，一旦删除就会把整个原始日志文件删除掉，万一某一部分日志还未写入EFK中，那么就会导致日志丢失，而且如果日志没有分割，需要查看原始日志的时候也是一件痛苦的事情，毕竟生产环境每天都能参数几个G的日志，如此庞大的日志，使用Linux的命令查看搜索都是耗时耗力的，所以日志分割不管是对于测试环境还是生产环境来说，都是有必要的，而分割日志也叫日志轮转，可以自己写脚本处理，当然也可以使用Linux本来就有的服务：logrotate logrotate简介logrotate程序是一个日志文件管理工具，它可以自动对日志进行截断（或轮循）、压缩以及删除旧的日志文件，并创建新的日志文件，起到“转储”作用。它是基于CRON来运行的，其脚本是「/etc/cron.daily/logrotate」。主流Linux发行版上都默认安装有logrotate包 配置文件介绍Linux系统默认安装logrotate工具，它默认的配置文件在： /etc/logrotate.conf /etc/logrotate.d/ logrotate.…