以优雅之姿，重塑长链——「快缩短网址」suo.run 的 Java 实践札记

一、序章
当一条冗长的 URL 在指尖翻滚，仿佛一段被拉长的旋律，失却了节奏。我们只需为其谱上简洁的音符，便可让其在任何屏幕、任何纸张上轻盈起舞。这便是「快缩短网址」suo.run 的初心：以最短的路径，抵达最长的想象。

二、两种古典写法的回眸
1. 随机六弦琴
早期工匠偏爱随机拨弦：从 62 根琴弦中任意挑取 6 次，拼成一段即兴旋律。
缺陷亦如其名——长度固定，扩容即重构；且旋律与原始 URL 毫无血缘，只能靠 Redis 这位书记员默默维系。



2. 自增的咏叹调
让数字自 0 起，步步为营，再化为 62 进制舞步。长度随数据量自然生长，代码无需返工。
然其仍为“无根之歌”，旋律与长链仍需旁注。

三、雪花算法的交响
当流量汹涌，单机自增便显单薄。Twitter Snowflake 以 64 位指挥棒，将毫秒级时间、数据中心、机器节点、毫秒内序列号编织成唯一节拍。
· 1 位符号，永为 0；
· 41 位时光，可咏 69 载；
· 5 位机房，32 座；
· 5 位节点，每房 32 台；
· 12 位序列，毫秒 4096 步。



将此 Long 化作 62 进制短码，如「7TDp0rS917i」，既无碰撞，亦无须记忆。

四、架构之舞
1. 发号器集群
32 台逻辑发号器并行，尾号 0–31 各守其序，互不干扰。
2. 存储
MongoDB 以雪花 ID 为片键，天然有序；Redis 缓存热点映射，毫秒级回源。
3. 跳转
301 永久，减轻后端；302 临时，洞悉点击。权衡之下，suo.run 默认 302，数据洞察胜于微末性能。
4. 二维码
Google ZXing 将短链化作方寸黑白，扫码即达。
5. 性能
JMH 实测：单机 QPS 4000+，HTTP 端到端 2000+，瓶颈在序列化与网络往返，非算法本身。

五、代码一瞥（精炼版）

// Snowflake 发号器

public final class Snowflake {

    private final long datacenterId = 1L;

    private final long workerId    = 1L;

    private final IdWorker idWorker = new IdWorker(workerId, datacenterId);



public String next() {

        long id = idWorker.nextId();

        return Base62.encode(id);   // 7TDp0rS917i

    }

}



// Base62 编码

public class Base62 {

    private static final char[] DIGITS =

        "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".toCharArray();

    public static String encode(long num) {

        if (num == 0) return "0";

        StringBuilder sb = new StringBuilder();

        while (num > 0) {

            sb.append(DIGITS[(int)(num % 62)]);

            num /= 62;

        }

        return sb.reverse().toString();

    }

}