这是一个创建于 1280 天前的主题，其中的信息可能已经有所发展或是发生改变。
众所周知，微信用户在不同的公众号、小程序都有不同的 openid 。
假设有 10 亿个微信用户，一百万个微信公众号、小程序，那么就可能存在
10 亿 x 一百万 = 一千万亿个 openid，每个 openid 大约是 30 个字节，那么光是存储这些 openid，就需要 三千万亿字节。
问题来了：
一，这些 openid 是固定生成的，还是通过微信用户 ID 通过一定算法算出来的？ 二，如果是固定生成的，那么这么多 openid 如何做到高效存储、查询的？ 三，如果是通过算法算出来的，万一算法被破解了（或者秘钥泄露了），那么就永远泄露了，因为有大量第三方系统存储着这些 openid，是不太可能去全部更新的。
 |
1
daquandiao2 2021-06-26 18:20:32 +08:00
实际没那么多 一个用户才能关注几个公众号
|
 |
2
0o0O0o0O0o 2021-06-26 18:37:56 +08:00 via iPhone
一个用户好像最多关注 2000 个公众号
|
 |
3
laowai89 2021-06-26 18:39:23 +08:00 via iPhone
你就一个微信？你关注了几个公众号
|
 |
4
gwy15 2021-06-26 19:05:36 +08:00 via Android
稀疏
|
 |
5
qiayue 2021-06-26 19:05:47 +08:00
我猜是生成的，而且是可以反解的。
你有没有发现，同一个公众号下的不同关注者的 openid 前缀是一致的。 我猜，openid 分成前后两部分，前一部分可以解析出公众号唯一 id，后一部分可以解析出微信号唯一 id，甚至中间有一位是校验位，拿到一个 openid 先用校验位判断是否是合法的 openid 。 至于你说算法是否可能被破解，我觉得总有办法可以解决。 |
 |
7
zpf124 2021-06-26 19:45:13 +08:00
看起来楼主好像不是搞后端的啊，甚至好像不是搞技术的。
几个部分， 1 、你的固定生成和通过微信 id 算出来，实际想表达的是不是“生成 id 是否与与用户或其他业务数据相关？”。 答：无 与业务数据肯定是无关，因为没意义，但大概率与时间有关，给你两个 id，你可以知道这两个 id 哪个生成的更早，仅此而已。 这世界上有许许多多的随机数生成方法，包括算法层面的伪随机(一般常用)，和真正意义上的随机(利用硬件电荷，效率慢，非特殊情况没人用)。 现在常见的各种随机字符串生成方案大多数都是根据 推特公布的雪花 id 生成规则的思路制作的，估计微信很可能也不例外。 2 、和其他数据存数据库没什么差距，数据库 io 写入瓶颈了就升配置或者加机器，查询慢了加缓存。 3 、你知道了规则有什么用， 身份证规则百度就有，但你随便生成一个去银行或者公安局人家又不是查不出来。 而且这种随机 id 生成会给许多不同的地方用，第一个用在用户 1 关注公众号 a，第二个用在用户 1 使用小程序 b，你用 A 公众号知道了 openid 又怎样，你公众号的关联数据里又查不到。 |
|
8
zpf124 2021-06-26 20:00:49 +08:00
发出去之后我突然理解楼主的想法了....
楼主以为 openid 有个大列表， 就个网址短链接一样，一个 id 对应一个值，不论是啥数据都从这查。 然而实际上， 这种 id，生成的服务只管生成，生成的值有没有地方用到对这个服务都无所谓，也没有一个大列表记录每个 openid 对应啥。 我公众号需要用到一个 id， 那我就获取 /生成一个，存我这个表里， 他小程序要用到一个 id，那他就生成一个，存他那，支付用到了支付那边自己再存一个。 不用 openid 用数字自增这功能都不会出安全问题， 我公众号生成了 id=1， 他小程序生成 id=21，你在我这公众号里用 21 查能找到啥？ 即便我公众号的表里有个 id=2 的，你查的时候我又不是不判断这个 id 是不是你能看的。 |
 |
9
JohnH 2021-06-26 20:55:29 +08:00
小的关系系统可能存储起来更方便。
像微信这种体量，如果把 openid 存起来，我觉得不如有一个固定算法更划算。 一个 openid 维持了一个关系，通过算法来加密解密来计算出关系，在业务上就相当于用户位于应用的 token 。 |
 |
11
nvkou 2021-06-26 21:43:37 +08:00 via Android
@qiayue 若无需要，勿增实体。id 只是标识符，没有意义的。只要能验证张三，我就恒定给他发同一个 id 即可。id 本身是阿猫阿狗无所谓，如果本身还自带信息容易引起安全问题。我不记录你的密码原文，但我知道你有没有输错
|
 |
12
tianxia 2021-06-26 22:51:50 +08:00 via Android
固定生成的可能性大，如果是算法生产的，有办法反解的，那风险是巨大的
|
 |
13
pcbl 2021-06-26 22:54:54 +08:00 via Android
不得不说微信的这种设计还是挺好的，比 tg 的一个用户 id 全包了好很多
|
 |
14
Seanfuck 2021-06-27 00:11:07 +08:00
至少是拼起来的，前 6 位跟公众号关联，第 7 位没有数字，大小写一致；后面的看起来是随机生成的
|
 |
15
leokino 2021-06-27 06:29:41 +08:00
@nvkou 我思考了下，确实也有可能是可以还原的，但是从微信的角度来说没有必要，因为微信是在已知用户 id 的情况下提供给小程序。
其次，三千万亿字节听起来很多，但其实也不过 3000 TB，更何况，上亿用户使用的小程序，屈指可数，实际可能几个 TB 都用不到。 |
|
16
qiayue 2021-06-27 10:50:39 +08:00
@leokino 我是这样考虑的，每个微信号的唯一 id 和公众号唯一 id 肯定是在数据库不同的表里分别记录的。
也肯定会有一张表，记录了微信号和公众号（小程序、App 同理）的关系，在首次产生关系时保存一条记录，同时生成一个 openid 。 在实际使用时，对于传过来的每一个 openid，如果都去缓存或数据库中校验 openid 是否合法，没多大必要，第一步直接通过一个固定的算法去校验合法性，之后解开得到公众号 id 和微信号 id，再去处理业务，会不会更好。 |
 |
17
melkor 2021-06-27 11:21:37 +08:00 via iPhone
想太多，就是算法生成的而已
|
Select Language