@kayseen 这个 base62 可以被反解，你的业务是需要能被反解还是不能被反解的？这套方案主要解决了分布式发唯一号的坑，不过可以反推原来序号这个问题可能还需要额外解决，因为 base62 出来之后不是个随机数，其实应该说是 62 进制的顺序增长的数比较合适

@kayseen 我的思路就是你只要能够保证分发的数字（ deci ）唯一，就能保证 base62 没有冲突，分发唯一这个靠 ZK 和本地库的自增使用来保证，或者自己想思路也可以

@kayseen 不好意思 排版有点问题，下面这个 demo 可以直接运行
https://pastebin.com/zSDjvULE

@kayseen
```
def base62_encode(deci):
s = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
hash_str = ''
while deci > 0:
hash_str = s[deci % 62] + hash_str
deci /= 62
return hash_str

if __name__ == '__main__':
num = 12837912839128347316
print(base62_encode(num))
```

https://blog.2014bduck.com/archives/241
https://blog.2014bduck.com/archives/250
同分享

@PanJiaChen 2333 我也不知道他讲的是啥 orz 尼克杨.jpg

@royzxq 谢谢 发了 不过活动什么就算了 留给其他人参与吧～

另外特别感谢 @PanJiaChen 大佬的内推，整个等待过程都不断被我骚扰进度 Orz 继续努力～再接再厉～

帮忙顶一下帖子，楼主 wx 解答问题很耐心～

@yoyos base62 方案号段会影响输出的长度，如果你要做成一次性分配完的话不方便在固定长度短链（也就是业务要求的 7 位）下水平扩容，而且复杂度并没有降低，还是要实现扩容发号那一套东西。。。

@mrlmh00 嗯看到确实是这样，但是这个问题还是非常好解决，只需要想办法将 base62 生成的信息按照特定规则编码出来增加破解难度就可以了？至于其他的生成方案，主楼已经讲过为什么不打算使用了。

当然如果有所谓的''完美''方案，也欢迎提出来交流学习～

@daquandiao2 hhhh 是的特地注册的～ me 后缀还不让备案

@mengzhuo 随机数和 mac 地址做异或，如何保证唯一性能解释下吗，个人认为这种生成器里面出现随机数的话思路就已经错掉了。。。不同 mac 地址+随机数可以保证不发生冲突吗？

@levelworm 虽然听起来可行，首先你的中心节点 /或者说生成器需要做成单实例的，因为不能多个实例同时生成，否则就会有冲突，其次中心节点分发生成后的 ID，也就是一段字符串，会有额外的流量开销（比如分发 1000w 个长度为 7 的字符串），不管大还是小，肯定是不如按号段分发计数器（只需要传输[0, 10000000]这样的范围数据），单点的服务再生成 ID 的

@sdjl show full processlist 只能查看当前用户的 process，并不是全部 mysql 连接

@jason0916 这个不是业务需求，是系统设计的一些学习和思考笔记吧（自嗨行为 hhh ），不过问题多一点的话可以多了解一些知识也是很好的。

在我看来因为查询的时候如果按照 unique_id 查询，如果改用 mysql 存储的话，因为数据总量会比较大可能我会考虑按时间分表，这时候 Unique_id 的设计可能会从纯 base62 改为时间前缀标识+base62 来做，切分单表或者库的数据量，也是一种方案。

整个系统都是假设的，需求也是假设的，不过讨论可以学习到东西，thx

@jason0916 zk 分段是 1 的形式，app 崩溃确实会导致分段浪费，可以看 app 内是否能解决这个问题，例如现在 app 持有某个分段，服务重启后看是否能继续使用；另外也可以优化分段区间，减少浪费的区间长度，具体两个都是业务方案的实现

使用 redis 集群来存储长短链映射关系主要是考虑性能和 Cluster 易于横向扩展，Cluster 的模型主节点如果失效，会切换至从节点（当然抖动是不可避免的），可以一定程度降低风险，但是确实会有丢失写入，以及持久化 buffer 未写进磁盘的问题，这个再想一想好了，没有覆盖到这个问题

如果直接用例如 MySql 这类，性能上可能会需要更大的成本来满足？不同方案各有优劣，可以看业务来定，谢谢建议，很有帮助

@jason0916 我的理解是因为设想里面 ZK 是负责号码段的分发，按照预定的请求（如 1000/秒）只要业务上将号码段划分得合理，App （也就是生成短链的服务）实际上并不需要特别频繁地向 ZK 索取新号段，得到的号段是由 App 自行管理的（比如丢在 Redis 持续自增到>上限再进行获取）。

假如我划分的号段，每段长度是 10w，按照请求速度预计可以支撑后续的 100 秒内的 ID 生成，如果我的 App 服务一共部署了 20 个，也就是 100 秒内大约只会有 20 次 App 向 ZK 索取号段的请求，这样是否可以忽略 ZK 的问题？

ZK 这块新学，还有很多不懂望多指教