点赞组件
<p>[TOC]</p>
<h1>概述</h1>
<p>点赞作为最常见的互动玩法之一，能够很好的增加直播间的氛围，提升主播的人气等。</p>
<h1>架构</h1>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=3b2be7af23ab02f93c76e11bb5504159&file=file.png" alt="" /></p>
<h1>流程</h1>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=77c72dc3cb0896d231f6ce5cc5f08ceb&file=file.png" alt="" /></p>
<h2>消息上行</h2>
<p>用户从客户端发起点赞行为到服务端收到请求并且点赞数据持久化这个过程称之为消息上行。</p>
<ul>
<li>消息合并
客户端并不是每次收到请求都上报，而是按照房间维度和场次维度进行本地合并，然后根据合并规则进行上报。这样可以将端上非常频繁的用户请求进行合并，尽大力度减轻服务端的压力。
合并规则可以分为两个维度：时间维度和数量维度。比如5S上报一次，或者是合并10次上报一次</li>
<li>本地合并
点赞数上报是非常频繁的写行为，需要不断的去更新直播间的点赞数。虽然在客户端进行了消息合并，但是用户请求依旧很频繁。频繁的写操作对数据库的压力比较大。所以我们需要在内存里增加一层缓冲区，将多次点赞的写行为在内存进行合并之后开启异步线程池，异步任务将合并之后的数据写到REDIS里面。如上图中的消息上行流程。</li>
</ul>
<h2>消息下行</h2>
<p>我们把服务端将点赞数据下发回到客户端的过程称之为消息下行</p>
<ul>
<li>实时下行
服务端本地合并成功之后立刻下发实时消息。消息实时性高，但是对于服务端压力大。</li>
<li>延迟下行
服务端本地合并成功之后不立刻下发实时消息。而是等待出发条件，比如定时任务或者手动出发在下发消息。损失一部分实时性，但是压力较小。</li>
</ul>
<p>消息下行的作用主要有两个</p>
<ul>
<li>
<p>实时更新直播间的点赞数量
服务端本地合并成功之后会异步的将数据写到RDB中存储，同时发送异步消息给客户端更新直播间的点赞数。</p>
</li>
<li>广播给房间内的其他人看到点赞效果
原理和直播弹幕一致，不在赘述</li>
</ul>