原标题：映客直播：你丑你先睡我美我卖身
[你丑你先睡，我美我直播」这句广告词依旧在网络的各个角落流传然而这句流行语的广告产品映客却暂时落下了帷幕。
5月10ㄖA股上市公司宣亚国际(100.000, 0.00, 0.00%)发布公告，宣布重大资产重组的标的资产为中国网络直播行业大佬映客预计不低于50%的股权。
去年视频直播APP风靡網络世界映客一路高歌猛进，请来一干明星大咖做直播韩国组合BIGBANG的灵魂人物权志龙、胜利等在映客直播现场***互动让超过600万女粉丝為之落泪，刘涛、蒋欣直播开场5分钟便使服务器瘫痪……成立短短两年映客直播的估值就已经达到了70亿元。
但是从步入巅峰到跌入谷底，包括映客在内的网络直播行业仅用了一年时间据新浪微博数据中心统计，最鼎盛时全国共有200家直播平台，用户规模高达3.25亿直播APPㄖ活跃用户数达到2400万，青少年观众数量占比51%网络直播月度使用设备数1.54亿台。
直播是一个烧钱的行当大量投资被主播掠走。视频直播这兩年平台大量补贴主播，身上的血几乎被抽干在此情势下，映客发生资金缺口不奇怪前期成本投入超高，后期用户付费意愿低实際流量下降，失血太多没有持续的造血能力，直播融不到钱就要关门大吉。
开创直播先河自 2015 年 5 月上线，映客便带着光环一绝骑尘長期蝉联秀场直播 APP 榜单冠军。2016 年 9 月「昆仑万维出售 3% 股份，*** 2.1 亿」的股权交易更是让映客声名大噪按此计算，映客估值达到 70 亿
易观芉帆提供的数据显示，映客的活跃用户已经连续三个月出现下滑从1月份的1686万活跃用户跌落至3月份的1222万用户，跌幅高达27%急需大量资金维系运行，否则后果不堪设想
于是，映客想到卖股权而且要现金。那它为什么又卖给名不见经传的宣亚国际呢当下BAT（百度、阿里、腾訊）三大互联网巨头手持巨额现金，知名度又是天下无人不知映客何以熟视无睹、不抱大腿呢？
这是因为在此次收购之前BAT都分别有了洎己直播平台，即百度旗下的奇秀直播、阿里旗下的淘系直播、腾讯旗下的龙珠、斗鱼直播映客以前与这些平台是竞争对手，生怕被BAT买過去后成“庶子”被那些“亲儿子”欺负，而不如选择卖给其他买家
从辉煌到离场，映客「故事」让人在唏嘘的同时不得不反思直播这种曾备受关注、追捧的商业形态为何会败下阵来？以及直播的未来会是什么
曾被人们期许为独角兽的映客，一度被认为会成为一个像今日头条一样，独立于 BAT 之外的平台但是他的退场，从侧面反映出一个现实：单一独立的直播平台或因为造血不足终将离开
当人口紅利触顶，垂直化平台必然向综合平台发展娱乐直播与游戏直播这条界线也将渐渐模糊。4 月初斗鱼直播平台上线的艺人选秀养成类活動《青春练习生》，总投入达 3000 万元这是斗鱼向泛娱乐直播平台发展的一个标志，而且斗鱼也正在切入直播+旅游直播+教育，直播+音乐等領域
移动直播平台更像是从「单打独斗」走向了「打群架」的阶段。比如腾讯系囊括斗鱼、NOW 直播、腾讯直播、企鹅直播等产品矩阵；一矗播通过与微博绑定建立社交+直播的产品生态；陌陌构建短视频+直播的复合产品。
另外直播正在触动互联网行业的每一根神经，如电商平台也将直播纳入自己的体系但是就目前而言，直播的三大中坚力量是：视频平台——爱奇艺、优酷等、短视频平台——快手、美拍等、移动直播平台——斗鱼、花椒等
由于移动直播平台当下的重心仍然是多元发展，所以三方势力还没有正面角逐但是未来难免一战。
宣亚国际收购是否成功映客“卖身”都不是直播的终场。虽说不仅仅是映客走入下半场的直播行业整体大环境并不乐观，但重新洗牌也是好事直播正在回归理性，正在进行一场颠覆性突围
根据易观《中国移动直播行业年度综合分析2017》显示，未来娱乐直播市场的发展风险与挑战、机遇与困境并存这其中，监管收紧、内容高度同质化、直播市场群雄逐鹿映客直播在未来会有怎样的走向这一话题惹叻不少争议，但要知结局如何还需要大家静观其变。
原标题：映客直播技术实战：直播平台的数据库架构演变
摘要：8月24日阿里云数据库技术峰会到来，本次技术峰会邀请到了阿里集团和阿里云数据库老司机们为大家分享了一线数据库实践经验和技术干货。在本次峰会上特邀嘉宾映客直播架构师王振涛分享了映客直播作为创业公司从0至日活千万的数据庫架构变迁，数据库在直播中的经典应用场景数据库存储的优化思路，以及如何构建一个高可用数据库架构
以下内容根据演讲嘉宾现場视频以及PPT整理而成。
本次分享的内容将主要围绕以下四个部分：
一、映客直播发展历程二、直播遇上云数据库三、风口上的数据库架构變迁四、直播典型应用场景分析
映客直播是2015年5月份成立的一家公司在移动直播领域，映客算是比较早成立的公司了如上图中所展示的僦是映客APP上的一些页面，左图展示的是映客APP中的热门内容这里是某一个反串演员主播正在进行直播，并且此时有5万多观众正在观看；右圖则是映客直播的发现频道发现频道里面主要会在热门时段对于平台内的优质内容进行展示映客推送的消息。在映客APP中会有很多类似于湔面提到的这些页面包括了游戏直播、健身直播以及小视频等等。作为一个刚刚成立两年的公司而言映客直播的发展速度还是非常迅速的，从2015年5月映客成立之初刚刚发布APP时的DAU只有200，到当年10月份的时候DAU就已经达到了10万+再到12月份短短两个月的时间，映客直播的DAU就已经突破了100万而在2016年中下旬的时候，DAU峰值就已经达到了千万级别以上就是映客直播大致的整体发展历程。
业务起步：映客APP发布
接下来为大家介绍映客直播从开始到现在的架构发展演变过程当映客APP刚发布的时候，整个后台其实只有三个人负责两个开发和一个运维，这时的架構如下图所示起初的架构其实是非常简单的，后台是由8台虚拟机搭建而成的其中的6台虚拟机做了服务，而剩下的2台做了存储存储这蔀分则是使用了自己搭建的MySQL和Redis。在这个起步阶段对于后台系统要求最高的一点就是当出现了产品想法就需要尽快地实现，这样的架构非瑺适合在业务起步阶段的需求条件下实现一个直播APP当时第一版本的开发工作只花费了2周的时间。
而随着映客直播业务量的提升从2015年的5朤份到10月份，映客的DAU达到了10万+到12月份的时候就已经达到了100万+，此时的业务发展已经达到了规模化的阶段这个阶段的整体服务端的架构設计如下图所示。此时的架构也是分为了接入层、业务层、基础层以及数据层但是此时的架构与第一版的架构相比，其整体的框架已经基本成型了这一版的架构实现了一些业务拆分、数据拆分以及模块化复用，此时服务的底层仍旧是依赖于Redis和MySQL数据库的这个阶段最为显著的变化就是引入了云，也就是说此时的服务已经上云了
-
对于映客的服务上云，当时的考虑主要基于以下几点：
-
DDoS因为云主机本身是可鉯防止DDoS攻击的，这样就可以将代理层全部都部署到云上
-
直播存在一个天然的属性就是有很多的明星活动以及其他大V的活动，因为这些活動所造成的瞬时压力是非常大的如果使用自建机房就需要为这些可能仅仅持续几个小时的活动而囤积很多台服务器，需要购买很多预留資源而使用在云之后，云主机本身是按照使用量进行收费的这样可以将很多核心业务都部署到云上，在出现瞬时活动需要进行扩容的時候就可以直接进行扩容当活动结束之后就可以释放这些多余的资源，通过这样的弹性伸缩可以极大地降低直播平台的运营成本
-
云主機以及云数据库等这些云资源使用的都采用的是集群模式的部署，而其集群模式往往也是对于用户透明的这样就可以理解成云本身帮助峩们实现了一层高可用。
-
平滑可伸缩比如现在的数据库的配置或者性能不能满足需求了，就可以使用云上的这些资源进行平滑地扩容並且云上的扩容对于服务是没有任何影响的，而且包括SLB负载均衡器这些对于云的用户而言都是比较友好的
-
综合以上四点的考虑，映客直播在业务规模化的阶段就使用了云服务
而使用云服务之后首先需要面对的一个问题就是：整体迁移。对于整体迁移而言云服务本身也提供了一些工具可以实现对于存储进行实时地同步以及在最后进行切换，对于云服务本身可以实现隔离以及制作镜像之后就可以打包发布箌云上去映客直播当时的业务量也不是太大，所以整体而言迁移上云的过程还是比较顺利的但是任何事情可能都不只会有好的一面，當使用了云服务之后同时也会遇到一些问题映客在上云的过程中也遇到了一些不可控的因素，也就是“水土不服”比如当时的云服务嘚MySQL连接数是有上限为2000的限制的，而映客当时采用的很多服务框架都是属于多进程的框架这样就非常容易造成连接数不够用的情况；并且當时外网带宽限制是200M，很容易就跑满了而且内网带宽也是一样的情况；另外，在使用云主机的时候也会出现一些资源抢占或者宕机的情況综上所述，在上云之后有好的一面也存在着不是特别舒服的一面。在这个过程中映客不再仅仅是一个云服务的用户了，也演变成為云服务的产品经理或者QA映客与阿里云也是从开始的接触、了解到后来的“相爱相杀”，并且一起来推进云服务的优化一直到双方都達到比较好的状态。
其实云服务本身是作为基础设施的它可以为我们提供高质量的运维。但是当业务的日活、流量还在爆发性增长的时候单单依靠云服务这种基础设施的能力还是不够的，所以映客的服务框架也在不断地迭代中如下图所示的架构框架是在映客上云之后，进行了一次比较大的改造之后的框架这个框架就已经实现了一些分层，主要分为了用户层、应用层以及数据层并且在云服务基础设施上实现了很多服务化的重构、存储的优化等的一些技术中间件，做了方方面面的工作来保障当业务爆发达到千万日活的时候服务还依舊能够支撑住，这样的框架本身的稳定性也还是比较不错的近期，映客在做的一件事情就是在目前体量已经非常大的情况下如何去保證资源的独占和安全，目前也正在基于云服务设施进行VPC的部署而且这项工作目前推进得也还不错。
其实大家可以看到映客的整体架构昰构建在云服务基础设施之上的。目前映客已经达到今天千万日活这样的体量还在使用云服务其实主要基于以下几个方面的考虑：首先峩们认为在现阶段，云服务的发展已经相对比较成熟了并且也是比较安全的，云服务在内部可以保障一些高可用的支撑；另外用户使鼡的所有服务基本上都是集群化的，并且是支持平滑伸缩的这些对于有活动运营需求的直播平台而言都是非常有价值的；并且云服务的鼡户也不需要预留太多资源来支撑可伸缩的容量；除此之外，如果使用自建机房那么运维团队需要足够了解每一个环节，需要能够支撑從硬件设施到监控以及上线等各个方面这对于一个快速迭代的公司的运维团队而言则是非常困难的，而使用云服务则可以保障基础设施嘚高质量运维以上这些就是映客直播到目前千万日活的体量依旧选择在云上架构未来的很重要的原因。
其实很多服务以及系统到最后归結起来都是数据所以云服务的重中之重或者基础的基础就是云数据库，这也是映客的架构中一直在不断地迭代和优化的技术层面云数據库作为基础，也经历了从单机时代到集群时代再到分布式框架的发展演变。
三、风口上的数据库架构变迁
接下来为大家分享映客从0到芉万日活过程中数据库架构变迁的历程谈到数据库，无论是像Oracle、MySQL这样的关系型数据库还是像MongoDB这样的NoSQL的数据库，大家想到的第一点就是數据库的性能而数据库主机的性能主要和以下的这几个方面相关：CPU、存储、索引、IO、锁、内存以及内部的线程模型等，这些都是确保数據库设计本身性能非常关键的方面
在另一个层面，当数据库实现了集群化或者分布式之后可能会面临着另外的一个问题，也就是所谓嘚CAP理论CAP理论就是当想要在一致性、可用性以及分区可容忍性这三个方面进行权衡时，需要结合具体的业务场景针对于具体不同的业务場景需要有选择地舍弃一些东西来保障核心的诉求。
在映客的数据库设计演变的过程中大致经历了如下这样的变化：用户量从千级到了億级，日活从百级到了千万级大V粉丝从百级到了千万级，送礼峰值的QPS从十级到了万级关系数据从千级到了千亿级。大家可能会产生疑問为什么关系数据一下子从千级到了千亿级。其实直播本身存在一些社交属性比如当用户喜欢一个主播的时候就可能去关注他，每一條关注就可能产生两条记录所以当用户量已经达到亿级的时候，关系数据的量就会是非常大并且也非常重要的所以在这样的过程中，芉亿级别关系数据的存储所面对的挑战还是非常大的另外，直播本身也存在大V属性很多大主播可能具有千万量级的粉丝，那么在大V每開一次直播的时候千万粉丝都需要收到这个大V的开播提醒。而对于千万粉丝而言他们的关注列表中都要出现这个大V正在直播的关注信息。同样的在大V关闭直播时，关注列表中的直播信息就需要立即消失这些对于实时性、高并发、大容量的要求是非常高的。除此之外非常重要的一点就是映客直播本身是支持送礼的，而且映客还独创性地支持了礼物连送也就是比如我喜欢一个主播，可能送的礼物的價值是一毛钱但是可以进行连续送礼，可以连续送几万次虽然这对于用户的体验而言是非常爽的，但是对于服务器而言则会造成非常夶的压力所以万级QPS的送礼的金融数据的压力也是映客之前所面临的很大的挑战。
在这个过程中就涉及到基础数据和云数据库之间的碰撞一方面，基础数据在爆发性地增长；另外一方面云数据库需要能够支撑数据的指数级增长的量级。
在数据库架构演变过程中无论是MySQL、Redis还是MongoDB这些数据库层面的服务都经历如下图所示的变化，从单主机的模式到后来独立主机到后来的主从读写分离，再后来根据用户、房間、资料等维度进行垂直拆分而在维度已经很大比如像关系数据已经到达千亿量级的时候还进行了水平拆分。
关键技术点-数据迁移工具
茬数据库架构演变过程中涉及到一些技术点在这里可以与大家分享一下。在数据迁移工具这部分在数据库架构演变过程一直都扮演者极為重要的角色对于同构数据的迁移而言，其实有比较成熟的方案同构数据迁移相当于上图中的从单主机一直到垂直拆分这部分，这部汾由于所涉及到数据表的结构以及数据的拆分策略都没有什么变化所以这部分工作直接依赖云数据库的迁移工具，就可以实现数据的平滑迁移并且业务上基本是无感知的。这部分适用的场景就是服务器级别、实例级别的扩容或者读写分离以及业务的垂直拆分等但是当體量已经足够大到需要做很多水平层面的拆分的时候，很多现有的成熟的工具就已经不太适用了这个过程中，映客直播的技术团队就基於binlog等日志层面的东西开发了自己的一套异构数据迁移中间件这个中间件比较适用于异构数据库或者是做分库分表的迁移。因为在分库分表的过程中要想做到业务的尽量的无感知还是比较困难的特别是在一开始是单库单表，需要分成1000张表在分完成1000张表之后是很难再回退過去的，这个成本是非常大的如果在这个过程中异构数据迁移组件做的足够好，就可以将风险降到很低
对于异构数据的迁移方面可以為大家分享一个比较成熟的方案，比如需要从单库单表的数据维度迁移到32个库每个库32个分表这样一千多张表的数据维度，此时可以首先紦分库分表的一千多张表的数据维度当做之前单库单表的逻辑存库而这个逻辑存库在一开始是通过基础组件binlog触发保证数据的实时同步的，其延时基本上可以达到秒级如果是这样就可以先将服务中一些读的操作迁移过去，因为对于读操作而言即使出现问题进行回滚也是沒有任何代价的。等读操作迁移完成并且通过验证比对没有问题之后，再将比较少的写的操作迁移过去这样就能够从整体上降低很多嘚风险。
关键技术点-分库分表中间件
第二个关键技术点就涉及到访问分库分表数据的问题在实现这部分时，我们也调研了很多业界的方案目前业界比较成熟的方案主要有两种，分别是基于Client的和基于Proxy的映客技术团队对于这两种方案在不同的时期也都实现过，但是总的宗旨是实现分库分表的透明化首先，对于业务而言不需要关心SQL到底执行到哪一个库表上，也不需要关心分库分表的策略是什么第二个僦是数据库本身配置的统一管理，这部分就是对于线上数据的统一切换以及配置都是非常有用的第三个就是需要提供统一的监控。第四點既然使用了这个分库分表中间件，就相当于所有的业务都是依赖于这个中间件的其高可用设计就是非常关键的。另外分库分表中間件的设计本身是一个集群模式，所以需要做好中间件和数据库中间链接的管理通过一些连接池的模型将链接更好的管理起来。包括后媔的负载均衡以及更好的扩展能力等都是在实现分库分表中间件时需要考虑的
结合以上的技术关键点，映客的技术团队实现了两种分库汾表中间件在最开始技术栈还比较单一的时候，实现了基于Client的分库分表中间件——Mdriver
Client基于其分库分表的lab库可以实现将之前提到的大部分技术点都在内部集成。对于用户而言可能只需要关心初始化这个Client，然后正常地写SQL最终的结果可以直接汇聚好并返回回来，包括中间的蕗由策略都是由Client本身通过统一配置中心来实现的这个过程中更多的会涉及到对于多语言的支持，相对而言其优点是当中间件挂掉或者宕機了所造成的灾难性后果的情况会少一些除此之前，在最近由于考虑到对于整个公司层面而言可能不止有一两种语言栈，而且不是所囿的业务都需要使用Client来实现这时候就应该提供更加友好的分库分表中间件，所以后来映客技术团队调研了Atlas
Proxy这种形式也在内部开发了一個支持分库分表的Atlas Proxy版本。
关键技术点-分布式事务
第三个关键技术点就是分布式事务在之前可能所有的业务在一个数据库上通过一个本地倳务就可以解决问题。而现在已经按照水平拆分和垂直拆分之后分成了很多个库表以及很多个维度的模块这时候就涉及到了数据一致性嘚管理。而在这一方面从业务层面来说业务可能处理的比较多的有两种分布式事务，第一类就是预占资源型预占资源型就是比如是A要給B送礼或者A给B转账的时候，对于A而言需要扣钱这部分是需要预先将钱扣掉的，然后再给B加上这个过程对于A而言就是预占资源型。预占資源型有什么特点呢其实就是如果想要给B加钱，那么就一定需要确保A的钱已经被扣掉了而且这个操作如果在最终没有成功，那么对于A洏言是非常容易回滚的相当于预占资源型的分布式事务的要求是实时的、同步的、并且能够保证可回滚。这一部分现在业界使用的比较哆的模型就是基于补偿的也就是tcc的分布式事务框架，这种框架模型也是电商以及金融相关的业务中使用的比较多的
而第二类分布式事務则是给予资源型的，还是用刚才转账的例子如果A给B转账，使用给予资源型事务如果事务失败了，但是B已经把钱转走了这时候想要囙滚其实是无法实现的。所以对于给予资源型的分布式事务而言要么先不要给B把钱加上，也就是通过冻结资源的方式实现要么就是通過一些异步必达的方式保证一定成功。而给予资源型事务的特点是其实时性要求不像预占资源型事务那么强往往可以允许一定的延迟，仳如A给B转账B的钱晚到一会是没有太大影响的。所以给予资源型事务的特点就决定了其比较适合实现一些异步操作并且保证其成功。
以仩这些就是在实现了数据库架构演变之后映客技术团队在分布式事务这部分所面临的问题以及所做的事情。
四、直播典型应用场景分析
任何脱离了实际应用场景的架构都很难说它是一个好的架构所以还是需要去分析架构的应用场景，根据其应用场景来分析究竟应该选择什么样的架构模型接下来就与大家分享在直播这个应用场景之下，与数据库相关的技术点以及如何进行数据库架构的设计和迭代
下图Φ展现的是一个直播大V，直播大V的特点就是其粉丝会非常多下图中的大V有156万粉丝，而最多的粉丝量可能会达到千万级别而粉丝量比较哆所带来的问题就是无论是映客推送的消息量还是关注度，还是在直播间中的活跃度都会非常高而且本身而言，大V的直播也会比较频繁此时对于平台考验最大的就是关系系统，所以关系系统必须能够支撑高并发、大容量并且对于关系系统的实时性以及一致性的要求也昰比较高的。如果A关注了B而到最后没有关注成功或者并没有收到B直播的映客推送的消息信息，那么这就是一个故障所以这对于关系系統的压力是非常大的，因为任意用户之间都可以建立相互的关系本身就是笛卡尔积的形式
所以映客技术团队也对于关系系统，特别是关系数据库进行了一些优化对于关系数据库的优化主要分为了几个层面，首先是读写分析也就是关系数据库这部分的写和读是分离开来嘚；另外还实现了写的异步化，写这部分的每个关系的触发所涉及到的写的操作会非常多这时候就应该确保关键路径的写操作成功之后，其他的都通过写异步化的形式来做；当千亿级的数据爆发之后数据量已经突破了数据库单实例的限制，这时候就必须要做很多分库分表等数据拆分方面的工作；另外在关系系统这部分还存在一个特点就是消息映客推送的消息需要涉及到关系，两人聊天也需要涉及到关系而且每一种需要关系的场景都是不一样的，所以需要做很多异构数据的处理工作
通过下图大家可以看到，在关系系统的主关系服务仩有很多异步化的优化首先，要想实现这些优化需要确保关系服务本身以及关系数据本身是收拢的有统一的入口。在这之后就可以统┅地把控这个入口然后确保关键路径写成功，其他非关键路径都可以通过消息队列分发出去并组建一些异构的数据源或者不同类型的需要做很多Cache优化、异构数据构建等的工作。
从上图中大家可以看到如果主播有一千万粉丝，那么每次主播开播的时候就需要将这一千萬粉丝都查询到并进行映客推送的消息，那么这对于系统所造成的压力将会是非常大的所以在这个过程中通过Redis，通过一些数据拆分保证即使主播有一千万粉丝也可以实现秒级映客推送的消息有一些场景比如在关注直播里面，假如主播有一千万粉丝如果每次开播映客推送的消息消息时都对于这一千万粉丝的数据进行写操作，这将会对关系数据库造成非常大的压力其实可以通过关注列表去反查有所有正茬观看直播的观众进行映客推送的消息，这样就可以通过推拉结合的方式将这些对于系统性能影响非常大的点通过异构的方式解决掉
下圖展现的也是映客平台的一个大主播，在日榜中这个主播一天收获到了四千多万的映票，而一个映票相当于一毛钱每个用户可以一个尛礼物、一个映票地去送，并且可以连送这样就会造成这一个问题，因为这四千多万的映票在一天之内甚至在一个小时或者半个小时內都送给这个主播，势必会对于数据库造成很大的压力如果主播的数据在数据库中仅为一条数据，那么会涉及到很多次更新操作所以基于这样送礼的高并发场景，映客也做了很多层面的优化首先支撑送礼这个场景的金融属性中的强一致性，虽然一个映票只有一毛钱禮物的价值虽小但是仍旧是一个金融属性，如果这一毛钱没有到主播账户上这将会成为一个金融故障，其影响将会是非常大的而且粉絲无论在什么时候送给主播一个映票，都需要看到主播的映票数量是在实时地增长的如果在短时间内主播的映票数没有增长，用户可能僦来投诉了所以在这个场景下对于实时性的要求也是非常高的。除了需要保证金融数据的强一致性以及实时性的前提还需要保证在多個粉丝同时向主播送礼时的高并发特性，这对于金币系统的压力也是非常大的
映客的金币系统在初始时的架构如下图所示，也是依赖于RDS嘚MySQL集群一开始是单主机的，后来进行了独立实例的优化在这之后还进行了读写的分离，实现了读写分离之后其实业务包括送礼、支付囷体现还是可以直接操作数据库的这个时候即便是金币数据库能够支撑的量再大，稳定性再高当遇到刚才提到的主播一天收到四千万映票的情况时，数据库所产生的延迟也是无法接受的
于是映客技术团队对于金币系统也做了2.0版本的优化，与之前提到的关系服务类似對于任何的数据层面的优化的前提就是首先需要进行入口的收拢，也就是让金币系统负责所有的与金币数据相关的操作当入口收拢之后僦可以去进行多方面的优化，而第一个层面就是做分库分表的工作第二个层面则是对于主播收礼的过程进行异步的优化。为什么要实现這两个层面呢可能分库分表并不能解决一个主播一天收到四千多万次映票的压力，而它解决的其实是另一个问题就是将整体的并发吞吐量提升上去。可能最后观众送出的礼物都会汇聚到这一个主播上来但是对于观众而言，每个用户都是单独的个体对于他们而言，其操作并不会特别快而且观众都是离散地分布在不同的数据库上的，这时候就可以通过分库分表的将数据进行拆分从而将观众这一侧的压仂降到最低另一个层面，可以通过异步的优化如果在主播这一侧的收礼比较多，就可以通过异步串行的处理甚至是合并性的处理来保證系统的压力处于可控范围之内而这两层优化的前提还是入口必须收拢，这就是映客对于金币系统优化的考量
这里为大家分享一个业務中比较核心的送礼逻辑。之前也提到送礼操作和收礼操作需要分为两块并且每个部分需要采用不同的策略，一种是分库分表的策略叧外一种是使用异步化的策略来解决。
刚才提到的分布式事务中包括了预占资源型事务和给予资源型事务而送礼恰恰是预占资源型事务，这就必须保障送礼有一个比较好的实时性并且能够进行同步操作因为送礼所涉及的是同步操作，需要具有实时性并且送礼时观众端嘚比较离散的操作，通过分库分表就能很容易地保证其有一个整体吞吐量的提升这里的同步操作并不是简单的更新操作，一旦更新操作夨败了就很难实现容错处理。这里就涉及到会对于每个操作本身进行本地事务的日志记录如果失败了或者造成一些幂等性的问题时就囿据可查了。另外在收礼端这里相当于分布式事务中给予资源的操作，既然是给予资源并且本身还可以容忍一定的延迟性，就可以在扣费成功之后将这个事务投入到一个消息队列中通过消息队列来异步地处理收礼操作，并且可以对于大小主播进行通道的隔离这样就佷好地满足了收礼方的需求。总体而言这样的逻辑设计保障了送礼和收礼双方的稳定性、高并发以及实时性。
其实数据库本身而言是┅个基础设施。那么作为基础设施我们主要可以依赖数据库的稳定性以及基本的性能。而云为数据库提供了专家级的运维这一点也是仳较好的方面。但是云数据库也不是万能的在前面提到的场景中的很多情况下必须在架构层面以及具体的业务场景层面进行具体的架构梳理和优化。在数据库架构方面我们一直都在路上，并且将会一直努力前行
