工作点滴

工作后的记录

炒股半年

Posted on by snoopy

本文记录笨狗过去半年跟进美股的经历

很久以前就开始关注美股市场, 主要是所在的互联网公司都在美帝上市 (NASDAQ 居多), 股价也反映着市场对公司的前景态度. 后来去 RENN 后公司给了点期权, 更加有动力去关注下美股市场, 不过期权在可行权的时间内多数时间是负值, 所以也没投入去看. 倒是 QIHU 的股价真的一直在往上走, 不喜欢这个公司可以, 但是没必要跟钱过不去, 就想能不能去分点羹

综合各种原因, 在 2013.9 开始去办招行香港一卡通, 当时还是阿里员工, 办理时似乎有个啥优惠 (免一年年费?). 具体过程在招行的网点找相关表格, 提供资料弄就可以了, 印象中只需要提供身份证, 有效期够的港澳通行证或护照, 居住证明

从这开始发现有个居住证明太重要了, 非天朝地区都是认为你有固定居住地点才算靠谱. 对我等租房的穷鬼来说, 显然没有自己名字的房本, 天朝的水电费账单都是房东的名字, 只有信用卡账单才能证明自己有居住地. 而偏偏公司地址的信用卡账单别人是不认的, 租的房子有邮箱且能收到信这也是很幸运的一件事, 还好招行靠谱, 给我寄了两个月的纸质账单而且都收到了, 交行就似乎从来没寄到过. 顺便提一句虽然电子账单节能环保, 但算到居住证明这个上来, 隔一段时间收一份纸质账单还是很有必要的

等搞定香港一卡通后再去弄美股帐户开户, 我找的是 SogoTrade, 原因是几乎没门槛, 而且教程众多, 短期内笨狗好像也不会去搞期权或买空等高级玩法, 这样就够了. 那时候住院耽搁了下, 到十一后终于走完了线上流程, 线下为了省钱没直接把资料寄到美国, 而是挂号信到 SogoTrade 上海的办公室等他们统一把 W-8BEN 发去美国总部, 然后大概是十月中旬帐户可用. 再次感慨都信息化时代了, 很多能用复印件/扫描件甚至拍照的文件, 真心没必要搞原件啊, 好多地方因为这个搞的好麻烦

自己激活香港一卡通转了 1000USD 过去, 然后跟小强换了点钱, 他从 HK 转给我 HKD, 我在大陆转给他 CNY, 这样两个人都比较省手续费, 最后转到 SogoTrade 帐户里是 6100USD 的本钱

去年十月那时候, 自己了解的几家公司股价都很坚挺, 也没急着入手. 听小道消息 YY 快要发财报, 可以到 80, 于是 48 入了 YY. 当时太贪心, 56.x 没卖, 想着够 60 就行了, 结果跌到 42. 后来涨回 49.5 时仓促出手想着不亏就行了, 结果现在回头看看, 要捂小半年就妥妥的 50%+ 的回报. 不过这个股个人不了解, 当时也就是凑热闹上了下, 现在跌回去了, 还是看不懂

后来看 RENN 跌到 2.9 左右的时候入了一点, 自己对 RENN 的定位是 3.3 的目标价, 过了几天快到 3.1 忍不住出了, 落袋为安. 后来看居然还能到 4.x, 真奇葩, 现在又跌到 3.3 左右, 也算符合我的目标. 我对 RENN 价值看法是, 其单股资产都有 3.x, 所以低于 3 的股价是非常不正常的, 可以入, 又考虑到外界不看好他和陈一舟, 按内部执行过一段时间的 3.3 行权价来看, 高于 3.3 又可能有风险 (现在内部新发的期权行权价应该比这个低了)

然后就是 QIHU 这个我不喜欢的公司但是又觉得还可以的股票, 去年十二月玩过一次短线 82 入 86 出, 然后今年四月弄了一次 87 入 92.4 出, 算是在这上面赚的最多. 不过春节前后两拨大潮都错过了, 当时没空关心这个, 也没时间半夜守着玩波段, 看了下现在也跌到去年入场时的水平, 不用感慨错过了好事, 毕竟风险也避开了嘛. 个人感觉 QIHU 目标价在 100 的样子, 不过他家受各种外界因素影响也还挺大

其他随便扯几家还看过下的
WUBA 完全就莫名其妙么, 真的不是一群人在乱炒? 不过不懂业务不瞎指挥
GOOG 还是值那么多钱的, 不过拆股才 1:2, 要按度厂那个 1:10 的拆法估计市场上的小白们会把单股价推的更高?
AAPL 也就现在那样了, 一个月前写本文草稿时是 ~500, 现在 ~600, 感觉估值偏高, 毕竟没看出特别的发展前景, 算过气了吧
TSLA 多半是炒作, 过山车一般上下, 都是些不懂行的在装懂
BIDU 四年前就说他该到 140, 现在也没高多少, 物是人非, 当时说这话的人都不在 BIDU 了, 也没见有太多好的发展
0700 那一拨上 600 的绝对是疯了, 现在这样还比较理性, 除非真有新的大招, 不然凭什么支撑?

上一张自己的回报状况, 以及和买过的几家的对比图

Finance Performance from Oct.2013 to May.2014

Finance Performance from Oct.2013 to May.2014

上图还是可以看出笨狗是完全随性而为玩票性质的搞, 总共买卖次数两只爪就能数过来, 白瞎 SogoTrade 的首月多少次免费交易的优惠了. 未来估计也不会频繁操作, 就每天会关注下市场, 也算是关心互联网了解大趋势, 有大的利润空间时会出手去捞一点, 保本跑赢 CPI 就是目标. 只要不出现非常大的不可控变故, 这种小赚一点就跑的玩法还是会很稳健的, YY 那次没赚到太多就是因为想贪大, 但是自己没有足够的消息和分析能力来支撑自己的贪欲, 后来几次就好很多

最后, 股市有风险, 入市需谨慎. 笨狗投钱进去只是为了让游戏变得刺激点, 让自己真心从另一个角度来关心下自己所在的行业, 赚钱这个目的暂时就算了. 祝那些真心投入且相信自己内幕消息或分析能力的朋友们财源广进

举手之劳, 顺势而为

Posted on by snoopy

凑个热闹, 点评下微信送红包收获这么多绑定的银行卡, 手段远好过支付宝的事

在我看来, 二马最大的不同, 一个是在努力创造需求, 一个只是在帮人解决已有需求. 无论是双十一, 还是双十二, 抑或是现在全员 all in 在推的来往或淘宝无线客户端的航母版, 无处不是在努力的创造需求设定目标让大家去做某件事情, 去玩游戏抢红包制造日均活跃用户, 去刻意制造一个购物狂欢节, 去画饼描绘用户需要的各项功能然后去提前实现结果发现没市场又要努力推, 最后搞的自己人全员神经衰弱, 局外人凑过热闹后就再无兴趣. 反观微信, 极少有在刻意推自己的新功能, 更多的时候使用过程都感觉是这个功能我需要, 而微信恰好有, 一些放到别的产品本该大力推的特性微信反倒一直在打压, 比如功能明显受限的朋友圈, 入口还藏那么深

