/首页
/开源
/关于
B10-3篇：老赵归来（下）
发表@2018-11-11 22:26:21
更新@2023-01-21 22:47:40
是时候展现真正的技术了！ 憋大招的短视频社区+微信朋友圈功能需求就这样定了下来，这次主要是由张大彪和老赵砌砖头。 其实短视频这个板块真的没啥好说的，就是有些人会发短视频，然后所有用户都可以看到。但是，但是，比较屌的是：哪个视频会出现在前面，以及排序依据，没人知道。反正我不知道。 - 是根据地理位置？ - 是根据浏览热度？ - 是根据某种综合排名？ 没人知道，后来就索性变成由运营直接在后台里改数据，按照浏览热度倒序排名就行了，又不是不能用～～～ 所以这个是确实没什么难度的，但是在选择短视频存储这上面，出了点儿幺蛾子，事情大概是这样的：早在初期定这里存储商的时候，我们是想继续用百毒云服务的，因为当时我在百毒云的文档里看到过客户端临时上传token的概念，这个是什么东西呢？我来画个图表演一波儿，你们感受一下：  上半个图中的方案，好处是可以更好地控制上传权限以及上传完毕后的回调数据（比如有些业务场景需要的就是上传完毕后直接将文件地址返回给客户端），最大的问题有两个： - 一是需要上传两次，客户端先到服务器，然后服务器再到七牛 - 二是如果服务器本身带宽大就还好，如果带宽小就比较糟了 下半个图中的方案优点就是客户端一次直接上传到位，耗时一定是更短的，缺点是业务流程上会复杂一些。客户端上传前需要先从业务服务器获取一个用于上传的临时token（一般是具备一定时效性），然后上传文件时候需要带着这个token到七牛云，七牛云会对这个token进行校验，当文件上传完毕后，七牛云会异步给业务服务器发送一个上传完毕的通知同时还会附带上传文成的文件信息。 但是，我们研究了一波儿百毒云的这个token凭证功能，发现sdk有点儿难用有点儿搞不定（确切说是张大彪有点儿搞不定，因为我不想吸甲醛不想干活）。那么简单，直接换其他家服务就行了。于是就注册了企业七牛账号。七牛的人还组队来GM公司转了一圈，表演了一波儿demo，用来表示七牛的彪悍实力完全可以hold住GM这点儿需求。会议在一片欢乐祥和的气氛中结束，会议双方对短视频存储这个议题进行了愉快地磋商，同时也就各项未来可能出现的业务增长点达成了共识，就差发币割韭菜了。。。 然而，这要是不给你整点儿幺蛾子那是一定不行的。。。 本来视频上传的功能都已经完成了，结果忽然有一天，ZZ介入了。ZZ何许人也（其实，我还是很敬佩ZZ的，打过一次交道，很不错）？是GM投资商派来监工头，说话分量和权力还是足足够的。他经常坐在GG办公室和GG谈笑风生，每次看到他们两个在一起，我总能感到黄金搭档的感觉，似乎看到美国《时代》杂志封面上，GG坐在沙发中间，ZZ站在沙发后面，杂志封面语为“新时代约炮”哦哦不，说错了，应该是“新时代社交，由GM掌控”。。。当时ZZ不知怎么滴过问了一把张大彪视频用的什么云服务，在得知为七牛后当即表示七牛不大行，牌子太小支撑不起来GM这么大的流量，应该用TX，然后还给张大彪看了看“你看，人家TX能支撑千万级并发”，所以当即拍桌子要换TX并表示“我在TX有人，有问题可以直接找TA”，GG也表示“换换换，不换不是人！”（不过我并清楚GG是真想换，还只是被迫同意）。 当时我请假在家，张大彪在群里告诉我后，我特么差点儿气炸了，马上就想抄家伙进群里开始骂。要说还是于巨蛀鸡贼，上来就跟我说“哎呀，别激动别激动，反正也不是你的公司，生气伤身，等我操作一波儿”。。。于是操作结果就是，借着换云服务商的契机，直接多要了一周的开发时间。实际上切个存储厂商，顶多也就2天的事儿，这波儿操作也是骚。 要说也只能说是TX不争气，我们GM这么牛逼的产品给你面子用你家服务，结果TX好想当时并没有类似于百毒或者七牛那样利用临时token直接上传到服务器的功能，这件事情我们就汇报到微信群里了，于是ZZ表示等我给你拉个高手过来，于是一个微信群就顺势成立了，人员分别是我、ZZ、张大彪、于巨蛀、GG、高手等。高手是谁呢？高手就是ZZ所属投资公司投资的另外一家直播公司（请记住这家直播公司，后面将GM产生完美的交叉）的CTO，结果CTO上来就来了一句“用啥TX啊，为啥不用七牛？”。。。话题终结，已经没法再聊下去了。 然后是朋友圈的功能，其实和微信朋友圈功能完全一样，本质上讲就是动态feed流，这个功能是由老赵负责开发的。 记得当时天已经比较冷了，但为了避免吸入甲醛，我和大彪还有老赵那天下午三点多，坐在公司门口，在目睹了两条狗在地毯上撒完尿后拿着纸和笔，哆哆嗦嗦地冻的跟个孙子似的，商量这个东西该怎么做。我上去提了两个方案，然后扔给了老赵跟大彪，说“你们感受一下”。实际上一般常用的确实是两种方案： - 第一个方案就是比较粗暴，关键点就是直接利用sql数据库的in查询。比如你的好友有10个人，那么你的朋友圈中查询动态的关键点就在于“select * from feed where uid in(十个好友的uid)”。这种方案快捷粗暴，简单有效，但是数据量一旦大了，瓶颈还是比较严重的。比如你有10万个还有，你想想上面那个sql语句。 - 第二个方案复杂了些，但是从长远角度考虑，一定是一步到位的。这种方案中，当你的好友每发一条动态，还会再写一条通知记录到另外一个数据表中。比如你的好友uid是10，你的uid是11，发了一个图文装逼，那么除了记录图文到user_quanzi表中外，还要像user_feed中写一条通知，这条通知构成应该是类似于“insert into user_feed(uid1,uid2,feed) values(11,10,动态ID)”，你在打开你朋友圈的时候，就要执行如下“select * from user_feed where uid=11”，这种方案可以长期支撑一段时间。但是，最大的问题在于，如果一个人（我们暂且叫TA大奶），有一万个人加了大奶为好友，那么每次大奶发动态时候，就一定会在user_feed表中制造一万条动态通知，如果大奶连续发了3条动态，那就是三万条动态。这个动态通知表（user_feed）有可能会增长的特别快，所以需要提前准备。说白了就是提前做好分表，于是老赵就亲自去调研了mysql分区表功能来解决这个问题。 服务端地工作在老赵加入后，就更能够快速提前完成了，我们几乎领先客户端两个月就完成了人物，然后继续开启放羊模式，天天开着服务器睡大觉。客户端地工作比较屌，毕竟动画、图片都是精确到0.01个像素级别的，于是当时场面经常是服务端这一排几乎没人，客户端两排人山人海。服务端这里要么空无一人，要么有人但是在看哔哩哔哩或者睡觉：    每个iOS或者Android客户端的后面，都会有1-2名设计亲自监工并指导工作，然后XY轮训执行监工工作，最后面一层是GG执行最终监工工作，放两张图你们感受一下：  你要说这会儿办公室没甲醛了么？怎么可能会没有。除了原有的甲醛外，山寨人家合空间的厕所里也会散发出十分奇怪的味道，就是那种劣质松木外加厕所本该有的那种味道的二合一体。不过，GM这个测试也是非常屌的，它出了味道刺鼻外，大约有一半时间是不能用的，能用的一半时间里也仅仅是只能撒尿不能用于拉屎，据说是因为管道太细，除非你是拉稀，不然任何一个条状的屎都能把厕所给堵住了。最屌的一次，厕所的水直接溢出来了，溢地满地都是。上图那个位置中，汪洋大海，溢水是小事儿，牛逼的是这个水是从马桶管道里溢出来的。。。所以正合我意，索性天天和老赵还有柱子和巨蛀去798那个公用厕所，一去就是半个小时。
