岁危机。虽然我不迷信这个说法，但是我很清楚的知道：我身处的这个行业已然内卷，如果没法维持和我当前年龄以及薪酬相匹配的竞争力，终究会迎来分水岭。那时候，我的职场发展曲线将会往下走，也许这个节点会推迟到

字，也是全网难得一见的有关程序员职场发展方面的资料，里面有大量的案例，同时提炼了很多经验。我相信如果在职场初期你就能重视并且用对方法，无疑能让你的职场之路走得更顺畅，成长和收入一个都不会错过。

具体是如何工作的？举一个很形象的例子，如果我们把「Kafka」类比成「高速公路」：1、当大家听到京广高速的时候，知道这是一条从北京到广州的高速路，这是逻辑上的叫法，可以理解成

鹏哥，他跳槽到一家快速发展的创业公司当技术总监，恰好那时我也打算离开大学同学的初创公司，看看外面的机会。得益于亚马逊那两年多鹏哥对我工作的认可。他跟我说，要不你来我这边带一个团队吧，就这样我有了

大家好呀，我是武哥。今天给大家分享一个颇具争议的知乎问题。知乎链接：www.zhihu.com/question/421237964有经验的同学都知道：「高并发」属于高频面试题，同时也被很多人称为「面试造火箭，工作拧螺丝」的典范。我也算是无心插柳，用去年写的这篇文章：高并发，你真的理解透彻了吗？作了回答，很意外地被推荐成了热门内容，收获了我在知乎的第一个

C），那又该如何解决呢？如果采用传统的队列模式（单播），那当一个消费者从队列中取走消息后，这条消息就会被删除，另外一个消费者就拿不到了。这个时候，很自然又想到下面的解决方案：也就是：当

其他的应用场景基本类似，都能回归到消息模型的特性上，找到它适用的原因，这里就不一一分析了。总之，就是建议大家多从复杂多变的实践场景再回归到理论层面进行思考和抽象，这样能吃得更透。

—方法论交代完了，本来当作首篇技术文的前言来写的，发现写完后字数已经挺多了，而且感觉还有些价值，所以单独拎出来水一下。《吃透系列》的首个技术方向是

Top，对于复杂需求或者复杂问题能够快速理解，具备将复杂工作拆解成一系列简单子问题并搞定这些问题的人。他们能从实际场景出发，有造轮子的能力，也有不造轮子的觉悟。高质量：编程质量能做到团队中的

你最想传递给评委的亮点是哪一个？充分利用标题、文字加粗等形式突出这个亮点，去掉不必要的废话。3、非常不建议粘贴大段代码，这不是代码审查会，你可以用流程图、类图等方式呈现你的思路。4、PPT

这些都是技术实力以外的东西，任何一点做不好都很难说得上是一篇好文章。因此，好素材不一定能写出好文章，好文章不一定就有高阅读，高阅读也不一定带来高关注。每个环节，如果你都能做到精益求精，从

相关的原理知识介绍清楚了，下面正式进入问题的分析过程。最开始拿到这个问题，我也是比较头秃的，尤其看到读者下面这段信息。当然，我的功力是达不到盲猜水平的，说下我的完整思路。

本文作者：张勇，现任科大讯飞高级架构师。11年后端经验，曾就职于同程艺龙、神州优车等公司。乐于分享、热衷通过自己的实践经验平铺对技术的理解。一位七牛的资深架构师曾经说过这样一句话：“Nginx+业务逻辑层+数据库+缓存层+消息队列，这种模型几乎能适配绝大部分的业务场景。这么多年过去了，这句话或深或浅地影响了我的技术选择，以至于后来我花了很多时间去重点学习缓存相关的技术。我在10年前开始使用缓存，从本地缓存、到分布式缓存、再到多级缓存，踩过很多坑。下面我结合自己使用缓存的历程，谈谈我对缓存的认识。01

经典著作《重构》这本书中有这么一段话：一开始，我所做的重构都停留在细枝末节上。随着代码趋向简洁，我发现自己可以看到一些设计层面的东西了，这些是我以前理解不到的，如果没有重构，我达不到这种高度。重构，着实是一件让程序员兴奋的事情。今年年初，我们团队完成了一个复杂项目的重构工作，它属于广告系统最核心的引擎部分，大概有

10月8日，在去往丽江的旅行车上，音响中放着《林中鸟》，老婆靠在我肩上酣然入睡，我在手机上随心地敲打着文字。此刻，心情无比的放松，世界似乎都是静止的，空气中弥漫着的是自由的味道。—

的故事相信很多人都听过，年轻爸爸去超市购买尿布时，经常会买点啤酒犒劳自己。因此，沃尔玛将这两种商品进行了捆绑销售，最终获得了更好的销量。“啤酒与尿布”的故事这个故事背后的理论依据就是

广告、增值服务、佣金，是互联网企业最常见的三种盈利手段。在这3大经典中，又以广告所占的市场份额最大，几乎是绝大部分互联网平台最主要的营收途径，业务的重要性不言而喻。从技术角度来说，广告业务涉及到

从元旦节开始写公号，转眼已经半年多了，粉丝数在上周达到了5000，非常感谢读者们的关注（文末一点小福利）。写作，本身是一件不太容易的事情，能把它坚持下来，还是挺让自己感动的。虽然称不上牛逼，但是的确很锻炼人的耐力，基本上占用了我周末大部分的时间。平时忙于工作，累计只输出了19篇文章，但一直把质量当做自己的底线，希望能对得起读者们的时间。半年下来，心态上也经历了不少变化。越发觉得：当你把公号当做自己的个人品牌去运营，算得上「一场修行」。—

