hanhan13 最近的时间轴更新 hanhan13 最近的时间轴更新 |
hanhan13V2EX 第 374828 号会员，加入于 2019-01-03 11:58:07 +08:00 |
| 要过年了，请老哥们推荐下坚果的渠道
1 二手交易 • hanhan13 • 2020-01-15 12:21:01 PM • 最后回复来自 pcbl
|
15 |
hanhan13 最近回复了
9 天前 回复了 cheesekun 创建的主题 › 问与答 › 想把苹果全家桶换成安卓全家桶🤔 |
@cheesekun 如果你没拆修过的话，官网价格 ok 的，我也是对比了转转、爱回收等回收平台，当然你要去咸鱼卖，也许能多个百八十。官网回收的话，不用必须换购，可以打钱到银行卡或支付宝，基本收到货第二天就打钱，线下 apple store 回收只能换购。这里仔细看看： https://www.apple.com.cn/shop/trade-in
9 天前 回复了 cheesekun 创建的主题 › 问与答 › 想把苹果全家桶换成安卓全家桶🤔 |
我是冲的 iqoo13 首发，当天晚上到店里买的。把 iphone12 和 s6 给苹果官网回收了，airpods pro 、ipad 、mac 继续用。后面准备入个小米手环 9pro ，就看时间和记录运动用。
两周用下来感觉没啥不便的，特别是 vivo 的车载导航，插线和 carplay 体验基本一致。电脑上的办公套件，让我的 win 台式机也能复制剪切板了。这么多年第一次用国产高刷大屏，体验还是很不错的，特别是打游戏太爽了！
两周用下来感觉没啥不便的，特别是 vivo 的车载导航，插线和 carplay 体验基本一致。电脑上的办公套件，让我的 win 台式机也能复制剪切板了。这么多年第一次用国产高刷大屏，体验还是很不错的，特别是打游戏太爽了！
2023-10-16 16:34:39 +08:00 回复了 96XLLL 创建的主题 › 深圳 › 深圳婚纱照求推荐地方 |
2 年前在北遇映画拍的，效果非常惊艳，就是有点小贵，差不多要 9000+，看片时有一套不满意，直接安排了重拍。拍外景的话需要自己解决交通，要么自己开车，要么租车。另外就是可以找老客户推荐，好像能打个折便宜几百块，具体记不清楚了。
2020-12-07 10:29:11 +08:00 回复了 1194129822 创建的主题 › 求职 › 阿里的大哥，可以帮小弟内推一下吗？ |
@1194129822 留个微信吧，我来推你
2020-07-19 09:37:42 +08:00 回复了 bruinxs 创建的主题 › 酷工作 › [字节跳动过] [内推] [后台研发工程师 — 抖音] [深圳] |
请问楼主在深圳字节吗？能不能聊下，我最近想找深圳字节的内推。wx: SF9MZWUxMw==
2020-06-08 18:03:06 +08:00 回复了 jdz 创建的主题 › 程序员 › 一则面试题，如果 10 万人同时打赏某快手主播，对支付系统来说，瓶颈在哪里，该怎么解决呢，组件是 mysql， redis 等， 假如打赏的钱加到主播余额而不是去银行那边进行交易 |
@ISSSSSSS 可以简单介绍下一般采用什么样的补偿机制去核对吗？对这块不是很清楚，感谢~
2020-06-08 17:18:28 +08:00 回复了 jdz 创建的主题 › 程序员 › 一则面试题，如果 10 万人同时打赏某快手主播，对支付系统来说，瓶颈在哪里，该怎么解决呢，组件是 mysql， redis 等， 假如打赏的钱加到主播余额而不是去银行那边进行交易 |
@ISSSSSSS 有个问题是，你说的 2 、3 、4 是有事务约束的，只要用户支付成功，那就要保证能给主播充值上。采用分布式事务似乎不能满足 QPS 要求，不知道您有什么思路？我的想法是用队列加一组单独的充值处理应用来异步完成 3 、4 。
2020-05-19 23:00:50 +08:00 回复了 yuk1no 创建的主题 › 问与答 › 一道面试题给我整懵了，求指导 |
貌似忘了应用层的设计。判断 valid 的话，最简单粗暴的方案是直接在内存里遍历 value，假设平均每人有 1 万个订单号，直接遍历速度已经足够快了。如果 orderid 有规律的话，比如有时间顺序，就可以二分查找，应该能在微秒级搞定。
2020-05-19 22:46:42 +08:00 回复了 yuk1no 创建的主题 › 问与答 › 一道面试题给我整懵了，求指导 |
看起来像是一道分布式系统设计题。首先算一下，一百亿订单 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，保证最终一致性。
大致想到这么多，欢迎大佬们批评指正。
设计思路如下：
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，保证最终一致性。
大致想到这么多，欢迎大佬们批评指正。
Select Language