@mayday1997 2 年以上就 OK

哪位朋友有解法，求艾特我下~

我待过 3 个公司 /部门，这个是氛围最好的

铁子们呀，快来快来呀

老铁们，人呢~~

老铁们，快来呀~~~

@sadfQED2 可以加可有可有详聊，二流三把其二丝儿八五

@sadfQED2 老哥有没有兴趣了解下快手？

@flowfire 赞

@daquandiao2 挖个贴，楼主最后去了吗，想了解下拼多多内部的氛围，最担心的还是工作节奏

@xiubin 挖贴，楼主最后去哪了呀，想了解下拼多多内部的氛围

挖贴，楼主最后去了吗，想了解下拼多多内部的氛围

借宝地，已经招到，欢迎大家继续联系我内推哈

这里恐怕很少能在老哥面前称为过来人。。。

分成几个层面：
1. 接入层：瓶颈在于并发，这个可以通过加资源、优化性能解决
2. 业务层：对于支付本身的逻辑，实时处理。各种上下游、周边逻辑，比如弹幕播报，特效等，这种尽量通过消息队列去耦合，异步处理。
3. 存储层：这里是关键，如果设置一个 mysql 余额表，显然撑不住十万的并发写，每一个请求都要对该行加锁。但是又不能完全依靠 redis，可能会导致数据丢失，不一致等。
一个方案是，使用消息队列+mysql 存储流水，使用 redis 存储余额，定时对账。
由于流水是追加写，不涉及到加锁，同时可以通过分库分表等提升性能。
redis 提供余额的高并发读、写，但是对单机 redis，十万 QPS 也扛不住，redis 集群两个方案，主从或 cluster，在这个场景，主从更合适（因为 cluster 对单 key 是固定路由到一个节点，所以没办法提升单 key 的处理能力）。再考虑到十万的并发写，这个只能牺牲一点余额的实时性，大概可以通过 group commit 或 kafka 异步更新缓存。
-----
瞎想的，不对的地方，各位老铁随意指出

@Neoth 有道理

期待，期待每一项技术变革。

有木有前端大佬啊，发现后台的好多

两个问题哈：
1. 如果楼主其他方面，比如学历够硬，那么方向最重要！方向最重要！选择自己感兴趣的方向
2. 如果这次去腾讯，比较难得，那么抓住机会，无脑腾讯没问题。