直播软件打赏记录查询：我是怎么一步步搞明白这事的

前阵子有个朋友找我聊天，说他刚接手了一个直播项目的技术重构工作，老板让他重点搞定直播间打赏记录的查询功能。他问我这事儿难不难，我愣了一下，因为这事儿说简单也简单，说复杂也真挺复杂的。

回家路上我就在想，这打赏记录查询看着就是个功能，但背后涉及的东西其实挺多的。从数据怎么存、怎么取、怎么保证不丢、怎么保证查得快，每一个环节都有讲究。与其让朋友自己去踩坑，不如把我知道的这些整理出来，说不定能帮到更多像他一样刚接触这块的开发者。

先搞明白：打赏记录到底是个什么东西

在说怎么查询之前，咱们得先搞清楚打赏记录到底包含了哪些信息。很多人觉得打赏不就是个金额和时间吗？其实远远不止这些。

一场完整的打赏行为，底层需要记录的东西远比表面看起来复杂。我给大家列个清单，你们感受一下：首先是基础信息，包括打赏ID、直播间ID、主播ID、用户ID、打赏金额、虚拟货币类型、支付方式这些。然后是时间维度，创建时间、支付完成时间、到账时间，这几个时间点有时候会不一致，特别是网络波动的时候。还有状态标记，这笔打赏是成功了还是失败了、是已结算还是待结算、有没有发生过退款。

另外还有些容易忽略的字段，比如打赏时使用的优惠券ID、用户当时的等级、主播当时的分成比例设置等等。这些字段在日常查询中可能用不上，但一旦出问题需要追查，或者财务需要做报表的时候，缺一个都不行。

我见过不少团队早期为了快速上线，只记录了最基础的信息，结果后来业务扩展了，查询需求一多，数据结构根本撑不住。所以这块真得在一开始就考虑清楚。

数据存储：第一道关卡

搞清楚了要记什么，接下来就是怎么存的问题。这块我建议分成两条线来走，热数据和冷数据分开处理。

热数据：用Redis扛住高频查询

啥叫热数据？就是最近一段时间的打赏记录，比如最近七天的。这些数据查询频率特别高，用户可能随时想看看自己刚才打赏了没，主播可能每隔几分钟就想看下今天的收入情况。

对于这种高频场景，用传统数据库直接扛压力是扛不住的。我通常会建议用Redis来做缓存。具体怎么做呢？可以按用户ID和主播ID分别建立索引，用户看自己的打赏记录，就从用户维度的索引里快速捞取；主播看收入统计，就从主播维度的索引里拿数据。

Redis的Sorted Set结构特别适合这个场景。把打赏记录按时间戳作为分数存进去，这样既保证了插入顺序，又天然支持按时间范围查询。比如我想查某个用户最近三个月的打赏记录，直接用ZRANGEBYSCORE命令就能搞定，效率非常高。

不过Redis有个问题，它重启后会丢数据。虽然现在Redis的持久化方案已经很成熟了，但打赏数据这种敏感数据，还是得留个心眼。我的做法是额外起一个定时任务，每隔几分钟就把热数据同步到MySQL一份。万一Redis真出了问题，至少不会丢得干干净净。

冷数据：存进数据库的深冷区

热数据的问题解决了，那三天前的、七天前的、三个月前的数据怎么办？总不能一直放在Redis里吧，内存它不允许啊。

这时候就需要把数据归档到传统数据库里。我见过几种方案，各有各的优缺点。第一种是按时间分表，比如每个月一张表，名字叫打赏记录_2024_01、打赏记录_2024_02这样。这种方案查询的时候只要知道时间，就能精准定位到表，效率不错。但缺点是跨月查询的时候要聚合多张表，开发的时候稍微麻烦一点。

第二种是按用户ID哈希分片，把数据分散到多张表里。这种方案的好处是数据分布均匀，单表数据量可控。但查询的时候如果只知道时间范围，不知道具体用户ID，那就比较麻烦了，需要遍历所有表。

还有一种现在比较流行的方案是用分布式数据库，比如TiDB或者CockroachDB。这类数据库天然支持水平扩展，写入和查询的性能都不错，对开发者友好度比较高。不过部署和运维的成本也相对高一些，适合中大型团队。

我个人比较推荐的做法是混合使用：热数据走Redis，温数据走Elasticsearch，冷数据走MySQL。Elasticsearch在全文检索和时间范围查询方面很强，很适合做打赏记录的二次检索。比如用户想搜索”给主播XX打赏的所有记录”，Elasticsearch就能派上用场。

查询服务：怎么设计才能扛住并发

