腾讯会议号设计的几种猜测

可以说疫情给我们打工人带来最大的改变，就是居家办公，而这其中，对工作模式冲击最大的就算是在线会议了，以前都是会议室，面对面交流，现在都是对着一个屏幕，如果有视频的会议还好，能看见对方，还像一个会议，但大多是没视频的会议，就对着个屏幕，用一位朋友说的，这种会的主讲人，就像一位"过了气的主播"，跟大家扯东扯西，没眼神交流，没任何反馈，确实有些尬。

既然在线会议如此之火，出现了很多老的、新的在线会议的软件，这其中最常用的，可能就是腾讯会议了，简单、实用、稳定，是很多人选择他的原因。

大家都知道，腾讯会议上开会，无论是加入会议，还是创建一个快速会议，又或者是预定一个会议，都是用的一个会议号进行标识的，

d576c8a0c6a9aeb77cdf967223dd4fb6.png

如果细心的朋友会注意到，这个会议号是一个9位的数字，假设每位可以是0-9一共10个数字，10的9次方，是1000000000，10亿。换句话说，他应该同时支持10亿个在线会议。

不知道你是不是尝试过，例如定了一个09:00-09:30的会议，但实际上09:00之前，09:30之后，都可以登录，而且尝试过可以登录一个月(这个随机测的，未必非常准确)之前的会议号，但是更久的，会议号就失效了。

因此，按照刚才计算的，虽然支持10亿个会议号，但这些号是否会出现重复的，或者因为用满了这些号，禁止创建新的会议了？

从产品的功能角度来讲，这个应该是不太可能的。但是如何实现的，我没找到资料，不过可以做一些猜测，其实就和系统设计相关了。

(1) 每个会议号，应该是随机创建的，因为是无序的，所以不太可能只是用像数据库的sequence或者分布式自增ID的方案，很可能是一种混合的号码生成器方案，为了安全起见，还需要随机的。像避免重复的功能可能会用到序列、snowflake等分布式自增ID的特性，但是范围确定(10亿)，所以其中可能有判重的设计，例如通过缓存，key/value来判重。

(2) 10亿是个确定的值，这就要求每个产生的会议号，需要存在有效期，一种简单粗暴的方式就是给定一个具体的时间段，例如从创建开始，一个月内有效。另外一种"优雅"的方案，可能就是像Oracle等关系型数据库采用的LRU链表设计，最少最近使用的队列，根据当前会议号的使用情况，动态淘汰最少使用的会议号，这给用户的体验就会很好，但相对来说，在设计和实现上，就会更加复杂一些。

腾讯会议的稳定性、功能上的实用性、操作上的简易性，很出众，其实这些都是同类软件的基础，都是用户最需要的功能，相比很多"花里胡哨"的同类软件，在产品的设计层面还是有很多值得借鉴的地方。