从知乎 微信红包的产品经理是谁 这个回答上看, 这似乎是微信无足轻重的一着棋, 但真的要让这个功能能用, 财付通后面应该也是做了很久的蓄力, 不然银行卡不可能可以被绑上. 腾讯推什么似乎都不会那么刻意, 但又感觉排山倒海势不可挡, 这种企业太可怕了. 相比较另一边总各种咋呼, 让员工鸡飞狗跳诚惶诚恐, 路人被吸引眼球围观下然后就走掉, 虽说媒体效果非常棒, 但最终收获和世人口碑未必能有多好

之前听淘宝支付宝余额宝的故事感觉都挺好的, 都是先有需求, 再有产品, 或两者在同步前行. 现在不知道是盘子大了人多了要找事, 还是只是为了上市在酝酿故事, 某厂各种揠苗助长急于求成, 当然可能换个思路是未雨绸缪, 可能只是我多心. 笨狗提醒下注意人心向背, 不然可能要坏大事, 反正我是跑了做别的去了, 帮人发财就能自己发财

2013 年度盘点

Posted on by snoopy

继续每年一次的年度记录

流水账

一月, 折腾 12306 和被 12306 折腾, 各种刷票
二月, 春节回家, 投入玩 Clash of Clans
三月, 跟阿牛去了一次天主教堂的英文弥撒, 通过租房合同取了次公积金, 帮人经手了一次大额现金
四月, 开始从帝都离开的计划
五月, 入手 Kindle, 去上海面 Google, 第一次京沪高铁全程和虹桥全交通工具体验, 去杭州面阿里
六月, 和 zz/lx 自驾大同玩, 跟喵一起去西安玩, 又在北京面了一次阿里
七月, 搬家来杭州, 给老爸全程追踪他的东北草原行
八月, 喵开始上班, 入手 iPhone5 电信合约机, 爸妈来杭州小住, 参加传说中的 “百年阿里” 洗脑培训
九月, 杭州大雨倾城, 感冒发烧转肺炎住院一周多, 公司搬余杭淘宝城
十月, 在杭州又一次大雨倾城时去北京出差, 买车, 被阿里无线 All in 战略影响被转部门到无线算法
十一月, 习惯了每天早起挪走趴路边的车以免被贴条以及来公司人肉抢车位
十二月, 自驾去常州结果大雾堵车再去了趟南京, 还是不喜欢阿里这样的氛围, 谈妥去抱 zouyu 大腿去

工作生活

在人人折腾了半年的新鲜事消息流, 后半段因为已经决定要离开北京, 自己做的和管的也少, 放手带了下人, 离职后听其他人评价多半还不错, 很欣慰, 自己做事还是对得起良心的, 只是在抢地盘给自己团队争取更大蛋糕上做的还是很不够, 从这点来说自己也当老大也当的不够好, 让下面人成长空间受限

在阿里一开始做搜索广告的 Query Rewriting, 感觉又回到以前在度厂做 CS 的时候, 不过两边基础架构很不一样, 设计理念也差很多, 等我把自己过往知识体系跟现有系统基本打通后, 做了一般类目预测就悲剧住院了, 等再回来没两天就被调到无线. 说在无线其实大部分时间在做基础地址相关的工作, 又把很多隐私事给看了下, 产品线是淘宝手机客户端生活圈功能, 有兴趣的可以去看看, 就现在这个版本要说有多好我只能呵呵, 但是要公开吐槽这种伤 RP 的事还是少说了

自己倒是搞了点小东西. 一是跟着死猫折腾 12306, 最早还有能全自动化的工具, 后来验证码加强过一次我就没搞了, 今年春运改版, 去年的那个工具彻底没用, 一些折腾详见 12306 和火车票那点事. 二是自己把 buyvm 的 VPS 搞的基本可用, 优化记录详见BuyVM VPS 安装优化记, 上面挂了自己的主站 (静态页面, nginx), 这个 Blog (WordPress + PHP + MySQL), 饭团 (django, 详见django 入门小试), dropbox 备份 (参考师弟的自动备份网站并同步到 Dropbox) 以及 shadowsocks 翻墙, 没开 VPN 是因为太耗资源了. 三是在公司自己学了点 JavaScript, 配合 Flask 搭了个内部查询用的小工具, 年底时为了搭 demo, 继续研究了下 Flask 又做了俩小工具, 倒是把 BootStrap 这个前端框架给大概了解了下算是意外收获, 最后两天把被度厂影响的自己写索引数据圈放内存的习惯反思了下, 把那个重 js 的工具改成 Flask 用的 jinja 引擎完成页面渲染, 并把数据改用带索引的 sqlite, 速度也不慢

生活上没啥明显变化, 九月份生病住院搞了一遭, 详见发烧住院记 Part 1, 发烧住院记 Part 2, 发烧住院记 Part 3, 发烧住院记 Part 4, 发烧住院记 病友番外篇, 发烧住院记 医护番外篇. 其他的, 到无线后没空做饭, 家里都好久没开伙了

学习锻炼

买 Kindle 后看了几本书, 不过最近落灰时间更多, 全年正儿八经看过的书少, 更多都还是看技术上用到的东西的官方入门和手册, 多是英文版 (tutorial/manual)

锻炼也有点废, 没搬淘宝城前每天骑车上下班, 回家扛着自己的小折爬楼梯上五楼, 还算锻炼了下, 搬淘宝城换公交班车以及后面买车后就没锻炼了, 最近穿衣体重超 70, 惨不忍睹, 还好冬天穿的多看不出来. 又因为阿里坑爹的晚餐补贴政策, 晚饭餐补进支付宝食堂餐券, 当天不用作废, 本着不要浪费的思想每天晚上又吃的还行, 少食也没做到. 去年和今年的体重计划都失败, 接下来的 2014 因为工作变化, 应该可以做到多动少吃才对, 要控制体重

活动旅游

因为面试, 去了趟上海, 特意多留了个周末去见了不少老友, 去时京沪高铁全程, 回来 SHA 飞 PEK, 体验了下虹桥各种交通工具. 面试时来过一次杭州, 一个人绕西湖走了半圈, 感慨还是江南更亲切

去了一趟大同, 第一次自驾, 各种欢乐见大同游记. 去了一次西安, 第一次自费高铁, 第一次软卧, 路上总总见西安游记 – Day1, 西安游记 – Day2, 西安游记 – Day3, 西安游记 – Day4. 搬家来杭州那次赶上京沪高铁全线大晚点, 大坑, 我出行的 RP 似乎明显低于平均水平?

