一般在设计通知中心时,都会在入口处显示一个未读消息数,这样不仅可以醒目地告知用户有未读消息,还能让用户更容易从众多小图标中区分出通知中心的入口。比如 ucloud 控制台的顶栏: 我们网站的通知中心也一样,在入口同样加上了未读消息数的显示。 上线后平稳运行,以为可以就这样一直美下去。程序只要有人用,总会有出 bug 的那一天,最近高峰期经常会出现来自通知表的慢查询语句,仔细一查,原来就是统计未读消息数的语句,而且都是来自几个大用户。我们通知里分了多个组,每个组都有自己的一个未读数,sql 语句差不多是下面这样: SELECT groupID, count(0) unreadCount FROM notification WHERE userID=xxx AND hasRead=…

在文章开始前,先介绍一个背景。著名的异步框架 async 中有一个 waterfall 方法(官方示例),该方法用于控制异步的流程非常直观而且方便,就像下面这样: async.waterfall([ function Task1(callback) { callback(null, 'a'); }, function Task2(last, callback) { // last now equals 'a' callback(null, 'b'); }, function Task3(last, callback) { // last now…

代理 ip 因为配置简单而且廉价,经常用来作为反反爬虫的手段,但是稳定性一直是其诟病。筛选出优质的代理 ip 并不简单,即使付费购买的代理 ip 源,卖家也不敢保证 100% 可用;另外代理 ip 的生命周期也无法预知,可能上一秒能用,下一秒就扑街了。基于这些原因,会给使用代理 ip 的爬虫程序带来很多不稳定的因素。要排除代理 ip 的影响,通常的做法是建一个代理 ip 池,每次请求前来池子取一个 ip,用完之后归还,保证池子里的 ip 都是可用的。…

好像在我们团队建立的初期,那还是两年多前,就有了打枪的传统。噢,这里要解释一下,这个打枪是指在手机上的FPS(第一人称射击)游戏,不是那个意思啦。那时还是玩BIA2(兄弟连),这个游戏太老了,以至于后面IOS升级后没法玩,官方也出了BIA3,但是联机不是这个游戏的特长,所以有很长的一段时间,打枪文化逐渐消退了。直到最近两个月,发现CFM(穿越火线手游版)可以联机实时PK,我们的这个文化又浮出了水面。每天中午吃完饭休息的时候都要来个三局两胜。你以为这篇是要介绍CFM,那就真的错了,下面我要给大家介绍一下我们打枪背后的那些事,其实就是我们的打枪计分系统。 计分系统1.0 这个计分系统的发起人是Johnny,Johnny喜欢数据,什么都喜欢搞个报表,他一开始的想法是搞个Excel,把我们每局的比分记下来,然后可以看到每个人的发挥趋势和排名;…