确定系统的最佳线程数属于衡量容量的范畴，根据上期的知识点。衡量容量就要用到压测和监控。确定系统的最佳线程数大体上分三步：第一步，分析理论值；第二步，用压测进行调整获得实际值；第三步，持续监控，观察是否需要再次调整。理论值，首先分析资源。Linux操作系统有进程允许的最大线程数限制，默认是1024，当然这个是可以改的，还有文件句柄等其他资源，一般都不是瓶颈。每个Java线程都要占用内存空间。栈空间默认是1M，可通过JVM参数调整。与线程数关联最紧密的是CPU资源。IO密集型服务和CPU密集型服务的线程数差异很大。在《java并发编程实践》中，建议对于CPU密集型，设置为CPU核数+1；对于IO密集型，有个公式：线程数=

领域驱动设计(DDD)，因非常适合与微服务进行配合而闻名，因《领域驱动设计》那本书的难懂而让人望而却步。其实《领域驱动设计》这本书讲的是：以领域为核心，在代码中体现领域的思想，开发人员和领域专家要紧密沟通。这也侧面给出了公司划分组织结构的建议。开始之前，我要声明一点：领域驱动设计不是万能药，它适合于实时系统，而对于分析汇总的场景，则不必使用领域驱动设计。技术是在进步的，现在大家对领域驱动设计抽象的越来越好。今天就来总结一下领域驱动设计简单易用的技巧。首先声明一下：提到的技巧不一定是领域驱动设计提出来的，但是这些技巧可以帮助我们更好的进行领域驱动设计。限界上下文画架构图尽量简单易懂。但是项目本身很复杂怎么办呢？那就要按问题域划分子域。每一个子领域架构是很简单的，想看到全貌可以将它们之间的关联形成上下文地图。这就是限界上下文的作用。DDD建议区分场景来划分子领域，通过依赖接口而不是具体实现解耦。使用微服务实现限界上下文中的低耦合。微服务不是简单的拆分，而是对设计提出了更高的要求。举个常用的例子：SOA架构中建议进行数据库操作单独提供服务进行，使用方通过接口依赖实现低耦合。这个思想和DDD的思想异曲同工：DDD建议将领域对象与数据库映射，把数据表的增删改查采用接口调用实现。底层数据表结构的修改对上层屏蔽。这就是将软件对象进行持久化操作，并且形成独立的限界上下文。DDD还要求数据库表设计以领域模型为核心，并且推荐不要在sql中进行join操作，而是通过逻辑层来进行，让表与表之间的关系直接转化为软件对象之间的关系。如果看到这里你还是觉得限界上下文很抽象，不用担心，其他的技巧就是来帮忙咱们划分独立的子领域。聚合与聚合根聚合体现的是整体与部分的关系。部分与整体有相同的生命周期。一旦将对象间的关系设计成聚合，外部对象只能访问“聚合根”。充血模型就是一种聚合的实现。我在《CURD系统怎么做出技术含量--怎样引导面试》里用实例介绍过充血模型。白话来说，就是一个普通的POJO，如：“人”对象，里面有对应属性，如姓、名、年龄、学历、出生年月。贫血模型中“人”对象只包含可以通过lombok自动生成的方法。而充血模型则可以包含由各个属性组成的一个完整简历的方法，或者是直接返回星座的方法。外部只能通过这些方法，也就是“聚合根”来操作“人”这个对象，不能直接访问其内部属性。因为部分和整体有相同的生命周期，意味着人这个对象被销毁，它的属性和方法也同时消失。DDD工厂与装载DDD工厂与设计模式中的工厂有较大的差别。设计模式中的工厂，是将被调用方设计成一个接口下的多个实现，并装配到工厂中。工厂负责通过key值找到对应的实现类，创建出来，返回给调用方。这样就降低了调用方与被调用方的耦合度。DDD工厂是通过工厂创建领域对象，作为对象生命周期的起点。它的核心在于装配这个环节，比如订单工厂需要将订单对象是要将订单概述、订单明细统一封装到订单对象中。举个例子：漫画中的超级英雄在设计模式工厂中，工厂创建出来的时候可能是个小菜鸟，在业务逻辑运行过程中，他可能会需要升级打怪才变成超级英雄。而在DDD工厂中，工厂会负责给超级英雄披上钢铁侠的盔甲，装配好美国队长的盾牌。他从工厂里出来就可以拯救世界了。DDD仓库DDD工厂和DDD仓库都是聚合的实现。通过DDD工厂装配好的领域对象会返回到DDD仓库中。事实上Spring上下文就是一个DDD仓库底座。它包含了程序需要的各种领域对象。有些领域对象如DAO是从数据库中取的，有些是从缓存中取的，还有些如POJO是直接创建的。但是业务逻辑不关心领域对象的来源，只需要在需要的时候直接使用，就与领域对象的具体实现之间做了解耦。事件风暴法在领域设计之初的需求分析阶段，需求分析的基本思路就是统一语言建模。它是我们的指导思想。但落实到实践层面可以采用的方法是事件风暴法。它是一种基于工作坊的DDD实践方法，可以帮助我们发现业务领域中正在发生的事件，指导领域建模以及程序开发。事件风暴中的风暴是头脑风暴的意思，我在《复联4里用到的方法论》中详细解释过头脑风暴法，这里不再赘述。事件即事实，已经发生，不会更改。信息管理系统可以将这些事实以信息的形式存储，即信息就是事实。信息管理系统的作用就是将信息存储，管理与跟踪。对事件可以采用上游发布、下游订阅的方式进行解耦，按照业务流程来梳理领域事件。举个例子：把大象装冰箱分成三步，每个步骤都是一个事件，每个事件之间要解耦。打开冰箱门涉及冰箱领域对象、人领域对象等。这个事件完成将会触发一个信息存储：冰箱状态变成已打开。这些都是围绕着打开冰箱门这个事件展开。这个事件完成后，只要对第二步把大象装冰箱进行通知即可。之后的事情再不会和第一步发生关系。防腐层防腐层（Anti-corruption

