校招就是有这样的风险，跳槽是人家的自由，只能怪贵司没留住人……

估计被封了网页微信的使用权限，无解……

websocket 也行，长轮询也行。并发是必然的，有多少用户在登录就会有多少并发。又想要实时又不要并发哪有这么好的事……

指定一个回调地址，当消息返回时调用该地址即可。
很多 web 端的异步处理，例如调用支付宝进行支付，都是这么做的。

@begeekmyfriend
-- B+tree setting...
Set data index file name (e.g. /tmp/data.index):
Set index file block size (bytes, power of 2, e.g. 4096): 4
config node order:1431655762 and leaf entries:1431655762
Please input command (Type 'h' for help): i 1
Segmentation fault (core dumped)

file: bplustree.c
line: 1079

_max_order = (block_size - sizeof(node)) / (sizeof(key_t) + sizeof(off_t));

有符号数与无符号数一起运算，导致 block_size < sizeof(node) 时返回非预期的结果

对于按时间订阅的服务，这么做没啥毛病

协议上只规定了两者有不同的用途，剩下都是客户端与服务端实现上的差别

想售后？先下载我们的售后 APP （#滑稽

@puritania 几千万粉丝其实数据量并不大。对于微博来说，上 TB 的内存集群都没啥问题吧。

@puritania 我不是说数据库特殊处理，我是说缓存特殊处理。
这种数据用 NoSQL 存储，根本没有分库分表的问题。用关系型数据库存储，必然达不到性能要求，必然要上缓存。数据库进行特殊处理，恐怕收益非常有限。

用户的关注关系是一个访问极端频繁的数据，是必然要缓存在内存里的。所以即使需要用关系型数据库做持久化，在设计上也不必太考虑性能的问题。
估计会针对大 V 和非活跃用户做一些特殊处理。

你说考虑备案，他提醒一下你需要有主机才能备案，没毛病啊……
企业用户只要想做国内的业务，还能不备案吗……

不过我接到阿里云的电话，如果是推销的，我估计就直接挂了

不懂楼上的人……楼主遇到这个问题，就说明别人也会遇到这个问题。怎么就是一块钱的事情了。照理来说就算要收回优惠，也应该按订单金额等比例收回才对。否则下次先优惠 10 块钱，然后直接少发一件 10 块的东西，然后一毛钱都不退？这不是欺诈？

类似的想法在很多软件上都有，只不过一般不会做放大按钮这种操作……

楼主真是厉害……一开始就知道除了 ofo 摩拜都活不下来，那些公司的投资人大概都是人傻钱多……

要保证数据类型一点都不麻烦……返回之前强制转换一下就好了

握草傻 B 了，上面算错了。总之意思就是商家的目的不是把东西卖完，而是利润最大化。