百万直播间点赞高并发方案

用户在直播间连续快速点赞，一秒之内甚至能点击十几次，如果前端不做任何处理，不仅挤占的是服务器的带宽，还会让后端的接口压力值拉满，资源白白浪费，所以第一层的，优化，永远从前端开始，而不是一开始就折腾后端的中间件，前端做好请求的聚合与频次的合并，短时间内用户连续多次点赞，统一积攒整合到一起，合并成一次，批量的请求上报后端，直接砍掉百分之七八十的无效请求，从源头完成流量削峰，搞定前端的流量削减后；
第二，如果整个直播间的点赞全部汇集到redis同一个固定的key，进行累加计数，那这个key，立马会变成超高热点key，海量读写请求，扎堆涌向单一节点，集群其他节点全部闲置，资源严重失衡，单节点性能很快就会达到瓶颈，根本撑不住百万流量的冲击。
解决方案：业内通用标准的做法就是热点数据分桶打散，把直播间的点赞数据，拆分划分成，多个存储的分桶，按照用户标识，来均匀的分发请求，让流量均匀的分散到不同的Redis节点来分担压力。
日常点赞增量分散存储，后台统计直播间点赞数据的时候，再把所有的分桶数据统一的汇总计算，轻松的消解单点压力，解决玩并发技术难题，有个核心问题，点赞数据全部存redis，一旦redis宕机了，数据不是全部没了。
首先要区分业务数据的属性，直播间的点赞本身就不属于金融交易这类强一致性的核心数据，短时间内少量点赞数据缺失，统计出现微小的偏差，完全在业务的可接受范围内。没必要死磕百分百数据领丢失。线上主流的落地方案就是，依靠Redis全权接手瞬间超高并发点赞请求，再开启定时任务，周期性把redis的点赞增量数据，异步平缓的同步写入到Mysql数据库，完成持久化留存，就算Redis出现异常故障，就只会丢失极短时间内的临时数据，不会造成整体数据大面积的丢失。