hanhan13

2 年前在北遇映画拍的，效果非常惊艳，就是有点小贵，差不多要 9000+，看片时有一套不满意，直接安排了重拍。拍外景的话需要自己解决交通，要么自己开车，要么租车。另外就是可以找老客户推荐，好像能打个折便宜几百块，具体记不清楚了。

@1194129822 留个微信吧，我来推你

请问楼主在深圳字节吗？能不能聊下，我最近想找深圳字节的内推。wx: SF9MZWUxMw==

@ISSSSSSS 可以简单介绍下一般采用什么样的补偿机制去核对吗？对这块不是很清楚，感谢~

@ISSSSSSS 有个问题是，你说的 2 、3 、4 是有事务约束的，只要用户支付成功，那就要保证能给主播充值上。采用分布式事务似乎不能满足 QPS 要求，不知道您有什么思路？我的想法是用队列加一组单独的充值处理应用来异步完成 3 、4 。

貌似忘了应用层的设计。判断 valid 的话，最简单粗暴的方案是直接在内存里遍历 value，假设平均每人有 1 万个订单号，直接遍历速度已经足够快了。如果 orderid 有规律的话，比如有时间顺序，就可以二分查找，应该能在微秒级搞定。

看起来像是一道分布式系统设计题。首先算一下，一百亿订单 id 和一亿用户 id 一共 10G 左右(假设每个 id 占 8byte)，数据量不算大，就算每天都新增一百亿订单，5 年的存储需求也不过 20T 左右。但问题在于并发很高，可以粗略认为系统的 QPS 要求达为一千万。
设计思路如下：
1. 系统架构。自上而下分为 4 层：网关层--->应用层--->缓存层--->数据层。
2. 存储系统。 首先考虑数据模型，系统里涉及到的数据为用户 id 和订单 id，两者为一对多的关系。由于 QPS 的高需求以及无事务需求，应该优先选择 NoSQL 。针对一对多的关系，可以考虑列存储数据库，比如 HBase 和 Cassandra 。每个用户对应一行数据，大约这个样子：uid(主键) | "orderid1, orderid2......" 。其次是缓存层的设计，可以使用 redis 或 memcached 对请求结果进行缓存，使用 LFU 策略，缓存 20%的数据(根据 28 原则)，当然一开始这小数据量，全缓存也没关系。
3. 扩展性。高 QPS 以及系统持续增长决定了必须考虑可扩展。扩展主要是两点：i). 分表分库分片； ii). 请求的负载均衡。对于 i，可以考虑按照 userid 对数据进行 hash 分片，范围 hash 和一致性 hash 都可以满足要求，一致性 hash 更万金油一些。可以考虑直接做 100 个分区，前期可以将每 10 个分区物理上放在一起，后期需求上来了再迁移。对于 ii，上面提到的 4 层两两之间都可以添加负载均衡，目的是避免出现热点，以及保障每层功能高可用。
4. 容错。一是缓存层需要使用副本，主要用来分担读请求，防止数据库击穿。二是分区的数据库需要副本，主要是保存数据，也能分担读请求。副本方案一般是单 master 多 slavor，保证最终一致性。
大致想到这么多，欢迎大佬们批评指正。

吃瓜群众路过支持一下