全国统一热线：400-028-5800028-
密　码:
Domain Trader
VPS SERVER
CLOUD HOST
您当前的位置：&>&&>&
微信――腾讯战略级产品，创造增速记录，10个月5000万手机用户，433天之内完成用户数从零到一亿的增长过程，千万级用户同时在线，摇一摇每天次数过亿……在技术架构上，微信是如何做到的?日前，在腾讯大讲堂在中山大学校园宣讲活动上，腾讯广研助理总经理、微信技术总监周颢在两小时的演讲中揭开了微信背后的秘密。周颢，2001年毕业于华南理工大学，计算机专业硕士。2005年加入腾讯广州研发部，历任QQ邮箱架构师，广研技术总监，T4技术专家，微信中心助理总经理。周颢把微信的成功归结于腾讯式的“三位一体”策略：即产品精准、项目敏捷、技术支撑。微信的成功是在三个方面的结合比较好，能够超出绝大多数同行或对手，使得微信走到比较前的位置。所谓产品精准，通俗的讲就是在恰当的时机做了恰当的事，推出了重量级功能，在合适的时间以最符合大家需求的方式推出去。他认为在整个微信的成功中，产品精准占了很大一部分权重。敏捷是一种态度，敏捷就是试错微信研发团队里鼓励一种试错的信仰：他们坚信，在互联网开发里，如果能够有一个团队在更短的时间内尝试了更多机会（并能改进过来），就能有（更多的）机会胜出。敏捷是一种态度，在软件开发过程中，项目管理者都会非常忌讳“变更”这个词，但是在微信的项目运作中是不可以的。因为微信必须要容忍说哪怕在发布前的十分钟，也要允许他变更。这是非常大的挑战，因为打破了所有传统项目开发的常识。所有人都说不可能做到的，但微信做到了。研发团队所做的一切都是要给产品决策者有最大的自由度，而这个决策正是微信能够胜出的关键。海量系统上的敏捷，无异于悬崖边的跳舞敏捷有很多困境，如果做一个单机版程序，是可以做到很敏捷的，但是腾讯正在运作的是一个海量系统，有千万级用户同时在线，在一个单独的功能上每天有百亿级的访问，同时还要保证99.95%的可用性。在海量系统上应对项目开发会有很严谨的规范，都说要尽可能少的变化，因为90%-95%的错误都是在变更中产生的，如果系统一直不变更会获得非常高的稳定度，但是微信就是要在悬崖边跳舞。微信的研发团队要做一些事情，让敏捷开发变得更简单。如何做到这一切？周颢认为，首先，必须建立起一种狂热的技术信念，就是一定是可以做到的。然后，需要用一些稳固的技术（理念）来支撑，例如大系统小做、让一切可扩展、必须有基础组件、轻松上线（灰度、灰度、再灰度，精细监控，迅速响应）……等等来支撑。四大法器：大系统小做、让一切可扩展、要有基础组件、轻松上线大系统小做当设计庞大系统的时候，应该尽量分割成更小的颗粒，使得项目之间的影响是最小的。一切可扩展：在高稳定度、高性能的系统中间，为了稳定性能把它设计成不变化的系统，但为了支持敏捷需要让一切的东西都要变得可以扩展。必须建立基础组件：要解决复杂问题的时候，需要将已有的经验固化下来，固化下来的东西会成为系统中的一部分。轻松上线：当做了变化并把它从开发环境中部署到现有的运营环境中去，在这个过程中，“灰度”这个词非常关键，就是在黑和白之间的选择，必须要变成一种小规模尝试，再逐步扩展到海量过程中的一个问题。大系统小做――仅仅把模块变得更为清晰，这在海量系统设计开发中是不够的，还需要在物理环境上进行分离部署，出现问题的时候可以快速发现，并且在最快的情况下解决掉。大系统小做，混搭模式将不同的应用逻辑物理分割独立出来，用户注册登录、LBS逻辑、摇一摇逻辑、漂流瓶逻辑、消息逻辑独立开来。把关键的逻辑混搭在一起，当所有的逻辑部署在同一个服务器上，确实也会带来很大敏捷上的好处，因为不需要额外的考虑部署和监控的问题。在整个微信的逻辑中，可能现在已经有上百种不同的逻辑，因为会在逻辑的分割上拆分成8-10种做分离部署。一切可扩展――网络协议可扩展、数据存储可扩展扩展的关键点有两块。一个是网络协议需要扩展，当要升级一个新功能的时候，会有一些比较大的困难，所以所有协议设计都比较向前兼容，但是向前兼容还是不够的，因为网络协议设计本身有非常多的功能也会有比较大的字段，相关的代码可能会有数千行，这一块不能通过手写方式完成。可以通过XML描述，再通过工具自动生成所有的代码，这是微信获得快速开发的一个重要的点。另外一块就是在数据存储方面是必须可扩展的。在2005年绝大多数海量系统的设计都是采用固定字段的存储，但是在现代系统中会意识到这个问题，会采用KV或者TLV的方式，微信也做了不同的设计。把复杂逻辑都固化下来，成为基础软件在微信后台会有几种不同的基础组件，大致包括：Svrkit――Client/Server自动代码生成框架:10分钟搭建内部服务器LogicServer――逻辑容器：随时添加新逻辑OssAgent――监控/统计框架：所见即所得的监控报表存储组件――屏蔽容灾/扩容等复杂问题灰度、灰度、再灰度在变更后的部署方式上，微信在一些规则会限定不能一次把所有的逻辑变更上去，每一次变更一小点观察到每一个环节没有问题的时候，才能布局到全网上去。微信后台每一天可以支撑超过20个后台变更，在业界来说，通常做到5个已经是比较快了，但是微信可以做到快4倍。腾讯内部的上线系统而所谓灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。（在腾讯，灰度发布是最常采用的发布方式之一）孙子兵法：古之所谓善战者，胜于易胜者也常识上，解决一个复杂问题的时候，会用高明的技巧解决复杂的问题，这个不是微信团队的目标，他们追求的要做到让所有问题很自然和简单的方式解决掉。在周颢看来，微信架构的技术复杂点在四个要点：协议、容灾、轻重、监控。微信架构协议：手机终端跟后台服务器之间的交互协议，这个协议的设计是整个系统的骨架，在这一点做好设计可以使得系统的复杂度大大降低。容灾：当系统出现了若干服务器或若干支架（宕机的时候），仍然需要让系统尽可能的提供正常的服务。轻重：如何在系统架构中分布功能，在哪一个点实现哪一个功能，代表系统中间的功能配置。监控：为系统提供一个智能仪表盘。在协议设计上，移动互联网和常规互联网有很大的区别。首先有CMWAP和CMNET的不同，在中国现在有相当多的手机用户使用WMWAP连接，还有就是在线和离线的概念，当QQ下线的时候叫离线，当你登录的时候叫在线。但是在移动互联网这两个概念比较模糊。从微信的设计中，不管在线还是离线系统表现都应该是一致的。还有一个是连接不稳定的问题，由于手机信号强弱的变化，当时信号很好，5秒钟走到信号不好的地区，连接就必须断掉。这个中间带来不稳定的因素为协议设计带来较大困难。此外就是资费敏感的问题，因为移动互联网是按照流量计费的，这个计费会使得在协议设计中如何最小化传输的问题。最后就是高延迟的问题。对此，业界标准的解决方案：Messaging And Presence Protocol：1)XMPP，2)SIP/SIMPLE。它的优点是简单，大量开源实现。而缺点同样明显：1)流量大：状态初始化，2)消息不可靠。微信在系统中做了特殊设计，叫SYNC协议，是参考Activesyec来实现的。特点首先是基于状态同步的协议，假定说收发消息本身是状态同步的过程，假定终端和服务器状态已经被迟了，在服务器端收到最新的消息，当客户端、终端向服务器对接的时候，收取消息的过程实际上可以简单的归纳为状态同步的过程，收消息以及收取你好友状态更新都是相同的。在这样的模式之下，我们会也许会把交互的模式统一化，只需要推送一个消息到达的通知就可以了，终端收到这个通知就来做消息的同步。在这样的简化模式之下，安卓和塞班都可以得到统一。这样的系统本身的实现是更为复杂的，但是获得很多额外的好处。让剩下系统实现的部分更加简单，简化了交互模式，状态同步可以通过状态同步的差值获得最小的数据变更，通过增量的传输得到最小的数据传输量。通过这样的协议设计，微信可以确保消息是稳定到达的，而且是按序到达。引用一句俗话：比它炫的没它简单，比它简单的没它快，没谁比他更快，哪怕在GPRS下，微信也能把进度条轻易推到底。追求完美设计的团队不能胜任海量服务在容灾之前面向最坏的思考，如果系统真的挂了，需要做一些事情，首先是防止雪崩，避免蝴蝶效应。如果关注春节订火车票就知道了，用户的请求量会因为系统服务不了而不断的重试，意味着发生雪崩的时候，系统可能会承载原先3-10倍的流量，使得所有的事情更加恶化。所以微信有很多“放雪”功能的设计。第二个词是柔性可用，在任何的系统中不要追求完美设计，追求完美设计的是团队是不能胜任海量服务的。如果在一个系统出现问题的时候，这个系统就挂了，那么这是一个不好的设计，最好的做法是提供0-1中间的选择。举一个例子，当一个用户向另外一个用户发消息的时候，可能会通过一个垃圾信息过滤的检测，如果垃圾信息过滤这个模块突然挂掉了，这个消息难道就不能达到了吗？在这样的情况下，要忽略掉这个错误，使得消息正常达到对方。要精确定位出哪一个环节是最为重要的，把不是重要的错误尽可能的忽略掉。当不能做到完美的时候，尽可能为用户提供服务。另外一个重要方面叫做“保护点前置”，最前的一个点就是终端，在手机终端上蕴埋更多的保护点，这样会为用户系统赢得更大的处理空间。如果终端具备这样的能力，会获得更大的反应空间。周颢介绍了在微信上具体容灾设计的做法。在所有的容灾中存储层的容灾是最难的，一个系统的设计分为三层：接入层、逻辑层、存储层。接入层和逻辑层的容灾都有比较成熟的方案。逻辑层的容灾相对来说比较简单，尽量不要有状态的设计，比如说当你做上一个请求的时候，会保持一些状态，要使得下一个请求发到下一个服务器。如果任何一个请求之间互相不关联的话，这个就是无状态的设计，只要做到这一点逻辑层的容灾可以随意的切换。在回到存储层本身的容灾设计上，相对来说困难一些，但是微信研发团队采用了一些技巧，叫分而治之，分离业务场景，寻求简单的设计，并不会寻求大而同一的解决方案，因为这样会使得系统的复杂度大幅度上升，而微信会尽可能把产品拆细，寻求简化的设计。首先是主备容灾，这是最常见的方案。在有一些业务场景中是可以容忍最终一致性的，比如账号系统的设计，每天写入账号系统的请求是非常少的，但是访问的请求非常多，这个差异可能会达到数万倍的规模，在这样的场景下，微信会在账号系统中采用简化的方案，也可以获得比较大的稳定度。SET模型+双写第二种容灾的模式叫双写，两台Master的机器，当一台机故障的时候，另外一台机还是可以接收到写请求，当两台机交错启动的时候，会得到数据的丢失。但是有一些场景是可以容忍轻度数据丢失的，比如说会有一个存储专门记录用户终端的类型，比如说安卓还是塞班以及他们使用终端的微信版本是什么，这样的数据是可以容忍轻度数据丢失的，因为偶尔有一些丢失的话，下一次访问会把这些数据带上来，会尽快的修复所有的数据。双写也是非常简单的模式。微信的研发团队做了一个叫Simple Quorum的机制，在微信的后台中，同步协议有一个很重要的基石叫序列发生器，这样的一个序列发生器需要有极高的稳定度。首先可以看到序列号有一个特点永远是递增的，用递增方式往前推进的时候，最大的序列号就是最新的系列号。有一个毕业才加入广研的毕业生想到一个绝佳的方案，按SET分布，从2G减到 200K。前轻后重，功能点后移周颢还谈到了轻重的概念。这个概念的提出主要是从终端本身的一些困境所带来的。首先在终端上需要表现最多的一个产品的逻辑，逻辑非常复杂，变更的成本也非常高，当需要修复的时候必须发布一个新版本，这个新版必须由自己下载才能完成，下载的成本非常高。在这样的前提下，如果手机终端产生了任何变化的时候，如果这个变化有非常大的问题就会有极大的困境，所以需要在每一个发布之前做一些充分的数据，确保不会发生致命问题。如果一旦出现致命问题难以修复，需要把关键的点从终端移到后台实现，把功能点后移，来充分发挥后台快速变更的能力。接入优化：从GSLB到IP重定向在接入层的优化，速度很重要的因素，是不是能够就近接入一个最优的节点，比如说移动用户最好接入移动的节点，海外的用户可能需要寻找更佳的路由，有的时候可能无法自动做到这一点，一点是在终端上做测速，微信会通过在后台IP逆向的能力，通过后台指挥微信终端联网的能力，寻找最优的接入点。上图就是每分钟收到同一项指令曲线的报表。如何解决“偷流量”的问题――当国内类微信类产品发布的时候出现一个大的问题就是“偷流量”，当用户在某一些逻辑下进行一个死循环，不断访问某一些数据，这样的死循环是非常可怕的，如果在用户不知觉的情况之下，可能会在一个小时之内偷到数10兆甚至数百兆的流量。有非常多业内的同行都需要花大量的精力解决这个问题，微信研发团队用了非常强大的方式解决它。通过在后台建立起严厉的监控系统，对每一个用户的行为做一个监控，当发现异常的时候，后台会给终端发出指令，使得微信终端在一段时间无法联网，但是可以保证用户流量不会白白的使用掉。功能适配的例子――第一期微信版本发布的时候，当时没有群聊的功能，第二版发布的时候做了这个功能。当时有两个选择，对于早期版本的用户，因为不支持群聊，就无法享用到这个功能，但是微信希望提供更好的选择，想让早期不支持群聊的版本，也可以被拉到一个群里面收消息、发消息，通过后台功能的适配也能做到这个事情。分而治之，把监控嵌入基础框架对于一个海量系统来说，一个精密的仪表盘非常重要。监控是非常痛苦的，对于这样一个系统来说，每小时会产生数百G的监控日志。微信希望在1分钟之内监控的数据就能够显示在报表上，因为只有这样的精准和实时度才能够赢得处理故障的时间。微信会做关联统计，通过摇一摇加了好友，他们活跃度如何，过了一段时间他们的活跃度变化情况又是如何。这种需求是需要通过大量日志的关联统计来获得的。研发团队也花了一段时间来理解这个问题，发现了中间一个重要的经验叫做“鱼和熊掌不能兼得”。为了让监控数值更敏感，需要把监控细化再细化，上面数据表示每一栏子系统的数据，下面这个是按微信版本号来划分的，这里的数据项是非常多。微信还需要采集一些异常的点，如果有异常的话会发布紧急的版本，尽可能快的替换它。对收发消息延时做的监控，比如说0―1秒端到端的速度，会对不同的区段做一些统计，当某一个环节出现异常的时候，通常会在中间的延时上体现出来。有一个很重要的点叫自动报警，现在有数千项的数据，不可能每一项都靠人工去看的，必须要跟自动报警相关联，微信有一些智能的算法，是不是在正常的范围内，跟历史的数值进行对比，如果有异常的话，会通过短信、邮件还有微信本身来发出报警信息。把监控嵌入基础框架微信会把监控嵌入到基础框架里面去，因为并不是每一个人都会意识到在需要的地方嵌入一个监控点，所以在基础框架本身内置很重要的监控点，比如说这个表上的栏目，非常多的栏目大概会有数百项的栏目，都不需要程序员自己去写，当用基础组件搭建一个系统的时候，就可以直接观测系统数据。在谈到微信未来的技术挑战时，周颢首先希望能够让微信成为可用性99.99%的系统;设计出面向现在10倍容量的系统以及完全的容灾。
版权申明：本站文章部分自网络，如有侵权，请联系028-6，我们收到后立即删除，谢谢！
特别注意：本站所有转载文章言论不代表本站观点！本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。
西部数码（west.cn）6月1日消息，“云服务”已然不是新鲜词，
在当下的互联网时代，尽管云主机凭借其快速、稳定、安全等特
安全组是西部数码上线的一项公共网络安全防火墙。可对一台/组
Copyright & &&版权所有
电话总机：028- (20线)
400电话：400-028-5800为什么爱看游戏直播？如何提升直播平台用户体验？
小编要问大家：为什么爱看游戏直播？答案无非以下几种：1.自己手残，看大神学技术。2.没时间，过眼瘾。3.有美女!有美女!下面就让小编为大家介绍一下游戏直播的具体内容吧！
美女配游戏，既养眼，又过瘾，每一个游戏直播间都是男人的天堂。最近，龙珠直播大批韩国人气主播入驻，各个身材完美，脸蛋精致，让宅男们欲罢不能。
然而：当你正看到精彩之处，屏幕突然这样&&&
毫无征兆，悄无声息，它就这样出现，让你的激情破碎!!!
是不是犹如晴天霹雳?是不是有想砸了电脑的冲动?是不是有想灭了后台技术人员的心?遥想前些天国民老公的某熊TV公测当天仅开启半小时左右，网站便频繁出错、用户无法登录、注册、进入直播间间歇性报错等技术问题，虽然最后有66部iPhone6s慰劳，但你以为这样就能抚慰宅男受伤的心灵么?
留住用户第一步，视频流畅技术酷。视频卡顿让多少人饱受折磨，完美流畅、五星级观看体验的需求亟待解决。那么问题来了，谁能拯救?
想要留住用户，首先要让用户有好的体验。就在前几天，国内知名游戏、电竞赛事直播平台&龙珠直播&的CTO谭振林做客了这么一档节目&&《云会客厅》，与腾讯云副总裁曾佳欣面对面对话，分享了视频直播平台如何才能提高用户体验的技术秘笈，嗯哼!全部都是干货!
秘笈一：与腾讯云合作，400+CDN给网速插上翅膀
谭振林认为，电竞行业这几年的快速发展有一个很大的功臣，这个功臣就是云计算。龙珠直播的迅猛发展离不开腾讯云的支持，双方有着全方位的合作，包括视频解决方案、内容分发服务(CDN)、安全服务和运维服务，尤其是视频服务，腾讯云为龙珠直播带来了包括直播、点播在内的一整套的互联网+视频解决方案。
这就说到了重点，大家都知道，视频直播在计算、存储及网络等方面，都有很高的要求，是个高冷的天蝎座美女。腾讯云具备卓越的音频信号处理算法，开放了行业最多的、超过400个流媒体加速节点，这就有效的确保了龙珠直播终端玩家流畅的观看体验。
不仅仅这些，在长期合作中，腾讯云为龙珠直播提供了超过5Tb的出口宽带，并可根据需求不断扩容、配备了超过10000台的计算集群网络，腾讯云更为龙珠直播解决了视频点播业务中繁重的转码、分发等底层基础业务，节省了大量的服务器成本投入和人员投入，使龙珠直播能够更加关注业务的发展。
秘笈二：数百G级别DDOS防御，保证平台信息安全
腾讯云在保障平台流畅直播的同时，更能够为龙珠直播提供上百G级别的防DDoS攻击能力，避免黑客、DDOS的攻击，以此来保证用户信息的安全，就好比是龙珠直播的&金钟罩&。
例如，在前不久的LOL龙珠直播狂欢夜上，龙珠直播平台同时在线人数突破313万，面对如此庞大的用户访问量涌入，在大流量高并发情况下，龙珠直播的系统后台却依旧保持平稳运行，并没有出现宕机、卡顿等棘手问题，就是依赖于云服务技术的保障。
秘笈三：背靠企鹅好过冬，腾讯优势资源强力支持
刚起步的龙珠直播青涩懵懂，电竞行业里视频人才匮乏。除了技术方面的助力，腾讯云就像一个兄弟，为龙珠直播提供了很多同行机会的介绍、相应的论坛、活动，而且在企业发展遇到相关技术难题时，腾讯云更是帮助龙珠与相关领域的专家或企业牵线搭桥，很快解决问题。
各行各业初创的小伙伴们，还在为业务发展之快，研发技术跟不上节奏苦恼吗?文章都看到这里了，还在等神马，立刻去拥抱云计算，赶紧和腾讯云联姻，才能从此走上人生巅峰。
不要问我是谁，我叫雷锋!
<div class="<div class="
最新安卓游戏排行
类别：角色扮演
类别：休闲益智
类别：休闲益智即构ZEGO：直播答题的痛点不止是低延迟和高并发
14:11:37&&来源：中华网&&编辑：
& & & & 【每日科技网】&　　2017年刚刚过去，在线抓娃娃热热度还未完全消减。新年伊始，大家还在回首总结、展望未来、好奇着2018年会有什么风口的时候，一场以《冲顶大会》、《芝士超人》和《百万英雄》为代表的全民狂欢直播答题的旋风就这样席卷而来。
　　高额奖金的诱惑，超低的参与门槛，王思聪的微博助推，邀请好友获得复活卡的社交裂变，多种因素加持下，这种新玩法迅速引爆了社交网络。
　　一直以来，竞技类答题对人们都极具吸引力，从《开心辞典》和《一站到底》在电视上火爆多年就能看出来。而直播答题APP将在线答题、知识付费、视频直播等众多火爆元素连结在一起，极有可能成为2018年的第一个风口。
　　风口背后，直播答题类APP的技术痛点
　　目前，这类直播答题APP的玩法很简单，每天举行几场答题直播，每场设置几万到几百万不等的奖金，1场12道题，每道限时10秒钟，全部答对者即可平分奖金。
　　直播答题的应用场景大概可以分为3类：
　　1)直播答题场景，单向直播和互动答题结合，主持人侧把题目实时地推送到直播间内所有用户，在限定时间内(10秒)，用户侧提交完成的问题答案，主持人能实时看到统计数据。
　　2)明星连麦答题，连麦直播和互动答题结合，除了基础的直播答题外，主持人邀请明星加入直播间，明星参与答题而且和主持人连麦互动，直播间内的用户能看到明星的视频画面和答题的实况，大大提高节目的观赏性和刺激性。即使是被中途淘汰的用户也会有耐心继续看完这个直播版的《开心辞典》节目。
　　3)组团群聊答题，视频群聊和互动答题结合，除了基础的直播答题外，多个用户线上组团加入视频聊天室协同答题，在视频聊天室内既能实时看到主持人和题目，还能群聊讨论题目答案并有带头大哥去操作答题。这个场景和2017年的狼人杀场景十分相似。
　　虽然直播答题的玩法简单，但是技术实现可一点都不简单。结合上面的应用场景，直播答题APP在实现上有如下4大痛点：
　　1)低延迟，无论是视频还是答题
　　答题的窗口时间只有10秒，读题时间4秒，思考时间3秒，选择时间1秒，满打满算都要8秒才能回答一道题目。如果延迟超过2秒，那么用户看到题目的时候已经比主持人的节奏落后2秒，那么用户就少了至关重要的2秒答题。
　　2)直播与答题同步
　　大部分的解决方案是把直播和答题消息分开实时音视频和IM消息两条通道来传输，直播与答题的同步就比较困难。如果直播和答题不同步，往往会出现主持人说开始答题，答题框还迟迟没有显示，造成十分差的用户体验。
　　3)超强互动(答题互动 + 连麦互动)
　　直播答题场景中的互动比单向直播的互动强很多，主持人要在极短时间向百万级用户(芝士超人直播间人数107万)推送问题消息，用户在极短时间内向服务器回复答案，由服务器统计答案反馈给主持人。在连麦直播场景中，受邀的明星会加入到直播间来一起答题，明星会和主持人同框连麦互动，全体用户还能看到明星的答题实况。这种互动的难度比常规的连麦直播都还要高。
　　4)百万海量并发
　　百万级别的在线用户，海量并发的压力不然而喻。更加重要的是主持人要一键向百万级别的用户分发问题消息，百万级别的用户要在极短的时间内回复问题答案，这样活跃度的海量并发所产生的压力超出你的想象。
　　即构ZEGO直播答题方案剖析
　　这次直播答题风口的时间窗口比以往的风口都要短得多，有业内人士表示，直播平台早已经完成了流量和技术积累，短短十来天就出现百万级别的直播间，完全还在考虑要不要入场的团队惊呆了。这时候，自行研发直播答题方案根本不可能是选项，每一个团队都想着如何尽快上线产品，要么一飞冲顶，要么堕入凡尘。
　　为了响应这个市场需求，基于经过映客、花椒和一直播验证过的直播方案，即构推出了直播答题一站式解决方案。
　　即构直播答题系统架构图
　　即构视频直播的业务流程
　　1) 主持人通过语音视频传输通道向即构ZEGO实时网络进行推流。
主持人的语音视频流通过两种方式达到用户端，要么通过即构ZEGO实时网络，要么通过即构ZEGO实时分发网络，前者的延迟大约300毫秒，成本相对较高，后者延迟大约1秒，成本相对较低。
明星嘉宾和主持人连麦参与直播答题的场景中，明星嘉宾通过即构ZEGO实时网络推流，主持人通过即构ZEGO实时网络拉流，延迟平均300毫秒左右。
　　即构直播竞答的业务流程
　　1)主持人从即构客户的业务服务器拉取问题内容和问题ID，把问题ID通过语音视频扩展传输通道推送到即构ZEGO实时网络，这一步和推流同时进行，也就保障了语音视频流和问题ID的严格同步。
　　2)问题ID和语音视频流通过两种方式到达用户端，要么通过即构ZEGO实时网络，要么通过即构ZEGO实时分发网络，前者的延迟大约300毫秒，成本相对较高，后者延迟大约1秒，成本相对较低。
　　3)用户端获得问题ID以后，向即构客户业务服务器查询并获得问题内容，然后答题，最后分别提交问题答案。即构客户业务服务器统计问题，并且把结果返回给主持人端。
　　即构直播答题方案的关键点
　　1)完美地帮助即构客户解决瞬间百万级问题推送的海量并发问题。要知道，在主持人按下按键向一百多万个用户推送问题的时候，极短时间内从单点向海量多点推送消息会产生难以想象的压力，这是一个关键的技术难点。
　　2)允许即构客户通过异步和服务器集群的方式来响应问题查询，还有问题答案统计。答题用户通过异步查询问题内容和提交问题答案的方式和即构客户业务服务器集群交互，避免了单点在瞬间承受海量数据并发的压力。
　　3)允许即构客户完全地保护问题内容的私密性和安全性。在即构的实时网络内只传输问题ID，允许即构客户完全掌控问题内容的私密性。
　　4)语音视频数据和问题ID通过实时信道传输和同步，完美地解决了语音、视频画面和问题同步的问题，保障优质的用户体验。
　　即构直播答题一站式方案
　　在过去两年，即构的直播方案已经得到了直播平台的验证。据了解，第一梯队的直播平台，比如映客、花椒、一直播、酷狗、六间房、陌陌、全民直播、Blued和喜马拉雅FM等都在使用即构的视频直播方案。
　　在其直播方案的基础上，即构针对直播答题的场景需要，推出直播答题一站式方案，完美地解决上述4大痛点。
　　1)超低延迟
　　在明星答题和组团答题等互动场景，即构直播答题方案的延迟达到300毫秒;在用户答题的互动场景，延迟在1秒以内。这种延迟水平可以很好地满足直播答题的各种场景需求。
　　2)直播与答题同步
　　即构的实时网络为语音视频数据和答题信息实现了良好的同步机制，让用户纹丝合缝地和主持人互动答题。答题信息既可以作为独立的图文消息来传输，也可以作为视频画面的一部分动画来传输，大大地增加答题的趣味性。
　　3)超强互动(连麦互动和答题互动)
　　即构的连麦互动直播方案在过去两年经过了映客、花椒和一直播等平台的验证，花椒直播曾经使用即构的连麦直播方案举办过各种K歌海选活动，并且获得巨大的成功。即构的实时网络无论传输语音视频数据还是答题数据，都可以实现超低的延迟，从而让主持人、明星嘉宾和答题用户之间进行超强互动。
　　4)百万海量并发
　　针对直播答题的高并发挑战，即构也解决方案是经过验证的。即构的核心研发团队来自腾讯QQ，早已经历了QQ亿级并发架构的挑战，在高并发架构上有着丰富的实战经验。更重要的是，即构的直播方案从设计之初，就是面向海量并发架构的，并且早已经过映客、花椒、一直播等众多头部直播平台亿级用户的验证。
　　另外，即构直播答题方案提供了丰富的直播前处理接口，包括主持人画面直播、主持人背景替换、片花/广告播放、奖金池信息展示、场景切换等功能。开发者只需4行代码即可轻松集成即构的直播答题SDK。
　　关于即构ZEGO
　　即构于2015年由QQ前总经理林友尧创立，A轮获得IDG投资，核心团队来自腾讯QQ，汇聚了来自YY和华为等厂商的语音视频人才。
　　即构ZEGO的市场定位
　　即构ZEGO致力于提供全球最清晰最稳定的实时语音视频云服务，助力企业业务创新，改变用户线上沟通方式。即构ZEGO深耕视频直播、视频社交、语音、线上抓娃娃和在线教育等领域，赢得了映客、花椒直播、一直播、喜马拉雅FM、陌陌、自由之战2、和好未来等厂商托付和信赖。
免责声明：本文仅代表作者个人观点，与每日科技网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
本网站有部分内容均转载自其它媒体，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责，若因作品内容、知识产权、版权和其他问题，请及时提供相关证明等材料并与我们联系，本网站将在规定时间内给予删除等相关处理.