FFCreator是我们团队打造的一款轻量灵活的短视频处理库。只需添加几张图片或文字，就可以快速生成一个酷炫的短视频，类似于抖音。github地址：https://github.com/tnfe/FFCreator欢迎star。背景好久没写文章了。我沉默了半年多。我每天都有持续的抑郁症和间歇性癫痫发作。我每天都在困惑和焦虑中度过。我不得不承认我其实是个废物。作为一名底层前端工程师，最近在处理一个传承了十几年的祖传老接口，继承了所有至高无上的复杂逻辑平均调用时间3s多，导致翻页严重.经过各种深入的分析和专业的问答，结论是：放弃就医。鲁迅在《狂人日记》中曾说过：“唯有女人和酒精，不能有虫子”这句话总能让我在黑暗中看到光明，所以这次我要硬起来。我决定做一个node代理层，通过以下三种方式优化：按需加载->graphQL数据缓存->redis轮询更新->调度代码地址：github按需加载->有问题graphQL天秀的老接口，我们每次请求1000条数据，返回的数组中，每条数据有几百个字段，其实我们前端只用到其中的10个。如何从一百多个字段中提取任意n个字段，这个用到了graphQL。graphQL只需要三步按需加载数据：定义数据池root描述数据池schema中的数据结构自定义查询数据查询定义数据池我们为屌丝追女神的场景定义一个数据池，如下：//datapoolvarroot={girls:[{id:1,name:'女神一号',iphone:12345678910,weixin:'xixixixi',height:175,school:'剑桥大学',wheel:[{name:'1号备胎',money:'24万元'},{name:'2号备胎',money:'26万元'}]},{id:2,name:'女神二号',iphone:12345678910,weixin:'哈哈哈哈',height:168,school:'哈佛大学',wheel:[{name:'3号备胎',money:'80万元'},{name:'4号备胎'',money:'200万元'}]}]}包含了两位女神的所有信息，包括女神的姓名、手机、微信、身高、学校、备胎收藏等信息。接下来我们将描述这些数据结构。描述数据池中的数据结构const{buildSchema}=require('graphql');//描述数据结构schemavarschema=buildSchema(`typeWheel{name:String,money:String}typeInfo{id:Intname:Stringiphone:Intweixin:Stringheight:Intschool:Stringwheel:[Wheel]}typeQuery{girls:[Info]}`);上面的代码是女神信息的schema。首先我们使用Query类型定义一个女神信息的查询，里面包含了很多妹子的信息Info。这个信息是一堆数组，所以[Info]我们在Info类型中描述一个女孩的所有信息的维度，包括姓名（name），手机（iphone），微信（weixin），身高（height），学校（school),备胎组(wheel)定义查询规则获取到女神的信息描述(schema)后，可以自动定义各种信息的组合，获取女神。比如我想认识一个女神，只要她的名字（名字）和微信号（weixin）就可以了。查询规则代码如下：const{graphql}=require('graphql');//定义查询内容constquery=`{girls{nameweixin}}`;//查询数据constresult=awaitgraphql(schema,query,root)筛选结果如下：再比如我想和女神进一步发展，我需要获取她的备胎信息，查看她备胎（轮子）的钱，分析是否我可以获得优先选择配偶的权利。查询规则代码如下：const{graphql}=require('graphql');//定义查询内容constquery=`{girls{namewheel{money}}}`;//查询数据constresult=awaitgraphql(schema,query,root)过滤结果如下：我们以女神为例，展示如何通过graphQL按需加载数据。映射到我们具体的业务场景，天秀接口返回的每条数据包含100个字段。我们将模式配置为获取其中的10个字段，从而避免传输剩余的90个不必要的字段。graphQL的另一个优点是它可以灵活配置。这个接口需要10个字段，另一个接口需要5个字段，第n个接口需要另外x个字段。按照传统的方法，我们需要做n个接口才能满足要求。现在只需要一个接口配置不同的schema就可以满足所有情况。感觉生活中，我们这些舔狗的确实缺少graphQL按需加载的思维。奸男贱女，各取所需。你的真情实感在名人面前不值一提。我们要学会随心所欲，上来就出示车钥匙。今晚，我有一条祖传染色体，想和大家分享。实在不行就改一下，直奔主题。简单粗暴的缓存->redis第二种优化方式是使用redis缓存天秀老接口内部其他三个老接口调用，而且是串行调用，极其耗时耗资源。我们使用redis缓存天秀接口的聚合数据，下次调用天秀接口，直接从缓存中获取数据即可，避免调用耗时复杂。简化代码如下：constredis=require("redis");const{promisify}=require("util");//链接redis服务constclient=redis.createClient(6379,'127.0.0.1');//承诺redis方法使用async/awaitconstgetAsync=promisify(client.get).bind(client);constsetAsync=promisify(client.set).bind(client);asyncfunctionlist(){//先获取缓存中的数据，没有缓存则拉取天秀接口letresult=awaitgetAsync("cache");if(!result){//拉取接口constdata=awaitTianxiuinterface();结果=数据；//设置缓存数据awaitsetAsync("cache",data)}returnresult;}list();先通过getAsync读取redis缓存中的数据，如果有数据，直接Return，绕过接口调用，如果没有数据，会调用天秀接口，然后setAsync更新到缓存中，供下次调用.因为redis存储的是字符串，所以在设置缓存的时候需要加上JSON.stringify(data)。为了方便理解，我就不加了，详细代码放在github中。将数据放在redis缓存中有几个优点。可以实现多接口复用，多机共享缓存。这就是传说中的云备胎。追求女神的成功率为1%。同时，如果你追求100个女神，那么你能得到一个女神的概率是100%。鲁迅在《狂人日记》中曾说过：“舔一个就是狗，舔一百个就是狼”。你想做狗还是狼？加油，使用缓存，使用redispollforupdate->schedule最后的优化方式：pollforupdate->schedule女神的备胎用了很久，定期换一批备胎让新鲜血液进来，发现新人快乐缓存也是一样，需要定时更新，保持与数据源的一致性。代码如下：constschedule=require('node-schedule');//每小时更新缓存schedule.scheduleJob('**0***',async()=>{constdata=await天秀接口();//设置redis缓存数据awaitsetAsync("cache",data)});我们使用node-schedule库来轮询更新缓存，**0***这意味着缓存更新逻辑会在每个小时的第0分钟执行，将获取到的数据更新到缓存中，所以其他接口和机器在调用缓存时可以获取数据。对于最新的数据，这就是共享缓存和轮询更新的好处。早年当舔狗的时候，把轮询机制用得淋漓尽致。每天定时给白名单的女神们投票发消息。云三件套跪舔：“啊宝贝，你最近是不是很想我啊？”啊，宝贝早安”“宝贝，晚安，好吗？”虽然女神还是看不起我，但她还是时刻准备着为女神服务的！最后，经过以上三个方法的优化，界面请求时间从3s降低到860ms，这些代码都是业务上的简化逻辑，真实的业务场景远比这复杂：数据分段存储，主从同步读写分离，高并发同步策略等。每一个模块都晦涩难懂，仿佛每一个女神都高不可攀。屌丝打败了所有的虫子，却战胜不了自己的心。我只能一个人在半夜醉，但每次我DreamofThegoddess打开我制作的页面，被极其流畅的体验惊艳到在精神高潮中享受心灵升华的那一刻。