引子下一篇标题是《深入理解MQ生产端的底层通信过程》，建议文章读完之前、或者读完之后，再读一遍我之前写的《RabbitMQ设计原理解析》，结合理解一下。我大学时流行过一个韩剧《大长今》，大女主长今是个女厨。她升级打怪的过程中，中国明朝来了个官员，是个吃货。那时候大明八方来朝，威风凛凛。那小朝鲜国可不敢怠慢，理论上应该大鱼大肉。人家长今凭借女主光环，给官员上了一桌素餐。官员勃然大怒，要把长今拉去砍头。长今解释说：官员脾胃失和，不适合大鱼大肉，让官员给她一段时间，天天吃她做的菜，他吃着吃着就会觉得素餐好吃了。官员就和她签了对赌协议。吃了一段时间素餐之后，官员向长今道歉，说明知道自己身体不适合大鱼大肉，但是管不住嘴，长今帮了他大忙。其实要讲《深入理解MQ生产端的底层通信过程》这一篇之前我也做了很多的铺垫：从《架构师之路-https底层原理》的https协议，到《一个http请求进来都经过了什么(2021版)》实际上经过的物理通道，然后深入理解三次握手《懂得三境界-使用dubbo时请求超过问题》。有的文章读起来有点难度，我希望大家能像那位中国的官员一样，虽然不情愿但还是坚持一段时间，相信对于多数人来言对底层通信的理解会提升一个层次。接下来是网络编程的干货时间，是下一篇文章的预备知识，不用担心，浅显易懂(多读几遍的话)。socket编程究竟是什么？socket的本质socket的本质就是一种类型的文件，所以一个socket在进行读写操作时会对应一个文件描述符fd(file

引子刚才下班回家路上，无意中听到大街上放的歌，歌词有这么一句：“毡房外又有驼铃声声响起，我知道那一定不是你”。这一句我似乎听懂了歌者的魂牵梦绕和绝望，如果在十年前我大概只能感受出悠扬的声调里溢出的悲凉吧。在工作上，我没有十年的时间来把思考能力上升一个等级。对于一个问题，需要在很短的时间反复思考，深层次的弄懂。懂得，有三个初级境界，对应三个方法：1>字面理解-what、why、how2>前因后果-5why3>选择最优-SMART想了解what、why、how黄金圈法则或者5why分析法可参考我之前的文章：《代码荣辱观-以运用风格为荣，以随意编码为耻》；想了解SMART原则可参考我之前的文章：《知名互联网公司需要什么样的人才》。回到主线：为什么是初级境界？我自己也不知道更高级别的境界是有什么，因为自己境界没有达到。但是至少有：刻入骨髓

引子四年前我写过一篇文章《一个请求过来都经过了什么》，这个问题是每隔一段时间我就要重新梳理一遍的。因为每个阶段接触的信息不同，看到的想到的也不同。今天来比较一下与4年前认知上有什么变化。提出问题高技术含量开放性面试题驾到：”请描述一个请求过来到响应完成都做了什么，越详细越好。”

引子很多朋友可能会因为自己做的工作不是特别核心或者业务简单而引起面试中没有自信。但是很多公司面试的时候是可以接受面试者之前岗位的并发量、交易量低一些的。比如我们要招聘和我们交易量同等级或者以上的出来的人才，业界本来就没有多少，但我们还是要招人的。所以很多时候更偏向于考察面试者的设计底蕴、思考和解决问题的能力。我建议面试时，面试者要争取主动权，主动引导面试。一般作为面试官也很乐意被面试者引导。因为面试官的职责是发现面试者的技术特长，为此我们绞尽脑汁的从简历中、自我介绍中去发掘。如果面试者可以自己有完整清晰的思路，是面试官求之不得的事情。假设我是一个面试者，近几年做的都是XX后台管理系统。后台管理系统嘛，没有高并发、没有高可用需求、没有复杂架构，属于三无系统。要是我的话，会把自己的以下知识技能放到项目介绍里展示给面试官：可测试性设计谦卑对象模式RESTful风格领域驱动设计DDD充血模型CQRS可测试性设计谦卑对象模式作为一个后台管理系统，一般场景下微服务化的价值不大。DDD领域驱动设计这种专门用于复杂问题的解决办法在这里多半也是杀鸡用牛刀。后面会讲到一些DDD技巧还是可以用的。实际中大多是采用前后端分离的架构，这种架构实践一方面是动静分离，便于缓存优化等性能考虑，另一方面也是一个出于可测试性的考虑。分离出可自动化测试的接口层和测试难度高的展现层。展现层对象等测试难度高的对象在整洁架构中被称为谦卑对象。通过拆分不同的类或者模块，来区分容易测试的行为和不容易测试的行为，这种设计上的隔离模式被称为谦卑对象模型。现在的很多设计对程序的可测试性提供了友好的改进和支持。比如：程序调用数据库执行操作，mybatis等持久层框架将把sql以接口的形式对外提供服务，接口有成熟的工具来做mock打桩，这是比较典型的谦卑对象模式。另外一个比较典型的比较典型的谦卑对象模式是feign。netflix的feign把原本需要手写的httpClient(或者OKHttp)代码使用接口调用的的形式，实现了命令式到声明式的转换。同时，谦卑对象和非谦卑对象之间有很好的隔离层，也对测试更友好。对feign想做进一步了解的可参考我之前的文章《Java&Spring过时的经典语录》，这里简单举个例子：public

引子先说说我对架构师的理解。从业务能力上，需要的是发现问题和解决问题的能力；从团队建设上，需要的是能培养团队的业务能力；从项目管理上，把控好整个项目和软件产品的全生命周期。我搜索了一下架构师的培训课程，讲什么的也有。实际上是Java从入门到精通的课也冠名架构师课程；讲持久层框架的也冠名架构师课程；讲组件、中间件的也冠名架构师课程；讲分布式系统设计的也冠名架构师课程。个人意见哈，内容其实没有什么问题，但是课程开始之前至少让大家有个整体的视图：熟悉https等常用技术的底层原理，可以增强解决实际问题的能力，作出正确的决策。举个例子：接到安全团队的指令，要求各个团队梳理域名是否存在证书将要到期的安全风险。怎么来给团队下发具体任务呢？这个问题在文章最后总结并回答。简单入门先来回答下面两个问题：1、大家都知道使用https协议传输默认使用443端口，那什么情况下必须使用443，什么情况下不使用443？大家想一下端口的本质是什么。其实端口有两种，一种是物理端口，比如集线器、路由器的端口。大学的时候记得有门课叫集成电路，里面有讲到过。另一种是逻辑端口，是TCP/IP协议的端口，也常叫网络端口。本质上一个端口是用来绑定服务的，那服务器用监听什么端口，客户端就要向哪个端口发起请求。我们自己也可以写个简单的例子，写过这个例子应该很容易就能明白。《懂了！国际算法体系对称算法DES原理》也有完整的例子。简单点说服务端可以自己决定什么端口提供服务。但是呢，大家各自为政，记忆起来麻烦也不便于端口管理。所以逻辑端口也进行了划分。其中0~1023是公认端口，比如80就默认是http的端口、443就是https的端口。这样约定好了，就不需要特殊来记了。所以一些对全人类开发的公网网站，就是用的默认端口。但是你自己或者公司内部用的或者和合作方商量好的，也可以用其他端口，只要服务提供方认就行。2、使用443的端口的同时，80端口还会用吗？这就是涉及到https的本质了。https本质是http协议上加了一个安全层。安全层做了一些处理，http要做的事情一点也没有减少。就相当于在药粒外加了一层胶囊，本质上起作用的还是药粒呀；快递送来的海鲜放在保鲜箱里还加了保鲜袋本质还是买的海鲜呀。所以当然要用啦。安全层原理既然https协议本质只是http上加了安全层，本文就主要将安全层是怎么实现的。当然要靠加密。加密又分成对称加密和非对称加密。要使用对称加密，客户端和服务端要有一个相同的秘钥，这个秘钥怎么能安全的传输就成了问题。非对称加密是公钥只能用来加密，私钥只能用来解密。那服务端自己存私钥，客户端来请求的时候，服务端把公钥发给它就可以了。那有的朋友就问了，那别的客户端来请求是不是也拿到的是同一个公钥呀，信息就不安全了呀。没错，同一个服务端给所有的客户端返回的是相同的公钥。但是威胁网络安全的黑客需要是截获信息，不是公钥。信息发送方用公钥把信息加密了，黑客没有私钥解不开。他能拿到公钥和密文，想解开那就只能暴力破解，把所有语言文字的组合用公钥试一下看看和截获到的密文是不是一样的。如果用常用的RSA2048的话，要80年。总之，非对称加密是比较安全的，但是它慢。通常加解密速度是对称加密的几百倍，信息大了速度还会快速下降。所以https协议是用非对称加密沟通一个对称秘钥。真正的信息就用对称秘钥来加解密了。CA证书很多人都听过网络抓包吧。抓包的原理和黑客截获信息差不多，都是自己作为一个代理。客户端B想访问C网站，黑客D发现了。D就伪装成了C把自己的公钥发给了B。B发请求“我是B，我的提货卡号码是XBXB”到网站C时，黑客D截获了这个信息，用自己的私钥解开，之后把数据篡改成“我是D，我的提货卡号码是XBXB”发给网站C。于是本来B的东西就被D领走了。抓包也是这种充当代理的原理。为了防止这一问题。客户端就需要在收到公钥的时候做一下判断，信任的公钥才使用。于是出现了一些大家都很认可的组织，它们可以颁发公钥。打个比方，在唐朝，贺知章贺老可谓是少有的文坛官场双得意的代表，“二月春风”没少光顾他家。从7品官做到3品大员，是皇帝的老铁，为国服务50年后退休皇帝了还送豪宅，后来还被追封礼部尚书。《长安十二时辰》里那个80多的老头何监就是影射的贺知章，因为他退休前的官职就是监事，人称贺监。不少诗坛大家就是受了他的推荐才与皇帝建立了通信成为了公务员。所以，贺监还有一个身份是“大唐最佳星探”。这里贺监就是大家都认可的组织，在贺监80多岁的时候，40多岁的李白找到贺监，请求他给自己签发一份公钥。贺监就用自己的私钥给他做了签发写了推荐信，不仅如此，还金龟换酒传为佳话。皇帝想选公务员，李白拿出了贺监的推荐信。皇帝一看，确实是贺监的笔迹，马上就给李白封了公务员。这里提一下，很多时候https抓包可以成功，原理是客户端很多时候并不验证证书的合法性。有个选项check=false。那至于哪些是认证机构，这个是系统预装的。可以在IE浏览器的internet选项里查到预装的证书。在中国，很多金融机构，它们的认证机构是央行。这些证书都是有有效期的，有的三年一签发、有的五年一签发。上面图中有显示，证书除了公钥信息，还有数字签名信息。数字签名当然需要有信息来进行签名，具体信息就是我们在生成密钥时需要输入的那些，如下图：总结回答开头的问题：接到安全团队的指令，要求各个团队梳理域名是否存在证书将要到期的安全风险。怎么来给团队下发具体任务呢？1、要梳理的是提供https服务的服务端，只有服务端才会需要找认证机构签发证书2、只有需要外部认证的证书有过期的概念，自己签发的可以更新也可以不更新。可以通过向服务端发请求的获取到证书，查看证书是谁签发的、有效期是哪天架构师经常面临着需要做出正确的决策，比如连续几天团队都在执行生产程序发布，但是后面几天大家有纪律涣散的趋势，这时候应该敏锐的察觉到并及时指出并纠正。这些都需要对原理或者事情的走向有深刻的认知才能做出正确和及时的判断。推荐阅读一个请求过来都经过了什么两个流程链路问题的排查和总结稳定性三十六计-超时处理漫画：大公司都在重复造轮子吗？

背景RabbitMQ现在用的也比较多，但是没有过去那么多啦。现在很多的流行或者常用技术或者思路都是从过去的思路中演变而来的。了解一些过去的技术，对有些人来说可能会产生众里寻他千百度的顿悟，加深对技术的理解，更好的应用于工作中去。本篇整体采用从浅到深的逻辑结构来描述。入门部分什么是MQMQ全称是Message

背景社招面试的同学往往有个误区：认为面试准备更多的是刷leetcode和按照网上的常见面试题准备。甚至花钱买网课学习kafka、flume、Redis、ES等框架，以便可以进入大厂。但是这种准备方法，最后拿到的offer级别都不会太高。一般是阿里的P6、字节的2-1、京东的T6或T7、滴滴的D7、美团老职级体系的2-3及以下。阿里的P9、美团的4-1以上我也不知道该怎么面试。但是针对阿里P7-P8、美团3-X级别，个人有如下建议。重点考察点的比重项目经历项目经历在面试中比重很大，大概占到60%-80%。如果这部分回答的不好，实际上已经被pass了。面试官问基础知识环节只是为了符合面试的流程要求走的过场。因为一般大厂为了体现对面试者的尊重，对面试时间有要求，不能低于40分钟。个人履历个人履历背景占比10%以上。这个背景主要指学习经历、工作经历等。比如跳槽频繁、没有长时间在一个公司或者岗位工作的经历会严重减分。这里面的逻辑是这样的：对于一个岗位或者业务真正达到精通一般需要2年以上的时间，这时候一般都完成了从0到1的过程，业务也会趋于稳定。自己的能力和创造性将项目带的更长远至少还需要1年或者更久。也有可能按照公司的规划，所负责的项目目前的设施和能力已经够用，不需要再深耕。那就说明自己这块已经做的不错了，理论上上级会有新的业务来让自己做。所以，有4年以上同一家公司的工作经历侧面上有可能表示之前做的还不错。软素质软素质占比5%以上。常见的软素质包含沟通能力、领导力、抗压能力等。其实价值观也是面试官非常希望考察的项目，只是在短时间里很难精准的判断。这部分主要依赖背景调查阶段的了解。但是问题比较大的话，还是能被面试官在面试阶段捕捉到。比如面试官问了一个问题：Java线程池参数详解。面试者回答如果使用ThreadPoolExecutor来创建，有5个参数(实际有7个，这个无伤大雅)，分别是线程池基本大小、线程池最大大小、线程存活保持时间、任务队列、策略(实际为线程饱和策略，说的不明确也可以接受，如果希望面试者说明确，面试官有义务进一步提问，否则不应该给面试者扣分。)然后面试官问到策略有几种。因为面试过程中面试官已经提前到面试者共享了桌面，所以面试者提议可否看着代码说还是需要背下来。面试官说可以看着代码说。面试者小声说：“我感觉是想让我背下来”同时打开了代码(说话的原则应该是言之有物、言之有理、言之有力。此时面试官脑子里画了问号：你这句补充是想表达啥？)。面试者通过代码查找到了有4种线程饱和后拒绝策略。我问面试者这四种策略都代表的什么意思，面试者说就是英文代表的意思。面试官问那这个英文是什么意思。面试者支支吾吾说英文不好，所以面试官告诉了面试者：AbortPolicy的Abort是中止的意思，DiscardPolicy是Discard是废弃的意思。那两个策略究竟有什么区别呢。面试者说没啥区别(实际上AbortPolicy:丢弃任务并抛出RejectedExecutionException异常。DiscardPolicy：也是丢弃任务，但是不抛出异常。)。这里面面试者本来只是知识深度不够。但是其回答方式容易让人联想到不符合实事求是的价值观或者是容易在压力下降低标准。但是面试官不会从一个问题给面试者定性，会结合其他问题一起来看。但是这整道题的分大概率没有了。项目经历怎么表述项目经历的表述大体和很多公司每年都会有的述职差不多。个人有个三段式的架构：先介绍项目上下文，拉齐背景信息；再介绍项目做了哪些优化或者个人有哪些业绩；最后总结一下项目心得。项目上下文，拉齐背景信息这部分表述的好要建立在站位清楚、逻辑清晰、对业务理解深入的基础上。建议从大到小、从整体到局部的顺序来介绍。不用着急，一定让面试官理解。否则下面的面试官都听不懂。项目优化或个人业绩这部分是我发现大多数面试者欠缺的地方。面试者会说目前只是维护或者是接入的工作，来了一个接入方我们对接一下之类的。给人的感觉是萧规曹随，自己没做什么。举个例子说明一下，如果是我的话，我怎么表达。比如一个支付网关系统，所做的事情是就是对接支付宝支付、微信支付、其他第三方支付或者直接对接银行。经常面临的业务需求是一个新支付机构或者银行的接入。我所做的项目优化如下：1、配置化将底层能力下沉，将原有新项目接入走代码变更发布转变为配置数据变更，提高了系统的稳定性及开发运维效率。2、监控告警优化之前告警频繁，以至于电话告警被无视，造成了“狼来了”式告警麻木。经过告警梳理，每周邮件告警降低到了40封以下，电话告警3个以下。提高了告警的敏感度。当然这么表述是不够的，要把方法说清楚，详见：《通知&告警治理(降噪)的7种方法》其他优化省略。项目心得这个可以从很多方面来说，比如跨部门沟通方面：相关阅读分享一个作为面试官的面试思路推荐一种通过刷leetcode来增强技术功底的方法刷14道leetcode的总结

情景&任务很多团队的成员都被海量通知和告警所困扰：工作日打开邮箱，几百几千封的邮件。虽然可以通过邮件过滤器将邮件分组，让自己快速找到自己最关心的内容。但是还是不可避免过个1年半载邮件过多，容量不足，其他人发邮件发不进来。或者真正出问题时，邮件过于频率，最需要的时候反而打不开邮件了。周末正在旅行，手机告警短信一个接一个的。眼看手机快没电了，还等着下车刷手机上公交卡呢。一个告警短信来了嗒嗒嗒一声，手机没电了。对于短信和邮件等通知和告警形式，当消息量大于一定程度后，平均可用价值在降低（内容熵增）。容易引起下面问题：l

Auth。我就问：Redis服务有没有设置密码。他说没有，还演示了一下，我在旁边确认了没有。就查看客户端配置有没有配置密码。果然客户端里有密码配置。这就与服务端不匹配了。问题3：报错cluster

背景前段时间接手了一个还处于方案设计阶段的工作，我重新做了设计。觉得新方案比旧方案业务清晰明朗、解决了旧方案的缺陷。我就很高兴，跟同事聊这个事情。同事就问我是怎么想到这些的呢。我说了一些细节的，但是没有把核心本质讲出来。我觉得这是个很难回答的问题。因为一个方案怎么更合适，主要因素包含业务理解、个人经验、思维逻辑。这3个要素一般都是靠经年累月的积累才获得的。从这些中提取出别人可以学习和使用的方法确实不是一会儿就能想出来的事情。市面上可以看到的关于技术方案设计的经典的书都没有仔细的去讲这个问题。比如《人月神话》讲的是项目大了怎么办、《架构即未来》讲的是架构扩展性的问题。那对于最普通的CURD(创建更新读取删除)系统究竟怎么去设计。都是做CURD的，架构师和普通开发区别在哪里。本文就来探讨一下这个问题。CURD系统怎么做出技术含量我前几年在面试别人的时候，遇到过一些面试者，已经带领别人做过项目了。可能人家的管理能力是不错的。项目管理是个博大精深的学问，可能一个项目在不同的阶段，更上层会找不同的管理者来做。比如初创团队，会找些善于创业、擅长打造敏捷团队的管理者。这样的管理者可能会比较善于鼓舞团队士气。而到了一定阶段，项目业务量起来之后，不再求快，而是求稳。这时候管理者可能会换人，新的管理者做事并不那么快，但是做决策的路很正。路很正怎么理解，打个比方说：别人提了需求，前一个领导人很好，人家来需求他就接。这个领导不是，他会分析利弊和领域、业务是否合适放在这里。再比如更一层领导提了一个需求，要求什么什么时间做完。这个领导会去分析上层领导更本质的需求，宁可延期，要做稳做好。而项目稳定之后，继续稳定下去已经没有什么业绩了。这时候可能会再换领导，这个领导会带来一些原来积累的规划、方法。总之，这个面试者可能有这些能力，但是我们要招聘一个技术人员，先考察硬实力，所以很自然的先请他介绍之前的项目做了什么和怎么做的。他自己也很没底气的说就是CURD嘛。给人感觉就是没有想法，在工作过程中思考的少。拿一个后台管理系统来说，要对重要数据进行添加修改删除，一般需要审核、审计，敏感数据脱敏，甚至需要数据灰度。将这整套流程串联起来，需要一个工作流系统，可能会用到工作流引擎。目前有些数据脱敏已经用上了NLP(自然语言处理)技术。这里面每一步都涉及知识点。数据模型有限状态机设计刚才提到后台管理系统里用到审核、审计、灰度。这三个可以与业务流程分离，做成三个工具组件。审核有审核状态：审核中、审核成功，审核失败。灰度也有待灰度、灰度中、灰度成功、灰度失败四种状态。假如有一条数据，目前它的状态可以分成数据状态：有效数据和无效数据。另外还有审核状态和灰度状态。这时候数据模型(可以简单理解成数据库的数据表设计)应该设计成三个状态用三个数据字段表示呢，还是用一个数据字段来表示这三种状态呢。这要看情况，一般来说，如果三种状态之前是相互独立的，比如：审核中是否可以待灰度，也可能是灰度中？对于一个工作流系统来说，一般要先审核通过才会进行灰度流程。就是说各个状态是互斥的。所以设计成三个字段，程序的判断逻辑会很复杂，因为有些组合是不成立的。这时候更合理的一个设计是用一个状态字段表示，通过状态机流转来控制。设计方案中可以通过类似下面的流转图来体现：实际方案设计过程中我改造了一下，状态正常从左到右流转，将终态用不同的形状(这里用椭圆)来表示。这样表示秩序感强些，更好理解。数据表设计在数据表设计时，要至少考虑数据类型、是否默认、是否为空和索引设计。比如对于钱什么的，需要用decimal(10,2)，具体精确到多少位，要根据业务理解来定。对于加密字符什么的，加密如果是md5的，可以用char，而不用varchar来提高效率。这里面就好像《红楼梦》里的台词一样，每条都很有学问。所以面试时的场景题也经常爱让进行一个数据表设计。流程设计我比较建议在一个设计方案开始时先把设计流程图先给出来，便于对方案有个整体认知。流程图也很有学问，【亿图】软件上把流程图分成了下面的子类。我个人最常用的是泳道图和BPMN。BPMN可以简单理解为业务流程图和泳道图差别不大。就是在普通流程图基础上增加一个分类，这个分类可以是阶段、也可以是执行者这些。就是给流程图多增加一个维度的信息，理解起来更清晰。总结在设计方案里还必须要有里程碑和未来规划。有句废话叫只怕有心人。在工作中，往往工作出色的并不是最聪明的，也不是花时间最长的。而是真正用心做的人。特别是设计方案，建议多用前人和大家总结的设计模板。模板最能代表一种设计思路。自己想到的、设计模板想到的都要考虑清楚，把方案做细。遇到具体的问题，要做业界调研。之前听过一个实习生做的方案，他说业界调研的时候并没有查到特别相关的方案资料。当时我的领导就说了一句特别值得思考的话：如果没有查到，肯定是你的检索关键词不对。我后来反复斟酌这句话，发现能想到的检索关键词才是真正体现自己对业务理解的。同时，业界调研的时候不仅要对业务相关做调研，需求可以分解，具体到每个步骤也需要调研。调研过程是个极好的学习机会。下功夫和不下功夫的区别，想想《红楼梦》，之所以这么多红学者。人家红楼梦的作者设计每句话都是剧透，人物说出的话，都会被啪啪打脸。里面的每道菜谱都是值得专业厨师来研究的。这都是心用到了。优秀架构师也是这样炼成的。之所以说这个废话，因为我就被diss过方案做的不够细，我也看过别人的方案不够细的。时常回想被diss不够细的那句话，觉得真的是金玉良言。心怀感激。

概念加密领域主要有国际算法和国密算法两种体系。国密算法是国家密码局认定的国产密码算法。国际算法是由美国安全局发布的算法。由于国密算法安全性高等一系列原因。国内的银行和支付机构都推荐使用国密算法。从上图可知，对称加密算法在算法体系里占了半壁江山。因为国际和国密算法的过程差异并不大。只是应用的数学公式和秘钥位数不同。DES在里面算是基础，所以今天主要介绍一下DES的原理。原理密码咱们从加密的原理说起。举个最简单的加密：我有一段明文：520我的秘钥是：221我的加密算法是：加法加密后的密文就是：741如果这个密文被截获了，接受者看到的信息是：741(气死你)，和原来明文520是完全不同的，不能知道信息原有的意思。从这个简单的例子可知：加密是包含：明文、秘钥、加密算法和密文四个要素的。加密算法可公开可不公开，常见的算法有：位移、循环位移、异或、置换、数学函数。凯撒密码加密技术从古罗马凯撒时候就在用：凯撒密码凯撒密码是古罗马时期凯撒大帝和他的将军们通信时使用的加密方式：明文：由26个字母组成秘钥：1到25之间的任意数字加密算法：循环位移密文：举例明文为eat

SpringBoot默认使用tomcat作为web容器。大家也可以通过在pom文件中exclusion掉tomcat，denpendency

引子幸福很简单：今天项目半年规划被通过，终于可以早点下班。先坐公交，全程开着灯，买了了几天的书竟然有时间看了。半小时后，公交到站，换乘大巴车。车还等着上人的功夫，有昏暗的灯光，可以继续看会儿书。过会儿车跑起来了，灯关了。我合上书，头靠着车窗，眼睛看着窗外，脑子想着怎么把书里的东西用到工作中进行知行合一。想着想着出了神，突然听到报我们小区的名字，赶紧下了车，刚好没坐过站。回家一看，那个声称今天会下班很晚的人果然比我还晚。边洗漱边想着上周末，和小鲜肉一起看了动画片。小鲜肉非要我买培根。因为他想像动画片里一样用两个荷包蛋做眼睛，培根做嘴巴。于是晚上睡觉的时候，我下单买了培根，早上7点快递送了来。我就和小鲜肉一起做早餐。他说想吃糖口味的蛋，于是我们改良了一下把荷包蛋眼睛变成摊鸡蛋大脸。本来小鲜肉说只要一片培根。我想一包都打开了，干脆一起煎了。结果因为是自己动手，小鲜肉只好多吃，结果吃培根吃的一天都感觉油腻。想着这周，一包培根要分到一天三顿里，加上配菜，和小鲜肉一起做出三种花样来。关键是小鲜肉到周末比我还忙，8点开始跆拳道，一天各种兴趣班。他想自己做早餐得早起。洗漱完，吹完头发。看看洗澡水又烧的差不多了。这次终于轮到我发那条消息：“洗澡水够了”。然后拔掉烧水的电源确保安全。竟然有时间贴上面膜再看会书，满足。原来幸福就是：其实很忙，但是能挤出点时间干点自己的事情，提升提升自己。hystrix隔离原理hystrix可以完成隔离、限流、熔断、降级这些常用保护功能。这四个功能可以这么来理解：hystrix的隔离分为线程池隔离和信号量隔离。信号量隔离原理信号量隔离就是hystrix的限流功能。虽然名字叫隔离，实际上它是通过信号量来实现的。而信号量说白了就是个计数器。计数器计算达到设定的阈值，直接就做异常处理。ratelimiter的令牌桶算法和漏桶算法，都是直接对请求量来计数。只是令牌桶算法可以将前面一段时间没有用掉的请求量允许余额拿过继续用。而漏桶算法一段时间就允许这么多，前面没用掉的也不能用了。而hystrix信号量隔离限制的是tomcat等Web容器线程数，一段时间仅仅能支持这么多。多余的请求再来请求线程资源，就被拒绝了。所以是一种“曲径通幽”的限流方式。因为实际是通过隔离了部分容器线程资源，也算是一种隔离方式。线程池隔离原理信号量隔离只是起了个限制作用，它的保护能力有限：如果下游服务有问题，长时间不返回结果。本身信号量隔离对这个单个请求是起不到任何作用的。它只能限制这样的请求太多了就拒绝，不让整个服务挂。为了解决这个问题，hystrix又产生了线程池隔离。这种隔离方式是通过引入额外线程的方式。对原来的web容器线程做管理控制：如果一个线程超时未返回，则熔断。既然引入额外的线程就涉及线程池管理、线程的上下文切换这些额外的开销。所以相比信号量隔离，线程池隔离成本更高。熔断原理隔离不但可以做保护，还可以做统计：成功了多少失败了多少。既然有统计数据了，它就可以进一步处理：失败太多了，说明现在有问题，执行完了再发现失败太浪费资源，干脆就先不让worker线程执行了。过段时间再试试。这就是断路器模式，也就是熔断的原理。降级原理任何异常需要熔断的场景，为的都是反正都是错，干脆把这资源省了。直接返回一个预定的错误。这个熔断后返回设定错误的过程就是降级。资源保护的流程从上面来看所谓的hystrix的四大功能：限流、隔离、熔断和降级。只是完成了一整个对资源保护的生命周期。来看看对应的BPMN流程图：信号量隔离的流程线程池隔离的流程现在大家请回答我一个问题：我上面说的是对的吗？hystrix隔离验证采用淘金式的思维，不要别人说什么都信。网上很多技术博客里说的都是错的。我的文章也有可能是错的，事实上我说的很多东西都带有自己脑补的成分。既然不确定是否是对的，就要去验证。先验证1>hystrix隔离确实能限制资源2>信号量隔离采用的Web容器的线程池，而线程池隔离采用的是自己独立的线程池。本次验证，Web容器使用的是spring

背景做面试官也是一个需要持续完善和改进的技能，避免面试官和面试者都没有收获或者面试感觉不舒服，间接影响公司的形象。作为面试官的核心要点1.

乱码问题现象在一类简单的业务场景下发起http请求的测试案例，返回的时候会100%有乱码。如果跳过跟厂商定制的7层负载均衡设备，直接连后端一台机器，则100%无乱码。在其他测试场景，则100%无乱码。注意，此处的100%是那段时间实际发起请求的情况中乱码的占比，与SLA无关。大家猜一猜，产生乱码的原因在哪一层？处理过程首先自证清白，我负责处理1。直连是无乱码的。其他场景是无乱码的。代码和线上稳定运行的版本是一套，线上是无乱码的。这个场景和其他场景唯一不同的是返回数据的模板是放在测试数据库中的。所以我将测试库中的模板换成其他无乱码场景的数据(避免编码问题，直接拷贝)，仍然不起作用。将模板数据改成12，也能返回一个乱码。所以乱码应该是和[处理1]程序无关。与自己这边无关，再看是上游的问题还是下游的问题？下游[处理2]是新逻辑，像SSL和处理3都是线上稳定运行的。但是从日志里看，通过[处理1]的时候还不是乱码，只是回到发起端才有乱码的，说[处理2]有问题不合逻辑。上游[跟厂商定制的7层负载均衡设备]，因为有两个场景的对比，所以还是有理由找负责的同事查一查的。他们调查的结果是没有地方进行编码转换。再往上游[案例发起端]，要证明和案例发起模拟程序本身有没有关系。因为是http请求我采用直接将请求头和body使用在其他服务器上使用curl模拟请求的方式，结果与案例平台的结果一致：使用7层负载均衡设备会有乱码，不使用则无乱码。看来与模拟程序本身无关。我们团队内部也有一个模拟工具，可以模拟请求，将http请求的body体复制进去，无论是否使用7层负载均衡设备都没有乱码。我们团队内部模拟工具和案例发起端的区别

背景如果前人认为这个一种学习提高或者检验能力的成功实践。而自己目前又没有更好的方法，那就不妨试一试。而不管作为面试官还是被面试者，编码题最近越来越流行。而两种角色都需要思考的问题是希望考察什么能力，通过什么题目，需要达到怎样的程度可以说明面试者具有了这样的能力。而要找到上面这些问题的答案，比较好的方式除了看一些理论性文章和接受培训之外，自己动手刷一刷leetcode切身实践一下不失为一个不错的方式。而既然要花精力去做这件事情，那就需要解决一个问题：我从中可以获得什么提高。以下是个人的一些经验和感受。收益对底层有了更深入的了解和思考leetcode一些常见题也是平时工作中常用的一些底层数据结构的实现方法。先举个大家使用比较多的算法：LRU(最近最少使用)，在Java的实现中实现特别简单。只是使用了LinkedHashMap这种数据结构。而如果看一些开源包里LRU的实现，发现也是这样实现的。实际上动手实现一遍，LRU就再也不会忘了。再举个数据结构的例子：字典树又叫前缀树。它是搜索和推荐的基础。标准点的定义是：字典树又称单词查找树，Tire树，是一种树形结构，是一种哈希树的变种。典型应用是用于统计，排序和保存大量的字符串（但不仅限于字符串），所以经常被搜索引擎系统用于文本词频统计。它的优点是：利用字符串的公共前缀来减少查询时间，最大限度地减少无谓的字符串比较，查询效率比哈希树高。因为之前做过搜索引擎，一直也对这块很有兴趣，所以对它底层知识的补充对个人而言，感觉深度有增加。养成评估时空开销的习惯我刷leetcode必看官方解答里估算的时间和空间复杂度。这也是作为一个架构师的必备基本能力。数组、哈希这些因为数据的位置不需要进行查找，只需要算数计算就可以得到，所以它们的时间复杂度是O(1)。链表如果直接在头部或者尾部插入，因为不需要查找，所以时间复杂度也是O(1)，但是定位的话因为涉及查找，按遍历查找来算是log(n)。所以对于jdk1.7之前，hashmap底层采用的是数组+链表的数据结构。所以如果不算哈希冲突和扩容的话，获取和插入数据的时间复杂度是O(1)；如果出现了哈希冲突，则插入因为是头部插入，时间复杂度还是O(1)；获取时间复杂度因为涉及先查找，所以是O(n)，这个n代表冲突的数量。对于在有序数据中进行查找，因为可采用二分查找等优化，时间复杂度可降到log(n).对于递归调用，如果递归方法内进行2次调用。对于层数n来说，时间复杂度是2的n次方。举个例子就是一个数等于前面两个数之和。当然，如果是前面3个数之和，不进行优化的情况下时间复杂度就是3的n次方。对于一个n*m的二维数组等需要进行嵌套循环遍历的，时间复杂度是O(n*m)，有个特殊情况是n*m，这时候时间复杂度是n的平方。对于全排列的情况，时间复杂度是O(n!)。代码简化的方法我习惯的一种学习方法是先做题，有了一定自己的总结和思考之后，再看书学习别人的总结思考方法。对于刷leetcode相关性高，也比较受认可的书是《Cracking

背景最近了解到很多朋友对限流、熔断、降级、隔离、超时重试的概念和应用场景理解的不是很到位，所以想用五篇的篇幅稍微系统的介绍一下。本篇是第一篇，是限流做详解，如果反馈好的话，我会继续写下面四篇。不好的话就算了，算我理解不够，再自己总结总结。限流的概念有朋友问我限流和熔断有什么区别，我的理解很简单。限流作用是防御上游流量超过处理能力的手段，熔断作用是容错下游的快速失败手段。举个生活中的限流例子：小A最近打算找个女朋友，他拜托了很多朋友帮自己介绍，朋友们也很给力，很多姑娘都愿意和小A聊一聊。小A发现时间忙不开了，他就制定了一个计划，一天见2个。这就是限流。举个生活中的熔断例子：小A在见这些姑娘的时候，如果有的姑娘不守时，超过约定时间半小时还没有出现，那小A就会离开。不然会耽误见下一位姑娘，这是一种熔断手段。另外，如果有的姑娘特别能说，聊天超过了3小时，小A也会打断姑娘，把姑娘先送走，不然也会耽误见下一位姑娘。这也是需要的熔断措施。限流的原理不管任何编程语言的实现，目前主流的底层就是基于令牌桶算法和漏斗算法。这两种算法达到的效果有所不同。令牌桶算法令牌桶算法是先有个固定容量的桶，一个任务会以固定的速率往桶里放token，请求来了会去取token。如果桶满了，token就溢出了。多出来的token就不要了。如果请求太快，token生产速度跟不上消费速率，桶空了，有的请求取不到token，这时候就会直接返回错误而不继续处理。举个例子：比如小A最后找到了心仪的女朋友小C。他俩相处融洽，一起包饺子吃。小A负责擀皮，小C负责包。小A会把擀好的皮放到一块案板上。这个案板可以放20张皮。如果皮擀多了，就放不下，这时候小A就会停下来等。如果皮擀的慢，小C没的包，也就只能停下来。这里的皮就相当于是token，包饺子就相当于是处理业务的请求。用图表示如下：漏斗算法漏斗算法也是先有个固定容量的桶，请求来了先经过桶，从桶里出去的速率是一定的。如果请求量让桶满了，多出来的请求就不处理了。如果桶是空的，新来的请求就能马上处理。事实上，各种MQ比如kafka就是典型漏斗算法。broker就是这个固定容量的桶，生产者会不断的将数据写到broker里，消费者是采用的拉取模式，总是以固定的速率来消费。令牌桶算法和漏洞算法的比较限流的实现基础实现在Java中业界用的比较多的是Google出品的Guava

题目一MyISAM和InnoDB的区别，什么时候选择MyISAM参考回答InnoDB是目前MySQL主流版本(5.6、5.7、8.0)默认的存储引擎，支持事务、外键、行级锁，对于并发条件下要求数据的一致性，适用于对数据准确性要求高的场景。MyISAM只支持表级锁、数据排列是按照插入顺序，没有做规则排序。适合应用以查询和插入为主，只有很少量的更新和删除操作，对事务的完整性和并发性要求不是很高的场景。实际运用看到很多人在选择存储引擎的时候会无脑的选择InnoDB，这个选择合理的一点是如果对数据准确性要求没有那么高，直接用NoSQL就好了。用MySQL就是为了可靠啊。但是实际工作中，我设计的数据库中通常都会有几张MyISAM的数据表，通常用来存储历史记录，与使用InnoDB存储实时记录信息的配合使用。举个例子：比如一条物流信息，在实时的表里存着目前物流的状态：比如配送中。这条物流在历史上经过了：正在通知快递公司取件、XXX已收揽等，这张记录表基本只有插入和查询，并且丢失一个中间状态不影响当前结果，这就很合适用MyISAM。题目二简述MySQL的MVCC多版本并发控制参考回答MVCC是对于事务隔离级别的读已提交RC和可重复读RR，基于乐观锁的实现。在LBCC(基于锁的并发控制)RC、RR和串行化分别是通过加行锁、间隙锁和表锁来基于悲观锁实现。而乐观锁的原理就是在特定的时间点(RC是每次读时，RR是事务开始时)生成一个当前快照，读数据读取快照，只在提交时判断是否有冲突，类似于git的branch和commit。MVCC会在新开启一个事务时，给事务里包含的每行记录添加一个当前事务ID和回滚指针。并包含一个Read

/xxxx?appkey={appkey}&ips={ip}&username={username}&operator={operator}")

引子先介绍几个概念，同步一下认知：容灾：是指系统冗余部署，当一处由于意外停止工作，整个系统应用还可以正常工作。容错：是指在运行中出现错误（如上下游故障或概率性失败）仍可正常提供服务。可用性：描述的是系统可提供服务的时间长短。用公式来说就是A=MTBF/(MTBF+MTTR)，即正常工作时间/(正常工作时间+故障时间)。可靠性：描述的是系统指定时间单位内无故障的次数。比如：一年365天，以天为单位来衡量。有天发生了故障，哪怕只有1秒，这天算不可靠。其他没有故障的是可靠的。稳定性：这个业界没有明确的定义，我的理解是：在受到各种干扰时仍然能够提供符合预期的服务的能力。从要求的严格程度上：可用性服务部署隔离

引子-多维空间我们生活在三维空间。看一本书的时候，每一页和下一页的内容不相同。每一页相当于一个二维空间。生活在这个空间并不知道下面要发生什么。但是生活在三维空间的我们却清楚的意识到下面一页的内容是定好的，基本不会改变的。而生活在四维空间，多出一个时空的概念。他们能看到过去和未来。对三维空间的我们来说，就像平时所说的先知。生活在五维空间，能够看到各个因素的变化随着时间产生不同的变化的过程。对一个人来说，就是他的各种可能性。就像《复联3》里奇异博士通过时间宝石做的事情。以上都是别人想过的事情。四维空间的坐标轴是时间，而五维空间的坐标轴是什么呢？我在想，可以是对世界规律的掌控。它把各个因素串联起来。对规律的掌控决定命运。如果说四维空间多出来的一维是时空的话，五维空间多出来的一维就是命运。每个人都有对规律的掌控，所以会在做一件事情的时候很确信，比如知道自己的努力终究会有回报。就好像同样的输入到同一段程序肯定得到同样的输出一样。稳定性是一直是高速发展中服务的一个难题。发展变化会引入更多的因素，最终得到的真理是：是程序就会发生故障、故障不可避免。而把这件事情放在五维空间里看，我们可以控制问题发生的各个因素，来更好的把控整个过程，影响最终的结果。OK，做了一个比今天主题更晦涩的引子。今天主题是讨论稳定性的一个因素：解决问题要彻底。对应的规律就是“海因里希法则”。海因里希法则和稳定性海因里希法则是美国著名安全工程师海因里希提出的300：29：1法则。意思是：当一个企业有300起隐患或违章，非常可能要发生29起轻伤或故障，另外还有一起重伤、死亡事故。对于稳定性方面的启发是：如果能在发生第一个隐患时找到事情的根因，就可以避免后续的故障和事故。具体事例场景一个服务在每天固定的时间点会发出服务不响应的报警。任务需要找到问题的原因并解决。行动首先分析到自己掌握的信息太少。服务不响应的直接原因是什么呢？造成服务不响应的原因有：1.

背景

1背景转眼已经过了33岁生日。作为一个大龄程序媛，昨天又收到了阿里技术直接打过来的面试电话，照例客气的回答不考虑机会之后，算算今年下来阿里技术直接打过来的面试至少也有十几次了。每次都问你是多久不考虑机会呢？我回答几年吧。这些面试官人都很好，有的告诉我说帮我备注一下。那次真有效果，两个多月没收到直接打过来面试的电话。不过不知道是不是季节的原因哈。然后就还是现在这样，挺频繁的收到电话。这是个好事，虽然我不去，或者就算我面了很大概率可能还面不过，但是至少没有因为年龄没给我机会。有机会就有希望。不是去阿里的希望哈，看好我司的前景。是职业前进的希望。2放弃焦虑，不要放弃好奇心很多人对未来表示焦虑。程序员吃青春饭，大龄程序员不好找工作……我毕业早，和我同届基本都超过35岁了。历数这些老同学、老同事。坦白说：不用焦虑了，都过得挺好的！咱们这么来算一笔帐，假设一个人25岁大学毕业做程序员，头3年月薪不到1万。开始存不下什么钱，28岁开始月薪2万，加上年终奖什么的1年存10万。到35岁退休。手上有70万存款。有人说自己工作3年月薪到不了2万，很正常，我工作3年月薪7千，要用发展的眼光看问题，只要上进肯定越来越高。存在银行大额存单里，按月取息。就是说35岁之后不干活了每月也有稳定几千块钱的收入，基本生活保障是没问题的。当然了除了基本生活保障，很多人有太多额外的花销，这个后面说。买房有月供的话更不用担心了，在大城市房子一卖，去个偏远城镇买一套，过个世外桃源的日子多好。我刚结婚的时候，公公的母亲还在世，近80的老人。有次她女儿来看她。那时候本来奶奶就住我们家。奶奶本来有些钱。她强行把奶奶从我家接走。花光了奶奶的钱后又不愿意养奶奶了，把奶奶扔到敬老院门口。她说自己现在日子过得不错，住上了楼房。奶奶就说我也想住楼房，她没答话。她走后，我就跟婆婆商量买个楼房给奶奶住。虽然那时候我自己还没有房子，什么也没有，还是花了13万买了房子先给老人住。那套房子目前也就是值个十八九万，谁给20万，我卖他。我只是想说：很多小城镇的房子是不值钱的，不用为买房操太多心。所以如果不是要求太高，生活上其实问题不大的。剩下就是「自我实现」的问题了。程序员是一个高智商群体，骨子里总有一颗不甘平庸的心。怎么在人生的旅途中破局前行呢？首先要利用自己的好奇心将自己置于「学习区」。心理学研究说，人类对于外部世界的认知可分为三个区域：舒适区、学习区和恐慌区。在舒适区，我们得心应手，每天处理熟悉的环境中，做擅长的事情，但是学到东西很少，进步缓慢。在学习区，周围充满新颖的事物，可以充分锻炼自我，挑战自我。在恐慌区，人会噶闹忧虑、恐惧，不堪重负。心被恐慌控制，不能成长。研究结果表明，在「学习区」内做事，才能进步。放弃焦虑，是避免进行恐慌区。不要放弃好奇心，是避免呆在舒适区。3以终为始，合理规划上面说70万的存款基本的生活有了保障，但是35岁之后要做点什么呢？这是一个值得从现在就开始想的问题。定好目标，才能合理规划。比如希望自己之前的工作经验能继续发挥作用，除了找个国企等相对轻松的工作之外，还可以去当讲师，传业受道解惑。未来，是科技高速发展区，程序员的比例和数量会进一步增加。这对目前已经有经验的程序员来说是个红利。他们有很多培训的需求等专门面向这个群体的需求。培训出来了就要找工作，而对于已经在这个行业有一定经验的人肯定多少有些人脉，可以将供需方联系起来。等这些人入职开始工作，他们需要在业余时间学习知识，付费的知识也是刚需。这就形成了一条产业链。如果想换个行业体验一下，好的就不说了。看看一个基本没有特长的人能干什么。以终为始，换个行业没问题，希望可以月薪1万以上的收入。外卖快递员，一单快递跑腿费大概在6元。月薪一万多，平均每天跑60单足够。自己有车，开专车。之前朋友干这个的说根据车的好坏和勤劳程度，每月入手1万到5万不等。有大爷大妈在小区门口搬把椅子给人推平头的，理发6元起。跟他们聊天，说一天100位没有问题。干这个也月薪上万。我有几个闺蜜都是做保险的，她们中差的每月在2万多。有个已经做到了领导层，下属的业绩也能让自己月入十万。几年前有几个原来一个公司出来的同事，去卖肉夹馍，开了连锁店的。这些只是例子，举这些是因为这些工作基本没有什么门槛。但不管35岁之后想做什么，现在就要开始规划准备了。这个准备甚至可以是多经历一些痛苦。只是这个痛苦不要是焦虑的痛苦。因为在焦虑的时候，人的渴望是内心的平静，是不产出正能量的。而爱情的痛苦会产生理解和懂得；挫折让人成长，打不死你的会让你更强大。羞愧更为难耐，挫折中还可对环境和他人产生幽怨。羞愧是所有的窘境都是自己造成的，是能触动心底的更大反思。这些痛苦都是可以产生正能量的，都是为了明天更好的自己的准备。而工作十年的以上的大多数程序员可能确实面临一个难关。十几年前找工作、做工作太容易了。会做能做就可以了。而现在的要求至少是做对做好。这个差异需要很多人把自己打回起点之后20公里的心态砥砺前行。要不维持现状，要不忍受一段长时间的打击和低谷而后浴火重生。4总结文本讲述程序员破局前行的两个方法：1是放弃焦虑，不要放弃好奇心。2是以终为始，合理规划。作为程序员，很多人的焦虑不是想到了未来，而是根本没有仔细想。对于未来的不确定性主要是因为这个行业是新兴的行业，这个行业还没有大批人员进入到四五十岁或者退休的阶段。但是这个问题大可不必过于担心。可能提到去送外卖、卖保险这些的时候，很多人是不屑的。很多人的焦虑不是如何养家糊口，而是怕自己从上升期跌落下来。而不让自己跌落最好的方法是放弃焦虑。我经常在来回上下班的路上，想到过去的自己多么愚蠢。愚蠢的无地自容。甚至希望自己一直愚蠢下去，就不用承受现在的羞愧。而正是现在的羞愧才体现出自己确实在成长了。才是未来自己变得更好的动力。现在有越来越多的原本铁饭碗的职业比如高速口收费人员、无所事事的政府人员。单调轻松的工作岗位在不断被设备所代替。国家和社会在逼迫很多人重新学习。而程序员本身最擅长的就是不断学习和更新自己。这让社会不论如何变化，程序员都将是最快适应的那个群体。5推荐阅读面试专家职位面试官会问什么工作中常见的五种技术leader项目改进的四个抓手

org.mockito.internal.runners.DefaultInternalRunner$1$1.evaluate(DefaultInternalRunner.java:44)

引子为什么我要刷leetcode？换工作？不是！那是？玩！巴菲特的双目标清单系统，基本方法是列两个清单，一个是职业生涯最重要的目标（不超过5个），另一个是比较重要的目标。对于比较重要的目标，要像躲避瘟疫一样的去躲避它们，不投入任何的时间和精力，把这些资源花在最重要的目标上。这个双目标清单系统以方法的形式说明三件事：1，目标很重要2，专注很有力量3，比起「有所为」、「有所不为」更为关键所以当我想做一件事情，但是想不到这件事情能给我带来实在的收益时，我就定义为「玩」。就像看电影、喝奶茶一样。我只是去做这件事，在有闲暇的时候占用一些时间，并不占用精力。

引子很早之前听同事说：“要开会了。我都知道领导要问什么，就那几板斧。”其实领导之所以为领导，人家问的问题确实很合情合理，甚至可以说一针见血。而之所以能问出来这些合理的问题，就是因为头脑中有自己的思考框架。比如要做一件事情，一个思考框架就是：1，我们现在是什么样的？2，我们要做成什么样（解决什么问题、有什么收益）？3，怎么才能达成（解决路径）？根据这个思考框架，开会的时候，给领导做汇报，一上来就说我做了什么什么。领导自然要问：“做这件事情有什么收益？”

引子上高中的时候，每次物理老师开始讲：世界是由物质构成的。物质存在三种基本的物理状态：固态、液态、气态。我脑子里就开始列举这个公理不能解释的现象：各种波：光波、声波属于那种物理状态？情感、情绪属于哪种物质呢？那时候我就创造了一套自己的理论。这么多年过去，我发现这套理论可以解释所有的事情。物质分为两种：波和传播波的介质。介质存在四种基本的物理状态：固态、液态、气态和真空。介质是波的载体，能够传导波。情感和光波、声波一样，都是一种波。真空是一种物理状态。为什么放在真空的东西会维持原来的质量、速度，而不是消失呢？我的解释是它是一种介质，可以维持物质的这些属性。所以我的基本世界公理是这样的：因为这套公理在我的世界里运行的很好，甚至可以解释灵魂、魔法、唯物主义和唯心主义。所以我一直沿用这套公理，把它作为基本的世界模型。有时候，像这样一些自建公理，当自己一直在自己现有的圈子里时会运行的很好，一旦跳出这个圈子，会有一个凌乱期，叫做：「颠覆了我对世界的认知」。面对这个困境。「奇异博士」里提供了一个很好的解决方案：「forget

Redis很好用，相比memcached多了很多数据结构，支持持久化。但是在很长一段时间里，原生是不支持分布式的。后来就出现了很多redis集群类产品，Tair是其中胜出的优秀作品之一。

在ES上层增加tair缓存。在进行数据更新操作时是单个数据读取。采用tair有更好的事务性，并减少了对ES的压力。ES只处理复杂查询请求。

读取消息的客户端。和生产者相对应，一台服务器会起一个消费者。同理，写个死循环建立一堆消费者直到内存溢出也是可以实现的。Partition和BrokerPartition

在工作和生活中，沟通是重要的一环。想把事情叙述清楚有几个常用的逻辑结构。主要分为四种类型：传统型、流程型、情境型、要素型。传统型传统型是知识点按照常用逻辑，抽丝剥茧般的展示出来。又有三种主要的结构。流程型知识点按照完成一项任务的顺序来呈现。情境型知识点按照一项能力在不同情境中的应用来呈现。要素型知识点按照一个问题在不同方面上的体现来呈现。思考Q:

考察实践经验和方法很早之前阿里打电话过来面试我，是一个架构师的职位。当时问我一个问题：在review代码的时候，如果代码特别长，比如几千行几万行，你如何去review呢？我的回答角度是这样的：1.review

一般需要打日志的有：每个对外提供方法的入口和出口，调用第三方的调用前和调用后。打印内容主要包括入参和出参。https://github.com/xiexiaojing/concise-logger

背景前段时间开发一个接口，因为调用我接口的同事脾气特别好，我也就不客气，我就直接把源代码发给他当接口定义了。没想到同事看到我的代码问：要么

力不从心型在工作中有种技术leader，总认为自己是最好的。在方案设计的时候，自己有一种方案，下属有一种方案。leader非要别人听他的。如果两种方案没有优劣之分，比较建议的做法是让真正实施的人按照自己的想法去做，让人家有个实践自己想法的空间。而自己没有办法证明自己的方法更好，这属于能力问题。认为自己是最好的，会有个副作用。容不下别人比自己强。别人受到认可，自己会不爽，所以大家处于非常压抑的状态。如果发个员工幸福度问卷，多半这组是最差的。最可怕的是这领导也特懒。比如在会议中明确说：“我愿意去外面分享啊，只要有人给我写ppt就行了。”

Spring是为简化Java开发而生的。与传统的如Sturts这样的框架相比，它采用最小侵入编程，让开发者更少的感知到它的存在。随着Spring越来越强大，Spring体系也越来越复杂。为了化解戴着镣铐跳舞的窘境，产生了SpringBoot。SpringBoot的理念是约定大于配置。大家都这么用，有了规范，一切就容易多了。这就实现了一个标准化->流程化->工具化的跃迁。复杂度大大降低。但是一般一个web工具，引用一个jar包是搞不定的。依赖的冲突问题仍然是一个业界痛点。一般一个web项目使用SpringBoot最好显示的引入5个jar包，其中最后两个是测试用的，请注意统一版本。

报警10年前我会过别人一个问题：这个逻辑上理论上不可出现空值，要不要进行非空判断呢?现在这个问题终于有答案了：要进行非空判断，判断如果问题发生则立即发出报警，报警中明确标出，如果这个报警被触发，一定是代码里有bug，请立即处理!类似这种理论上不应该触发的分支、或者触发了资源的水位，在代码中应该做报警处理。所谓资源的水位是指：比如数据库当初是按照tps3000来申请资源，达到tps2500就很危险了，应该考虑X轴、Y轴、Z轴拆分之类扩容措施。再比如磁盘空间只剩余20%，这就该检查一下是否异常情况导致日志过多、或者业务增长太快，机器配置需要更新，日志设置需要优化等。监控有些问题不需要使用推送(push)这么极端的方式，属于重要不紧急，可以在每天固定时间，或者自己有时间的时候、有需要的时候自己进行check。这种通过拉取(pull)方式来对应的问题一般通过监控来呈现。下面的配图不是有意给脉脉打广告哈。只是觉得这个四象限工作法的小帖子确实不错^_^。注：本人就职于美团，并不就职于脉脉。因为是脉脉KOL，所以会偶尔收到些脉脉的小礼物O(∩_∩)O~美团点评这边用CAT，可以侵入式在程序里灵活埋点。我每天早上9点多到公司第一件事就是查看自己负责项目的CAT有没有异常，异常包括：failed、耗时长、长尾请求，和自己最近有过发版的地方的指标。有些监控不一定是以监控的形式，比如下面是定时任务的执行状态。如果状态是failed，就需要查查问题原因了。数据报表调一调焦距，再宏观一点看。我们需要通过数据报表来分析系统、业务状况，看有哪些需要改进的点。看报表的关键是在看之前要自己有一个心理预期。让预期数据和实际数据做一个对比。这也是junit测试assertEquals的原理。举个例子：业务申请资源时，申请服务器成功时会触发incUse，释放服务器成功时会触发decUse。每个小时数据都是下面这样的：申请服务器几百个，释放服务器十几个，哇，一天要消耗近1万个服务器。资源很快就耗尽了吧？这符合预期吗？再举个例子：不比不知道，看看平均耗时就知道谁做的烂。在报表中重点数据要用不同的颜色或者特性符号进行标注方便引起注意。复盘复盘在工作和生活中用的都很好用。昨天男神发微信给我说学校群里通知说考试了。小鲜肉没在家庭群里晒卷子呢，肯定是没考100啊。果然，晚上我俩回到家看到桌子上有份99分的试卷。作为一个中科院心理学毕业的研究生，我第一个反应：别给孩子贴标签，说马虎、不细心之类的。周末咱们做个复盘。复盘原本是围棋术语，在下完一盘棋后，双方棋手把对弈过程重新摆一遍，总结过程中的亮点和不足，对局中招法的优劣与得失，并从中寻找提高水平的方法。何时复盘？小事及时复盘，大事阶段性复盘，项目结束后全面复盘。如何复盘？复盘四步曲：回顾目标、评估结果、分析原因、总结经验。在回顾目标阶段，建议使用SMART原则。下面是一个复盘例子：我在美团基础架构部参与公司的容器化项目HULK。HULK其中有一个子项目:调度系统SHIELD，目标是负责容器的整个生命周期。就是从容器创建到销毁的整个过程。根据目标来制定我们的SLA是扩缩容成功率，即创建和销毁容器的成功率。回顾目标在项目启动之初，我们SLA很不稳定，在18年底，也只有97%。当时我们制定的目标是在19年春节结束之前达到周成功率99%；19年4月前达到周成功率99.9%；19年6月前达到周成功率99.95%。评估结果从CAT（美团点评分布式开源监控系统）的统计结果来都完成了目标。分析原因能够达成目标的主要原因是从目标出发，制定了一系列以目标导向的问题收敛计划，并严格执行。总结经验过程中做的好的方面是每一个问题都用了5Why分析法找到问题的根因进行根治。不好的方面是对子模块的指标制定的不合理导致走了一些弯路。具体例子如下：从失败的数据分析，大概1%的失败是由于资源不足引起的。而资源余量子模块carter的调度成功率却基本维持在100%。出现这种差异的原因是如果资源不足，carter服务应该返回资源为0。这样carter服务实时准确的返回了实际的资源情况，这时候不允许扩容发生，就不会出现失败。而carter服务正常运转，但是返回资源还有余量，让扩容进行到执行真实扩容时才发现扩容失败。问题的原因是carter的指标出现了问题，不符合SMART原则的Relevant原则，与最终目标的相关性不符合预期。carter的SLA指标应该是：调度成功率*结果的正确率。如上图所示，调度系统SHIELD将对请求的处理划分为请求层和执行层。请求层处理参数合法性校验、资源校验等校验问题。在请求层拦截掉没有资源还进行扩容的请求是符合系统目标的。这个请求处理算是成功的。但是进入到执行层，由于任何原因导致的容器没有正常创建完成都算作失败的。所以资源校验的成功率应该定义为是否正常拦截了无资源还进行扩容的请求，即：调度成功率*结果的正确率。总结发现问题是工作中最重要的能力之一推荐阅读编写代码的「八荣八耻」-

org.springframework.context.annotation.AnnotationConfigApplicationContext@a37aefe:

两种能力境界1.解决问题在工程师中有一种人被称为”救火队长“。哪里出了问题，哪里就有他的身影，他的出现，燃眉之急就有救了。他们是解决问题的高人。但是“救火队长”在晋升上往往会遇到瓶颈。对标人物：漫威-美国队长每天严阵以待，随时准备拯救世界。无法接受钢铁侠防患于未然用机器来解决问题解放自己的方式。2.发现问题更高的高人会问一个问题：“为什么每天会任务追着你跑？你为什么没从根源上解决所有的问题？”一个在办公室里和下面人一起研究茶道的领导要比和大家一起加班到半夜的领导受欢迎。因为他们从更大的层面上杜绝了对救火队长的需要。对标人物：《罪恶黑名单》雷丁顿雷丁顿总是运筹帷幄游刃有余。所以在形势危急的情况下，他总是评价哪家的什么东西好吃，或者任何别人没有注意到的生活琐事，观众并不恨他。因为知道他早就搞定了一切。三种需求对应境界1.对应需求一个兢兢业业的工程师或团队，对产品有求必应。项目初期这样没有错，时间一长，就会遇到维护和扩展性问题。对标：下图的状态有木有很熟悉的赶脚？2.快速对应需求通过系统性的设计和不断的迭代重构，一个需求来了，通过少量开发或者不开发就可以完成。每周上班五天，三天用来团建。很好，直到公司创始人完成了最初的宏图伟业，连高层也不知道要干什么，公司开始走下坡了。对标：请参考《浪潮之巅》3.引领需求在线上跑着的服务就会产生数据，通过数据的分析，自己的观察思考，推演出新的商机和需求，开拓更大的市场。对标：请参考google的7-2-1原则。四种技术运用境界1.会用很多面试者在面试中被淘汰时很不服气，这些我会用，给我分配的活我都干出来了。为什么不要我？答案很简单，你这个工作别人也能干。所以聪明的老板宁愿花4个人的钱招聘3个人干5个人的活。所以怎么才能获得一份收入不错的工作？2.知道各种优劣势，知道怎么用更好公司绝对不会鼓励重复造轮子，他们更鼓励用好轮子。所以深入透彻的技术调研分析，根据场景选择了合适的技术是个不错的开始。但是现有的技术并不是为自己定制的。当自己用的足够深，就发现很多方面，现有技术确实不能满足自己的业务需要。3.理解原理及技术血缘，深入运用特别是一些新技术，由于场景覆盖还不是很全面，需要在此基础上做一些二次开发或者内部改造，甚至重写。重写重写着，突然觉得自己有更好的想法？4.创造技术技术创造价值，技术引领一个时代。总结持续有声音

八荣八耻中不但介绍了每个条目的意义，而且有通俗易懂的代码实例便于和实际中的代码在头脑中做对比。文中明确的指出了哪些写法是鼓励的、哪些是不鼓励的，是基于什么理由不鼓励这样做。(五)Q:

SpringBoot是一个框架和编程规范。它化简了很多个框架和组件的使用，一站式简单的完成文件配置和应用部署。因为它内置服务器并装备启动类代码，可以快速开启一个Web容器。

通用技术1.一般公司对应届生都要考察编程能力，所以应聘之前先刷刷题。我做面试官出的编程题两年没有变过。就是这道喜欢这道题是因为这是当年我去hulu面试时被面到，自己没写出来的一道题。2.对应届生的考察项，我做面试官的考察大纲是这样的：3.很早以前我被面试的时候，发现面试官很喜欢从几本书里找知识点来考察。其中一本是周志明的《深入理解Java虚拟机》。不一定，很多时候面试官在看什么书他就问你什么方面知识。有时候面试官还会问你都看什么书。我作为面试官问这个问题有以下场景：1>面试者技术很菜，并且理不清楚自己的擅长点。面试官试图从他读的书里帮他找到亮点。2>从他读的书里摸索他的思维方式和格局。

回答这个问题就要先弄清楚交易最重要的是什么。交易的核心是稳定。如果重构是维持稳定的必要条件，而我们需要一个重做级别的重构，需要大量的时间。那么这时就需要保证重构和需求至少1：1的投入。

}}总结代入思考，技术提升的关键推荐阅读「前任的50种死法」开发踩坑案例--慢就是错一个请求过来都经过了什么？(2017年http版)测测你是《花千骨》里的谁-业务代码里常用的设计模式

1.奇异博士漫威系列电影体现了很强的逻辑性最突出的是在每一个故事中和结尾都会提出新的悬疑。无限战争里奇异博士说这是唯一的办法，终局之战道出了唯一的方法是什么。

5000);最近因为OkHttpClient比HttpClient更简单易用，使用的人多起来。借助OkHttpClient的调用代码来感受一下其使用

AOP解决的问题往往可以用代理模式来解决。Java开发中常说动态代理和静态代理，而AOP就是动态代理，因为代理的类是在运行时才生成的。而一般说的代理模式写成的代码是编译期就已经生成的，叫静态代理。

然后我请了好长时间的假，到处旅行。相机的照片装不下了。我在QQ上问谁在。需要别人帮忙把照片传回去。因为正好他在线，我就一边把照片传给他，一边无意说了一句：端午节的时候可以一起出去玩。