HiSEN

Personal Technology Blog

0%

Posted on Edited on In Symbols count in article: 3.9k Reading time ≈ 4 mins.

一、背景

今天中午一个朋友问我一个问题没来得及回，现在折腾一下;
问题：有一个包含以N个空格分割的字符串，求最大子串的长度，要求时间空间复杂度最优;

二、方案：

  1. 朋友给人方案：直接split分割遍历数组，找出最大值;
  2. 面试官的方案：使用StringTokenizer，找出最大值;
  3. 我想到的方案：indexOf计算index差值，找出最大值;

三、结果：

封装的代码比较复杂，目前来看不在么好分析时间复杂度和空间复杂度；
于是就直观得对比了一下时间；

1
2
3
4
//        output
//        use(nano): 15486049, by 方案3
//        use(nano): 66060102, by 方案2
//        use(nano): 80844275, by 方案1

有时间再深入了解下StringTokenizer的源码

四、代码对比

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
String oriStr = "aa aa aaaa aaa a a a aa aa a";
int times = 100000;
// 自定义实现
final long start1 = System.nanoTime();
for (int i = 0; i < times; i++) {
    String splitStr = " ";
    findMaxLength(oriStr, splitStr);
}
final long end1 = System.nanoTime();

// 利用 StringTokenizer
final long start2 = System.nanoTime();
for (int i = 0; i < times; i++) {
    findMaxLength4StringTokenizer(oriStr);
}
final long end2 = System.nanoTime();

// 利用 Split
final long start3 = System.nanoTime();
for (int i = 0; i < times; i++) {
    String splitStr = " ";
    findMaxLength4Split(oriStr, splitStr);
}
final long end3 = System.nanoTime();

System.out.println("use(nano): " + (end1 - start1) + ", by findMaxLength");
System.out.println("use(nano): " + (end2 - start2) + ", by findMaxLength4StringTokenizer");
System.out.println("use(nano): " + (end3 - start3) + ", by findMaxLength4Split");
//        output
//        use(nano): 15486049, by findMaxLength
//        use(nano): 66060102, by findMaxLength4StringTokenizer
//        use(nano): 80844275, by findMaxLength4Split

五、完整代码

Read more »

Posted on Edited on In Symbols count in article: 424 Reading time ≈ 1 mins.

一、为什么要学Dubbo

近几年一直在使用dubbo进行支付系统的开发;
作为国内比较受欢迎的一个SOA框架，Dubbo使用简单设计优雅;
里面用到的思想和技术，基本上涵盖大部分互联网公司用到的技术;
记得直属领导说过一句话，看完Dubbo他觉得设计者简直就是天才;
而且看完dubbo的源码，对他的影响很大，处处模仿dubbo的思想;

二、文档地址

中文文档：用户文档、开发者指南、源码导读、运维管理
http://dubbo.apache.org/zh-cn/docs/user/quick-start.html
用户手册(比较完整)：
https://dubbo.gitbooks.io/dubbo-user-book/demos/routing-rule.html
官方博客：
http://dubbo.apache.org/zh-cn/blog/index.html

三、Dubbo创始人博客

最后更新于2014年
https://Javatar.iteye.com/

Posted on Edited on In Symbols count in article: 3.3k Reading time ≈ 3 mins.

一、权重算法

权重算法一般在路由里面用的比较多，分布式环境下对等的服务有多个，加权随机选出一个服务来调用；

可能还有其他方面的用途，下面的代码简单的实现了这个权重，本质上就用到了数组，随机下标；

二、代码概览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public static void main(String[] args) {
    String[] weight = {"A", "A", "A", "A", "A", "B", "B", "B", "C", "C"};
    final int times = 500000;
    final long hashStart = System.currentTimeMillis();
    List<String> hashRes = getList4Hash(weight, times);
    printRes("Hash", hashStart, hashRes);

    final long randomStart = System.currentTimeMillis();
    List<String> randomRes = getList4Random(weight, times);
    printRes("Random", randomStart, randomRes);
//        Hash          use millis: 931
//        A:49.92%
//        B:29.99%
//        C:20.09%
//        Random        use millis: 50
//        A:50.08%
//        B:29.93%
//        C:19.99%
}

三、完整代码

Read more »

Posted on Edited on In Symbols count in article: 376 Reading time ≈ 1 mins.

一、初衷

有时候上线会出现合错代码，比如功能，或者maven的pom文件；

人都不是十全十美的人，只要是人就会犯错
关键是要想办法去避免，只有工具才不犯错

