直播礼物系统设计要点

直播礼物系统的特点

• 数据一致性要求高。用户购买的礼物，主播收到的礼物。这些都涉及真金白银结算，自然是不能错。
• 实时性要求高。腾讯公司做过一次问卷调查，用户送礼时，最关注的是主播的反馈。送出礼物后，希望能较快听到主播感谢自己，念自己名字。主播会更关心礼物排行榜的变化，以便及时和粉丝互动。这样要求送礼后，礼物账户及各种排行榜准实时的更新。
• 关联模块多。一次送礼，需要更新各种各样排行榜，还要增加用户等级，发送礼物消息等。
• 安全性要求高。用户礼物账户好比银行账户。
• 消息的重要性高。热门主播直播时，大量的粉丝进行送礼，粉丝及主播是根据看到的送礼消息来确定礼物是否送出和收到什么礼物。消息不能丢也不能多，同时还要求能较快显示。

礼物系统架构选择

• 模块交互模式送礼功能关联的模块多，操作流水需要同步到其它模块，可选的方式有notify模式和消息队列模式。两者特点如下
  

  [1508831667027_9201_1508831705866.png]
  根据实际工作的碰到的各种问题，建议采用生产者消费者模型，用消息队列来进行模块间通讯。送礼是直播业务里的核心功能，随着业务的发展，围绕着送礼功能会衍生各种周边功能，如增加几种排行榜，建立一种荣誉体系等。这样，送礼流水需要同步的模块会越来越多，如采用notify模式，链条会越来越长，主notify流程需要经常修改，模块间容易互相受影响。如采用消息队列模式，一次生产，多次消费，当新增一种功能需要送礼流水时，自行接入消息队列拉取流水进行计算，不用修改现有的模块而影响到其它接入模块。另外，在notify模式里没有考虑到被通知端的实际处理能力。在生产者消费者模式，消费者可以根据自己的实际计算能力来调节拉取速度，架构的可扩展性强，更具备弹性。
• 计算模式

排行榜是送礼服务里必不可少的功能。直播送礼是读多写少的服务，基本上还是大部分观众围观土豪送礼的模型。建议排行榜采用写扩散模式，异步计算好排行榜，读取时直接进行拉取。在实现上把读写进程分开，两者各司其职，互不影响。

• 存储模式 根据礼物系统的特点，其在不同方面有不一样的要求。
  

  [1508831741220_5364_1508831780036.jpg]
• KV存储：排行榜等核心基础数据最终落地在KV存储，以加快计算读写速度。
• MEM：定时缓存KV的数据。减少网络请求，加快读取速度。
• SQL：存储送礼流水。用于进行对账和各类实时性要求不高的统计计算。
• SSD: 存储送礼流水。用于异常情况下的数据丢失重建，定位问题，日志回溯等。

礼物业务的流水数据重要，建议分级和分多份存储以便数据对账和数据重建。当然成本也是考虑因素之一。

数据一致性

1. CAP理论已经广为人知。这里结合实际工作中遇到的问题，谈点个人的认知和方法。在服务海量用户时代，传统的SQL存储并不适合高并发，实时性要求高的场景，大量KV存储应用在我们的业务中，追求高性能高并发的KV的存储大部分并不支持事务功能，这样带来了数据一致性问题。总体来看，影响数据一致性主要有两个方面。一：数据损坏。这个可通过备份数据进行重建和对账来恢复。二：超时。在分布式架构下，超时简直是噩梦，其带来了状态的不确定性。
2. K歌礼物业务解决数据一致性基本方法：每次送礼时会生成唯一送礼id号，唯一id号会贯穿整个送礼流程，最终的存储也会记录有id号信息。当送礼流程中有超时的会记录日志，由Redo程序来进行重试处理，Redo程序会先判断送礼id号是否已经处理以防止多算一次。

安全

1. 送礼协议端到端加密防破解。
2. 防抓包重放攻击。具体实现方法为送礼分两步走，分下单和消费两个步骤，联合送礼步骤的状态机进行判断。下面为实现流程图

[1508831813199_3502_1508831852016.png]

举例：如果下单数据包被截获重放，只会新生成不同的订单号，如果消费包被截获，流程里会判断状态机这个订单是否是合法及是否已经消费了。

3.内部安全。堡垒最容易在内部被攻破，加强内部控制，严格流程规范。DO分离，定时对账。