欢迎来到Heck's Blog,专业承接拿站、企业建站、仿站、网上商城架构、门户网站搭建、空间域名注册、软件定制等项目。关注网络安全,因为专注,所以专业,懂得放弃,才能收获。有事请发邮件至i@heckjj.com,请记住本站网址:http://www.heckjj.com,多谢。
5月26
Spring Boot项目在多环境下(开发、生产或测试环境)调用不同配置文件方式:

我们知道,一个项目在开发环境、测试环境、生产环境,不同的环境会有不同的配置,比如数据库的配置就不同,那么怎么样才能做到,不用每次换环境的时候,都去修改这些配置呢,下面以我写的一个小案例来作说明。

如下图是我项目的三个配置文件,其中,application.yml是启动服务时,服务器会自动加载的配置文件,而application-dev.yml代表的是开发环境的配置文件,application-prod.yml代表的是生产环境的配置文件,后两个文件在启动服务时,服务器不会自动加载,那么在不同的环境中时怎么调用不同的文件的呢?

点击在新窗口中浏览此图片

方式一、修改配置文件方式

    修改application.yml配置文件,具体内容如下图:

点击在新窗口中浏览此图片

这样,在启动服务时,服务器就会通过application.yml文件去调用application-dev.yml文件。同理,若active: prod,那么服务在启动时,服务器就会调用application-prod.yml文件。也就是说,在开发环境时,只需将application.yml配置文件配置为"dev",而生产环境时,只需将“dev”改为“prod”就可以了。
5月22
通过IDE创建一个springboot项目

<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>//这行红色
</plugin>

提示spring-boot-maven-plugin not found。在网上找了有说是通过添加<pluginRepositories>过解决,但是测试之后发觉不起作用。 经过多次尝试,最终spring-boot-maven-plugin指定版本后成功解决。 修改后的pom.xml文件

<plugin>  
<groupId>org.springframework.boot</groupId>  
<artifactId>spring-boot-maven-plugin</artifactId>  
<version>2.1.3.RELEASE</version>
</plugin>

其实说白了就是没有加上这些Maven插件的版本号,导致Maven无法自动下载插件到本地,基本上提示这个not found的错误都是这个问题引起的。

maven-surefire-plugin、maven-compiler-plugin
这些插件也会出现这种问题,解决方案同上。只要你本地有下这些插件,不管哪个版本,就不会提示这个错误,去掉版本号也无所谓。
5月22
一般情况下我们springboot用Application的main方法启动 ,怎么配置成tomcat启动呢?
首先有几个步骤:

1、<packaging>jar</packaging> 改为=> <packaging>war</packaging>

2、  排除springboot内置和tomcat容器(注:这一步可选)      
      
       <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <!-- 移除嵌入式tomcat插件--> 
            <exclusions>
                <exclusion>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-starter-tomcat</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <!-- 移除内嵌Tomcat需要重新添加servlet -->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>${servlet.version}</version>
            <scope>provided</scope>
        </dependency>

3、修改启动类,并重写初始化方法
我们平常用main方法启动的方式,都有一个App的启动类,代码如下:

@SpringBootApplication
public class Application {
public static void main(String[] args) {
  SpringApplication.run(Application.class, args);
}
}
5月19
cnpm : 无法加载文件 C:\Users\hecks\AppData\Roaming\npm\cnpm.ps1,因为在此系统上禁止运行脚本。
点击在新窗口中浏览此图片
win10搜索找到 powershell
点击在新窗口中浏览此图片
右键以管理员身份运行,

然后输入
set-ExecutionPolicy RemoteSigned

选择 A

再输入 get-ExecutionPolicy就可以了。
点击在新窗口中浏览此图片
4月21
首先我们来看看95后的生活和成长环境,这一代人很多是母亲做全职家庭主妇,每天接送孩子上学放学,陪伴写作业,吃饭请过来,水果送到面前。各种兴趣班,高强度补课,95后已经厌倦了学习。工作后家里给配车,几乎一线城市的父母都有房产留给他们,只要他们的工资能养活自己不用家里补贴就行了。

以上分析虽然不能代表所有95后家庭,但是绝大多数城市的孩子都在类似环境中成长的。

雇佣95后员工面临的问题是什么?