之前和天主教徒阿牛一起住了快一年, 一直对教堂活动很感兴趣, 三月份的时候周末跟着去了一次北京宣武门天主教堂 (南堂) 参加弥撒, 去的那次是英文弥撒, 感觉还是挺好玩的, 有信仰的人过的要简单快乐很多. 不过今年参加啥大的户外活动, 没骑远一点的地方, 也没去滑雪, 也就开车跑远了点, 小怨念

感情问题

因为喵已经工作, 笨狗家里催的又频繁了不少, 但是喵那边没进展甚至情况更不妙, sigh

败家理财

年度最大支出是买车, 裸车 7.69w, 买保险上税上牌照贴膜后不到 9.1w, 后期的配件什么的没花几百块钱, 就买了个行车记录仪和一点洗车的工具, 停车因为没摇到公司的停车位天天人肉抢免费临时车位, 晚上回去晚直接停路边, 也就周末能在小区里趴到位置出点钱, 去外面洗过两次车都用的电信 VIP 送的券没花钱, 加了一千五左右的油, 到今天跑了两千两百公里, 昨天加的油现在基本满箱

搬杭州来后买电器家具什么的有一波支出高峰, 双十一时去凑了下热闹买了些衣服和鞋, 五月份买了个 Kindle Paperwhite, 八月份换了个 iPhone5 电信合约机, 其他好像就没啥大额开销了. 出行上, 春节回家, 六月份去大同和西安玩花了点钱, 以及给爸妈买了些车票, 这块也没明显支出

八月份趁 RENN 高点时把之前的期权给清了, 赚的钱也就换个合约机加话费的吧. 十月份 $6100 进入美股市场, 到现在 $6595.28, 之前看了那么久市场终究还是漫不经心的旁观者, 真自己进去了就不那么淡定或没那么好耐心以及没有实时看盘的时间, 现在回头复盘看稍微注意点应该就可以过 $7000. 这个收益比买理财什么的高, 但比起美股上正常的收入回报还是差很多, 不过还好, 至少没亏, 以及赚到来回转钱的手续费了

四月份就跟人讨论过 BitCoin 的问题, 事后诸葛亮想下当时要入手点这月高点时还能翻几倍, 不过对这种高风险的东西还是敬而远之, 因为也可能是这月高点跳进去现在被套的一塌糊涂. 目前余钱分布在现金和活期 (无收益, 稳定性好, 流动性高), 银行理财 (收益一般, 稳定性好, 流动性一般), 余额宝 (收益较高有波动, 稳定性较好, 流动性较高), 美股 (收益很高不确定, 稳定性差, 流动性较差), 一些借款 (几乎无收益赚人情, 稳定性一般, 流动性非常差), 等明年出来后时间可控点可以慢慢再优化

广告从业者的良心

Posted on by snoopy

最近又回到做计算广告的路上, 在重新熟悉和看问题时, 想起来曾经看过这么一句话, 大概是 Facebook 的某技术高管离职时说的 “我们这一代最聪明的人竟然都在这里思考着怎样让人们去大量的点击广告, 真衰” (翻译的总不太对味, 原文是 “The best minds of my generation are thinking about how to make people click ads.” by Jeff Hammerbacher, 大家可以去搜下原文看看前因后果). 我个人对这句话也还是有一些不一样的看法, 倒不是反驳或辩解, 只是从我的角度来看看为什么会造成这样的现状

我们先跳开这句话, 来说说现在我们这个圈子里最聪明的人都在哪, 很多人第一反应都是说去了 Google, Facebook 这样的商业公司, 或者曾经是 NASA, Bell Lab 这样的实验室, 那既然是商业公司, 公司必然先需要活下去, 那就要去获得收入, 而实际上, 绝大部分的互联网公司的收入都来自广告, 这应该也是不争的事实. (互联网盈利主要有 广告, 增值服务, 游戏, 电商等, 在国内游戏是很大一块, 但是全球无论何处广告也都是压倒性多数的一部分, 很多光芒四射的创业公司不做广告, 可能只是他们还在烧风投的钱在攒用户, 还没到把资源变现的那一步而已) 去看看大公司的财报, Google, Facebook, 百度等公司的收入大部分来自广告, 微软目前可能还在靠企业应用和游戏, 但是互联网业务群也有广告盈利的压力, 国内腾讯网易等早转型为主要依靠游戏, 阿里系有服务费 (算增值吧), 但是广告也还是相当大一部分. 综上, 至少可以得到一个结论, 广告是生存之本, 是必需品

很多理想主义者还是会说那我们能不能只要维持公司的基本收入, 然后让更多聪明的人去做造福社会让人类进步的工作, 比如 Google 怎么去提升搜索质量, Facebook 怎么去让 SNS 更好用. 这样的模式不是没有, 比如维基百科, 就一直没有放广告, 而是靠捐赠和全民编辑, 但这毕竟是少数, 而且商业公司还需要追求利益最大化, 所以聪明的人去优化广告效果提升收入也无可厚非. 这是偏阴暗的理由

我想说的重点更多的是阳光的一面. 广告的本质是什么呢? 是广而告之, 是希望让一个特定的受众群获取一条特定的信息, 且希望受众采取一定的后续措施. 比如超市的广告希望告诉你他们在促销, 你们快来买. 这个信息之所以需要通过广告的形式送达到听众那, 就说明走常规的途径是到不了的, 广告商希望付费去送达信息, 而对收到广告的人来说, 如果这条信息对他有用, 而如果没有广告他就没法获知, 那这条广告就应该有正面价值. 实际上每个网民耗费在网络上的时间是无法被广告公司和广告商所左右的, 而这些时间内他们看到的广告也应该是一个相对固定的量, 我们计算广告的从业者, 提升的本质并不是用户看广告的数量和时间 (即更多的广告), 而是这些广告里对用户有用的比例要更高 (更高的广告点击率), 当然从另一个角度说, 广告看多了其他内容就看的少了, 但是如果这些广告信息确实是有用的, 那和其他内容比, 对用户产生的影响谁好谁坏还说不好吧

有很多信息, 没法通过自然信息流 (比如用户的固定订阅, 习惯性的浏览) 到达目标用户那 , 例如有限定的优惠, 新出现的内容, 那就需要广告在正常流程外给出合理的送达渠道. 我记得我最早踏进计算广告这个圈的时候, Google 在 AdSense 上给 wikipedia 做了很多免费的广告, 比如 “世界上最大的哺乳动物是什么? — 来维基百科查看”, 这样的广告我觉得很好, 因为我对这样的信息是感兴趣的, 对维基百科来说也很好, 因为他们作为一个新兴事物, 需要更多人的了解和关注, 对 Google 而言, 他们一是在做慈善 (免费给维基导流, 不然这些广告位也可以拿去赚钱), 二是避免自己给用户出不合适的广告影响特定网站上的用户体验 (相对而言维基的广告没有什么指向性, 不会让用户反感), 这是一个四赢的局面 (用户/广告商(维基)/广告中介(Google)/放 AdSense 广告的网站), 也是计算广告从业者的奋斗方向. 多说一句, 当时百度的网盟广告也有一定的比例在给百度百科导流, 虽然也赚不到钱, 但是还是有只分东西给自家的嫌疑, 所以没拿出来当完全正面的典型好好夸

