【大厂文章学习】腾讯会议高性能录制列表查询系统设计实践
【大厂文章学习】腾讯会议高性能录制列表查询系统设计实践
亿级流量!3倍并发!10倍平均耗时减少!腾讯会议高性能录制列表查询系统设计实践 讲解了在腾讯会议列表页设计场景中遇到的主要挑战和解决思路
文章主要内容
本文主要展示了腾讯会议列表页在重构的过程中的一系列技术挑战,包括但不限于:缓存的设计,异构数据源合并,存储选型等等,看似一个简单的列表页里面也有不少的设计门道。
缓存的设计
在列表中,因为查询的并发量比较大,后台涉及的查询系统也比较多,一个常见的优化手段就是添加缓存。对列表页而言,常见的缓存手段及其优缺点如下:
-
列表结果全部缓存:即用Redis直接缓存整个列表页的结果,like:
- 优点:如果命中缓存查询简单;查询命中性能极高。
- 缺点:缓存一致性;缓存易失效,列表中一旦有一个item改变,则整个缓存失效;存在数据扩散问题:对列表页的文件进行改动可能会级联影响多个缓存(比如给将录制文件的权限批量给会议室的所有人,则这些人的录制列表页都需要改动)
-
元素key查询db,value进行缓存:即录制文件的uid是查询数据库,而对uid对应的具体文件进行缓存,like:
- 好处:缓存设计方便;不存在数据扩散问题;基本不存在数据不一致的问题。
- 缺点:查询过程中某些文件在缓存中,某些不在,对于不同来源的需要合并并重新缓存;仍然需要一次数据库查询。like:
-
分别缓存元素key和value(结合上面两种方案):
以下是三个方案的优点和缺点。
优点 | 缺点 | |
---|---|---|
方案一:列表结果缓存 | 实现简单 | 一致性维护的困难过于频繁的维护缓存缓存扩散的场景维护困难 |
方案二:ID查询+元素缓存 | 缓存数据库一致性维护简单没有缓存扩散的问题数据库能命中聚簇索引 | 批量缓存获取的实现较为困难存在一次DB的查询 |
方案三:ID列表缓存+元素缓存 | 没有缓存扩散的问题大部分场景不需要数据库 | 实现相对于方案二更为复杂 |
列表页异构数据源合并
列表页异构数据源合并是一个「业界难题」,将其单独总结在了下方「思考」一节中。
存储选型
本人目前对存储选型不是特别了解,因此目前只列出文章中的结论:
业务适配性 | 扩展性 | 查询性能 | 写入性能 | 成本 |
---|---|---|---|---|
MySQL | 所需存储量级太大,需要人工分上千张表 | 低 | 中 | 低 |
TDSQL | 所需极多的分片 | 中 | 中 | 低 |
Redis | 不支持多维查询,需要人工构建多个维度的列表数据 | 高 | 极高 | 高 |
ES | 未来还可以支持全文搜索。但是不适合做高并发实时业务查询 | 中 | 中 | 中 |
MongoDB | 支持多维查询、排序 | 高 | 高 | 中 |
最终从业务适配、扩展性和成本等多种维度的考虑,我们选择了 MongoDB 作为最终的选型数据库。
思考
看起来简单的列表页竟也有这么多考究。
关于异构数据源和分库分表列表页的思考放在了:MySQL深度分页问题和分库分表的查询方案思考[^1]
参考:
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)