V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
GM
V2EX  ›  编程

探讨一下微信海量 openid 的存储方法

  •  
  •   GM · 155 天前 · 2159 次点击
    这是一个创建于 155 天前的主题,其中的信息可能已经有所发展或是发生改变。

    众所周知,微信用户在不同的公众号、小程序都有不同的 openid 。

    假设有 10 亿个微信用户,一百万个微信公众号、小程序,那么就可能存在

    10 亿 x 一百万 = 一千万亿个 openid,每个 openid 大约是 30 个字节,那么光是存储这些 openid,就需要 三千万亿字节。

    问题来了:

    一,这些 openid 是固定生成的,还是通过微信用户 ID 通过一定算法算出来的? 二,如果是固定生成的,那么这么多 openid 如何做到高效存储、查询的? 三,如果是通过算法算出来的,万一算法被破解了(或者秘钥泄露了),那么就永远泄露了,因为有大量第三方系统存储着这些 openid,是不太可能去全部更新的。

    19 条回复    2021-06-28 07:20:22 +08:00
    daquandiao2
        1
    daquandiao2   155 天前
    实际没那么多 一个用户才能关注几个公众号
    0o0O0o0O0o
        2
    0o0O0o0O0o   155 天前 via iPhone
    一个用户好像最多关注 2000 个公众号
    laowai89
        3
    laowai89   155 天前 via iPhone
    你就一个微信?你关注了几个公众号
    gwy15
        4
    gwy15   155 天前 via Android
    稀疏
    qiayue
        5
    qiayue   155 天前
    我猜是生成的,而且是可以反解的。
    你有没有发现,同一个公众号下的不同关注者的 openid 前缀是一致的。
    我猜,openid 分成前后两部分,前一部分可以解析出公众号唯一 id,后一部分可以解析出微信号唯一 id,甚至中间有一位是校验位,拿到一个 openid 先用校验位判断是否是合法的 openid 。

    至于你说算法是否可能被破解,我觉得总有办法可以解决。
    leokino
        6
    leokino   155 天前
    @qiayue 这位大哥大概没学过密码学,生成一定是生成的,但一定不可逆。
    zpf124
        7
    zpf124   155 天前
    看起来楼主好像不是搞后端的啊,甚至好像不是搞技术的。
    几个部分,
    1 、你的固定生成和通过微信 id 算出来,实际想表达的是不是“生成 id 是否与与用户或其他业务数据相关?”。
    答:无
    与业务数据肯定是无关,因为没意义,但大概率与时间有关,给你两个 id,你可以知道这两个 id 哪个生成的更早,仅此而已。
    这世界上有许许多多的随机数生成方法,包括算法层面的伪随机(一般常用),和真正意义上的随机(利用硬件电荷,效率慢,非特殊情况没人用)。

    现在常见的各种随机字符串生成方案大多数都是根据 推特公布的雪花 id 生成规则的思路制作的,估计微信很可能也不例外。

    2 、和其他数据存数据库没什么差距,数据库 io 写入瓶颈了就升配置或者加机器,查询慢了加缓存。

    3 、你知道了规则有什么用, 身份证规则百度就有,但你随便生成一个去银行或者公安局人家又不是查不出来。
    而且这种随机 id 生成会给许多不同的地方用,第一个用在用户 1 关注公众号 a,第二个用在用户 1 使用小程序 b,你用 A 公众号知道了 openid 又怎样,你公众号的关联数据里又查不到。
    zpf124
        8
    zpf124   155 天前
    发出去之后我突然理解楼主的想法了....

    楼主以为 openid 有个大列表, 就个网址短链接一样,一个 id 对应一个值,不论是啥数据都从这查。


    然而实际上, 这种 id,生成的服务只管生成,生成的值有没有地方用到对这个服务都无所谓,也没有一个大列表记录每个 openid 对应啥。

    我公众号需要用到一个 id, 那我就获取 /生成一个,存我这个表里, 他小程序要用到一个 id,那他就生成一个,存他那,支付用到了支付那边自己再存一个。

    不用 openid 用数字自增这功能都不会出安全问题,
    我公众号生成了 id=1, 他小程序生成 id=21,你在我这公众号里用 21 查能找到啥?
    即便我公众号的表里有个 id=2 的,你查的时候我又不是不判断这个 id 是不是你能看的。
    JohnH
        9
    JohnH   155 天前
    小的关系系统可能存储起来更方便。
    像微信这种体量,如果把 openid 存起来,我觉得不如有一个固定算法更划算。
    一个 openid 维持了一个关系,通过算法来加密解密来计算出关系,在业务上就相当于用户位于应用的 token 。
    qiayue
        10
    qiayue   155 天前
    @leokino 的确没学过,但从使用场景来说,能够还原不是更好吗?
    nvkou
        11
    nvkou   155 天前 via Android
    @qiayue 若无需要,勿增实体。id 只是标识符,没有意义的。只要能验证张三,我就恒定给他发同一个 id 即可。id 本身是阿猫阿狗无所谓,如果本身还自带信息容易引起安全问题。我不记录你的密码原文,但我知道你有没有输错
    tianxia
        12
    tianxia   155 天前 via Android
    固定生成的可能性大,如果是算法生产的,有办法反解的,那风险是巨大的
    pcbl
        13
    pcbl   155 天前 via Android
    不得不说微信的这种设计还是挺好的,比 tg 的一个用户 id 全包了好很多
    Seanfuck
        14
    Seanfuck   155 天前
    至少是拼起来的,前 6 位跟公众号关联,第 7 位没有数字,大小写一致;后面的看起来是随机生成的
    leokino
        15
    leokino   155 天前
    @nvkou 我思考了下,确实也有可能是可以还原的,但是从微信的角度来说没有必要,因为微信是在已知用户 id 的情况下提供给小程序。

    其次,三千万亿字节听起来很多,但其实也不过 3000 TB,更何况,上亿用户使用的小程序,屈指可数,实际可能几个 TB 都用不到。
    qiayue
        16
    qiayue   155 天前
    @leokino 我是这样考虑的,每个微信号的唯一 id 和公众号唯一 id 肯定是在数据库不同的表里分别记录的。
    也肯定会有一张表,记录了微信号和公众号(小程序、App 同理)的关系,在首次产生关系时保存一条记录,同时生成一个 openid 。

    在实际使用时,对于传过来的每一个 openid,如果都去缓存或数据库中校验 openid 是否合法,没多大必要,第一步直接通过一个固定的算法去校验合法性,之后解开得到公众号 id 和微信号 id,再去处理业务,会不会更好。
    melkor
        17
    melkor   155 天前 via iPhone
    想太多,就是算法生成的而已
    leokino
        18
    leokino   155 天前
    @qiayue ID 本身就是用来查表的东西,即用 ID 去查找关联的其他信息,因此即便储存,不增加复杂度,也不会对系统负载造成本质上的影响,合理分片和索引几乎不增加查找成本。其次算法同样解密消耗 CPU 时间,相较而言,我认为绝对是查找更省钱。
    qiayue
        19
    qiayue   154 天前
    @leokino 学习了
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3926 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 42ms · UTC 08:45 · PVG 16:45 · LAX 00:45 · JFK 03:45
    ♥ Do have faith in what you're doing.