如果只是让用户通过正常渠道获取到自己该获取的信息, 更多可能是一些循规滔矩的工作, 而在更激进的渠道上, 让多方的信息获取送达更高效合理, 听起来会更有挑战一些, 而且广告跟收入也直接挂钩, 很多改进可以非常明显的反应在账面上, 带来的成就感可能也更直接. 这是我个人的经验和看法, 所以我觉得当今世界最聪明的那拨人里有很多在做计算广告也是一个合理的状况. 另外, 我认识的计算广告从业者大部分还是很有节操良心未泯的优秀青年, 当然整个圈子里还是有一些让人无奈只能呵呵的存在, 我们不喜欢的是

1. 想办法收广告主钱但是没给他们带来收益
– a) 投递给错误的用户, 没给广告主带来希望的影响受众 (违反广告宗旨一或二, 特定受众/特定信息不符合)
– b) 诱骗用户点击, 实际上没法产生后续行为让广告主获利 (违反广告宗旨三)
– c) 玩弄游戏规则, 让广告主花更多的钱干更少的事
2. 助纣为虐, 违法乱纪 (赌博, 色情, 欺诈网游)

这些事情可能有法律管, 但是至少国内的法律在这方面是相当不健全, 除了违法乱纪的可能有点约束力, 其他都只能靠从业者和老板们的良知了. 目前我在的这个地方, 虽然技术上可能比其他地方要弱, 不过好在良心还算可以 (至少我能看到的范围是), 所以还是值得回到这个有意思的圈子来. 以后的工作中还是要勿忘初心, 有节操的去改善人类信息获取的方式. 与君共勉

svn co 时控制目录层次

Posted on by snoopy

发现很多地方的 svn 还是用 http://svn.corp.com/team/project/ 下同时挂 branch, release, tags, trunk 的目录结构, 如果想把整个 team 的所有 project 都 checkout 下来, 显然数据量会大的想哭, 事实上大多数情况只要 co trunk 就行了, 土法就是挨个挨个 co 对应的 trunk 来看, 不过这样似乎有点土鳖

好在 svn 在 checkout 和 update 的时候是可以带一个 –depth 或 –set-depth 的参数来控制下载的目录层级. 比较简单的记录如下

# 仅目录
--set-depth emtpy
# 一层
--set-depth immediates
# 无限
--set-depth infinity

具体应用例子如下

$ svn co --depth immediates http://svn.corp.com/team
$ for proj_name in $(ls) do; svn up ${proj_name}/trunk; done

这样就能把每个 project 下的 trunk 弄到本地了

杭州印象

Posted on by snoopy

第一次来杭州是 05 年的冬天, 过来浙大参加区域赛, 只记得当时去的紫金港, 最后有一个下午组织游了下西湖, 那时很惊讶杭州的出租车居然都是帕萨特, 然后司机跟我们说房价时只觉得以后毕业了一年有 15w 应该就算混的很好了

第二次来杭州是面试, 一个人又去走了下苏堤, 想可能就要一直在这个以前自己只认为是旅游城市的地方呆下去, 感慨万千, 人生真奇妙, 确实永远不知道以后会变怎样

这次过来则基本算搬家了, 跟人人过来参加 ADC 的同事一起坐高铁, 居然还碰上强降雨导致徐州断电的大面积晚点这种事 (插句话, 我总共在京沪高铁上走过四次, 北京南-泰安, 泰安-北京南, 北京南-上海虹桥, 北京南-杭州东, 其中第二次和第四次都遇上超过一小时的大面积晚点, 以后想跟我一起坐车的注意检查自己的 RP 是否能扛住我的 debuff 光环). 杭州东作为一个典型新站, 很给力的让我们等了一个半小时的出租车, 这次发现怎么出租车档次都下降好多

到杭州那天说是要来台风, 最后只是擦了过去, 南方闷热的天气, 但是会有风, 好多年没重新体验这种感觉. 整个城市的绿化率, 以及随处可见的小河港带来的水气, 空气中也还是典型的江南水乡的味道, 喜欢这样

在杭州这几天似乎也没遇上传闻中那么可怕的堵车, 或者是这边太敏感了, 要在北京天天看东三环堵的那样应该就完全没脾气了吧. 很多没有红绿灯的道口, 路过的车会很自觉的停下等行人通过, 我第一次碰到时扭头找了半天红绿灯在哪, 后来发现只是这个城市很友好的一部分

找房的过程发现, 杭州房价是要比帝都低, 不过好像也没有低到明显差一个 level 的情况

这几天找吃的过程中, 感觉杭州的小吃馆更本土化一点? 而不像北京遍地改良过的成都小吃, 最近两天恍惚间觉得收银妹子们说话都很有台湾腔 (或者应该就是东南沿海软甜的腔调吧)

习惯了帝都便宜的要死的公交, 在杭州找房和蛋疼瞎逛的两天里, 轻松把公交卡刷掉十几块钱, 这还是近距离我都骑公共自行车的情况下, 相比较而言杭州公交车上会觉得更暗一些, 窗户小, 而且现在太阳大一般都拉了窗帘. 公共自行车是个好东西, 虽然部分车况实在不行, 前几天都是上班期间在用, 感觉借和还都很方便, 昨天赶在下班时间想去弄下, 结果走了两个点都没有车, 果然真的要长期使用, 还是自备靠谱

三年又三年

Posted on by snoopy

