/首页
/开源
/关于
外包篇 : 余震
发表@2018-10-31 22:51:34
更新@2023-01-21 22:47:40
- 余震是在主震之后接连发生的小地震。余震一般在地球内部发生主震的同一地方发生。通常的情况是一次主震发生以后，紧跟着有一系列余震，其强度一般都比主震小。***余震的持续时间可达几天甚至几个月。*** - 俗语又有云:"天下乌鸦一般黑",虽然用在不是那么恰当. 根据上述两条可以推论:即便是灾后重建的积目,余震还会有,频率和持续时间都难以预测. 1. 上线后的第一天,有人反馈好友列表没了,注意是有人有,有人没有.我以为是数据迁移出问题了,上数据库咔咔一顿查询,数据是在的.Odd~后来调整大了socket缓冲区大小,有了~让我感觉隐隐一股蛋疼的是,部分人的好友数量竟然高达1000+,这些人的典型代表就是XZ.我深深的知道,无限制调大socket缓冲区大小,会耗尽服务器的内存.不过,先能用了再说吧,又不是不能用,反正又不是我公司和项目. 2. 吞消息,具体表现为A给B发信息,有提醒,但是打开后消息全让狗吞了,Odd.考虑到消息发送几乎全是C端做的,S端几乎一行代码都没有,所以我也没什么办法.期间,WYC给我电话,问我怎么回事,我说我也不知道,这块儿是C端用环信做的.我还记得当时我就在望京南站新世界广场低下一层南侧的那个石锅拌饭门口.剩下的几天内,这个问题一直存在并最终被发现了源头,如果我没搞错的话,就是因为新老系统数据迁移导致用户的user id发生了变化.而在重建前的那个灾难版本,YBY就发了一版,那一版将原来的融云换成了环信.使用环信的时候,需要系统自动向环信那里替用户注册一个即时通讯帐号,为了保证唯一性,YBY就利用了原来的用户体系中user id做了唯一标记符.然后S端迁移数据后,一个用户的user id就会发生变化,比如原来1号用户可能就会变成3号,然而C端在环信注册的用户帐号还是用的老帐号体系id,所以,消息就让狗吞了.解决方案呢?除了App端发新版,还需要S端矫正环信的帐号id.因为为了维护聊天窗口,用户发消息的时候会向S端的一个beginChat API请求一次,所以就利用这个API,然后开始矫正用户id,说白了就是即便是客户端使用错误的id,但是一到了我beginChat这里,就按照正确的规则矫正出正确的用户id,然后C端获取后,再用正确user id发送消息.但是,这样还不行,这样只能是主动发起聊天的一方会被矫正,被发送消息的人还是收不到消息.所以,又必须跑一个脚本,矫正所有环信user id.然后,就没有再出现大规模大面积聊天消息瘫痪,消息被狗吞的情况.还是会有极个别现象,不过,先能用了就不错了,又不是不能用,反正又不是我公司和项目. 3.发现API的人没有依照LBS规则,从近到远,而是乱的,确切说是按照注册先后顺序时间.S端的问题,跟WYC沟通后,修复成了按照距离排序.期间,WYC的意思是让我把这里改成带有"网易云音乐"或者"豆瓣猜你喜欢"类型的,我委婉地表示:"这是个大工程,没有挖掘机是不行的,而你给的钱顶多能买个手扶拖拉机.而且就目前来看,LBS这样的,又不是不能用".他被迫表示:"是的,你说的有道理".  ###### 自此之后,整个app就基本上告别高闪退,走向阳光大道了. ###### 尽管你可能觉得我们的施工态度有问题,动辄就是"又不是不能用",但是关于灾难版本,我就给你讲一个比"又不是不能用"要糟糕的十万倍一个非常牛逼的令人蛋疼菊紧的金龙鱼sssss压榨神级bug,具体表现是这样:用户登录总是提示密码不对,点击忘记密码,然后修改密码,修改完成后再次选择登录,依然会提示密码不正确.这是一个很蛋疼的问题,然而XZ又无法从用户那里要来密码.于是我们自己各种测试,S端各种拦截md5,各种对比,又发现完全没问题,所以暂时定义为用户傻逼.紧接着,剧情大反转了!YBY在wechat给我发来如下一句话:"客户端密码长度超过10位后,后面的会被自动截取掉"... ...:tw-1f614: :tw-1f614:也就是说,如果你输入一个12位的密码,C端不会有任何提示,而是很智障化的帮你把后两位给cut掉.怎么样,我觉得我们这种"又不是不能用"的施工态度咋样?