所以尽量想办法利用工具来防止我们犯错，git来说有很多办法；
简单的命令，或者gitlab的compare报告；
每次上线之前，开发自己看一遍当前版本与线上版本的区别，确认每一个点都是正确的改动；

二、gitlab compare功能(推荐)

2.1 入口：工程首页 -> Repository -> Compare
2.2 选择：上一个版本，当前版本，点击Compare
2.2 结果：一次能看到两个版本的所有commit、改动点

三、git命令

1
2
3
4
5
# 显示版本之间改动的文件名
git difftool master 1.2.4 --stat

# 在命令行挨个显示版本某个文件具体差异
git difftool master 1.2.4

Posted on Edited on In Symbols count in article: 368 Reading time ≈ 1 mins.

一、报错信息

1
com.alibaba.dubbo.remoting.transport.ExceedPayloadLimitException: Data length too large: 14277263, max payload: 8388608, channel: NettyChannel [channel=[id: 0x12a13c8f, /172.0.0.1:49402 => /172.0.0.2:23888]]

二、报错原因

dubbo默认使用Netty传输协议
并且默认的大小限制为：默认为8M，即8388608

三、解决办法

  1. 修改接口
    出现这种情况是因为一个接口查某个表的所有数据(几万条)
    一般这种接口肯定是需要分页的

  2. 更改配置信息
    在dubbo.properties 中增加如下

1
dubbo.protocol.dubbo.payload=11557050

Posted on Edited on In Symbols count in article: 347 Reading time ≈ 1 mins.

maven项目昨天遇到的一个错误：Java.lang.NoClassDefFoundError

理论原因：JVM在编译的时候能找到调用方法或静态变量所在的类，但在运行的时候找不到此类而引发的错误。

真实原因：(仅针对当前问题)
项目A依赖公共服务C-1.0.1版本
项目B依赖项目A，B中dependencyManagement强制指定C-1.0.0

此时编译可以通过，运行时如果有用的C的新版本功能就会会出现上述问题

解决办法：对项目B中C的版本升级，使用1.0.1

扩展阅读：
https://blog.csdn.net/qq_27576335/article/details/77102385
https://blog.csdn.net/jamesjxin/article/details/46606307

Posted on Edited on In Symbols count in article: 652 Reading time ≈ 1 mins.

CONCAT:连接字符串,CONCAT(55.00,’%’)->55.00%
truncate:处理小数点位数,truncate(10.1111,2)->10.11

统计sql

1
2
3
4
5
6
7
8
9
10
11
select res.*, CONCAT(truncate((res.succ / res.`all`) * 100, 2), '%') as 'success rate'
from (select tpc.USER_NO,
             tpc.TYPE,
             count(*)                                                            as 'all',
             sum(case when tpc.STATUS = 0 then 1 else 0 end)                     as 'succ',
             sum(case when tpc.STATUS = 1 then 1 else 0 end)                     as 'fail',
             sum(case when tpc.STATUS != 1 && tpc.STATUS != 0 then 1 else 0 end) as 'other'
      from t_hisen tpc
      where tpc.DATE between '20190216' and '20190217'
      group by tpc.USER_NO, tpc.TYPE
      order by tpc.USER_NO) res

统计结果

USER_NOTYPEallsuccfailothersuccess rate
4561010010.00%
1231029230679.31%

Posted on Edited on In Symbols count in article: 413 Reading time ≈ 1 mins.

一、问题

1
com.mysql.jdbc.MysqlDataTruncation: Data truncation: Incorrect datetime value: '2039-01-07 12:58:20.625' for column

二、原因

由于程序没有控制好，计算下一次更新时间失误，造成数值过大。

1
2
3
update table_a
SET UPDATE_TIME = '2039-01-07 12:58:20.625'
WHERE ID = 6241

以下是MySQL官方的说法，就是时间超过了范围。

1
2
The TIMESTAMP data type is used for values that contain both date and time parts.
TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC.

Posted on Edited on In Symbols count in article: 2.3k Reading time ≈ 2 mins.

一、背景介绍

想用docker搭建一个lnmp环境

使用这个脚本：

1
https://github.com/buxiaomo/docker-compose/tree/master/lnmp

执行命令之后报错