数据存好了，接下来就是怎么查询的问题。这块的核心矛盾在于：直播间的打赏查询可能同时面对几万甚至几十万用户的请求，你得保证查询接口既快又稳。

首先是查询接口的拆分。我把打赏记录的查询需求大概分成这么几类：

• 用户查询自己的打赏历史
• 主播查询自己的收入记录
• 管理员查询任意记录（用于运营和客服）
• 财务系统定时拉取数据做结算
• 实时统计大屏需要的聚合数据

这五类需求的查询模式和数据量级完全不一样，最好是分开做，不要混在一起。比如用户查自己的记录，一般就查最近几十条，量很小；但财务系统做月结算可能要一次性拉取几十万条。如果这两个走同一个接口，财务一跑查询，用户那边可能就卡死了。

实时查询和异步查询

对于实时性要求高的场景，比如用户刚打完赏想立刻看到结果，这种情况必须走在线查询，延迟要控制在毫秒级。实现上通常是先查Redis缓存，缓存没有再查数据库，然后回填缓存。为了避免缓存穿透，可以加个布隆过滤器，或者把查不到的结果也缓存几秒钟。

对于实时性要求不高但数据量大的场景，比如财务结算、运营报表这些，我强烈建议用异步查询的方案。用户提交查询请求后，系统返回一个任务ID，然后后台慢慢处理。等处理完了，用户再来拿结果。这种方案对用户和系统都友好，不会出现一个复杂查询把整个服务拖死的情况。

这里有个小技巧：异步任务的状态变更最好通过消息队列来通知，而不是让前端轮询。轮询一是浪费资源，二是体验不好。用消息队列的话，任务一完成就推给前端，前端再刷新页面，丝滑很多。

分页和排序：细节里的魔鬼

查询服务里最容易出问题的，其实是分页和排序这两个看起来很简单的功能。

先说分页。很多新手会直接用OFFSET和LIMIT来做分页，比如LIMIT 20 OFFSET 40。这种写法在数据量小的时候没问题，但一旦数据量上了几十万，OFFSET越大，查询越慢。因为数据库要跳过前面40条记录，这个过程是实打实要做的。

更好的做法是基于游标的分页。比如我记录上一页最后一条的ID或者时间戳，下一页就从这个位置开始取。这样不管翻多少页，查询性能都是稳定的。代价是没法直接跳页，只能一页一页往下翻。但对于打赏记录这种场景来说，这种代价是完全可以接受的。

再说排序。打赏记录的排序通常按时间倒序，最新的在前面。但这里有个坑：如果两个打赏记录的时间完全一样怎么办？所以排序字段最好做成联合索引，比如（主播ID, 创建时间 DESC, 打赏ID DESC）。这样既能保证同一主播的记录聚在一起，又能在时间相同的时候有个 secondary 排序依据。

还有一点很多人容易忽略：排序字段最好是有序递增或者递减的。这样在分库分表的时候，路由算法可以基于排序字段来做，把范围查询变成单库查询，性能会好很多。

聚合统计：怎么算出一场直播的收入

除了查明细，直播场景下还有大量聚合统计的需求。比如一场直播结束，主播想知道这场直播一共收了多少打赏；或者运营想看下今晚收入最高的十个主播是谁。

p>聚合计算有几种做法。第一种是实时计算，每次查询的时候现场聚合。这种做法实现简单，但数据量大的时候响应慢，而且如果聚合逻辑复杂，可能会把数据库拖死。

第二种是定时计算，用定时任务每小时或者每天跑一遍，把聚合结果存到另一张表里。查询的时候直接读聚合结果，速度很快。缺点是数据有延迟，不是实时的。对于打赏收入统计这种场景来说，延迟个十几分钟通常是可以接受的。

第三种是流式计算，用Flink或者Kafka Streams这类流处理框架，每进来一条打赏记录就实时更新聚合状态。这种方案实时性最好，但开发和运维成本也最高，适合对实时性要求极高的场景。

我自己的经验是，大部分直播项目用定时计算就够了。比如每小时跑一次任务，把每个直播间、每个主播的实时收入算出来存好。用户看到的收入数据延迟个半小时，其实感知不强。但如果你们老板要求秒级更新，那就得上流式计算了。

性能优化：我踩过的那些坑

说完了正常情况下的实现，再来说说我踩过的几个坑，希望能帮大家避雷。

防止查询穿透

有一段时间我们线上经常出现数据库CPU飙升的情况，查了很久才发现是查询穿透的问题。有人在疯狂查询一些根本不存在的数据，比如随机构造的用户ID。由于这些数据不在缓存里，每次请求都穿透到了数据库，把数据库打挂了。

