点击登录后就没有输入框。 但是客户端上提示等待激活。
https://i.imgur.com/Jt8jSFK.png

注册是填写的。

VIPNU7CDR 激活不了，陷入死循环了。

3 个项目并发，ai 可以闲。人不能闲。

建立的有点晚。

刷题和刷基础知识很重要。
看到很多同学基础不扎实。上来就面试，面试一次不过。相同的问题再面，还是不会。
这里感觉不是人不努力。是缺少方法和人力。

邮件进入垃圾箱里刚看到。

简历的项目亮点比较少，三个项目都是 demo 级别。需要区分一下前后端的侧重点。
看简历的文件名目标是后端职位，需要加强一下后端相关的描述。数据库，代码分层，语言特性的使用：如切片等。减少前端的描述。

由于你的学校不错。估计还是有面试机会。建议刷题大于简历优化。

刷一下 leetcode 看看网上飞书的面经。

收到 3 个简历，已经给了简历。问问他们可以公开不？
隐去隐私信息，来给大家做 case 。

@yiyulantian 可以帮改简历。

@wjswxp 超级缺人。

登陆点赞。小机箱看上去就好看。

知识点拆解，还原成小的知识点，然后通过网络串联起来。
学习就变成了圈地。通过熟悉的知识点快速学习未知知识点，形成自己的知识网络。

这块之前想过，但是转化成产品很难。 如果 @bagel 说的。这块很难有一个切入点来做事。

这个没有最好的方案。 取决于但一个用户的任务数，以及操作读写占比，业务流程。
结构 3 {userid:xx,tasks:{taskid:{k:v...}}}

@lhx2008 ttl 设置短点，比如。 让内存里面维护的少一点对象。
或者换策略，allkey-lru 呢？

压缩数据呢？
每条数据接近 1k 大小，压缩掉 20%看看。

@Breadykid 大叔一个。
看业务，按照你需要的业务时间设置超时时间， 比如抢锁多长时间，可以设置成具体需要的时间， 比如 1 分钟或者 5 分钟。
这只是记录进度，如果需要保存进度信息。还需要存储到 mysql 中。

问题：布式下的导入进度条获取，限制同一数据表同一时间只能导入一次，需要记录导入进度，解决并发和服务不稳定引发的问题

解决：
同一数据表同一时间只能导入一次。使用分布式锁就可以解决。
服务不稳定，这块只要保证存储稳定就行（ redis/mysql ）

领导的 mysql 方案，使用建表的方式来解决分布式锁的方式目前不太建议使用在高并发的后端服务。主要是性能太差。
同事的 zookeeper 方案，使用 zk 来做分布式锁。这个方案本身没有问题。不过考虑 zk 的部署，业务代码编写并非很容易，建议可以用来扩展思路，尝试实现一个来提高个人技术水平。
目前常规的做法都是使用 redis 加个锁，然后实时更新锁就行了。


容错性低的方案一：
1. 使用 SET NX 设置分布式锁。
set table_name 0 EX 3600 NX

table_name 表示表名
0 表示进度为 0
3600 表示到期时间。这里的到期时间需要根据业务自行调整，建议大于业务每批次的处理时间。最好等于业务表导入最小间隔。

2. 如果抢不到锁表示其他业务正在处理导入，当前线程退出或者休眠后重试。
3. 抢到锁的线程批量处理业务并实时更新进度
set table_name N EX 3600 XX

N 数字，表示当前进度

4. 处理完之后，可以删除当前 key，或者设置到期时间为下次需要运行的时间。

缺点：
1. redis 分布式锁的方案虽然简单，但是并不安全。如果存储不稳定，暂时没有特别完善的方案。 关键词：” redis 分布式锁的安全性“

2. 更新进度，直接按照 table_name 设置，可能出现当前线程卡住很长时间。这段时间中当前的锁过去后，别的线程重新设置锁。然后两个线程同时写一个 key，导致进度出现问题。

可行性：
由于没有足够的信息，无法确认方案是否满足业务需求。不过根据你领导的方案可以推断，上面这个方案在设置比较合理的到期时间之后应该问题不大。

思考题：
可以从 key 入手，设计一个容错性高的方案。

大二还早。公司招实习是希望干活的。大二可以被剥削的时间太短。

在学校参加开源项目，acm。
大三暑期找短暂实习再找实习工作不迟。

优惠券不会比 12306 复杂。 优惠券提前生成，乱序放到 redis 的列表里面，或者 MQ 里面。

redis 列表可以按照用户 hash，这样可以减少一次锁。并且可以拆分到多个 redis 中，增加 qps （ 1w qps 用不到）。
拿到优惠券之后，就同步记录用户流水，并更新优惠券状态。 如果更新成功再记录流水。

如果需要同步快速返回，可以将更新优惠券状态改成异步处理，但是到账也是异步。

如果 qps 达不到要求还要减少 io。可以以 redis 数据为准，则还可以减少用户流水的记录（存在优惠券丢失的情况，更新 redis 成功，写 mysql 失败。需要业务逻辑去补充这类数据）。