你想的太多了，仅仅查询订单表是否存在已付款的订单就足够安全了，试读一部分是全部用户都一样的吧，也不需要单独做权限控制，至于判断用户是不是购买用户...

将大字段从表中拆出去，单独建库，做好分表策略使得单表数据量足以满足查询速度，可以考虑用 redis 缓存数据，每个 key 设置较短的超时时间，每次 get key 时重置超时时间，让热数据一直在 cache 中，冷数据及时过期。

@pkookp8 你写 c 底层玩的好 做其他的都简单啊

换种思路？ cache 永不过期，数据变更时你主动更新 cache。

个人觉得短连接的 socket 还不如老老实实用 http 了，之前用 swoole 做过 apns 推送长连苹果的服务器。

新手直接做 java 吧 生态太牛逼了

我们之前的 dba 是每天早上都是把慢查询日志发到开发的邮件里。

@immomohr 是的啊 年前投的 我是真的比较想去你们公司 现在我感觉比上次面试也成长了不少。。

17 年上半年去面试过，当时没过，现在在投简历都无视我啊。。 是有间隔时间吗。。

社保交的越少,养老保险就是大坑,公积金是越多越好

这个职位现在还在吗 老哥

现在还招吗 大佬

旋律黑，死 不要太带劲

@owenliang 不明白你什么意思 数据库存储结构跟批量写入有什么关系

@fcten 数据库肯定是要有完整数据的，缓存的话每个大 v 几千万的粉丝都缓存感觉不太现实吧。

不要心疼工资了 这职位要求不高 会简单改改 cms 就行了

@clino feed 也是很难的设计

@fcten 问题就是特殊处理应该如何处理。。

@clino 所以说是推拉结合的 可以考虑只给再现用户推 部在线用户 上线时拉取