waitingChou

能说下具体哪个业务线吗？

字节面试八股文太多了。。

外地社保怎么交？

接受其他语言转 GO 吗

听起来感觉像是数据库锁竞争，没 SQL 也没啥思路。同一个用户的话做点击频率控制下

看你描述操作的内容不少，追求前端响应体验的话，可以把点击操作成功，改成点击提交成功。
接口只提交操作任务，后台慢慢执行，这个要看业务上能不能接受

第一个问题面试官问法有问题，他应该继续追问一下，那具体用到了索引的哪些字段？ 三个字段都用上索引了吗？ 笼统地回答用上了理论上没错的。

第二个问题是老生常谈的问题了，只是减少缓存不一致的的概率和影响，不可能保持完全一致。可用的办法很多，但都不能完美解决，延迟双删你入消息队列就失败的情况怎么办。binlog 也有这个问题，你也不能完全保证他运作，更何况 binlog 到缓存 key 的映射也是个问题。 你在这行数据上建了多少缓存，相当于又做了个小型系统出来。
我觉得一般控制下缓存时间不太长，比如不超过五分钟。然后采用 先操作数据库再删缓存的方案就足够。

一个比较常见的情况是，mysql 判断走索引的成本太高，还不如扫全表。

一个典型的案例是，你的查询命中了索引 2/3 的数据， 如果走索引得先扫 2/3 的数据，然后这 2/3 的数据还得回表。相当于 扫了全表的 4/3 数据。

但我不太确定这会不会 导致 force index 语法也不生效

这个业务入口会为接口带来多少的 qps 增长？
===== 这个基于原有页面的曝光，和类似入口的点击率来估算，实在不放心可以灰度
这个接口能抗住多少 qps ？
===== 压测
这个业务要上缓存的话，预计会带来多少缓存占用？
===== qps 都有了，可以估一个占用上限出来。 当然，有些数据是公用的，只要缓存一份，有些用户独占的，看你访问用户数，再结合你的缓存过期时间来估算。比如缓存时间一天，一天内有 1 万用户访问这个接口，每个用户需要缓存数据量。
现有的 redis 能抗多少并发？内存占用是否过高？是否需要增加机器？
===== 看 redis 缓存的数据类型和数据大小，配合历史的 redis 监控图标数据来做分析估算，比如流量增加一半，假设 redis 线性增加会到一个什么量级。
现有的 nginx 集群，能抗住多少并发？是否需要增加机器？
=====这个没多少经验，暂不做回答。
业务上线预计会带来 1000qps 的增长，服务器资源(接口，缓存，数据库)是否能扛得住？
=====正常来说思路还是压测，但是如果考虑这么多，那为了真实需要在生产压测，风险比较高。
这个业务的性能瓶颈在哪里？怎么查出来？ 等等
===== 我个人两种思路，第一种直接看代码，分析这段代码有哪些外部调用 /依赖，然后再从中挑出风险最高的部分。 另外一种压测配合火焰图或者 benchmark 类工具实际运行分析。

楼主如果买房无望，只考虑每个月存多少钱的话。 我再提供一个考虑的角度，就是生活舒适度，可能你觉得住城中村已经没舒适度可言了。 但是住宿环境还是有较大差别，另外一个就是通勤等成本。
像北京、深圳这样的城市，租房成本较大，很多人为了省成本，单程通勤时间长达一两个小时，在员村通勤应该还好，而且千元左右的城中村，环境应该都还可以，至少应该不是暗无天日的深巷握手楼。