之所以想起这个题目, 一是受无间道里梁朝伟跟黄秋生吐槽 “说好的三年, 结果三年又三年, 三年又三年” 和 “再见警察” 那个悲凉的音乐影响 (只是无厘头的觉得三年确实可以算一个比较合适的 checkpoint 而已, 相关曲目请见 http://www.xiami.com/song/1769154348), 二是的确最近的每个三年都是大阶段变化, 三年前的三年前的三年前, 离家上大学, 三年前的三年前, 第一次出来实习, 后面也基本没太多在学校混, 三年前, 毕业工作, 现在的这个三年, 离开北京到杭州, 基本上又是一个全新的开始

上一次确实也写了一篇三年 http://www.yewen.us/blog/2010/07/%E4%B8%89%E5%B9%B4/, 那这次也还是对比着写写看

2007.7.18 星期三 北京 晴
2010.7.18 星期天 北京 晴
2013.7.18 星期四 杭州 晴
*
2007.7.18 百度实习入职, 第一次实习
2010.7.18 在百度工作, 第一份工作
2013.7.18 已从人人离职但还没在阿里入职, 换了个城市
*
2007.7.18 百度网盟, 第一次接触互联网广告, 从此一条路走到黑
2010.7.18 百度凤巢, 那段时间比较顺手, 后面有两次被坑到不行, 感觉自己的离开也还是跟这有关系
2013.7.18 未知的方向, 重装上阵的阿里妈妈? 当年的友商, 现在自己也混迹其中, 而前东家是友商了
*
2013.7.18 过去的三年, 在西二旗十六个月, 在柳芳二十个月
2013.7.18 看起来会在杭州呆很久, 很可能就一直在这了?
*
2007.7.18 在学校阿排还是被叫的最多的名字
2010.7.18 更多扮演的角色是恶趣味无聊理工男
2013.7.18 可能又要回到天天被叫阿排的日子?
*
2013.7.18 过去的三年, 搞过搜索广告, 也搞过展示广告, 也从广告退出来去折腾用户产品相关的, 最后绕了一大圈, 还是回到广告, 在赚钱的部门, 有压力有动力倒也不是坏事
2013.7.18 在百度被希望转 manager, 结果好像 tech/manager 都没做好
2013.7.18 在人人倒是因为下面挂了一堆人而被动变成了 manager, 也被各种培训, 换个角度看问题思路会开拓很多
2013.7.18 离开一线心里还是发慌, 自己这种闲散的心态去带人没法给小弟抢地盘, 人再好也还是白搭, 还是走技术线吧, 能管好自己已经很不错了
2013.7.18 很感谢这些年碰到的各位导师, 同事, 都很赞, 只是可惜自己不够成器
*
2010.7.18 想尽办法跟妹子在一块
2013.7.18 还是想尽办法跟妹子在一块
*
2013.7.18 Good Luck

django 入门小试

Posted on by snoopy

对 django 这个框架早有耳闻, 最近因为想给组内写个饭团系统, 想是不是可以刚好学习用下这样的框架

先按官方教程学了下基本的内容, 很简单: https://docs.djangoproject.com/en/1.5/intro/

然后就自己操练了下, 记几个小细节或坑

1. 简单应用时, 数据库辅助表不要自己建, 否则维护关系很麻烦
2. 用 shell 来做本地测试, 用 dbshell 来修复数据库问题
3. 对不同的模块, 功能, 善用辅助字段, 各种 Google 查询就是了
4. 调试完成关闭 DEBUG 模式发布后如果还有错, 那就在 setting.py 里配好管理员邮件等着收邮件看报告分析错误

过程中还经常参考的是 The Django Book, 不过没找到哪里有比较好的全本或翻译版下, 我都是从新浪爱问等地方找到的半成品

目前已经完成饭团, 架在内网的一台台式机上, 源码和说明在
https://github.com/whusnoopy/fantuan

这个系统在我们组内已经用了好几个月, 目前看来工作良好 :P 我是用的 fastcgi 模式在跑, 使用 unix socket 通信, 配好 nginx 的转发规则就可以了, 注意对应 socket 文件的读写权限, 我一开始被这个坑了半天, 其他的看上面那个 github 工程的 README 应该都说清楚了

补一句, 关于饭团, 之前支付宝有 AA 收账其实就能满足需求, 只是没法回溯查看, 对我们团队的问题则是不知道大家的支付宝帐号, 统计收集也麻烦, 加上我们还想记录下来做点 data mining 玩, 比如偏好餐厅等, 就还是有单独饭团的需求. 另外, 最新版的 QQ 客户端里, 群也有 AA 收账功能, 看了下, 跟支付宝类似, 发起会更方便, 但考虑到财付通的覆盖面远不如支付宝, 估计也够呛, 另外一些我们想要的记录似乎也是没有的 (比如餐厅, 付款人等)

为什么要预估点击率

Posted on by snoopy

背景

想到这个题目是因为 @lijiefei 某天跟我说他有师弟面淘宝时被问到 “点击率预估的目标到底是什么”, 笨狗当时胡乱扯了一通, 发现要把这个似乎已经是真理的事情掰清楚还没那么容易, 于是有此念想写文一篇详细分析下原因

我和 jiefei 认识是在百度做搜索广告的时候, 那就从搜索广告开始说为什么要预估点击率, 以及预估点击率的目标. 先申明一些名词和假定:
1) 每个广告 (Ad) 有一个出价 (Bid), 并有其在某情形下实际的点击率 (Click-Through-Rate, CTR)
2) 广告按点击收费 (Charge per Click, CPC), 下面我们会分别讨论一价计费 (First-Price, FP, 即广告出价多少则一次点击计费多少) 和二价计费 (Second-Price, SP, 即广告按下一位出价来支付点击价格, 更普遍的是 GSP)
3) 千次展现收费 (Cost Per Mille, CPM, 或 RPM, R for Revenue), 即对点击付费广告其展示一千次情况下的收入 (一价计费下等价于 1000*CTR*Bid), 或是展示广告的千次展现固定价格
4) 预估点击率 (predict CTR, pCTR) 是指对某个广告将要在某个情形下展现前, 系统预估其可能的点击概率

目标分类

搜索广告跟自然结果一个很大的区别就是自然结果只要有一点相关就应该放到所有结果里去, 至于先后位置那个再说, 而广告, 是有个相关性的准入门槛的, 不相关的广告出价再高, 丢出来还是会被骂死. 那怎么判断相关? 用户会用鼠标点击来对结果投票, 相关的广告会被点击, 不相关的广告不会被点击, 那很自然就能得出 “点击率和相关性正相关” 这个结论 (至于描述里写 “二十五岁以下免进” 但实际是钢材广告的这种诱骗行为后面再说怎么处理). 那对于这种相关性准入的场景, 预估点击率就是预估广告是否相关, 最朴素情况下这是个二分类问题, 那不管预估成怎样, 只要有一种分割方法能分开是否相关就行了. 此时预估点击率的目标是能对广告按相关与否分类 (或说按相关性排序并给出一个截断值). 评估分类问题好坏, 一般都是看准确和召回两个指标, 用人工打分的记录来做回归验证就行

目标排序

判断相关与否只是点击率预估对广告的一个小辅助, 我们来看看广告的目标是什么? 没错, 是赚钱. (我曾经在其他场合说过广告的目标是维持用户体验下持续赚钱, 不过跟赚钱这一简化目标这不冲突, 前面相关性上已经保证了维持用户体验, 那只要能让广告主还有的赚, 就能持续赚钱) 我们再把问题简化下, 如果广告都是一样的固定价格, 且就以这个价格按点击计费, 那在 PV 一定且预算充分的情况下, 更高的点击率则意味着更赚钱. 这样目标可以等价于怎么挑出更赚钱的广告, 就是那些点击率最高的广告, 我们只要能弄明白广告实际点击率的高低关系就能取得收益最大化, 预估点击率在这时候又是个排序问题, 我们只要弄对广告之间的序关系, 就可以收益最大. 评估排序问题的好坏, 一个经典方法是对 pCTR 的 ROC 曲线算 AUC (曲线下面积), 实际上我见过的做法也都是通过评估 AUC 的高低来判断点击率预估模型的好坏

