之前写的直播从16年的票房开始走向现在的稳定。 在此期间，APP市场上出现了许多直播产品。 历史被称为“千放送战争”。 我有幸参加了其中的一个产品“腾讯新闻直播”，经历了从上线到优化再到探索的全过程。 因为在腾讯，所以这个产品的开发深深地刻着腾讯。 我不想介绍NOW是怎么设计和实现的。 如果我是这个产品的负责人，我想跳出来说一下怎么设计，怎么实现，怎么玩。
整体结构技术分为后台、客户端和web。
初始设计阶段需要注意的一点是，安卓和ios的实现是统一的。 安卓的特点是你想怎么玩。 虽然android基于开发者无限的权利，但由于ios通常受限于各种苹果政策，因此两端必须在计划设计的初期决定实现方式。 如果不能统一朴素就等于统一网络，实现不一致迟早会给自己补上漏洞。
web的优点是共同的，但缺点也很明显，速度和安全。
web和native是两个重要的选择，大致来说是以通用性为导向选择web，以体验为导向选择native。 另一个重点是，web可以随时发布，但客户端需要更新周期。 出现大错误时，android还可以打补丁。 虽然ios很痛苦，但是web更灵活。 如何选择是一门艺术，但别忘了不要叩头决定。
有了web和客户端，后台就必须提供两种协议支持： http和tcp。
后台的总体体系结构分为三层：访问层、逻辑层和存储层。 图：
接入层kndyd接入层在业务正式接入我们的业务后台之前，提供就近接入，安全策略、ip收敛和负载均衡等功能，在http协议分析之后，提供3358www.Sina.com/等功能对于tcp请求，移动端复杂的网络条件很难解决许多问题，业界已经有很多成熟的SDK，包括微信和互联网云服务。 我们利用这些SDK完成了网络通信，这样解放了客户同学的人力。 果然在复杂的网络中维护连接不是一件容易的事。 此外，后台可以方便地针对tcp请求集中访问一个代理服务，并进行传输，后台可以在内部进行流量控制的协调、链分析的调用、服务质量的监控等。
在许多情况下，接入层在逻辑上很简单，是反向代理，具有登录状态、安全性和消息不完整的基础功能，在tcp和http都必须将请求命中逻辑层的业务。 如何识别与请求对应的服务需要负载均衡。 在蚂蚁中，一个命令字是java类的全名，而子命令字是具体的方法名称，这也是许多Java RPC框架实现的标准。 但是，上述实现需要服务注册、消费等一系列基础框架，大多数互联网公司都有这种能力，但缺少腾讯，命令字，指令语为十六进制数字或字符串
的设计中选择pb。 由于更高效的编解码效率和友好的pb文件，一个清晰的pb文件可以减少一个wiki，也可以即时了解整个过程，但http层通常为json格式。 可以毫无损失地从json转换为pb，但从pb到json由于字节和长整型而失去精度。
那么，在逻辑层实现之前，需要一个能够处理tcp和http的框架。 我自己使用netty spring protostuff实现Teresa这个框架，也加入quasar协作库。 另一篇文章分析了rpc框架和微服务系统的设计要领。
逻辑层就直播业务的逻辑层分析三个最重要的系统。
直播间广播当然需要直播间，但基本上所有的直播场面都围绕着直播间转。 直播间有两个独立的系统。 一个是音视频，一个是直播间的具体业务，进入直播间是相对沉重的逻辑。 (白名单、黑名单、特效、排行榜等多项业务)、直播间业务失败不应该让用户看不到音视频流。 因此，因此我们的实现往往最接近事情原本的样子)、直播之间的播放开始和音视频的推送流互不影响。
直播间是整个直播业务的核心链接，平时明星活动时一个直播间可以实现10w的真实用户，挑战点有两个。
推还是拉？ 房间是消息内容的主机，消息的获取只能是按下推送或拉动。 推送的优点是实时性强，缺点是需要维护成员列表，需要关注linux单进程连接数限制。 pull的好处是没有成员列表。 缺点是可实现性差，请求可能呈锯齿状。 高峰失误能力需要事先考虑。 否则，所有客户端可能会立即一起请求并破坏后台。音视频流和直播间应该是解耦的，push可以合并消息，pull可以驱动器。 那么，是成员名单。 如何维护10w的用户成员名单？ mysql绝对不行。 使用redis、tair和ckv等缓存吗？ 在性能方面基本上是这种缓存的瓶颈。 另外，有同步播放的直播间是1k。 而且，网络抖动带来的影响很大。 那只是内存。 内存问题是如何将同一直播室的用户分配到一台机器上。一个复杂的系统往往是推拉结合的但一台机器还是有一点问题。 那是一致性hash
/strong>，多机完全冗余，并且能够分担读请求压力。多机的问题就是一致性和扩容，客户端在进入直播间之后需要定时发送业务心跳来维护在线状态，同时可以返回一些业务信息，1/min的业务心跳能够保证多机中成员列表多数情况一致。如果多机仍然扛不住读请求，那么就需要水平扩容，使用内存的另一个弊端就出现了，如何数据搬迁，搬迁时的变化又怎么处理？还是依赖于心跳，水平扩容先写，过2分钟后基本上就可以提供读了。在日常的直播场景中，小直播间（1w以下）占绝大多数，基本的业务都或多或少依赖成员列表。但是去年百万英雄之类的火爆答题（100w同时在线）条件下，成员列表就没必要存在了，另外那个场景另外再分析。怎么推怎么拉。进/退直播间、直播间内的心跳、送礼、发言等等都是直播间内的消息，这多多消息怎么处理。肯定要合并写、合并读，合并是根据直播间id进行合并的，合并的载体依旧是内存，那就又需要一致性hash了。另外一个问题就是成员列表怎么传输，分页拉取，增量调整。 pk赛pk就是两个主播比赛，通过送礼来加分，分数多的人胜出，是营收的主要来源，比赛方式多种多样，主要就是为了让用户看直播也有一种追星的仪式感。
PK的主要挑战是以下三点
匹配。玩过dota，lol的都知道这个流程，在当时12年左右11对战平台很火的时候，匹配效率最高的时候都能到毫秒级，那应该是一个很牛逼的系统。匹配的算法我们使用非常经典的EL0，也可以根据场景再改变。当用户点击pk时，将用户放入redis队列，根据时间变化，动态调整匹配上下限，直到成功为止。很简单的问题就是多机情况下的事务性，即不能把一个人同时分配了两场pk。如果用户量小，你甚至可以两台机器抢一个用redis实现的锁，抢到锁去执行匹配流程，但是匹配的瓶颈也就是单机的计算能力了。两阶段提交，把匹配出来的用户，放到第二个redis set队列中，如果重复就把用户重新放到原本队列中继续匹配。但是极端情况下会出现一直冲突，进入死循环。那就将等待队列分级，匹配冲突之后放到优先级更高的队列中，主动减少冲突。这种实现方式也应该是dota2的实现方式。11对战平台肯定不会这么实现，redis队列能否抗住和在鱼塘（大多数菜鸟玩家）分数段的匹配冲突都是两个问题。那只能再次细分排队队列，然后直接使用内存存储用户分数信息。扯远了。比赛。送礼事件通过mq旁路到专门的分数计算服务，分数在通过直播间广播到用户，在依赖于直播间的合并读写push时，业务也需要主动合并消息，减少网络流量，推送分数要推送全量而不是增量。实现时通过进程缓存能cache住大部分的请求，收益很高。结算。粉丝喜欢搞大事情，总是喜欢在最后几秒钟送大礼物，结算时就会有很多问题，比如服务器的时钟漂移，解决方案依旧是延后处理，两阶段提交。首先页面上展示结算中，给后台主动争取一些时间，然后将结算时间向后+buffer。胜利之后还会给粉丝一些礼物可以抢，这就是一个类似秒杀的场景了，限频、限流、过载保护非常重要。 答题17年年末答题火爆，只要是直播产品就一定会来蹭一波热度。答题的场景和特点很明了，人多，钱多。人多动辄100w+，钱多也是100w+。答题场景我们放弃了所有其他边缘业务，只做一件事就是答题，但还是有以下问题：
人数众多。这么多人怎么搞，依然是一致性hash，但是每台机器是单点，没有备机，因为业务心跳也没了。如果答题时宕机就会影响一部分用户飘逸到其他机器上，这个用户的资料就丢失了，我们通过把用户资料传给客户端，客户端请求时主动带上来，这样我们就有一份兜底数据。安全吗？相对安全，因为只有飘逸时才使用兜底数据，并且对数据加密（非对称）。基本上不可能用户一直在多台机器漂移。那么用户会不会有ABA问题，即宕机的服务恢复了，然后又飘回来了，因为原有机器上数据存在，但是之前的老数据，会不会有影响。解决方案：时间戳。峰值。8点开始的答题，不可能在一瞬间完成，业务需要主动的通过提前通知用户，引导错峰进入直播间，八点主持人再叨叨一会儿，给业务多点时间。拉。没有了成员列表，push变得不可能，拉的问题就凸显了，pull不能集中（后台可以控制请求频率，将请求打散），2000-3000ms。时间。答题一般10s，音视频延时时间+网络延时时间，计算一个最大的答题时间。题目。题目混在音视频流中容易跟着一起卡，因此需要题目单独拿出来。异地部署，就近接入。上海、深圳和天津依照公司的组件完成就近接入。结算，在结束后需要将得奖用户写入redis，最终在将三地的redis中用户汇总（mb级别），再通过mq异步发奖。 存储层存储层在2c业务方面起到一个很重要的角色，mysql这种传统的关系型数据库有可能在性能方面扛不住，redis在性能方面没有什么问题，但是需要考虑缓存击穿问题，而且这个问题还不太好处理，需要考虑的问题还很多。腾讯的ckv在这方面做得很好，一主一备，自动扩容，lru冷备，完全就当做能落地的持久层用。redis会受到单机容量限制，codis虽然搞定了这个问题，但是key的分片是一个坑，用不好坑自己。同时redis在容量满时会有丢弃策略。想用好需要下点功夫。
产品方面直播是一个变现十分可观的业务，相比于游戏直播，mm直播收入更高，同时带宽要求更低。但是直播也需要大流量一直在养，像抖音通过短视频养，momo通过陌生人社交的基数养。
但是直播也能带来更多的玩法，比如答题、抓娃娃、k歌房、1v1、桌游（谁是卧底、狼人杀）等。做产品也要大胆的给新兴业务一些浅入口，高曝光，而不是藏在角落，这可能涉及到产品册的一些思路。仅仅通过pk，各种活动来榨干用户的血是一种竭泽而渔的做法。要么就是看似直接但是套路很深的红包只能带来一些表象的DAU上升。
直播间是一种能力，它其实赋予了我们原本在线下开展的活动到线上的能力，就比如答题活动。在开放思路，原本的《幸运52》，是不是也能改变一下，或者非诚勿扰。玩法的升级，使得自身能够有能力吸引更多流量。
业务到了技术永远都是万变不离其宗，对于后台，客户端，web都有很多的通用之处。分析其中的关键点
设计艺术 能力收敛，以接口形式提供服务责任划分，整个流程清晰可见前端保护后端，上游保护下游，各端互不信任