Monthly Archives: 九月 2016

Hello World

一个外部接口引发的bug

上周开发上线了一个活动:从第三方点链接进入我们的站点,然后领取一个优惠券。使用微信oauth登录,每个用户可以领取一张券
周一,对方说,领取券后,需要给他们一个通知,使用URL上带的encrypt_code参数,调他们的一个接口~~三分钟,通知接口加进去了。当时也没多想:不就是调一个接口嘛
可是昨天看领取优惠券的数据时,发现有好多用户领取了不止一张,多的有三、四张。。。

分析问题,发现程序是先到mysql检查用户活动记录,如果没参加过,则新建优惠券、通知第三方、活动记录保存到数据库

逻辑很简单,怎么可能出问题。
再看活动记录:重复领取的记录,间隔的都很近,往往在1、2秒内
呵呵,猜到问题了吧~~给通知第三方加了日志,记录响应时间,。。。x,基本都在1秒以上
也就是说,用户进入页面、领券时,如果活动记录保存到数据库之前,再次进入活动页面,第二次进入的线程就查不到活动记录,还会继续发券~~不仅如此,这个接口本身,也拖慢了页面的响应时间,一般人看到时白页面,肯定会多刷几次
发现问题,基本也就解决了问题:
简单解决,将第三方通知放在保存活动记录之后
但是这样,页面响应时间慢的问题依然没有解决
所以,最终的解决方案是,将第三方通知改成异步进行~~

幻视幻听

海伯利安四部曲

还是去年入手的海伯利安套装四部曲,因为太懒,今年才开始看;基本就是每天的地铁时间,一个小时左右,四本书前后看了近半年~~
读翻译书就是这样,第一部的时候读的还很慢,慢慢适应的了文风和剧情看的就快起来了
书归正传,说一下整部小说的情况

 

第一部,是故事切入,也是全系列最精彩的一部

通过六个朝圣者的视角,小的方面是在讲述每个人的经历,而大的方面,就是在向读者介绍霸主、环网、内核组成的整个世界体系。
关于朝圣者的故事,实话说,这第一个故事就被震撼到:为了不被十字形“附体”,神父将自己钉在特斯拉树上,被反复电击、活劈,仍然不放弃自己的信仰,最终“命享真死”(说句题外话,三体1拿了雨果奖,而在国人看来更精彩的三体2居然没有入围,我想原因之一,三体2里将宗教写的太“弱”太浅薄了,这和我们的文化没有冲突,但是到了欧美受基督教影响的文化圈里,就大不一样了)
学者的故事,老学者眼看着自己的女儿一天天“回到”从前,从成年,变成少年、童年,再到婴儿,做了父母的人,才能体验到那种束手无策的绝望心情
其他几个故事也都自成体系,又各具特色,同时逐步将你带你入作者的世界体系

 

对,就是世界体系,科幻小说,最吸引人的地方,并不全是故事情节,更重要的,是它所构建的“世界体系”
太空歌剧类科幻,距离/时间是个硬伤。
基地系列、星际迷航,用跃迁解决问题,甭管多少光年,一跳了事;三体,则是冬眠,用时间战胜距离,更具可行性
而海伯利安的前两部,用的是更高端、方便的“传送门”:用不同的传送门连接起若干世界的几个房间,吃饭在一个星球,睡觉在另一个,甚至拉屎也要在一个专门的星球上~~当然,这套系统,随着悦石一声令下,基本全完蛋了,到了第三、四部,可以理解成女主伊妮娅构建新体系的故事了

 

继续说回第一部,科幻小说的故事总是这样,作者往往会在开始时想你展示各种脑洞,然后后面慢慢填这些坑,应该说,在这方面,海伯利安做的一般—-有些坑填的很牵强,比如第一部的故事线索:光阴冢和伯劳,也可能是本人理解能力不够,看完了四部,也不甚明白这两样“神物”的来龙去脉

 

第二部,人工智能“内核”的阴谋逐渐逐渐明晰,驱逐者对故事的影响逐渐增大,到了后半部的高潮,内核灭绝人类的阴谋被发现,驱逐者成功洗白,霸主体系与内核同归于尽,残存人类退回到没有远距离传输手段的“前太空”时代。

 

看评论,很多人说,海伯利安系列前两部是经典,后两部完全多此一举
我部分同意这个观点
后两部的主人公,有点“神棍化”、“完人化”,而且情节太拖沓
不过抛开这两点,后两部的叙事更流畅,情节类似公路电影—-满宇宙秀恩爱大逃亡
如果后两部能把追击戏“打薄”一点、合成一部,或许会更好些

 

抛开主人公神棍情节不谈,第三、四部有几个情节还是堪称科幻脑洞经典的

 

宗教里的哲学体系
教外别传,不立文字,直指人心,见性成佛,伊妮娅借佛教禅宗来讲解她的“大彻大悟”

 

十字形
可以理解成超级生物电脑,记录一个人所有的人格、记忆,人类通过它实现“永生”
相对第一部提到的十字形,这里是改良型的,复活的人并不会变傻

 

大天使信使舰
一种可以短时间星系内跃迁工具,但由于跃迁时加速度过大,里面的人会全被“压死”。但是搭配上面的“十字形”一起使用,简直是绝配

 

环恒星生物圈
基于牛逼的基因改造技术,环绕恒星生长的大树生物圈,完全不需要行星支持

 

缔之虚
即所谓“缔结的虚空”,全书最形而上的神物,一种跨越时空的“媒介”。整部书里,超广义、霍金驱动等所有的“超科技”都基于对此的应用

 

ok,再说就剧透太多了,整体来讲,海伯利安四部曲整的不失为比肩基地三部曲的史诗级经典

微信开发

微信用户信息接口的小坑

基于微信的开发,用户信息是基础,甭管是关注后,还是强制授权,都需要调取“sns/userinfo”接口,提取用户消息
很多事情,我们觉得理所当然,比如,sns/userinfo返回的nickname和headimgurl,这俩不都该成对出现吗?要么都有、要么都没有
不过,事与愿违,到库里去看用户消息,还真有不少nickname、headimgurl只有一个,另一个是空的;特别是nickname,很多都是空的

发现问题,就要寻找原因、解决问题,首先看nickname
由于项目里对外部资源调用的日志记录比较齐全,通过openid,很容易就能发现,比如nickname是下面早这类值时:
存到库就是空的。。。字符集的问题
库里varchar用的是utf8,请教运维,可以不可通过修改字符集,来保存这类支付,无果。。。
无奈关键用户表就不要胡乱做测试,解决方案是加了一个字段,专门保存urlencode(nickname),提取用户信息、需要显示昵称的时候,加个简单判断,再把urldecode显示出来

然后是headimgurl为空的情况
这个再查日志就没啥办法了:就是空的
猜测是用户本来就没上传头像,微信客户端里显示的默认头像,但默认头像既然非用户上传,就认为用户无头像,所以userinfo接口就不给喽
没限制的微信号做这类实际测试,还好headimgurl为空只是极少数

——补充。。。上面说的昵称中的表情符太毒了,wordrpess居然也没能兼容,无奈只能用图