目标带权排序

上一段里对广告这个业务做了很多简化, 比如大家价格都是一样的, 如果我们考虑价格不一样的情况, 那预期收益就会变成 (价格Bid*点击率CTR), 这个值很多地方也叫 CPM 或 RPM. 如果是对 CPM 排序, 那就需要我们预估的点击率在维持序关系正确的前提下, 还要保证相互之间的缩放比是一样的. 比如有广告 A, B, C, 实际点击率是 5%, 3%, 1%, 那在价格一致的情况下, 我预估成 5-3-1 还是 5-4-3 是没关系的, 但在价格不一样的情况下, 比如 1, 1.5, 3, 这时候 5-4-3 的预估点击率值会让他们的预估排名和实际排名刚好颠倒过来, 不过预估 5-3-1 或 10-6-2 (放大一倍) 倒没关系. 为了评估这个结果, 可以在描 ROC 曲线时把价格乘上去, 那最后还是判断排序问题的好坏, 加了价格的 AUC 我们可以叫 wAUC (weighted-AUC), 这个离线评估和在线效果依然可以对等

目标准确

从准确召回到 AUC 再到 wAUC, 看起来对已有问题可以完美解决了? 不过广告计费显然不是 FP 这么简单, 在 Google 的带领下几乎所有的搜索引擎都使用了 GSP (Generalized Second Price) 来对广告点击进行计费, 这里再简单解释下最简版 GSP 是怎么回事:
1) 所有广告按 CPM 排序 (即 CTR*Bid)
2) 排最后的广告收底价 (Reserved Price, RP)
3) 其他广告按他的下一位 CPM_i+1 除以他的 CTR_i 并加一个偏移量来计费, 并保证比底价高, 即 Price_i = max(CPM_i+1/CTR_i + delta_price, RP)

至于 GSP 的细节和为什么这么做能保证收入和体验的平衡等可以详见相关论文, 我们只讨论在 GSP 模式下, 点击率预估的作用和关键点. 根据介绍 GSP 时最后那个公式, 如果把 CPM_i+1 拆成 CTR_i+1*Bid_i+1, 看起来只要保证同比缩放还是会没问题? 但是, 凡事怕但是, 在搜索广告里, 不同的展现位置对点击率还有影响, 比如广告 A, B 在第一位点击率是 5%, 3%, 而在第二位是 3%, 2%, 那只是同比缩放就很难保证最终比较是一致的问题了, 所以最好还是保证预估值跟实际值尽可能接近的好, 这样才能在预估时获得更实际用时完全一样的场景. 评估准确度, 我们有 MAE 和 MSE 等一堆指标, 也是现成的工作的比较好的东西

扩展和吐槽

有行家可能会吐槽说我刚那个不同广告在不同位置的衰减不一致这个说法, 跟公开论文说的不一样, Yahoo 的 paper 里说不同广告在同位置的衰减是一样的. 我只能说, 骚年, 你太天真了… 衰减因子怎么可能只是 f(pos) 这样一个简单函数, 从实际情况来看, 衰减函数和广告是有关的, 但我们又不能对每个广告都去估一个 f(pos, ad), 好在, 我们发现可以把不同的广告做聚类后得到一个 f(pos, type) 的函数簇, 事实上, 最后的衰减函数不仅仅有 pos 和 type 两个因子, 而且里面的因子可以极度简化, 最后的衰减用简单函数就能很好拟合, 我说的够多了, 再说估计要被前东家找麻烦, 你们来感受一下就好

前面也提到介绍的 GSP 是最简版的, 那如果是正常版会有什么不一样? 那就是排序时用的是 Quality*Bid, 这个 Quality 百度叫质量度, 也就是广大广告主望眼欲穿的那几颗星. Quality 和 CTR 有什么不一样? 最简情况下这两个当然是一样的, 但是我们可能还要考虑广告主的信誉度, 目标网页的质量等因素 (比如前面提到过的那种描述欺诈或诱导的广告在这个 Quality 因子里被调整掉), 最后这个 Quality 就会是包含了 CTR 的一个多因子复合值, 那要准确估计这个复合值, 当然也要求其中的每个因子的值尽可能准确. 这里在炒冷饭说准确度, 以及 MAE/MSE 的作用

实际上据我所知各搜索广告平台用的是比正常版的 GSP 还加强或改造过的版本, 里面的因子, 公式, 逻辑更复杂. 在这种情况下还是需要继续强调 CTR 预估的准, 才能做更精确的预估, 从而带来更大的收益

广告之外

呼~ 说完了搜索广告, 我们再简单说下内容广告. 搜索广告几乎都是点击付费, 而内容广告同时存在按点击付费和按展现付费, 那怎么比较一个按点击付费的广告和一个按展现付费的广告哪个预期收益更高? 同样是 CPM, 按展现付费的广告给的是确定值, 而按点击付费的是一个预估值, 通过 Bid*pCTR 得到, 如果 pCTR 不准, 就会导致点击付费广告的预期收益计算不准, 则不一定受益最大. 继续强调预估的准的好处

说完广告我们就能说说其他的, 比如搜索, 比如推荐, 这几个的优化目标如果是带来的量, 因为总体 PV 我们没法人工干预, 且每个点击是等价的, 那最后的优化就变成了点击率, 预估的序关系越接近真实, 可获得的收益更高. 如果不同的点击价值不一样, 那就可以把这个点击换做价格代入广告的模型, 因为没有二价计费那么讨厌的变换, 所以就按一价计费来考虑, 保证序正确且等比缩放就能保证收益最大. 如果再激进一点, 评估收益时还加入更复杂的因子而不仅仅是价格这个独立因素, 那自然就要求点击率预估准确, 从而保证做决策时和实际情况一致, 继而保证最终的优化目标最大化

总结

1) 点击率预估是为产品的最终目标服务的, 最终目标可以是广告的收入, 广告的相关性, 推荐的接受率等, 看具体场景
2) 点击率预估的直接目标根据需求场景不同, 分别是保证预估值和实际值分类正确, 预估序和实际序正确, 预估值和实际值是等比缩放的, 预估值等于实际值
3) 要保证离线评估点击率预估的效果, 分别可用分类的准确率和召回率, 排序的 AUC, 带权排序的 wAUC, 相似度 MAE/MSE 来评估

SNS 背后的技术: 消息流的推拉模式选择

Posted on by snoopy

上一篇扯到 SNS 本质上还是要满足沟通需要, 既然有沟通就涉及到信息本体的传播, 曾经的各种传播方式多半采用把信息从消息源推送到接收者, 由接收者用收件箱保存并查看的方式实现, 比如短信, 比如电子邮件等等