解决方案有两个：一是布隆过滤器，把所有存在的用户ID存进布隆过滤器，查询之前先过一遍，不存在的直接返回；二是把”查询无结果”也缓存起来，缓存时间设短一点，比如30秒。这样同样的无效查询短时间内不会打到数据库。

避免缓存雪崩

缓存雪崩这个问题我在多个项目里都见过。主要是热数据集中在某个时间点过期，大量请求同时打到数据库上，数据库瞬间挂掉。

解决思路很简单，就是让缓存过期时间随机化。不要让所有数据都在整点过期，而是给过期时间加个随机偏移量，比如基础时间加上0到600秒的随机值。这样请求就会分散开来，数据库压力也就分散了。

热点数据的特殊处理

直播场景下有个特点：头部主播的打赏数据访问量特别大。一个大主播可能有几十万粉丝，每秒都有成百上千的人想看他的收入数据。如果这些请求都打到同一个数据库或者缓存实例上，很容易成为瓶颈。

对于这种情况，可以给热点数据做多级缓存。Redis作为一级缓存还不够，再加一层本地缓存，比如Guava Cache或者Caffeine。本地缓存的响应速度比Redis更快，能扛住更大的并发量。缺点是数据会有一点点不一致，但对于打赏收入这种数据来说，秒级的不一致完全可以接受。

数据安全：这根弦永远不能松

打赏记录涉及到钱，数据安全这块怎么强调都不为过。我总结了几个关键点：

数据备份是基本功。打赏数据至少要存三份，一份在线热备，两份离线冷备。备份数据要定期演练恢复，别等真出问题了才发现备份已经损坏或者过期了。

权限控制要做好。谁能查什么数据，都要管得清清楚楚。普通客服只能查用户的基本打赏信息，财务能看到金额和结算状态，管理员才能查敏感字段。而且所有查询操作都要留日志，方便事后审计。

数据脱敏也不能马虎。查询出来的数据，如果不是必须显示用户真实姓名、手机号的场景，就把敏感字段打码。比如手机号显示成1388888，姓名显示成张*。这样万一查询结果泄露了，也不会造成太大损失。

举个例子：用户想看自己的打赏历史

为了让大家有个更直观的感受，我完整走一遍用户查询自己打赏历史的流程。

用户打开APP，点击”我的打赏”，请求打到API网关。网关把请求转发到打赏查询服务。查询服务首先从请求里拿到当前登录用户的ID，然后去Redis里查缓存。缓存里有数据，直接返回给用户；缓存里没有，就去数据库里查。

数据库查询用的是用户ID索引，条件是用户ID等于当前用户，按时间倒序分页取20条。取到数据后，先回填Redis缓存，再返回给用户。整个过程的延迟控制在100毫秒以内，用户几乎感觉不到等待。

如果用户翻到第二十页，OFFSET已经很大了，这时候自动切换到游标分页模式。查询条件变成用户ID等于当前用户，时间小于上一页最后一条记录的时间，再取20条。这样不管用户翻多少页，查询速度都能保持稳定。

写在最后

回过头来看，打赏记录查询这个功能看似简单，要做好其实需要考虑很多细节。数据怎么存储、查询怎么设计、性能怎么优化、安全怎么保障，每一个环节都有讲究。

、声网这样的实时互动技术在直播领域已经非常成熟，打赏作为直播的核心功能之一，对查询服务的稳定性和性能要求只会越来越高。希望我这些经验能对正在做这块的同行有所帮助。

如果你们在实践过程中遇到了什么有趣的问题，或者有什么更好的解决方案，欢迎一起交流讨论。技术在发展，方案也在迭代，没有最好只有更好。

附录：打赏记录核心字段参考

字段名	类型	说明
打赏ID	VARCHAR(64)	唯一标识符，推荐使用UUID
用户ID	VARCHAR(64)	打赏者的用户ID
主播ID	VARCHAR(64)	收打赏的主播ID
直播间ID	VARCHAR(64)	发生打赏的直播间ID
打赏金额	DECIMAL(12,2)	实际支付金额，保留两位小数
虚拟货币金额	BIGINT	如果使用虚拟货币，记录虚拟货币数量
货币类型	TINYINT	1=人民币，2=虚拟货币，3=其他
支付方式	TINYINT	1=支付宝，2=微信，3=Apple Pay等
订单状态	TINYINT	1=待支付，2=支付中，3=成功，4=失败，5=已退款
创建时间	DATETIME	用户发起打赏的时间
支付完成时间	DATETIME	支付渠道回调确认的时间
主播到账时间	DATETIME	主播账户增加余额的时间
备注	VARCHAR(255)	用户自定义的打赏留言