2015届校招腾讯校招笔试面试大礼包_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
2015届校招腾讯校招笔试面试大礼包
上传于||文档简介
&&腾​讯​校​招​笔​试​详​细
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩140页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢点击上方“蓝色字”可关注我们！5月5日，腾讯视频“下一站，越作越嗨”综艺先锋汇上，不仅公布了大批独家网络综艺，更提出“网综不仅是要改造，更是对受众体验感的重新定义”的观点。5月以来，腾讯、爱奇艺、优酷土豆等多家视频网站相继加码网络综艺节目的投入，一大波新网综上线在即。热潮下，网综又将迎来何种体验令人期待。事实上，随着视频网站的崛起，不仅网综体验将被重新定义，版权综艺的体验也在持续升级中。以腾讯视频为例，背靠腾讯系大平台，在版权综艺的互动上从未停止，不断刺激用户肾上腺。《奔跑吧兄弟4》+花样互动，升级体验助力节目登顶2016年4月，《奔跑吧兄弟4》王者归来，终结了第一季度以来该档期收视被多档节目瓜分，却无人称王的颓势。众所周知，《奔跑吧兄弟》系列自播出以来，凭借新颖的节目内容及创新好玩的游戏环节早已成功俘获大批年轻观众的心。腾讯视频作为《跑男4》全网首播平台，在第一时间送上精彩节目的同时，不忘解锁互动姿势，让广大观众看得精彩，玩得开心。此次，腾讯视频特别打造《奔跑吧兄弟4》专属页面，覆盖了节目所有相关内容的同时，为广大观众精心设计了众多有趣的互动环节，比如，发起网友票选最喜欢的跑男扮相，引发观众大讨论。在弹幕成为观看综艺标配时代，腾讯视频也进行了新功能的开发，不但让每条弹幕能够被其他网友点赞，而且设立弹幕彩蛋。观众在聊弹幕的时候，输入的内容如果含有关键词即可激活弹幕彩蛋，例如输入baby、郑恺、邓超都会有不同形式的小图标刷屏。值得注意的是，腾讯VIP还可以享受跑男团专属气泡，让刷屏与众不同。为了方便追星族们边看节目边为偶像加油打气，腾讯视频别出心裁打造的“跑男明星耐撕榜”可谓是广大粉丝一重磅福利。数据显示，腾讯视频花样互动在服务于广大观众的同时，更创下了互联网播出版权综艺互动量的新高。截至目前（5月25日），节目播放量突破16亿，热门弹幕达470万，首期节目热门弹幕更是超过100万，“跑男明星耐撕榜”中七只人气值超过8亿，掀起全民互动新热潮。与此同时，腾讯视频多次邀请众兄弟与网友直播在线聊，更是将网友热情升至高潮。《燃烧吧少年！》+台网联动，深度参与让网友“玩转”综艺&不同于《奔跑吧兄弟4》的花样互动，2015年底，腾讯视频联合浙江卫视、天娱传媒出品的《燃烧吧少年！》则实现了台网深度合作，尤其是其对衍生节目的挖掘能力。节目内容上，腾讯视频在播放精彩节目内容的同时，推出了《少年频道》《燃烧吧梦想》两档深度定制衍生节目。《少年频道》是一档在《燃烧吧少年！》播出前的2小时直播节目，独具挑战性地邀请用户直接参与游戏，来决定少年的成败，让广大网友看到了“小鲜肉”更加真实的一面；《燃烧吧梦想》是一档揭秘台前幕后的衍生节目，满足粉丝观看正片后对掌门人、少年们、Boss团和掌门人助理幕后生活和互动的好奇心。这两档衍生节目可谓无死角地呈现了少年们在训练营中的生活、训练过程，也让网友了解和见证了偶像的养成。除了见证偶像养成外，网友们还能够直接参与偶像养成过程。观看节目时，标配的饭团、弹幕、精评等互动模式之外，网友可以订做火力榜，为喜欢的少年送道具，助其提升火力，少年们的火力值直接决定其能否参加每周《少年频道》的直播。值得注意的是，腾讯视频还携手机QQ热聊，邀请网友畅聊《燃烧吧少年！》。这种做法不仅挑逗了网民娱乐high点，更增强了节目用户的黏性，一举掀起跨屏社交互动潮。&综合看来，腾讯视频层出不穷的互动既飙升了节目热度，又博得用户好感。在这个观众口味越来越挑剔的时代，单纯的内容运输显然不再是良药，基于内容之上的体验牌是视频网站发展又一重要方向，接下来各视频网站的网综又将如何将体验升级引发期待。文章来源：中华网欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspective），我们将为您每天提供视频行业热腾腾的海内外行业热点，当然更多超实用的视频营销干货，我们也毫不吝啬地迅速给到您。至于最前瞻的行业数据、新锐的观察评论更加是我们的标配。不只兜售资讯，更量贩价值，腾讯视频与您一起前行。腾讯视频行业透视(TXVideoPerspective)　
　文章为作者独立观点，不代表微头条立场
的最新文章
点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect圣火熄灭，奥运开启亚洲时间。这个里约，受众对奥运的看法迎来了新时代的拐点。放眼下一个十年，身处体育营销风口之上，究竟如何才能飞得更高？腾讯智慧借数据之力，带你玩转体育营销的未来。点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect奥运虽然刚结束，足球热度还继续。英超、亚冠、世俱杯，各大联赛轮番至。2016下半场，看足球比赛更精彩！重温一番欧洲杯，展望一下新赛季。腾讯足球“比赛日”，“资讯+社交”让足球营销也精彩！点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect传媒内参导读：要让“星素结合”模式综艺诞生爆款，代入感、互动性和接地气三大要素缺一不可。不过该模式究竟能否引爆“综艺3.0时代”的到来，还要看平台用怎样的新鲜玩法释放数据与资源优势为节目效果进行加成。点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect当谈到羽皇的专属称谓“妖艳贱货”时，张若昀先是一声叹息，“其实最开始我就把他当做抖S、傲娇型来演的，没想到出来以后就成了妖艳贱货。”点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect奥运作为世界顶级体育赛事已经落幕，营销的顶级征程却才刚刚开始，在17天奥运营销赛事中涌现出一批营销创新冠军， 冠军不止于被加冕更值得一起分享。点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspect点击上方“蓝色字”可关注我们！ 文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspec点击上方“蓝色字”可关注我们！文章来源：欢迎关注“腾讯视频行业透视”（微信号：TXVideoPerspectTXVideoPerspective腾讯视频行业透视，这里有视频行业海内外热点、超实用视频营销干货、最前瞻行业数据、最新锐观察评论。不只兜售资讯，更量贩价值。热门文章最新文章TXVideoPerspective腾讯视频行业透视，这里有视频行业海内外热点、超实用视频营销干货、最前瞻行业数据、最新锐观察评论。不只兜售资讯，更量贩价值。后使用快捷导航没有帐号？
腾讯游戏数据自愈服务方案
查看: 21779|
评论: 0|来自: 腾讯游戏DBA团队
摘要: MySQL数据库基于binlog的数据同步方案，绝大部分情况下能保证主备数据完全一 致，但某些异常情况下，例如开发使用了unsafe statement的SQL（如带limit）及硬件故障等，都可能导致主备数据不一致。DBA通过checksum工 ...
1、引言在正式介绍项目背景之前，让我们先看一组数据：这是2个灰度的业务，都是Z3服务器，我们先只从时间成本的收益角度来看：⑴ A业务数据量是330G，数据不一致时通过重做slave需要150分钟左右，而借助pt-table-sync只需要5分钟，速度提升30 倍。⑵ B业务的量是93G，通过sync工具花费3分钟，而如果重做slave要35分钟，速度提升12倍。引入这组数据意在指明，整个过程不仅解放了DBA的双手，也符合”零运维”的趋势，数据自愈将是互娱DBA团队在未来提供的服务之一。2. 背景MySQL数据库基于binlog的数据同步方案，绝大部分情况下能保证主备数据完全一 致，但某些异常情况下，例如开发使用了unsafe statement的SQL（如带limit）及硬件故障等，都可能导致主备数据不一致。DBA通过checksum工具可以发现这些不一致的情况，但往 往需要重新做一个热备来恢复主备数据一致性，并且此过程可能需要10小时以上，而实际情况上主备数据通常仅有少量不一致，在线修复这些数据差异可以更高效 地完成一个数据一致的热备。3. 收益重做热备是我们目前首选的修复方案，但有时候没有备用的新机子却让修复步伐戛然而止，而 如果没有修复，倘若master故障，由于数据不一致，切换到slave是存在数据丢失的风险，那么又不得不执行修复，DBA就需要评估以前slave上 的连接切换到master是否会影响master的性能......这样DBA的工作量就无形中翻倍了。&我们在引言中也道出了sync工具相比传统的热备在时间上的收益，但除了这个，数据自愈服务的收益包括但不限于：业务数据更安全，恢复热备时间变短减少服务器资源，避免重做热备的机器申请提升DBA做热备的处理效率降低沟通成本，保证业务持续稳定运行4. 数据自愈解决方案我们从开源社区引入了Percona公司的pt-table-sync，该项目从2007年启动。下面我们对该工具的实现细节以及互娱DBA团队在此基础上进行定制开发的部分内容进行讨论。⑴ 流程图pt-table-sync有2种修复模式：replicate模式和非replicate模式，上图是replicate的，这也是我们所推荐，原因会在下文说明。这里，我们先对上图作下简要介绍① 对每一个chunk，再校验时加上for update锁，一旦获得锁，就记录下当前主库的show master status值。以我测试机的案例：SELECT /*water2.t:1/1*/ 0 AS chunk_num, COUNT(*) AS cnt, COALESCE(LOWER(CONV(BIT_XOR(CAST(CRC32(CONCAT_WS('#', id, name, CONCAT(ISNULL(name)))) AS UNSIGNED)), 10, 16)), 0) AS crc FROM water2.t FORCE INDEX (PRIMARY) WHERE (1=1) AND ((1=1)) FOR UPDATE & &SHOW MASTER STATUS & &② 在从库上执行select master_pos_wait()函数，等待从库SQL线程执行到show master status得到的位置，以此保证，主从上关于这个chunk的内容均不再改变。SELECT MASTER_POS_WAIT('binlog', , 60)③ 对这个chunk执行checksum，然后与主库的checksum进行比较DR：SELECT /*water2.t:1/1*/ 0 AS chunk_num, COUNT(*) AS cnt, COALESCE(LOWER(CONV(BIT_XOR(CAST(CRC32(CONCAT_WS('#', id, name, CONCAT(ISNULL(name)))) AS UNSIGNED)), 10, 16)), 0) AS crc FROM water2.t FORCE INDEX (PRIMARY) WHERE (1=1) AND ((1=1)) LOCK IN SHARE MODEDB：SELECT /*water2.t:1/1*/ 0 AS chunk_num, COUNT(*) AS cnt, COALESCE(LOWER(CONV(BIT_XOR(CAST(CRC32(CONCAT_WS('#', id, name, CONCAT(ISNULL(name)))) AS UNSIGNED)), 10, 16)), 0) AS crc FROM water2.t FORCE INDEX (PRIMARY) WHERE (1=1) AND ((1=1)) FOR UPDATE④ 如果checksum相同，说明主从数据一致，就继续下一个chunk⑤ 如果checksum不同，说明该chunk有不一致，深入chunk内部，逐行计算checksum并比较，如果发现某行不一致，则标记下来，继续检测剩余行，直到这个chunk结束。⑥ 直到修复该chunk所有不一致的行，继续检查和修复下一个chunk⑵ checksum算法有2个层次的校验算法，一是块级，一是行级。① 单行数据checksum值计算检查表结构并获取每一列的数据类型，把所有数据类型都转化为字符串，然后用concat_ws()函数进行拼接，由此计算出该行的checksum值，checksum默认采用crc32计算。下面是一个例子：SELECT /*rows in chunk*/ id, name, CRC32(CONCAT_WS('#', id, name, CONCAT(ISNULL(name)))) AS __crc FROM water2.t FORCE INDEX (PRIMARY) WHERE (1=1) AND (1=1) ORDER BY id FOR UPDATE;② 数据块checksum值的计算智能分析表上的索引，然后把表的数据split成若干个chunk，计算的时候以chunk为单位，可以理解为把chunk内的所有行的数据拼接起来，再计算crc32的值，即得到该chunk的checksum值。下面是一个例子：SELECT /*water2.t:1/1*/ 0 AS chunk_num, COUNT(*) AS cnt, COALESCE(LOWER(CONV(BIT_XOR(CAST(CRC32(CONCAT_WS('#', id, name, CONCAT(ISNULL(name)))) AS UNSIGNED)), 10, 16)), 0) AS crc FROM water2.t FORCE INDEX (PRIMARY) WHERE (1=1) AND ((1=1)) FOR UPDATE;⑶ 数据精确切分锁生命周期是我们一直很注重的问题。2010年底和2011年初，彼时我们刚刚引入了数据在线校验方案不久，在某业务每天日 常checksum时，DB有锁数据情况，导致TTC大量数据无法写入的告警，mk-table-checksum 1.2.8 版本数据分片方法不合理，当表数据分布非常不均匀时，数据切片会导致某些块包含的数据行过大，其中innodb行锁实现为索引间隙锁，checksum过 程会锁住chunk的数据。&felixliang修改mk-table-checksum的源代码，增加自定义 recursive_dynamic_calculate_chunks函数，实现了精确数据切片控制，该函数内部调用explain查看每个chunk 包含的rows，确保每个chunk中的行数不多于chunk-size参数设置的大小。当每个chunk切分均匀后，chunk数据校验在1秒左右完 成，锁数据情况几乎很难感知得到。&这个方案已经在腾讯游戏日常数据校验稳定运行3年多，我们相信该切分算法比官方默认的切 分而言更加健壮、同时也更加安全。而pt-table-sync同样会对不一致的表切分，由此我们迁移了该切分算法到pt-table-sync里面，这 也是”前人栽树，后人乘凉”的好处。⑷ 延迟控制这是为什么我们要采用replicate模式的必要性。&非replicate模式只是普通的线程请求行为，跳过MySQL的 Replication机制，本身不做延迟控制，然而，pt-table-sync在修复过程中是不能容忍从库延迟，如果延迟太多，pt-table- sync会长期持有对chunk的for update锁，然后等待从库的master_pos_wait执行完毕或超时，从库延迟越大，等待过程就越长，主库加锁的时间就越长，对线上影响就越 大。但是如果不等待，这个工具是无法验证主从数据是否一致。&但是，replicate模式下，补偿SQL是通过master上执行，生成 binlog，然后全量同步到slave，再在slave上回放，从而达到数据修复的效果。而数据安全是生命线，改错了master就得回档，就不是闹着 玩的。改错了slave不会对玩家有影响，对DBA是个保护。&那么，我们既想要replicate模式带来的好处，又想避免补偿SQL在master执行带来的风险不可控因素，该如何做？&互娱DBA团队通过修改get_change_dbh函数让最后一步生成的补偿SQL不走binlog，直接在slave上跑，从而避免在master上修复带来的数据安全问题。⑸ 普通索引pt-table-sync采用replace into来修复主从不一致，必须保证被replace的表有主键或唯一键，否则replace into退化成insert into，而insert是不能在master上执行，因为那样只会使不一致扩散。&对发现主从不一致的行，采用replace into 语句，在主库上执行一遍以生成该行的全量binlog，并同步到从库，这会以主库数据为基础修复从库：① 对于主库有的行而从库没有的行，采用replace在主库上插入（必须不能是insert）② 对于从库有的行而主库没有的行，通过在主库执行delete来删除&因为现网环境比较复杂，我们不能保证腾讯全球游戏每个表上都有主键或唯一键。因此，互娱DBA团队通过源码修改，当发现主库上的表没有唯一键时不会致命退出，而是继续执行，但采用了另外一种算法，即在slave上采用delete + replace 方式修补。⑹ 平台兼容我们先看mk-table-checksum与pt-table-checksum表结构。⒈ mk-table-checksumⅡ. pt-table-checksum是的，这2个表结构是不一样的，而pt-table-sync的replicate模式是直接读取pt-table-checksum的表，但是我们：① mk-table-checksum修复版已经集成到我们的GCS平台② 保留pt-table-sync最新版本的功能，避免引入mk-table-sync老版本bug基于上述2个理由，我们修改了find_replication_differences函数，让pt-table-sync兼容了mk-table-checksum，这样既能兼容现有平台的功能，又可以用得上pt-table-sync最新版本的新特性。&⑺ 超时控制在我们测试过程中，发现官方提供的超时控制--wait参数有”bug”① 对于非replicate模式，wait参数无效② 对于replicate模式，wait只能是0和非0，当非0时，任何值都是一样的下面是我们的测试现象所以，无论哪种模式，wait参数都是没有用的。我们修改源码来通过外部参数的动态控制超时行为：⑻ 差异修复线上某些高星级业务存在超过10G的大表，如果重新进行checksum的话，需要耗费大量的时间，因此我们只根据已经常态话了的checksum表进行修复。但pt-table-sync在Relicate模式下，差异修复（--where）与其是互斥关系，需要在代码层面进行变更，在测试之后，我们认为这个限制是可以去掉的。5. 小结数据自愈是数据校验的一种延续与补充，是随着后续业务全量铺开而互娱DBA团队不断定制开发演变的数据修复服务方案。在数据自愈的服务化之路上，相信我们会越来越好。欢迎加入本站公开兴趣群软件开发技术群兴趣范围包括：Java，C/C++，Python，PHP，Ruby，shell等各种语言开发经验交流，各种框架使用，外包项目机会，学习、培训、跳槽等交流QQ群：Hadoop源代码研究群兴趣范围包括：Hadoop源代码解读，改进，优化，分布式系统场景定制，与Hadoop有关的各种开源项目，总之就是玩转HadoopQQ群：&
上一篇：下一篇：