思路一开始就错了，这种判存在的问题肯定是布隆过滤器或者位图。你说的不能删除元素问题，首先想想是否一定要到元素级别的删除？是否能接受批量级别的删除？如果可以，建立一千个布隆过滤器，每个负责千分之一的 uid （须选择足够随机的哈希方法），过期时间为一天加随机时间（ 60 分钟内）。这是简单方案，仍可能有 0.1%级别的流量穿透，所以查询数据库限流也是必须的。更可靠的方案就复杂了，有必要再考虑。

@whjhh 不做别的吗？
你们反馈太慢了，去年拉勾给你们投简历后我都拿好几个 offer 了你们才约技术面

你们金融组是干啥的？

你们金融团队是做啥的？

感觉布隆过滤器合适。
误判率的意思是:把 ID 放进布隆过滤器中，若 given_id not in bloom_filter，则该 id 一定不存在于你的 ID 集中；但若 given_id in bloom_filter，有一定可能实际上并不存在于你的 ID 集中，这一定可能就是误判率。

你们有做金融么？除了风控

补充一下，靠谱意思是能力还没达标但培养一下可以干活不捅娄子，就这样都没招到啊，说多了都是累

现在这个价格招不到靠谱的人
不是来抬杠，我们也是港股券商，我们组招了大半年硬是没招到一个……

我是通信硕士转的后台开发，对转行的人来说，能找到实习的话，实习意义还是很大的。如果找不到，就好好刷题，刷题比啥都重要。

SICP 讲的是函数式编程和抽象，抽象即隔离变化的部分。我真正理解递归是从这本书开始的。
另外楼上推荐的 Designing Data-Intensive Applications 适合所有后端入门分布式系统。而且不是简单的入门，我个人感觉这本书对于分布式系统的逻辑是自洽的，有种融会贯通的感觉。

去年面试微信支付的时候面试官说微信支付已经全面使用了，我同学说微信很多团队都是 11 以上了

对了，分批的时候需要 order by id

给你几个建议：
out of memory 从两方面优化：①只查询所需字段而不是 select *，如 select card_info from card_table ；②分批，假设每次查询一万条记录，如果有自增 id，那么可以这样查询，select id, card_info from card_table where id > last_id limit 10000，其中 last_id 是上次查询出来的最大 id ；
索引方面优化：这个本来需要根据表结构和查询条件来，但是可以先简单粗暴地对 where 涉及字段建索引，explain 一下看看效果。

ultra boost 黑武士，好看

港行 MacBook Air 8000 多，我刚买了 7577，挺爽

月薪两万也是搞懂 csapp 就行了，跟着 cmu 15213 的课程上完就是了，其他用得着再学

@augneb 原来如此，感谢交流，祝招聘顺利哈