1. Mybatis官方ID生成策略的问题
我们知道,mybatis-plus官方提供了很多ID生成策略 官方地址  而其中个人觉得性能上最好的当属ASSIGN_ID,该策略能够得到一个19位的Long类型的值,Long类型的值天然有序,能很好的支持数据库的索引,所以我个人在工作中一般会把ID类型设置为bigint(mysql),然后在代码中使用这个策略。
那么这个策略有什么问题呢?生成的19位对于java long 类型来说没有任何问题,问题在于我们给前端返回的时候,前端js最长只能支持到17位的数值类型,后面两位会补0,也就是说,比如一条数据的ID为:133470684736716869,到前端看起来就会变成1334706847367100,这就导致后续的业务会报错。
2. 解决方案
现在你知道了问题的原因在于JS无法解析19位这么长的数值类型,那么有两种解决方案
- 不给前端返回数值类型,把数值类型转化为字符串类型
- 返回数值类型,但生成的时候不使用官方自带的生成器,自定义ID生成器(只适用于系统初建,没有历史数据的时候)
2.1 不给前端返回数值类型,把数值类型转化为字符串类型
这个方案在官方解决方案里面有:ID_WORKER 生成主键太长导致 js 精度丢失
2.2 自定义ID生成器
官方教程:自定义ID生成器 例子: 提供一个ID生成策略
@Component
public class CustomerIdGenerator implements IdentifierGenerator {
@Override
public Long nextId(Object entity) {
return IdGenerator.generateId();
}
}
IdGenerator是一个缩了位的雪花ID生成算法,生成的位数是16位,不会导致JS精度丢失
package com.yrt.framework.config;
import java.util.Date;
import java.util.UUID;
public class IdGenerator {
private static IdGenerator instance = new IdGenerator(0);
public static IdGenerator initDefaultInstance(int machineId) {
instance = new IdGenerator(machineId);
return instance;
}
public static IdGenerator getInstance() {
return instance;
}
public static long generateId() {
return instance.nextId();
}
private final static long MACHINE_BIT = 5;
private final static long SEQUENCE_BIT = 8;
private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);
private final static long MACHINE_LEFT = SEQUENCE_BIT;
private final static long TIMESTMP_LEFT = MACHINE_BIT + SEQUENCE_BIT;
private long machineId;
private long sequence = 0L;
private long lastStmp = -1L;
private IdGenerator(long machineId) {
if (machineId > MAX_MACHINE_NUM || machineId < 0) {
throw new IllegalArgumentException(
"machineId can't be greater than " + MAX_MACHINE_NUM + " or less than 0");
}
this.machineId = machineId;
}
public synchronized long nextId() {
long currStmp = getTimestamp();
if (currStmp < lastStmp) {
throw new RuntimeException("Clock moved backwards. Refusing to generate id");
}
if (currStmp == lastStmp) {
sequence = (sequence + 1) & MAX_SEQUENCE;
if (sequence == 0L) {
currStmp = getNextTimestamp();
}
} else {
sequence = 0L;
}
lastStmp = currStmp;
return currStmp << TIMESTMP_LEFT
| machineId << MACHINE_LEFT
| sequence;
}
private long getNextTimestamp() {
long mill = getTimestamp();
while (mill <= lastStmp) {
mill = getTimestamp();
}
return mill;
}
private long getTimestamp() {
return System.currentTimeMillis() / 10;
}
public static Date parseIdTimestamp(long id) {
return new Date((id >>> TIMESTMP_LEFT) * 10);
}
public static String uuid() {
return UUID.randomUUID().toString().replaceAll("-", "");
}
}
使用没有变化,还是用IdType.ASSIGN_ID
@TableId(value = "id", type = IdType.ASSIGN_ID)
private Long id;
这样就可以保证插入到数据库的ID是16位的,不会出现JS精度丢失的问题。
|