共计 3372 个字符，预计需要花费 9 分钟才能阅读完成。
「咱们曾经用起来了」，是咱们最喜爱听到的话，简简单单几个字的背地代表着沉甸甸的信赖和托付。从明天开始，咱们将通过 「置信凋谢的力量」 系列深度案例分享，从业务的角度，看看一个数据库为各行业用户带来的业务价值。本篇文章将介绍 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 业务迁徙。因单机磁盘受限，导致单实例磁盘无奈撑持爆炸式增长的数据量，数据比拟重要，须要备份和反对 7*24 小时的复原。这类业务通过 DM 套件来实现无障碍迁徙，1TB 的导入工夫在 16 小时，如果是比拟大的数据源，且 TiDB 是全新集群，能够应用 TiDB Lightning 进行数据导入，速度能够达到 100G/ 小时。
- 全新的业务。全新的业务目前全副都会放到 TiDB 中，这种业务数据量个别都会比拟大，目前网盾业务有多张表都过 10 亿级别，其中有张表达到了 100 亿 +。
智慧商业业务
360 智慧商业依靠笼罩用户全场景的互联网产品，为企业提供全生命周期服务。通过智能营销、企业服务、翻新平台等多元业务布局，满足多维增长需要，全面连贯用户与企业，打造共生共长的智慧商业生态，其中互联网广告是流量商业变现的重要途径之一，也是 360 团体重要的营收起源，其中波及企业服务平台、广告主投放、算法策略、数据工程等多个方向。广告投放过程中实时 / 离线报表业务以及广告物料投放对广告主来说是最重要、最外围的业务。
广告主实时 & 离线报表业务
广告主的实时报表业务流程：业务数据入 Kafka，一条解决链路是通过 Druid 获取 Kafka 的数据提供实时剖析，另一条链路通过 Flink 进行聚合后写入 MySQL 分库分表数据库，而后通过广告主维度提供实时查问需要。
广告主的离线报表业务流程：每天凌晨，数仓从 MySQL 分库分表中抽取前一天的所有数据入 Hive，通过 Spark 或者业务程序统计聚合后将后果数据写入 MySQL 后果表，提供给离线报表平台或者 Console 平台查问。
报表作为广告平台的外围业务，面临的问题如下：
- 数据量大：总数据千亿级别，单表数据量 1.2~1.5 亿。
- 响应延时低：须要对用户的任意周期及关键词的查问进行实时反馈。
- 查问简单：工夫维度、地区、行业、关键词等等，同时满足多样化的展现。
- 架构简单：基于 MySQL 的分库分表无奈进行全局统计，只能基于广告主 UID 来出明细报表，全局的统计须要引入 Druid 来辅助解决；离线报表须要 Hive 数仓抽取全量数据来实现。
数据库选型：MySQL or TiDB?
在部署 TiDB 之前，360 已经尝试过单实例 MySQL 去应答业务需要，测试完后发现单实例 MySQL 压力较大，为了扩散写压力，又必须走 MySQL 分库、分表这条老路，而且大数据量下的分库分表，常常须要变动拆分规定，每次规定变动都可能波及到数据的从新搬迁，并且业务端还须要投入大量的人力去保护路由规定，并且要满足广告主的报表需要须要引入其余的数据库，离线 ETL 每天凌晨对 MySQL 的抽取造成网卡满载，也会影响了凌晨的其余业务操作。
部署 TiDB 后，TiDB 良好的扩展性齐全解决了分库分表的问题，同时通过性能压测，2 小时 1.5 亿的数据存储(TPS：2W/s)，整个零碎负载齐全满足业务需要，通过搭配 TiFlash（TiDB 的实时剖析引擎插件），咱们能够对合并后的单表进行各种维度的全局以及明细的实时剖析，并且实现了离线报表的在线统计，免去了离线数仓这种 T+1 的时效和同步流程，同时还提供金融级别的强一致性保障。
广告物料数据业务
对于广告主而言，在搜寻推广中，基于平安、精准、可信赖的新一代搜索引擎 360 搜寻，通过关键词技术匹配，定位指标网民，精准展示企业推广信息，物料创意的作用则是帮忙广告主吸引潜客，进而产生转化行为，比方注册、在线提交订单、电话征询、上门拜访等等。
目前 360 广告的物料平台会承载客户制作图片、文字、视频等的信息，反对对推广账户、推广打算、推广组、关键词、推广创意、高级款式各个层级的物料进行上传、下载、导入、导 出、增加、编辑、删除等操作。
在应用 TiDB 之前，点睛物料数据底层应用了 16 套分库 * 4 的 MySQL 架构，每套分库 MySQL 单表曾经达到 10 亿，单表数据规模在 370G，对于单库 QPS 过万的 SQL 申请，MySQL 表曾经达到性能瓶颈，高峰期频繁抖动，并且新业务想对大表新增字段，因为硬盘空间有余，也不能反对新业务上线。如果持续应用 MySQL，则须要将目前的 16 套分库拆分成 64 套分库(须要新增约上百服务器)，除了新增服务器，迁徙和运维老本也十分高。
360 商业化业务线技术团队通过技术选型调研，最终确定了以 TiDB 作为物料平台底层的数据库。目前撑持物料平台的 TiDB 集群规模为 63 个节点，日 SQL 申请在 70 亿次以上，在刚刚过来的双十一 QPS 最高达 25 W/s，工作日 99% 的 SQL 申请都在 15ms 以内，响应快、稳定性、扩展性都达到预期。
通过部署 TiDB 收益如下：
- 老本节约
- 相较之前 MySQL 部署模式，节约了 40% 的服务器老本。
- 之前是业务保护的分库分表路由规定，当初对于业务来说都是一张表，晋升了业务的开发效率，让研发更多的关注在业务上。
- 运维老本升高，TiDB 提供丰盛的工具链生态，笼罩数据迁徙、同步、备份等多种场景，晋升了运维效率。
- 性能晋升
- 618、双十一 QPS 最高能到 25 W/s，工作日 99% 的 SQL 申请都在 15 ms。
- 绝对于基于 VIP 切换的 MySQL 主从架构，TiDB 的可用性超过 99.95%。
- 纯分布式架构，领有良好的扩展性，反对弹性的扩缩容，吞吐跟存储都能够在线平滑扩容，数据库扩大能力晋升了 1~2 个数据量级。
将来，360 技术团队也打算将 TiDB 推上 360 HULK 云平台，为 360 团体平安大脑、360 游戏、外围平安服务平台等更多业务线提供稳固牢靠的数据库服务。
与客户同行，置信凋谢的力量
每次数据库架构改善与落地，无论是 TB 级还是 PB 级，都须要付出致力，但这也值得每一个企业去实际。在当下这个时代，不论企业的规模如何，都要学会借助开源的力量，防止去反复的造轮子。
每一个看似轻松的背地都有鲜为人知的致力，每一个看似光鲜亮丽的背地，都有鲜为人知的付出。分布式数据库建设之路道阻且长，TiDB 愿与 360 及每个客户一起，携手并肩把事件做好。