这种推送模式在传统信息沟通中运作的还不错, 每个人维护一个收件箱, 消息发完就不用管了, 因为一条消息一般不会发给非常多的人, 所以发送过程几乎瞬时完成, 同时对接收者来说单位时间收到的消息不会太多, 所以收件箱也不用非常大, 定期清理或提供更好的查询方式就行了 (前者比如功能手机的短信收件箱, 后者比如 Gmail)

而在 SNS 上这个模式就不那么适用, 从消息获取机制上来看, 应该是 “我去看我的朋友们都在干什么” 而不是 “我的朋友们有什么事情要分享给我”, 从技术上来说, 因为 SNS 的消息非常多, 为每个人维护一个足够大的收件箱是非常耗资源的, 另外, 对 SNS 上的超级用户 (比如有上千万好友的人人公共主页或小站, 几千万粉丝的微博大号) 来说, 推送消息这个过程也非常耗资源和时间. 所以很多 SNS 采用的是所谓的拉模式, 即对每个用户维护一份发件箱, 用户需要获取信息时主动发起对所有其收听的好友一个拉取的操作, 从不同好友的发件箱拉回所有消息, 并实时组织这些消息

至此, 所谓消息的推模式和拉模式都简单说完了, 听起来都各有各的道理, 到底要怎么用才合适?

从存储的角度来说, 拉模式一定会节省资源, 因为消息都是一个源, 而接收者可能有多个, 如果收件箱和发件箱同时存在, 则所有的收件箱大小应该等于发件箱乘上单条消息的平均接受人数, 按一般理论上 SNS 平均好友数量是 150~200 的规模算, 拉模式比推模式节省 150~200 倍的存储空间, 另外考虑到好友更多的用户活跃度更高, 因而这个数字会更大, 再者人人网存在公共主页和小站小组等超大规模接收者的实体, 微博只限制单个用户收听其他人的数量而不限制单个用户被多少人收听, 所以这个差异还会更大

不过从网络流量的角度来说则两种方式各有利弊, 看具体的用户分布是怎样的, 如果那些收听了很多人的用户频繁的获取消息, 即意味着会有非常频繁的消息获取操作, 而这些操作都需要进行远程调用并带来网络流量开销. 不过这个问题应该可以用临时收件箱来解决, 把用户获取到的信息缓存起来, 下次有拉操作时只需要判断对应的好友那是否有更新的内容产生, 如果有则把新的信息拉过来, 否则只是一次远程查询的操作. 缓存只要维持一个不那么长的失效时间, 就应该可以在 cache 命中率和占用内容容量上获得一个比较好的折中

说来说去似乎都是拉模式更好, 那为什么还会有推模式存在的意义呢? 当然推模式也并不是一无是处, 从信息的异步角度出发推是比拉要好的, 试想如果别人说给你发了条短信, 等你要看的时候还必须对方在联网状态你才能看到他发的什么, 那不是坑爹么, 但是在 SNS 上这个问题基本不存在, 因为所有的信息发送源也都是同一公司下的服务器存储, 不可能不在线, 只是对于第三方应用来说, 需要把在第三方产生的消息推到 SNS 上来, 至少推到活动人的发件箱, 这样看推还是没有特别大的优势? 从用户体验来说, 推模式可以更快的拿到信息, 省去了多一层的信息获取流程, 登陆后就可以立即看到自己收到的消息无疑更有吸引力, 而且如果用户存在短时间密集登陆的行为, 则推模式下只要直接取收件箱就行了, 不会在后面还有 1*n 的拉取操作. 不过话说回来, 对用户密集登陆的情况, 只要高峰流量不大的离谱, 拉模式还是应该能扛住, 按上一段我们的优化方案, 不还有一层缓存么, 而且拉模式所谓登陆后要过一会才能看到信息, 这个 “过一会” 的时间绝大部分情况下应该只有不到一秒, 甚至不到零点一秒, 那这个延迟对用户而言完全感觉不到或不觉得有问题, 用户的宽带接入或手机带宽反而更可能是打开慢的原因

说到这里某狗作为拉模式的铁杆粉丝对推模式的不屑之意已经表露无疑, 估计有很多推模式的拥趸已经在准备找数据找架构要拍死我了, 那最后我再补一个拉模式更好的理由来对推模式一剑封喉, 那就是, 隐私

从本质上来说, 推模式是在维护一个巨大的面向所有用户的 cache, 而天底下几乎所有的 cache 设计思想都应该是满足超大的读请求, 一定的追加操作, 以及极少的修改操作 (如果是 FIFO 或 LRU 删除以保持空间大小这个应该是 cache 内部的事情不算调用者的操作, 所谓的修改是指改 cache 里某个 key 对应的内容), 如果是普通的消息发送-收件人阅读的模式, 推模式没有任何问题, 短信邮件活了这么久都好好的. 但是, 凡事就怕但是, 如果消息流有大量的垃圾信息, 那就会崩溃掉, 除非在收件箱里另开一块用于处理垃圾, 比如电子邮件一般都有个垃圾邮件分类, 自动帮你判别, 但在 SNS 上, 对垃圾信息的判断无法做到那么有效, 就算能判断的比较准, 也没有另一个信息流来存放 (从这点来说 Facebook 的 ticker 其实就能起到垃圾信息收件箱的作用, 信息不丢, 但是也基本不会干扰用户, 如果要找回来也有地方可以去找), 而且 SNS 上太多用户的随意行为想做撤销, 比如发了不该发的照片, 或是 spammer 被举报后要将起发送的垃圾信息收回或做过滤, 如果再考虑上因隐私范围修改而要对已发出去的消息做限制, 这一大堆修改操作会让 cache 痛不欲生欲仙欲死

考虑下 SNS 上好友关系的频繁变化, 如果有新增好友关系或收听关系, 则推模式下后台应该立即对 Social Graph 上这条新的边做消息推送, 这时候还要依赖发件箱, 即推模式无法抛弃发件箱模块. 而如果是删除好友关系, 也应该立即把这条边做个逆操作, 这个操作更重, 需要扫收件箱的所有内容并删除特定的消息. 万一还有用户注销, 或是 spammer 被封需要收回其发出去的各种垃圾信息, 或是被 XSS/CSRF 攻击后要做清理, 都需要对大量用户的收件箱做扫描和选择性删除, 这些操作既重又要求很高的时效性, 否则就可能是安全事故, 这些都让推模式下 cache 的设计初衷被破坏的一塌糊涂