之前，我写过几篇有关「线上问题排查」的文章，文中附带了一些监控图，有些读者对此很感兴趣，问我监控系统选型上有没有好的建议？目前我所经历的几家公司，监控系统都是自研的。其实业界有很多优秀的开源产品可供选择，能满足绝大部分的监控需求，如果能从中选择一款满足企业当下的诉求，显然最省时省力。这篇文章，我将对监控体系的基础知识、原理和架构做一次系统性整理，同时还会对几款最常用的开源监控产品做下介绍，以便大家选型时参考。内容包括3部分：必知必会的监控基础知识主流监控系统介绍监控系统的选型建议01

今天一大早，收到了HR发的入职1周年邮件，顿时有一丝小感慨。一方面，时间真的猝不及防，过得很快；另一方面，过去这1年里自己在努力地做出改变，虽然找到了一些节奏，但是内心依旧没法做到平淡如水，不迷茫却略带点焦虑。去年7月份，我从待了3年时间的创业公司离职，当时的目标很明确：就是希望打破固有的思维和环境，将自己在技术管理路上的经验换一个平台去验证和升级。转眼已经1年了，同时这也是我迈向总监路上的第1年。皓月当空，很久没有驻足远望，当停下来，再去思考当初的目标和所经历的变化，又有些新的感受。这篇文章，算作一个小结。—

client包进行定制化开发时不小心引入的，很显然没有经过仔细测试，并且刚好在我们上线前一天发布到了中央仓库中，而公司基础组件库的版本是通过super-pom方式统一维护的，业务无感知。7.

2、各层进行水平扩展：无状态水平扩容，有状态做分片路由。业务集群通常能设计成无状态的，而数据库和缓存往往是有状态的，因此需要设计分区键做好存储分片，当然也可以通过主从同步、读写分离的方案提升读性能。

今年元旦节，我写了第一篇有关管理的文章：#工程师如何从技术转型做管理#这篇文章系统性地总结了「从技术往管理转型期间，会遇到的挑战和应对方法」，累计有7万左右的阅读，引起了挺多过来人的共鸣。对于初级管理者来说，「能否顺利转型」是第一大挑战，因为它会决定你后续的发展路径。最终的结果无外乎这两类：第1种，放弃转型，发现自己不适合做管理，最终回到技术岗位，走专家或者架构路线。第2种，接受转型，认可管理者的价值，并且愿意投入热情和精力走好管理这条路。针对第2种情况，每个人的成长速度似乎又完全不一样。我身边有挺多一线管理者，摸爬滚打了好几年，一直没法晋升到中高层管理。而有些发展快的，2-3年时间便能跨越一个层级。到底是什么原因决定了这个差距？如果想在管理上做到快速成长，有没有可参考的建议呢？从技术经理到二线公司的总监，我经历了团队规模从几人到几十人的变化，用心体会过团队建设的方方面面。针对上面这个问题，我谈谈我个人的

上图中，按照对象所占内存大小排序，显示了存活对象的实例数、所占内存、类名。可以看到排名第一的是：int[]，而且所占内存大小远远超过其他存活对象。至此，我们将怀疑目标锁定在了

sql：引入RDD（弹性分布式数据集）这一特殊的数据结构，将SQL转换成RDD的计算，并将计算的中间结果放在内存中，因此相对于Hive性能更高，适用实时性要求较高的数据分析场景。3.4.2

上面这张监控图，对于服务端的研发同学来说再熟悉不过了。在日常的系统维护中，『服务超时』应该属于监控报警最多的一类问题。尤其在微服务架构下，一次请求可能要经过一条很长的链路，跨多个服务调用后才能返回结果。当服务超时发生时，研发同学往往要抽丝剥茧般去分析自身系统的性能以及依赖服务的性能，这也是为什么服务超时相对于服务出错和服务调用量异常更难调查的原因。这篇文章将通过一个真实的线上事故，系统性地介绍下：在微服务架构下，该如何正确理解并设置RPC接口的超时时间，让大家在开发服务端接口时有更全局的视野。内容将分成以下4个部分：从一次RPC接口超时引发的线上事故说起超时的实现原理是什么？设置超时时间到底是为了解决什么问题？应该如何合理的设置超时时间？01

图片

“同样的职场起点，为什么几年后大家差距很大？”“如果想快速升职加薪，有什么好方法吗？”“如何才能做到持续且快速的成长？”这些疑惑都离不开一个本质问题：『职场价值』，因为企业用人的核心出发点是：你能否为企业创造价值？你的价值和薪酬职级是否匹配？你是否还有升值潜力？所以，当你想清楚了一个人的职场价值到底该怎么衡量时，很多职场疑惑自然就不存在了，自己的成长方向也会更加明确。上周末，听了土豆教育CTO易洋的在线分享，关于如何经营好人生，他给出了一个公式，我觉得这个公式改造一下非常适合用来表述『职场价值』：一个人的职场价值

2、客户端限流：在接口设计时，我们就预埋了一个限流因子参数，可由服务端动态控制客户端的限流比例，在通知客户端抢红包的接口中，我们根据当前的在线人数以及红包总个数动态算出限流因子，控制最多只有10W

嫌组员效率低：一个你认为简单的需求或者技术问题，交给团队成员后，他们的处理时间远超出你的预期，当外界施压时，你忍不住抱怨和责怪，并开始自己动手处理，久而久之，习惯自己冲在一线，觉得这样效率最高。

弄清楚根本原因后，最简单的解决方案就是：增加一个新的业务线程池，用来隔离父子任务，现有的线程池只用来处理扣费任务，新的线程池用来处理反作弊任务。这样就可以彻底避免死锁的情况了。

我们在使用缓存的时候，不管Redis或者是Memcached，基本上都会遇到以下3个问题：缓存穿透、缓存并发、缓存集中失效。这篇文章主要针对【缓存并发】问题展开讨论，并给出具体的解决方案。