1
2
3
4
5
6
7
8
9
10
11
12
13
docker-compose -f lnmp.yml up -d
WARNING: Some services (mysql, nginx, php, redis) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.
WARNING: Some services (mysql, nginx, php) use the 'configs' key, which will be ignored. Compose does not support 'configs' configuration - use `docker stack deploy` to deploy to a swarm.
lnmp_mysql_1 is up-to-date
Starting lnmp_redis_1 ...
lnmp_nginx_1 is up-to-date
Starting lnmp_redis_1 ... error

ERROR: for lnmp_redis_1  Cannot start service redis: b'Mounts denied: \r\nThe path /usr/share/zoneinfo/Asia/Shanghai\r\nis not shared from OS X and is not known to Docker.\r\nYou can configure shared paths from Docker -> Preferences... -> File Sharing.\r\nSee https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.\r\n.'

                    memory: 100M
ERROR: for redis  Cannot start service redis: b'Mounts denied: \r\nThe path /usr/share/zoneinfo/Asia/Shanghai\r\nis not shared from OS X and is not known to Docker.\r\nYou can configure shared paths from Docker -> Preferences... -> File Sharing.\r\nSee https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.\r\n.'
ERROR: Encountered errors while bringing up the project.

二、报错原因

  1. mac机器的时间路径与linux不一样
  2. lnmp.yml redis用到了这个时间

三、解决办法

  1. 查看当前机器时间文件真实位置(/etc/localtime 这个路径是不让共享给docker的)
1
2
ls -la /etc/localtime
lrwxr-xr-x  1 root  wheel  39 10 19 11:13 /etc/localtime -> /var/db/timezone/zoneinfo/Asia/Shanghai
  1. 设置位置 ：Docker -> Preferences… -> File Sharing
  2. 新增共享目录：/var/db/timezone
  3. apply & restart
  4. 修改lnmp.yml配置文件 全局替换：/usr/share/zoneinfo/Asia/Shanghai 为：/var/db/timezone/zoneinfo/Asia/Shanghai

四、成功信息

1
2
3
4
5
6
7
8
docker-compose -f lnmp.yml up -d
WARNING: Some services (mysql, nginx, php, redis) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.
WARNING: Some services (mysql, nginx, php) use the 'configs' key, which will be ignored. Compose does not support 'configs' configuration - use `docker stack deploy` to deploy to a swarm.
Removing lnmp_redis_1
Starting lnmp_nginx_1                ... done
Starting lnmp_mysql_1                ... done
Recreating f5b9db566588_lnmp_redis_1 ... done
Starting lnmp_php_1                  ... done

Posted on Edited on In Symbols count in article: 1.2k Reading time ≈ 1 mins.

一、背景交代

  1. 部署方式：多点
  2. 业务概要：处理一批数据，可以失败重试

二、实现方式

  1. 主表入一条控制数据，两个控制字段：next，process(0:空闲,1:处理中)，子表具体处理业务
  2. 定时任务只扫描主表，通过其他业务字段，加上主表两个控制字段(now>netx,process=0)，捞出需要处理的数据
  3. 当开始处理数据时候，先更新process=1，如果更新成功，说明拿到锁(假装是一个分布式锁，因为两台机器)
  4. 如果拿到3的锁，则开始处理子表的业务数据，一次查100条(limit 0,100 desc update_time)，直到子表全部处理完成
  5. 如果遇到错误，把错误数据的id存起来，更新子表重试次数，和更新时间，如果达到最大失败次数，更改状态(让4查不出这条数据)
  6. 如果遇到当前处理数据的id存在List中，那么说明当前所有的数据都处理过一次了，退出(如果不判断，失败后会无限循环，直到全部成功)

三、伪代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public void process(MainTable mainTable) {

    // 1. 锁控制表
    boolean lock = service.lock(mainTable);
    LOGGER.info("lockFlag:,", lock, ",mainTableId:", mainTable.getId());
    if (!lockFlag) {
        return;
    }
    List<Long> repeatIds = new ArrayList<>();
    // 2. 根据主表id，下次扫描时间，每次查询100条
    List<SubTable> subTables;
    do {
      //扫描子表中的数据
        subTables = service.querySub(mainTable.getId(), 100);
        for (SubTable sub : subTables) {
            if (repeatIds.contains(batch.getId())) {
                subTables = null;
                break;
            }
            // 处理业务
            handle(mainTable, subTables, repeatIds);
        }
    } while (!CollectionUtils.isEmpty(subTables));

    // 5. 检查是否全部终态
    checkHandleDone(mainTable);
    // 7. 释放锁
    boolean unLock = service.unLock(mainTable);
    LOGGER.info("lockFlag:,", unLock, ",mainTableId:", mainTable.getId());
}