当你给好友发送一条消息后,如果对方在十秒内打开聊天窗口并开始在输入框中打字,微信的客户端就会向服务器发送一个“输入状态”信号。这个信号并非实时连续,而是每隔几秒上传一次,用以表示“仍处于输入状态”。服务器收到信号后,会将状态推送给你,让你看到“对方正在输入...”的提示。如果超过十秒无新输入动作,或者对方关闭了聊天界面,信号就会消失,提示也随之取消。这个机制利用了WebSocket持久连接技术,减少了服务器频繁轮询的负担,同时保证了用户体验的流畅性。
微信群聊的消息排序并非严格按发送时间先后,而是依赖于微信自研的“时钟同步”与“序列号生成”混合算法。每个微信群都有一个独立的序列号计数器,成员发送消息时,客户端会向服务器请求一个递增的序列号。服务器根据接收到请求的先后顺序分配序列号,但受网络延迟影响,不同用户可能同时发出请求,此时序列号顺序会与真实发送时间产生微小偏差。为了尽量保证公平,微信服务器会参考每个消息包携带的本地时间戳,对序列号进行二次校正,将偏差控制在几毫秒内。即便如此,在弱网环境下,偶尔仍会出现后发的消息显示在前面的情况。
当你按住麦克风按钮讲话时,微信首先在手机本地通过Opus音频编码器将原始PCM音频数据压缩成码率约16-24kbps的比特流。Opus是一种适合实时通信的编解码器,能在低延迟下保持较好的语音质量。压缩后的数据被切分成约20毫秒一帧的小包,每个包由UDP协议传输到微信的媒体服务器。服务器不直接转发原始包,而是先进行丢包重传和码率自适应调整——如果检测到网络拥堵,会降低码率以减少数据量;如果丢包率过高,会丢弃部分非关键帧以保证核心信息的完整性。最后,接收方的客户端再将这些小包解码并拼接成连续语音,整个过程端到端延迟通常控制在200-500毫秒之间。
当你发布朋友圈时,每一条动态的可见性由一套“属性标签-时间轴-分库分表”架构决定。微信后端会为每条动态生成一个包含用户ID、发布时间、可见权限(公开、好友、私密、部分可见、不给谁看)以及地理位置等元数据的记录,并存储在不同分库中。好友刷新朋友圈时,客户端向服务器请求“动态流”,服务器需要实时拉取该用户的所有好友的动态,并逐一匹配权限:如果是公开动态则无条件展示;如果设定为“部分可见”或“不给谁看”,则需要查询该好友是否在名单内,这一过程通过Redis缓存加速。此外,微信还使用了“社交图谱局部性”优化——将互动频繁的好友动态优先放入缓存,减少数据库查询次数,以此支撑数亿用户的同时刷新请求。