最近银联一纸 259 号改造通知,所有支付机构开始改造支付交易,上传终端信息。
不知道其他支付机构的小伙伴针对这次改造是否开始了?
由于这次银联给的时间非常少,我们这边改动涉及到相关上游一起改造,所以我们已经开始设计,马上投入代码改造中。
这次改造,支付机构内部需要维护交易发生的终端信息。在银联的改造文档中,支付机构内部需要为每一台终端分配一个唯一的终端设备号。
银联侧规定这个字段是 String(8),可以使用英文字母以及数字,即 a-z/A-Z/0-9。
由于我们内部发号器,只能产生纯数字的序号,按照 8 位长度,从 0 开始最多只能有 99,999,999 。
当前看来没什么问题,但是千万级数字还是太小,一不小心就没了。为了后续系统的稳定性,所以我们需要设计一种满足银联的规则终端号生成方法。
发号器现状
先来介绍先,我们这边的发号器现状,应该跟很多公司做法都比较类似。
我们这边发号器,有两种生成策略:
- simple
- snowflake
第一种策略simple 类型,这种策略方式非常简单,类似 MySQL ID 自增策略,可以指定从某个数字开始递增。
这种方适用于表ID 等场景,只需要保证唯一,不需要保证顺序。
第二种策略 snowflake 类型,即使用雪花算法。
这种方式适用于订单ID 等需要保留时间信息的场景。
这两种发号器都存在一定的问题,没办法直接适用于银联终端号的场景。
simple 类型发号器问题
这个类型发号器只能发纯数字的序号,按照 8 位长度,从 0 开始最多只能有 99,999,999 。
由于发号器虽然是单调递增的,但是可能存在机房配置,存在跳号的情况,这就导致可能可以用的序号少于 99,999,999 。
所以不能拿来直接使用。
snowflake 类型发号器的问题
snowflake 类型发号器的发出来的序号是 64 bit,格式如下:
这里就不解释 snowflake 策略具体的原理,举一个 snowflake生成的序号:
代码语言:javascript复制170916032679263329
可以看到 snowflake 发号器生成这个 64 bit 整数非常大,位数也远远大于 8 位。
设备号生成方法
上面说到设备号生成规则是允许英文字母,即 a-z/A-Z/0-9。
如果我们仅仅使用数字,那么我们仅仅只有 10^8-1= 99,999,999。
那我们转换一种思路,我们把英文字母也用,那么我们总共可以有62^8-1=218,340,105,584,895
可以看到这个数字已经很大,未来很长一段时间都不可能超过(除非后续开展银地球外的服务)。
那怎么生成一个带有英文字母的序号呢?难道需要重写一个发号器吗?
其实我转换一下思路,设备号规则可以使用a-z/A-Z/0-9,设备号每一位都有 62 个选择,那站在数学的角度,这不就是 62 进制的吗?
那现在我们使用发号器生成的序号只能是整数,那站在数学角度,是一个十进制的数。
那我们只要把这个10 进制数转成 62 进制数,这不就可以解决问题了吗!
所以这里我们使用 simple 类型的发号器,从 0 开始递增。
拿到发号器生成的序号之后,我们只需要将其转为 62 进制就可以了。
10 进制转 62 二进制的代码示例如下:
代码语言:javascript复制public class TermInfoUtils {
/**
* https://en.wikipedia.org/wiki/Base62#/
* wiki 上的标准
*/
private final static char[] charArray = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".toCharArray();
private static final int BASE_62_SCALE = 62;
/**
* base10 转 base 62
*
* @param base10
* @return
*/
public static String fromBase10ToBase62(long base10) {
int scale = 62;
StringBuilder sb = new StringBuilder();
long remainder = 0;
do {
remainder = base10 % scale;
sb.append(charArray[(int) remainder]);
base10 = base10 / scale;
}
while (base10 > scale - 1);
sb.append(charArray[(int) base10]);
// 倒序
return sb.reverse().toString();
}
/**
* 产生银联终端号
* @param base10
* @return
*/
public static String generateUnionDeviceId(long base10) {
String base62 = fromBase10ToBase62(base10);
// 往左补 0
return StringUtils.leftPad(base62,8,"0");
}
}
代码原理非常简单,类似 10 进制转二进制,除二取余,然后倒序排列,高位补零。转62进制也类似,不断除以62取余数,然后倒序。
最后,为了我们生成的序号长度统一,我们定一个规则,如果生成的 62 进制小于 8 位,那左边补 0 ,直到整个长度为 8 位。
## Base62 其他妙用
除了上面这个应用之外,其实现实也有很多应用也是使用 Base62 解决。
比如,我们现在常用的短网址服务,随便生成一个短网址。
代码语言:javascript复制https://tinyurl.com/y8jvg3eb
我们可以看到短网址最后都有一串字符串,那其实就是 Base62。
ps:有些短网址采用的是 Base64,即 a-z/A-Z/0-9/_- ,但是原理类似。
再比如,B 站现在使用的 BV 号,其实也是 Base62 的应用。
ps:按照网上说法,BV 号实际上是 Base58,去除用数字"0",字母大写"O",字母大写"I",和字母小写"l",以及" "和"/"符号。
那实际上,上面这两种方式都是将 Base62 当做一个唯一 ID。这种方式有一个非常明显的优点,可以用一个只有几位长度字符串,容纳超多超多的 ID。
我们对比一下,通常使用纯数字形式 ID,即 Base10与 Base62 。
当 ID 长度为 4 位的时候,Base10 可以容纳的数字:
而 Base62 可以容纳62^4-1=14776335
而当 ID 长度到达 5 位的时候,Base10 可以容纳:
而 Base 62 可以有:
通过对比我们可以发现,Base62 可以容纳数字远远超过 Base10,并且根本不是一个量级的。
另外假设 5 位长度 Base62 用完了,只要加上一位,又可以容纳 62 倍数字,几乎很难再用完。
说完优点,我们再来聊聊 Base62 的缺点,不容易记忆。
B 站以前还是 AV 号的时候,采用的是 Base10 ,这个非常容易记忆。
比如 B 站镇站之宝:av170001
以前我们可以通过弹幕直接发送 AV 号,感兴趣就可以直接输入跳转到那条视频。
但是现在 10 位 BV 号,几乎难以记忆,在弹幕中输入 BV 号都很困难。
哎,少了当初的快乐的。