有的同学虽然经常听说“系统可用性”、“系统可靠性”、“系统稳定性”这几个词，但却又傻傻分不清其中差别，我先来解释一下。系统可用性（Availability）：高可用的系统，故障时间少，止损快，在任何给定的时刻都可以工作。一般公司在系统可用性的要求在99.9%——99.99%之间，即：宕机时长在50分钟——500分钟之间。系统可靠性（Reliability）：高可靠的系统，故障次数少，频率低，在较长的时间内无故障地持续运行。系统稳定性（Stability）：在系统可靠性和可用性之上，即降低故障频次和提升止损速度的情况下，要求系统的性能稳定，不要时快时慢。换言之，不但要求系统尽可能地随时可以提供服...

我在技术面试的时候，经常会遇到如下场景。我：“你好，同学，可以说下MySQL有哪些锁吗？”候选人：“有行锁和表锁，乐观锁和悲观锁。”我：“还有其他的吗？”候选人：“还有共享锁和独占锁。”我：“那，还有其他的吗？”候选人：“还有记录锁、间隙锁、临键锁。”我：“还有其他的吗？”候选人有些面带惊慌：“这。。。这。。。”其实，关于MySQL的锁，这个同学真的只说了冰山一角而已，下面我们来盘点一下，MySQL是如何进行锁分类的，以及还有哪些不为人知的锁。锁分类如上图所示，是我在网上看了很多文章，总结出来的一个我认为最为合理的一个分类方式了。大家如果觉得有更为合理的分类方式，我们也可以一起聊聊。通过近期的...

首先，跟大家对齐一下，大厂中层到底是如何定义的。有的人认为，带几个人的小组长就算中层了，其实这是不对的。大厂中层的标准是总监级，即：阿里P9、美团L10、字节跳动4-1，滴滴D10等。大厂对于中层的要求是：具备跨专业领域带团队拿结果的能力。“你以为光这样就行了？呵呵，too young，too simple。”朋友老W吸了一口烟，然后慢慢吐出烟圈，故作神秘地说。老W去年刚刚在大厂答辩成功，晋升成了技术总监。接下来，他把自己混大厂的心得娓娓道来。下文是他的自述：做规划我先拉着几个团队leader搞头脑风暴会，会前我有言在先：“这个会必须明确产出未来三年我们要做的事情，从今天开始，每天从晚上9点开...

每当在面试过程中觉得枯燥乏味的时候，我总是会问候选人“说下微服务的优点”这个问题。因为，我特别喜欢看候选人在那一本正经地胡说八道的样子。在这些候选人眼中，系统架构中的”微服务“，似乎等于服务行业中的”微笑服务“，永远都是最优解一样。下面我来截取一些场景，看看他们是如何胡说八道的。胡说八道场景一：微服务更易于开发维护我：“说下微服务的优点吧。”候选人：“我认为微服务更易于开发维护，研发人员只需要关心自己负责的这个模块的逻辑即可，这样代码量和逻辑复杂度都会降低。”我：“可以展开说说吗？”候选人：“比如：如果我负责上游某服务，那下游服务的业务逻辑和存储数据结构，我们是不需要关心的；如果我负责下游服务...

相信每个互联网人都看过这段行业黑话：你这个产品的底层逻辑是什么？顶层设计又在哪里？最终给用户交付的价值是什么？过程中有没有抓手？你比其他同事的亮点在哪儿？优势在哪儿？你近期的思考和沉淀是什么？这个产品如果换成别人来做是否会不一样？那么，把互联网黑话用到现实生活中会是怎样的呢？一早上7点30分，手机上的闹铃准时响起，唤醒了它的主人——沉睡用户程序员小张，醒来后的他马上短平快地穿好衣服，洗脸刷牙，然后一路小跑地出了家门。小张来到小区门口的早点摊儿，排队买了个刚出锅的金黄的热气腾腾的鸡蛋灌饼。待他微信付完款，伸手从摊主那接过套着塑料袋子的鸡蛋灌饼时，被烫得“哎呦”了一声。小张不禁抱怨道：“你们的用户...

我发现一个非常有趣的现象。十多年前，那时“美女”这个称谓还是非常稀缺值钱的，被这么称呼的女性同胞占比，也就是不到10%的样子。后来就愈发不可收拾了，只要是个女的活的，下至5岁上至50岁的，99%都被人称呼过“美女”。当然，现在互联网行业的架构师，也越来越“美女化”了，基本上有个两三年工作经验的，带两三个应届生负责过一两个QPS不过十，用户量不过千的小系统的，把项目用SSM框架给搭建起来的，也都成架构师了。而这些所谓的“架构师”们，如果仅仅是title上的改动，平时工作中该撸代码就撸代码，该摸鱼看网页就看网页，其实也真的没什么。最最最最怕的就是，他们觉得自己的身份已经变了，是时候该体现出自己作为...

