360网盾（360如何轻松抗住双十一流量）

　　360网盾（360如何轻松抗住双十一流量）
　　我们已经用起来了，是我们最喜欢听到的话，简简单单几个字的背后代表着沉甸甸的信任和托付。从今天开始，我们将通过相信开放的力量系列深度案例分享，从业务的角度，看看一个数据库为各行业用户带来的业务价值。本篇文章将介绍TiDB在360网盾业务、智慧商业业务、广告物料数据业务等核心场景的应用与实践。
　　以科技为驱动力让世界更安全更美好
　　360公司创立于2005年，是中国领先的互联网和安全服务提供商，先后推出360安全卫士、360手机卫士、360安全浏览器等安全产品。
　　随着全社会、全行业数字化程度的深化，大安全时代加速到来，360以让世界更安全更美好为使命，致力于实现不断创造黑科技，做全方位守护者的愿景，随之而来的业务发展也更加全面，包括：政企服务、金融科技、直播、个人服务、智能穿戴等多方面业务。业务挑战
　　网盾业务
　　360网盾是一款免费的上网保护软件，可以拦截木马、欺诈网站等等保护消费者不受到病毒及虚假网站的欺诈。它的运行机制是会针对每一条URL进行分析，经过网址检测系统判别后，能够精准识别出该URL属于哪个类别。对有问题的URL发布到云，其他安全服务商就可以通过订阅云服务，来检测相关的URL是否安全，以向自己用户提供更加安全的网页内容服务。
　　目前整个网盾业务核心场景可以分为以下四个部分：
　　网址威胁监测：每天入库1亿条数据，8亿多资源链接数据；
　　关联分析场景：进行大规模恶意网址、黄赌毒等网站的关联分析；
　　高速返回：897亿条数据表，每个场景100条数的查询需要在5秒内返回；
　　人工运营分析：每天每个人不断反复查询统计、分析。
　　针对业务爆发式增长的数据量，读写上MySQL已经出现瓶颈。例如磁盘空间，虽然可以通过分库分表的方式，拆分出来，但这对业务和DBA来说都是不小的工作量；最痛苦的无异于这些大表的改表，对一张大表执行DDL的代价是非常大的。总的来说，MySQL已经无法满足网盾业务需求，这对负责底层数据平台支撑的360云平台技术团队提出了新的选型需求。
　　360云平台负责对360集团各大业务线提供服务支持，涉及的数据库支持方案有：MySQL、Redis、MongoDB、ElasticSearch、Greenplum、PiKA。在经过充分的市场调研后，360云平台团队决定引入TiDB来满足业务这一需求。
　　整体架构如上，使用TiDB的业务主要有两种：
　　原有MySQL业务迁移。因单机磁盘受限，导致单实例磁盘无法支撑爆炸式增长的数据量，数据比较重要，需要备份和支持724小时的恢复。这类业务通过DM套件来实现无障碍迁移，1TB的导入时间在16小时，如果是比较大的数据源，且TiDB是全新集群，可以使用TiDBLightning进行数据导入，速度可以达到100G小时。
　　全新的业务。全新的业务目前全部都会放到TiDB中，这种业务数据量一般都会比较大，目前网盾业务有多张表都过10亿级别，其中有张表到达了100亿。智慧商业业务
　　360智慧商业依托覆盖用户全场景的互联网产品，为企业提供全生命周期服务。通过智能营销、企业服务、创新平台等多元业务布局，满足多维增长需求，全面连接用户与企业，打造共生共长的智慧商业生态，其中互联网广告是流量商业变现的重要途径之一，也是360集团重要的营收来源，其中涉及企业服务平台、广告主投放、算法策略、数据工程等多个方向。广告投放过程中实时离线报表业务以及广告物料投放对广告主来说是最重要、最核心的业务。
　　广告主实时amp；离线报表业务
　　广告主的实时报表业务流程：业务数据入Kafka，一条处理链路是通过Druid获取Kafka的数据提供实时分析，另一条链路通过Flink进行聚合后写入MySQL分库分表数据库，然后通过广告主维度提供实时查询需求。
　　广告主的离线报表业务流程：每天凌晨，数仓从MySQL分库分表中抽取前一天的所有数据入Hive，通过Spark或者业务程序统计聚合后将结果数据写入MySQL结果表，提供给离线报表平台或者Console平台查询。
　　报表作为广告平台的核心业务，面临的问题如下：
　　数据量大：总数据千亿级别，单表数据量1。21。5亿。
　　响应延时低：需要对用户的任意周期及关键词的查询进行实时反馈。
　　查询复杂：时间维度、地域、行业、关键词等等，同时满足多样化的展示。
　　架构复杂：基于MySQL的分库分表无法进行全局统计，只能基于广告主UID来出明细报表，全局的统计需要引入Druid来辅助处理；离线报表需要Hive数仓抽取全量数据来实现。
　　数据库选型：MySQLorTiDB？
　　在部署TiDB之前，360曾经尝试过单实例MySQL去应对业务需求，测试完后发现单实例MySQL压力较大，为了分散写压力，又必须走MySQL分库、分表这条老路，而且大数据量下的分库分表，经常需要变动拆分规则，每次规则变动都可能涉及到数据的重新搬迁，并且业务端还需要投入大量的人力去维护路由规则，并且要满足广告主的报表需求需要引入其他的数据库，离线ETL每天凌晨对MySQL的抽取造成网卡满载，也会影响了凌晨的其他业务操作。
　　部署TiDB后，TiDB良好的扩展性完全解决了分库分表的问题，同时经过性能压测，2小时1。5亿的数据存储（TPS：2Ws），整个系统负载完全满足业务需求，通过搭配TiFlash（TiDB的实时分析引擎插件），我们可以对合并后的单表进行各种维度的全局以及明细的实时分析，并且实现了离线报表的在线统计，免去了离线数仓这种T1的时效和同步流程，同时还提供金融级别的强一致性保证。广告物料数据业务
　　对于广告主而言，在搜索推广中，基于安全、精准、可信赖的新一代搜索引擎360搜索，通过关键词技术匹配，定位目标网民，精准展现企业推广信息，物料创意的作用则是帮助广告主吸引潜客，进而产生转化行为，比如注册、在线提交订单、电话咨询、上门访问等等。
　　目前360广告的物料平台会承载客户制作图片、文字、视频等的信息，支持对推广账户、推广计划、推广组、关键词、推广创意、高级样式各个层级的物料进行上传、下载、导入、导出、添加、编辑、删除等操作。
　　在使用TiDB之前，点睛物料数据底层使用了16套分库4的MySQL架构，每套分库MySQL单表已经到达10亿，单表数据规模在370G，对于单库QPS过万的SQL请求，MySQL表已经到达性能瓶颈，高峰期频繁抖动，并且新业务想对大表新增字段，由于硬盘空间不足，也不能支持新业务上线。如果继续使用MySQL，则需要将目前的16套分库拆分成64套分库（需要新增约上百服务器），除了新增服务器，迁移和运维成本也非常高。
　　360商业化业务线技术团队通过技术选型调研，最终确定了以TiDB作为物料平台底层的数据库。目前支撑物料平台的TiDB集群规模为63个节点，日SQL请求在70亿次以上，在刚刚过去的双十一QPS最高达25Ws，工作日99的SQL请求都在15ms以内，响应快、稳定性、扩展性都达到预期。
　　通过部署TiDB收益如下：
　　成本节约
　　相较之前MySQL部署模式，节约了40的服务器成本。
　　之前是业务维护的分库分表路由规则，现在对于业务来说都是一张表，提升了业务的开发效率，让研发更多的关注在业务上。
　　运维成本降低，TiDB提供丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景，提升了运维效率。
　　性能提升
　　618、双十一QPS最高能到25Ws，工作日99的SQL请求都在15ms。
　　相对于基于VIP切换的MySQL主从架构，TiDB的可用性超过99。95。
　　纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容，吞吐跟存储都可以在线平滑扩容，数据库扩展能力提升了12个数据量级。
　　未来，360技术团队也计划将TiDB推上360HULK云平台，为360集团安全大脑、360游戏、核心安全服务平台等更多业务线提供稳定可靠的数据库服务。与客户同行，相信开放的力量
　　每次数据库架构改善与落地，无论是TB级还是PB级，都需要付出努力，但这也值得每一个企业去实践。在当下这个时代，不管企业的规模如何，都要学会借助开源的力量，避免去重复的造轮子。每一个看似轻松的背后都有不为人知的努力，每一个看似光鲜亮丽的背后，都有不为人知的付出。分布式数据库建设之路道阻且长，TiDB愿与360及每个客户一起，携手并肩把事情做好。