大家好，我是白露。

今儿个半夜，我在牛客里溜达，一不小心就瞄到这么一句话：

等我反应过来，我就乐了，这话太有意思了！

我差点儿没把手机给扔了，哈哈，这不是明摆着的反话嘛！

啊，说真的，要是大胆宣布“今年工作好找了，比去年容易多了”，那估计得挨一顿炮轰，没人信吧，即便今年稍微宽松那么一丁点儿。

但话锋一转，“今年比明年好”这种，貌似自然就有那么些道理，哈哈，是不是听着就容易接受多了。

白露觉得，持着“今年最美，未来都不如”这种念头，挺好的，至少咱们得积极一点儿。

还有一句话：“2024年工作环境是前十年最差的一年，同样也是后十年最好的一年”。

在我的粉丝群里有一个同学曾说过： “20年我毕业的时候感叹我们真是最倒霉的一届，16/17/18/19哪一届都比我们的条件好。

但是现在是24年了，我只能说我们那个时候真好，至少比21/22/23/24届哪一届的条件都好。

希望24届4年后不要和我有一样的感叹”

不管在什么时候，我们回不到过去，但是坚信现在比之后好，白露觉得是很有必要的。

老实说，咱程序员这一行，早就不是“培训学了三个月就能拿offer”的时代了。

现在哪儿还有不少培训班挂着“学费五万，找不到工作就退款”的大旗，我只想说，这玩笑开大了。

当然，我也不是说培训就一点儿用都没有，之前有朋友通过培训收获了不错的offer，但那个全额退款，你可别上当。

你可以吐槽学校的课程设置不好，学的东西没培训机构的精，但别为了躲避一个坑结果又跳进一个坑里去。

再说说我的情况，现在的确是能感觉到，大家对暑期实习格外重视。私信找我改简历的粉丝，大都是25届打算暑期实习的同学。

换句话说，今年暑期实习的竞争可比去年激烈多了。

这也是从去年秋招24届的小伙伴传来的信号**：有实习经历，面试机会多，offer也容易拿到**。

于是没找到暑期实习的小伙伴开始急了，是转前端呢，还是转测试，或者是运维？

我在这儿就想说，真没啥必要非得那么急。实习的门槛其实比秋招还高，高在HC少。

再加上，能参加暑期实习的基本上都挺优秀的。大部分人都是早早就开始准备的。总之呢，对于那些优秀的人来说，不管是回暖还是回寒儿，能上岸的总是会上岸的。

说白了，难就难在学历、项目经历、八股问答掌握得差一些的朋友。

我还真是感激我那会儿早生了几年，刚好赶上互联网野蛮生长的好时候。虽然那时候学习资料没现在这么多，但竞争对手少啊。

那会儿找工作，谁管你微服务分布式呢，谁啃过那堆算法题，谁知道MySQL索引、MVCC，或者Redis分布式锁等等高大上的技术。

随便把简历一投，公司觉得你能通过两三个月的内训成长起来，就让你开工了。

现在？

完全换了个模样，哪怕是小厂面试，都得你展示一下自己造过的火箭，别提大厂的四五轮面试了，面试官能把你问得怀疑人生。

看来，这就是所谓的不幸中的万幸吧？

学习资料一搜一大把，无论是算法、八股，还是实战项目，只要你愿意淘，总能找到宝。

学好了，忍住一年半载，还是能找到工作的。

最怕的就是，不知道往哪学，学不懂，坚持不下，那可就。。。

总的来说，今个儿秋招得抓紧了！

回归正题，今天要看的是《饿了么》的场景题，希望大家一步一步，拿到心仪的offer！

场景题：实现一个登录拉黑功能

面试官: 你好，今天我们有一个场景题，实现一个登录拉黑功能。我们需要处理一批要拉黑的用户名和手机号，既要实现拉黑，也要把已经登录的被拉黑的用户踢下线。首先，请你分享一下你的思路。

求职者: 嗯。。。大致上，我们可以按照以下流程执行：