我最近发现一件有趣的事情，很多同学去一家公司面试，往往技术面挂了之后，说的最多的一句抱怨的话就是：”沙雕面试官从头到尾全程问八股文，其他方面的问题一句都不问，垃圾！！！“然后，他们往往会愤愤不平地再加上一句：“问这些虚头巴脑的东西有什么用，实际工作中会用到吗？真的是面试造火箭，入职拧螺丝！”接下来，他们还会以此作为切入点，好好地批判了一下这种“行业乱象”。八股之疡他们认为八股文是一种对录用决策毫无评估价值的面试题，在实际工作中只需要动动小手儿百度一下，就可以分分钟掌握这些技术知识点。而往往技术面试内容决定人才质量，僵化的面试必然会带来僵化的人，就像古代科举考八股文，就选拔出一批会四书五经的书呆...

这又是一个高频的场景面试题，同时，它也是一个没有标准答案的、可以跟面试官讨论很久的面试题。对于这个面试题，我的观点是：“没有完美的方案，只有最适合某场景的方案。”这个问题表面上看是数据一致性的问题，其实根本上，又是数据一致性、系统性能和系统复杂度的选择与取舍。下面我们先历数一下各种技术方案，环肥燕瘦两相宜，总有一款适合你。1、先更新MySQL，再更新Redis这个方案存在如下问题：（1）如果先更新MySQL成功了，还未对Redis进行更新的间隙期，这时如果请求过来，读到的都是Redis的更新前数据。（2）如果先更新MySQL成功了，再更新Redis失败了的话，后面的请求读到的都是Redis的更...

SQL优化，算是数据库优化的一个子集。因此，吹大牛的候选人简历上，会赫然写着”擅长MySQL数据库优化“，而吹小牛的候选人简历上，往往会写”擅长SQL优化“。但结局是殊途同归的，就是当问他们用什么方式做的优化，他们都会说上三个字：”加索引“。当然，好一点儿的会说可以加联合索引，它有最左前缀匹配原则（8.0以后的版本就不完全对了）之类的，还能说说覆盖索引。那么，我的这篇文章，就好好聊聊这个面试话题。先教大家一个小窍门，最好大家在回答面试官这个问题的时候，最好可以做到跟自己简历中项目的进行真实场景带入，这样会给面试官一种可以理论结合实践的感觉，是个大大的加分项。举个例子，话术为：“当时我负责电商平...

我想，关于秋招，大家是真的焦虑的。作为一个刚起了两个月的公众号，平时写写技术相关的内容，阅读量少则几十，多则也不超过500。结果一聊到秋招这个话题，阅读量直接干到27000去了，让我硬生生地过了一把大V的瘾。（手动狗头）现代版的“国家不幸诗家幸，赋到沧桑句便工”有没有？所以，我决定再聊十块钱的“秋招焦虑”这个话题，以一个过来人的身份，开导开导同学们。如果同学们真的干了这碗鸡汤后，觉得暖心暖胃，精神上舒服一些，那也不枉我敲这么多字了。首先说下，产生焦虑的原因是什么？参照了知乎上的众多答案，我觉得最精辟的一个答案是：担心某件不好的事情，在未来的某个时间点将会发生，但主观上又拒绝接纳。而往往焦虑的人...

目前秋招已经过了一段时间，说下我看到的情况和整体感受，仅限于计算机相关专业。另外，我感受秋招的视角比较特别，今年做了半年的Java面试辅导副业，我是以一种"秋招面试陪跑"的"准老师"身份切入的。时隔五年，又跟着十几个同学重新经历了一次秋招，有点儿"爷青回"的感觉。对比去年，依然普天同庆（ai hong bian ye）很多同学觉得今年疫情阴霾散去，经济复苏，形势一片转好，他们甚至动了冲一冲大厂的念头。但真的到了秋招的时候才发现，24秋招 = 没有迪子的23秋招，转而发下重誓，不进体制誓不为人。不得不说，那些年，我们一起甩锅的疫情，这次...

这个问题，在电商领域的面试场景题下，应该算是妥妥的高频问题了，仅次于所谓的“秒杀场景如何实现”。说个题外话，有段时间“秒杀场景如何实现”这个问题风靡一时，甚至在面试的时候，有些做财务领域、OA领域公司的面试官也都跟风问。大有一种”无秒杀，不面试“的感觉了。重复提交原因其实原因无外乎两种：一种是由于用户在短时间内多次点击下单按钮，或浏览器刷新按钮导致。另一种则是由于Nginx或类似于SpringCloud Gateway的网关层，进行超时重试造成的。常见解决方案方案一：提交订单按钮置灰这种解决方案在注册登录的场景下比较常见，当我们点击”发送验证码“按钮的时候，会进行手机短信验证码发送，且按钮就会...

这个问题，在问到Redis方向的时候，经常会以当头炮的方式出现。一般面试官说：“我们来聊聊Redis吧”，接下来就会问到：“能说下Redis为什么这么快吗”。我听到最多的答案就是：“因为它是内存数据库，不用往硬盘上写，所以快啊。”btw：这么说除了俗点儿，肯定也没毛病。我听到最好玩儿的答案是：“因为它是单线程模型，不会涉及到锁机制，所以就快了。”btw：艾玛，这个锅多线程不背，合着是线程越多就越慢呗。下面我们就来详细分析一下，正在备战面试的同学也可以记一下，算是个蛮高频的问题。“基于内存实现”这个原因就不详细展开了哈，毕竟地球人都懂的。空间换时间 —— SDS数据结构这里所说的空间为”内存空间...