再说隐私控制, 最早的 SNS 压根就没有隐私这回事, 发出去的东西谁都可以看可以评论可以分享可以做任何演绎操作, 只是我的好友能有个简单快捷的入口找到, 后来就有了仅好友可见, 发送给指定分组 (其实是发送给特定的某些人的简化版), 不可分享不可回复等各种要求, 如果这个要求一直都是固定的也还好, 再消息发送的时候加个限制, 对不该收到此消息的人不做推送, 然后消息本身自带权限标记来说明收件人可以对此消息做什么动作. 可惜的是咱们亲爱的用户永远不会这么想, 发送对象会一直变, 今天是密友的明天可能是工作同事, 那推送时的判断就是一个一直在变的表达式, 维护这个表达式和查询判断又是个很重的操作, 而用户如果再发送完成后再改权限, 那就涉及到更多的对已推送消息的修改, 比如用户从所有人可见改为仅好友可见且不能被分享, 那其实是要重复一次消息的发送过程, 万一这中间有延迟或用户过了段时间才做这个操作导致以及有好友把该消息分享了出去, 那整个更新操作就不是一步而是一个 BFS 了, 对网络调用对 cache 都是莫大的伤害

如果我们把权限收回到消息本体, 每个人的收件箱或发件箱只是一个索引, 是不是就能解决问题呢? 好像是? 但是推模式下每次从收件箱给用户显示消息时还加一次判断, 这不还是在做拉操作么? 带了拉操作的推模式? 那为什么不直接改拉模式, 还节省 cache

再回到推模式更快的用户体验, 既然加了权限验证等操作, 那这个用户体验估计也省不到哪去, 而且 发送-验证-到收件箱 和 拉取-验证-取发件箱 都是三步操作, 谁也没有更简单, 反倒是拉模式的验证过程只在拉操作时发生, 而推模式下有修改时还要补发验证流. 另外因为收件箱容量不可能非常大, 不管是 cache 的用户数还是单个用户 cache 的消息条数都有限, 那 cache 不命中时还是必须走拉模式取消息, 如果把收件箱变成拉模式触发的短时小 cache, 或用推拉结合对热点用户做一些预处理, 整个用户体验应该还是可以保证的了的, 对于 cache 里可能的消息权限改动, 只要有一次通知, 让此 cache 失效, 下次还走纯拉模式应该就能搞定

上面都是理论扯淡, 具体应用还是要看 SNS 模型和消息模型来决定怎么用好. 以下根据公开资料和个人猜测来八卦下各家的做法

Twitter 公开资料说他们走的推拉结合, 有 cache, 但是大部分还是用拉的操作, 很多调用来源是移动端或 API, 慢点就慢点大家都无所谓, 第三方 API 本身就是在定期做拉操作以变相完成推模式, 而且发出去的东西容易收不回

Facebook 对离线用户应该是拉模式加收件箱 cache, 用不经常登陆的小号很容易验证, 只要稍微有几天没登陆, 一上去 news feed 也一定是空的, 要有取的等待时间, 而且明显不是因为翻墙带来的延迟. 而且 FB 对 news feed 默认不采用时间序, 如果用推模式用户查看时从收件箱取还是要做一次排序, 且这个排序操作不是非常轻, 那再前面套一层拉操作影响也不会大, 还不如直接走拉模式, 就算考虑热点用户被拉的操作会很频繁机器扛不住, 那同步几份发件箱对拉操作做负载均衡就可以了, 比起用推模式 100 倍以上的机器需求, 如果真的大量存在热点, 拉模式增加十倍机器随便就能解决这个性能问题. 不过如果用户在线, 则推模式生效, 有新消息会立马推送到 news feed 或 ticker 里来, 只是新来的消息只能按时间序放最新的地方了. 另外删除还是一个老大难问题, 经常发现有好友被攻击后发的垃圾消息要过很久才会被干掉 (退出后 cache 失效下一次登陆改拉操作才去掉的?)

新浪微博号称他们用推拉结合, 不过据我观察和小道消息应该还是纯拉加很小的 cache, 因为新浪微博活跃的都是一群公知大号, 给他们的消息做推操作会把网络压死 (另外吐个槽草根大号的运营人员都是准点上班的, 他们会几乎同时发大量内容, 这一瞬间如果用推估计就把全网给搞嗝屁了). 对用户而言, 登陆时拉出一整页的内容放 cache, 就新浪那个前端加载速度, 绝对不比后台做一次拉操作快, 所以用户几乎感觉不到, 等用户往下滚动页面时候依次吐出 cache 内容, 速度飞快体验完美, 吐完了就该手动翻页了, 不过有多少人会往后翻? 根据我在搜索上的经验, 应该不到 10%, 而这时候慢点大家也还是可以忍, 都主动翻了还在乎这一两秒? 在天朝政治正确很重要, 所以微博删帖的效率也一定要高, 以微博的删帖量, 走推模式估计还是会把网络拖挂, 而拉模式下只要判断下最原始微博是否不存在或属被证实的谣言就 OK

QQ 空间走的应该是推, 大部分时间都一亿多用户在线, 空间上有点新动态还是很快会在 QQ 面板上跳数字, 而且腾讯一直做的是实时通讯, 在实时过滤黄反方面经验好的很, 基本不用担心有太多类似删帖的更新操作把网络弄的很崩溃. 不过具体到 QQ 空间里的一些模块, 比如个人主页等, 那就看应用场景是推还是拉了

至于人人, 可能会比较敏感不便多说, 之前号称是推拉结合, 不过在我看来就是个比较单纯的推模式, 且目前看来推模式的各种坑爹问题都存在, 比如 cache 占用太多资源, 删除操作多且难做到实时等等都有. 还因为是推模式, 整个隐私框架也难有大的改进

最后给大家瞎掰一些数据算算不同模式的 cache 需求 (包括总 cache 大小和为负载均衡用的机器数) 和网络开销 (包括调用量和带宽), 看到底怎样好 (以下涉及到平均的数字多半都是长尾分布):
A. 某网, 日活跃用户 10M, 月活跃用户 50M, 总用户 100M, 平均每个人有 150 个双向好友, 每个活跃用户在活跃天内平均有 10 次查看操作, 平均每次操作取 20 条消息, 并有平均 3 次消息发布操作, 每条消息索引 1K, 消息本体 20K
B. 某网, 日活跃用户 15M, 月活跃用户 60M, 总用户 200M, 平均每个人有 100 个单向出好友边和 200 个单向入好友边, 每个活跃用户在活跃天内平均有 20 次查看操作, 平均每次操作取 10 条消息, 并有平均 2 次消息发布操作, 每条消息索引 1K, 消息本体 2K

极端情况 1: 如果消息发送者都是出边数在 M 这个级别且其每天发送量要比平均值高一两个数量级的怎么办? (比如新浪微博的各种大号, 算完后估计你也会理解除了商业原因, 某些架构下技术原因也还是对他们做点限制好)
极端情况 2: 如果消息查看者的入边数都在 K 这个级别且其每天的查看操作比平均值高一两个数量级怎么办? (比如新浪微博的 VIP 用户, 最多关注大几千人, 而且频繁刷)
极端情况 3: 考虑下活跃用户的各项数据平均值会比全局平均值高一倍