``
背景
在娱乐直播项目中，送礼打赏无疑是最根本的营收来源，所以在直播项目中，保证送收礼的高并发、高可用往往会成为了开发人员最头疼的问题，此篇文章全方面解析在多种场景、并发下送礼打赏的处理方式。
全流程要点分析
礼物数据维护、资源预加载
礼物上架
- 设计人员准备好礼物资源、动态特效等
- 运营人员后台配置礼物的基础信息，比如礼物有效期，礼物名称，礼物类型，礼物价值，礼物分成，礼物动效等，配置后将礼物上架，这个时候礼物就在用户的礼物面板生效了
拉取礼物
- 用户在进入直播间后，客户端先拉取本地的礼物资源缓存，拉取前需要和服务端返回的数据ID做一个增量同步
- 如果有新增/更新的数据需要重新预加载礼物动态等资源，如果缓存没有找到只能重新从服务端拉取礼物并预加载资源，拉取后分类显示礼物基础信息
服务端送礼处理
赠送礼物
- 用户选中礼物，选择礼物数量和收礼人，点击赠送按钮，调用gRpc送礼接口
礼物结算
- 长连接服务接收到送礼接口参数后分别对礼物服务、资产服务调用RPC 进行数据校验、资产处理等操作
- RRC接口两阶段都成功后推送送礼成功广播给收礼用户和观众
- RPC接口两阶段失败后回滚数据并返回失败原因给送礼用户
- 为保证响应速度，送礼记录、数据结算、榜单统计使用其他异步线程进行结算操作
礼物广播消息推送
- 送收礼数据拉取并封装，通过protobuf序列化后用户选中礼物，选择礼物数量和收礼人，点击赠送按钮，调用gRpc送礼接口传输给客户端
- 推送消息时注意优先级：送礼人>收礼人>观众
高并发下的挑战
礼物连击下大量的消息排队问题处理
- 在一些峰值时刻，如周年庆活动直播时，用户可能会对特定礼物进行礼物连击操作，我们的系统可能在短时间内接收到高达20,000条打赏消息。为解决这种峰值压力，我们选择了RocketMQ消息队列集群，经过多次优化，已经支持单秒处理高达30,000条消息，且保证消息的有序性。同时，我们部署了多个消费者实例，以确保消息在峰值时也能得到及时处理。
网络瓶颈、弱网情况下的降级处理
- 利用CDN分发网络，减轻单点服务器压力，并针对低速网络下的用户，提供320p的低分辨率动态资源，减少加载时间，同时延迟非核心资源如背景特效的加载，确保核心功能流畅。
- 针对网络不稳定的用户，我们的客户端会自动检测网络速度。一旦检测到网络低于100kb/s，就会启动低质量模式，这种模式下，礼物的动画和效果会进行降级，以静态图片代替，减少数据传输量，确保核心功能如礼物的发送和接收仍然流畅。
服务故障、数据不一致的处理
- 我们使用了分布式数据库，借助PolarDB的同步复制技术，我们确保所有节点间的数据实时一致，即使在故障转移后，新的主节点会保有完整且最新的数据，消除了数据丢失的风险。
- 我们定期使用PolarDB自带的数据验证工具进行数据的完整性检查，确保数据在各个节点之间保持一致，如果检测到任何不一致，系统会自动触发数据修复流程，将不一致的数据块同步至最新状态。
- 利用PolarDB的自动备份功能，我们确保每天进行至少一次完整数据备份，并在多个地理位置保存备份副本，这不仅保障了数据的安全，还为我们提供了灵活的数据恢复选项，可以根据需求恢复到特定的时间点。
- 结合PolarDB的监控工具，我们对数据库性能指标、容量、查询性能等关键参数进行实时监控，任何异常的波动，如读写延迟的突增、节点不可用等，都会立即触发告警，确保我们的团队能在第一时间进行响应和处理。
送礼点对点消息高到达率保证
- 基于gRpc，我们开发了长连接点对点消息自定义的重试机制，在消息未确认(ACK)的情况下，会在1秒、3秒和7秒后进行重试，同时，每一条消息都有唯一ID，确保消息不会被重复处理。
技术优化
多层缓存策略的优化
- JVM缓存：对于频繁访问但不常变动的数据，如用礼物属性，我们采用应用层的JVM缓存。这大大减少了外部数据源的访问频率，提高了数据获取速度。
- Redis作为热点数据缓存：对于实时变动的数据和高访问频率，例如直播间的实时礼物榜，我们采用Redis进行缓存，以降低对PolarDB的即时查询压力。
- 全球CDN缓存：静态资源，如礼物的动效、直播间背景音乐等，通过全球CDN分发，确保不同地域的用户都能快速获取。
数据库与消息队列的整合优化
- RocketMQ的作用：用户打赏请求首先被写入RocketMQ，随后异步地由后端服务进行消费和处理，这种策略提高了系统的响应速度并均衡了负载。
- PolarDB的高可用性与性能优化：PolarDB通过其多活三节点架构为我们提供了数据的高可用性，同时，我们结合其慢查询日志对SQL进行持续优化，并充分利用其读写分离和数据分区功能以进一步提高性能。
流程与逻辑优化
- 异步处理与批量操作：在RocketMQ的支持下，某些非关键操作，如礼物统计、榜单更新等，全部异步进行，对于连续高频的打赏行为，我们采用批量写入策略，减轻即时负担。
综合监控、告警与故障恢复
- 全方位实时监控：结合PolarDB、RocketMQ、Redis及应用层的监控，实现对整个系统的实时监控。
- 告警策略：为关键性能指标，如RocketMQ的消息延迟、PolarDB的查询响应时间，设置阈值，一旦超出，系统立即触发告警。
- 故障恢复策略：依赖RocketMQ的消息持久化和PolarDB的数据备份策略，确保即使面对应用或数据库的暂时性故障，用户的打赏数据也不会丢失。
总结
综合JVM缓存、Redis、全球CDN、RocketMQ以及PolarDB的特性，我们构建了一个层次丰富、高度可靠的技术架构，这不仅分散了高峰期的系统压力，确保了流畅的用户体验和稳定营收，而且在任何情况下都确保了数据的完整性和系统的高可用性。