巧用 Base62 解决字段太短的问题

最近银联一纸 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生成的序号:

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 二进制的代码示例如下:

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 解决。

比如,我们现在常用的短网址服务,随便生成一个短网址。

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 可以容纳的数字:

$$
10^4-1=9999
$$

而 Base62 可以容纳

$$
62^4-1=14776335
$$

而当 ID 长度到达 5 位的时候,Base10 可以容纳:

$$
10^5-1=99999
$$

而 Base 62 可以有:

$$
62^5-1=916132831
$$

通过对比我们可以发现,Base62 可以容纳数字远远超过 Base10,并且根本不是一个量级的。

另外假设 5 位长度 Base62 用完了,只要加上一位,又可以容纳 62 倍数字,几乎很难再用完。

说完优点,我们再来聊聊 Base62 的缺点,不容易记忆。

B 站以前还是 AV 号的时候,采用的是 Base10 ,这个非常容易记忆。

比如 B 站镇站之宝:av170001

以前我们可以通过弹幕直接发送 AV 号,感兴趣就可以直接输入跳转到那条视频。

但是现在 10 位 BV 号,几乎难以记忆,在弹幕中输入 BV 号都很困难。

哎,少了当初的快乐的。

posted @ 2022-01-23 16:02  楼下小黑哥  阅读(3966)  评论(11编辑  收藏  举报