在95后的家庭中,父母充当了保姆和秘书的工作,长期在这种环境中生活,有些能力被扼杀了,有些95后进入社会后,可能意识到这些问题,并主动去改变自己,更多的人可能一辈子无法改变,这种情况从90后身上可能看到。一旦进入公司,就离开了“保姆和秘书”的舒适区,需要很长时间去适应,这与80后是放养的一代人,野蛮生长,经过优胜略汰(社会达尔文主义),最后胜出的人完全不同。

95后员工缺少什么:
自驱能力
主动能力
思考能力
创新能力
自学能力

工作中你会发现,95后员工几乎绝大多数都存在上面列出的问题。
4月3
nginx的upstream目前支持的5种方式的分配

1、轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。 
upstream backserver { 
server 192.168.0.14; 
server 192.168.0.15; 


2、指定权重
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。 
upstream backserver { 
server 192.168.0.14 weight=8; 
server 192.168.0.15 weight=10; 


3、IP绑定 ip_hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。 
upstream backserver { 
ip_hash; 
server 192.168.0.14:88; 
server 192.168.0.15:80; 


4、fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。 
upstream backserver { 
server server1; 
server server2; 
fair; 


5、url_hash(第三方)
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。 
upstream backserver { 
server squid1:3128; 
server squid2:3128; 
hash $request_uri; 
hash_method crc32; 


4月3
1、水平切分:
通俗的来讲
例:QQ的用户表。假设QQ的用户有100亿,如果只有一张表,每个用户登录的时候数据库都要从这100亿中查找,会很慢很慢。如果将这一张表分成100份,每张表有1亿条,就小了很多,比如qq_user_0,qq_user_1,qq_user_2...qq_user_99表。

用户登录的时候,可以将用户的id%100,那么会得到0-99的数,查询表的时候,将表名qq跟取模的数连接起来,就构建了表名。比如123456789用户,取模的89,那么就到qq_user_89表查询,查询的时间将会大大缩短。

这就是水平切分。

2、垂直切分:

垂直切分指的是:表的记录并不多,但是字段却很长,表占用空间很大,检索表的时候需要执行大量的IO,严重降低了性能。这时需要把大的字段拆分到另一个表,并且该表与原表是一对一的关系。

例如学生答题表tt:有如下字段:

Id name 分数 题目 回答

其中题目和回答是比较大的字段,id name 分数比较小。

如果我们只想查询id为8的学生的分数:select 分数 from tt where id = 8;虽然知识查询分数,但是题目和回答这两个大字段也是要被扫描的,很消耗性能。但是我们只关心分数,并不想查询题目和回答。这就可以使用垂直分割。我们可以把题目单独放到一张表中,通过id与tt表建立一对一的关系,同样将回答单独放到一张表中。这样我们插叙tt中的分数的时候就不会扫描题目和回答了。

3、其他要点:

1)存放图片、文件等大文件用文件系统存储。数据库只存储路径,图片和文件存放在文件系统,甚至单独存放在一台服务器(图床)。

2)数据参数配置。

最重要的参数就是内存,我们主要用的innodb引擎,所以下面两个参数调的很大:

innodb_additional_mem_pool_size=64M

innodb_buffer_pool_size=1G

对于MyISAM,需要调整key_buffer_size,当然调整参数还是要看状态,用show status语句可以看到当前状态,以决定该调整哪些参数。
3月25

分布式事务解决方案

20:34编程杂谈  From: 本站原创
分布式事务了解吗?你们是如何解决分布式事务问题的?
一般来说,分布式事务的实现主要有以下 5 种方案:

XA 方案
TCC 方案
本地消息表
可靠消息最终一致性方案
最大努力通知方案

两阶段提交方案/XA方案
所谓的 XA 方案,即:两阶段提交,有一个事务管理器的概念,负责协调多个数据库(资源管理器)的事务,事务管理器先问问各个数据库你准备好了吗?如果每个数据库都回复 ok,那么就正式提交事务,在各个数据库上执行操作;如果任何其中一个数据库回答不 ok,那么就回滚事务。

这种分布式事务方案,比较适合单块应用里,跨多个库的分布式事务,而且因为严重依赖于数据库层面来搞定复杂的事务,效率很低,绝对不适合高并发的场景。如果要玩儿,那么基于 Spring + JTA 就可以搞定,自己随便搜个 demo 看看就知道了。

这个方案,我们很少用,一般来说某个系统内部如果出现跨多个库的这么一个操作,是不合规的。我可以给大家介绍一下, 现在微服务,一个大的系统分成几十个甚至几百个服务。一般来说,我们的规定和规范,是要求每个服务只能操作自己对应的一个数据库。

如果你要操作别的服务对应的库,不允许直连别的服务的库,违反微服务架构的规范,你随便交叉胡乱访问,几百个服务的话,全体乱套,这样的一套服务是没法管理的,没法治理的,可能会出现数据被别人改错,自己的库被别人写挂等情况。

如果你要操作别人的服务的库,你必须是通过调用别的服务的接口来实现,绝对不允许交叉访问别人的数据库。


TCC 方案
TCC 的全称是:Try、Confirm、Cancel。

Try 阶段:这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留。
Confirm 阶段:这个阶段说的是在各个服务中执行实际的操作。
Cancel 阶段:如果任何一个服务的业务方法执行出错,那么这里就需要进行补偿,就是执行已经执行成功的业务逻辑的回滚操作。(把那些执行成功的回滚)
这种方案说实话几乎很少人使用,我们用的也比较少,但是也有使用的场景。因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿了,会造成补偿代码巨大,非常之恶心。

比如说我们,一般来说跟钱相关的,跟钱打交道的,支付、交易相关的场景,我们会用 TCC,严格保证分布式事务要么全部成功,要么全部自动回滚,严格保证资金的正确性,保证在资金上不会出现问题。

而且最好是你的各个业务执行的时间都比较短。

但是说实话,一般尽量别这么搞,自己手写回滚逻辑,或者是补偿逻辑,实在太恶心了,那个业务代码很难维护。


本地消息表
本地消息表其实是国外的 ebay 搞出来的这么一套思想。

这个大概意思是这样的:

A 系统在自己本地一个事务里操作同时,插入一条数据到消息表;
接着 A 系统将这个消息发送到 MQ 中去;
B 系统接收到消息之后,在一个事务里,往自己本地消息表里插入一条数据,同时执行其他的业务操作,如果这个消息已经被处理过了,那么此时这个事务会回滚,这样保证不会重复处理消息;
B 系统执行成功之后,就会更新自己本地消息表的状态以及 A 系统消息表的状态;
如果 B 系统处理失败了,那么就不会更新消息表状态,那么此时 A 系统会定时扫描自己的消息表,如果有未处理的消息,会再次发送到 MQ 中去,让 B 再次处理;
这个方案保证了最终一致性,哪怕 B 事务失败了,但是 A 会不断重发消息,直到 B 那边成功为止。
这个方案说实话最大的问题就在于严重依赖于数据库的消息表来管理事务啥的,会导致如果是高并发场景咋办呢?咋扩展呢?所以一般确实很少用。
1月7
今天使用RequestBody接受前端传过来的参数,以前接受字符串数组非常成功,这次把形参改成了List,原本以为顺利接受参数并映射成User的list结构,结果竟然在我取user.getId()时报了com.alibaba.fastjson.JSONObject cannot be cast to xxx的错。

后端:
@RequestMapping("/insertUser")
public void insertBlank(@RequestBody List userList) {
     User user = userList.get(0);
     System.out.println(user.getId());
}


我的user对象没有转换成功,还是一个一个JSONObject,但是请观察,JSONArray转换成了ArrayList。

  嗯,配置的映射转换器生效了,结果表明,RequestBody能直接将json对象映射成java对象,但仅限于第一层的对象,至于嵌套的对象,则需要开发者自己去转换。

@RequestMapping("/insertUser")
public void insertUser(@RequestBody List list) {
    List userList = list.stream().map(json -> JSONObject.toJavaObject(json, User.class)).collect(Collectors.toList());
   service.insertUser(userList);
}
12月30
在弹出窗口里刚开始不管点击什么都无法显示,后来点击表情的时候发现表情的选项框出现在了当前dialog的后面
然后猜测所有的选项框点击后,都出现在dialog的后面。
接着开始F12,发现当前dialog的z-index的值是1005。
返回看ueditor的z-index。

在ueditor.config.js里zIndex的默认值是900;将值改为1100
强行刷新页面,或者打开ueditor.config.js强刷,然就成功!
分页: 1/50 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]