节前上线出问题，线上灰度发布后部分用户反馈付款后订单状态不更新，支付服务的失败率飙升。一顿排查后发现致命配置错误。小可爱上线时，将payment-service服务的 Nacos 注册类型改成了ephemeral=false（持久化实例）。当时其中一台服务节点因内存泄漏频繁 GC，心跳线程被阻塞超过 30 秒，但是由于持久化实例没被 Nacos 剔除，导致调用方持续往这台异常节点发请求，最终拖垮整个支付链路。这个面试场景题总问，不过很多同学对 Nacos 临时、持久实例的认知，只停留在服务会不会消失的表面，什么时候该用临时，什么时候该用持久，适用场景是什么，没太明白。注册中心和配置中心本质区别...

祝牛友们也能遇到自己的白月光，可惜国庆我回校，她回家，时间错开了，以后给她补一束鲜花

我想知道，你一个名不见经传的小厂hr，看见我boss上的实习经历（指目前还在某大厂实习），薪资要求（跟我说实习期一天100），有什么资格，用高高在上的姿态，跟我提这么离谱的要求的？你连什么是秋招，秋招什么时候入职都搞不清，臆想别人找不到工作哭哭唧唧求着你给一份工作，还大言不惭的说“那你不能放弃现在的实习来我们这吗”希望hr在招聘的时候，清清楚楚明明白白把要求说完，别再浪费秋招面试者的时间

这是一个典型的“消息分发模型”设计问题，微博/社交平台在设计大V发博分发时，推模式（push） 和 拉模式（pull） 各有利弊。下面结合你提到的“大V发博客”场景详细分析：一、两种模式简介推模式（push）大V一发微博，系统立即将内容推送到每一个粉丝的时间线中（如写入粉丝的消息队列或Feed中）拉模式（pull）粉丝查看时间线时，实时去拉取他关注的人（如大V）最新发布的内容，再合并排序显示二、微博类应用场景选型✅ 小V/普通用户：使用 推模式粉丝数少，推送量小；内容分发量级低；直接推送到粉丝的 Feed 表中，读取快，体验好。⚠️ 大V用户（如百万粉丝）：不能用纯推模式，会有严重问题顺便吆喝...