这东西根本没一个标准，还是主要取决于 公司招人急不急 /候选人多不多。

不急又有得挑的时候，别说有空窗期了，待在一家公司时间稍微短点都不要。一本看不上，985/211 起步。

@mooyo 深圳果然有点离谱，这价格广州起码能租个两房了

没做过外包，但是带过外包。外加我其他一些了解，仅供参考。

外包的工作楼上说明的挺好的了，你虽然在对应的大企业办公，但是你并不是该公司的员工，该公司的一切福利基本与你无缘。 之前在腾讯的时候，外包连门禁权限都没有，出入办公区还得等正式员工帮忙刷卡开门。

这些都还不算特别离谱，重点是工作内容，属于是有任务了就叫几个外包过来， 做最脏最累的活。 印象深刻的是有次技术讨论的时候，大家说这个方案可以，但是某部分的工作比较麻烦，属于重复打螺丝的类型。 另外一个项目负责人就说：这个不算问题，交给外包就行了。

所以外包是和核心项目技术无缘的，你想从外包的经历里好好沉淀学习非常难。

而且态度上，大厂的员工也大概率没有把你当同事，是把你当工具用，所以技术讨论不会叫上你，也不会跟你有过多的解释，再加上从事的都是技术脏活累活，成长性非常堪忧，久而久之我觉得也会失去思考的能力。

基于上述的事实，稍微上点档次的公司招聘正式员工时，外包经历都是非常大的黑点，因为默认外包经历没有技术含量可言，简历这一关都非常难过。

我的想法：
1. 车的各项开销对你来说较为轻松。（考虑一段时间失业、不工作、奖金等不稳定收入大幅缩水等情况下）
2. 确实能给生活质量有较大提升（经常出去周边郊区游玩、经常出行且行李多例如有小孩的情况、充面子等等）

两条起码得占一条

你细想一下，如果你想精确展示 总页数，这个 count 值是肯定需要的对吧？ 查询是避免不了的。

如果你觉得每次查询有点浪费，那缓存的作用就是减少 DB 查询压力的，所以上缓存就好了，至于前端缓存还是后端缓存看你的业务；
缓存更新机制则看数据实时性要求，要求比较低可以设置个几分钟自动过期都行。

但如其他楼提到的，相比于 count ，翻页到很后面的时候 limit offset 的问题一般更大一点，DB 要抛掉非常多的数据才能取到当前页。

所以现在蛮多地方都直接不显示总页数，而是”前一页 /后一页“的方式，因为很少有人真的翻到非常后面的页数，不必要花大力气支持这个伪需求。

打当地市长热线咨询一下。

广州地区的我咨询过，可以是可以，但是额度少非常多。还是得自己交

也有过这样的时期，细想一下如果是无来由的，那可能就是大姨夫日来了，这个是有科学研究发现确实存在的。这种时候去运动一下，跑个步会缓解。

如果潜意识里是担忧事业、或者其他人生问题，其实这种时候我个人感觉是最适合读书吸收的时候。

你带着困惑去读书，效果是最好的，当年就是在职业瓶颈期读了 《少有人走的路》，收获很大。
讲实话我之前完全看不进这种类型的书，但是也是因为对事业，人生迷茫，越看越上头。

当然这本书也不一定就适合你，不过现在找书太容易了，带着你的疑问和困惑，去找本书看看

那不如 1w 搞一台 m1 的 mac pro ？ 标配就是 16 + 512 的，比你 mini 多个屏幕岂不美哉

我理解的，架构师其实说白了和普通开发没有特别明显的界限区别，很多架构师平时可能也在写业务代码。
架构师的活，很多开发平时也在做，就是写技术方案，优化已有架构、设计新的系统架构。

要说区别的话，就是比普通的开发经验更多，对于技术方案和软件架构更有心得。

要成为架构师的话，我分享一些我的思考：
1. 要有经验和技术广度打底。
经验帮你了解 实用套路，技术广度则是熟悉常见的技术方案、组件，了解他们各自的优缺点、适用的场景（这点很重要）。
2. 技术之外的阅历经验累积。
很多时候设计一套架构不能简单完全从技术出发，你得开始考虑一些其他的东西，比如：
你得考虑这套技术方案的上手难度，维护团队水平咋样，搞不搞得定这套方案；
这套东西的成本会不会太高了，是不是换成本低点的方案，会让架构复杂一点，麻烦一点。
某个中间件虽然很适合现有的架构，但是社区不活跃，维护力度也差，如果出现 bug 比较难处理，是否退而求其次换个社区活跃点的。

3. 形成架构设计、评估套路
比如怎么评估现有的架构是否合理？让你从 0 开始新建一套系统的架构，你的思路是什么？这方面可以从别人分享的一些架构文章学习一点，但最重要的还是 结合自己多年的经验，总结出自己的一套思路，才能在日常工作中运用自如。

4. 牢记一些规则
没有一套架构可以打遍天下。阿里、京东、pdd 虽然都是电商，架构肯定是不一样的。
先有场景，才有架构。抛开具体的业务场景聊架构只能泛泛而谈。
要考虑业务发展，但不要过渡设计，合适的架构都是慢慢演化而来的。比如一开始业务还不知道有多少量的时候就上分库分表，异地多活多中心等复杂的方案， 会让初期项目落地的成本和时间压力变大。
清楚地知道自己架构为了什么场景设计的，在什么场景下会有问题，并清楚地向相关人员重点说明。（比如系统不适用于高并发，或者不适用于响应时间非常敏感的场景）
...

确实很贵，而且后期估计还有销售不停地让你们加精修照片张数，报价能好几百一张，你说不要了还会反复地磨你加照片，翻来覆去地说哪张好看还是加一下。

男生一般还比较理性克制，但女生感性可能架不住 一辈子就这一次之类的话语反复洗脑。

我结婚照好像也是三四千订的，拍了五套服装，最后选片的时候销售来回磨，老婆又加了大几千。但确实就这一回，你太小气又和老婆闹矛盾也操蛋。

真的，国内现在很多行业就是逮着结婚生娃使劲薅，觉得这是刚需你们舍得掏钱。

其实现在年轻人想开了挺好的，除了吃喝玩，结婚生子算啥刚需？

52

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

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

外地社保怎么交？

接受其他语言转 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 类工具实际运行分析。