1. 拉黑列表管理：一个存储机制来保存所有被拉黑的用户名和手机号。这个列表需要支持高效的查询，因为每次用户登录时都需要检查其是否被拉黑。
2. 用户状态管理：需要有一个机制来跟踪当前已登录的用户。这个管理系统同样需要快速查询用户状态，以便于确定哪些用户需要被踢下线。
3. 登录验证流程：在用户登录流程中，增加一个步骤来检查用户是否在拉黑列表中。如果在列表中，则拒绝登录。
4. 踢下线逻辑：对于已经登录的用户，如果他们被新加入到拉黑列表中，需要有一个机制来将他们踢下线。

面试官: 很好，你能详细地描述一下实现这些步骤的技术细节吗？

求职者: 当然可以。

1. 拉黑列表管理：可以使用键值存储系统，如Redis，来实现拉黑列表。使用用户名和手机号作为键，拉黑状态作为值。这样可以利用Redis的高效读写性能来快速查询拉黑状态。

2. 用户状态管理：同样可以使用Redis来管理用户的登录状态。当用户成功登录时，将用户的标识（例如用户名或用户ID）和其登录令牌存入Redis。这里可以设置一个过期时间来自动处理登录会话的超时。

3. 登录验证流程：在用户尝试登录时，系统首先查询拉黑列表，检查该用户是否被拉黑。这一步可以通过查询Redis中的拉黑列表来实现。如果用户被拉黑，则直接返回登录失败的响应。

4. 踢下线逻辑：当一个用户被加入到拉黑列表时，系统同时检查其是否在已登录用户列表中。如果在，系统将发送一个命令或消息来终止该用户的登录状态，并清除其在Redis中的登录记录。这个过程可以通过消息队列或直接服务间调用来实现，确保实时性。

面试官: 对于实时性，你有什么具体的实现思路吗？

求职者: 对于需要实时踢下线的用户，我们可以采用WebSocket或长轮询等技术来实现服务端与客户端的实时通信。当用户被加入到拉黑列表后，服务端可以通过这个实时通道通知客户端，客户端接收到通知后执行登出操作并提示用户。

此外，为了保证系统的可扩展性和可维护性，我们可以将拉黑列表管理和用户状态管理封装成独立的服务，通过RESTful API或gRPC等方式与主业务逻辑进行交互。

面试官: 你已经提供了一个非常全面和细致的实现方案。但有一个问题，在实际的网站或者app中，一般都不会使用webscoket来保留状态，可以使用session或者tokne来实现么

求职者: 您提出的确实是一个很好的问题。

在实际的网站或者App中，确实不太可能使用WebSocket来保持用户的登录状态，因为这样做的开销较大且不是所有应用场景都需要实时通信。更常见的做法是使用Session或Token机制来管理用户的登录状态。那么，我来重新梳理一下这个场景的实现思路。

1. 拉黑列表管理：依然可以使用Redis来存储被拉黑的用户名和手机号。

2. 用户状态管理：对于用户的登录状态，我们可以通过Session或Token来进行管理。用户每次登录成功后，系统生成一个唯一的Token，并将这个Token与用户的身份信息关联存储起来，比如也可以存储在Redis中。Token会在响应中返回给客户端，客户端后续的请求都需要携带这个Token来进行身份验证。

3. 登录验证流程：在用户登录时，系统首先检查提交的用户名或手机号是否存在于拉黑列表中，如果存在，则拒绝登录。如果不在黑名单中，则继续正常的登录流程，生成Token并返回给客户端。

4. 踢下线逻辑：对于已经登录但后来被加入到拉黑列表的用户，我们可以在用户的每次请求中进行验证。即在请求的认证环节检查用户是否被拉黑，如果用户已经被拉黑，则清除对应的Session或Token，并要求客户端重新登录。这样就可以实现将已登录的用户踢下线。

这种方式不依赖于WebSocket，而是通过传统的HTTP请求和响应机制来实现。对于客户端来说，如果收到了需要重新登录的指示，可以自动或提示用户进行登出操作。

面试官: 这样的改进更加符合实际应用的情况。你对于这种机制有什么进一步的优化建议吗？

求职者: 为了进一步优化这个机制，我建议增加一个中间件或拦截器来统一处理用户认证和黑名单校验的逻辑。这样可以减少代码重复，也便于维护。另外，针对被拉黑的用户，我们可以提供一些友好的提示信息，引导用户了解为什么会被踢下线，并提供合适的解决方案或联系方式。

面试官: 很好，今天的面试就到这，我们之后再见。