del

极客时间专栏/geek/高并发系统设计40问/结束语/春节特别策划 | 我们如何准备抵抗流量峰值？.md

@@ -0,0 +1,77 @@
+<audio id="audio" title="春节特别策划 | 我们如何准备抵抗流量峰值？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ee/e6/eeeeddba9908501f1a98314c1ab601e6.mp3"></audio>
+
+你好，我是唐扬，今天这一期加餐，我想跟你聊一聊如何准备抵抗流量峰值。
+
+如果你是后端技术团队的负责人，那么在日常工作中，除了要完成产品提出的功能需求点之外，通常还要思考如何让系统平稳度过流量的高峰期。也许你会问，我的系统用户量级也不大，平时的并发量也不高，难道也需要考虑如何抵抗流量峰值吗？
+
+在我看来，你当然需要，主要有两点原因：
+
+一个原因是，我们应该未雨绸缪，让技术走在业务前面，因为运营团队一次成功的活动就可以给系统带来比较大的流量，如果你在技术上没有准备好，就会拖了业务的后腿。比如我之前维护的一个直播系统，平时的DAU只有十万左右，8台云服务器就可以支撑了，然而有一天，我们邀请了姚晨、郑爽等明星来做直播，大量的粉丝涌入直播间和她们互动，给系统带来了极大的冲击。那么，如果你遇到这种情况，该如何准备呢？
+
+另一方面，你的系统也是不断发展的，系统的流量更不可能一成不变，你需要为系统的发展做准备。
+
+而我们一般需要应对多种场景下的流量高峰，比如秒杀活动，还有就是我刚刚提到的明星空降直播间的活动，再比如特殊的节日（春节、元旦等等），也会让系统的流量高于日常的流量。那么我们在这些活动、节日来临之前，要做哪些事情应对可能到来的峰值流量呢？这就需要你做一些预案。
+
+之前的课程主要涉及了在设计高并发系统时的一些方法，但无论你的系统设计得有多健壮，为了确保系统能够万无一失，我们还是需要在之前做一些预案的。
+
+## 如何确定系统的瓶颈点？
+
+在准备预案的时候，首先要梳理系统的调用链路。你要记住，我们需要保证整个系统的可用性，所以，你不能认为自己不用担心负载均衡服务器、数据库、缓存这些组件，因为它们是系统的一部分，你有责任主动地帮助发现问题和思考如何解决问题。
+
+还是以我目前维护的系统为例，我们的系统刚刚完成了往公有云的迁移，但是原有自建机房服务的机器以及依赖的存储资源还没有完全下线。原本我们想使用公有云来支撑春节的峰值流量，但是由于服务刚刚迁移完成，公有云上的一些组件还不是很成熟，所以我们担心云上的服务在支撑高并发流量的时候会出现问题，就考虑使用公有云和自建机房一同支撑流量。经过我们对整条链路的梳理，下面就是一个简单版本的部署图。
+
+<img src="https://static001.geekbang.org/resource/image/eb/0c/ebc74ac7f512f2704af5225fd08a080c.jpg" alt="">
+
+你发现了吗，这不就是我们在[28讲](https://time.geekbang.org/column/article/171115)中讲到的同城双活方案吗？事实上，云机房与自建机房确实在同一个城市，经过我们的测试，两个机房之间的延迟在3ms左右，是可以使用同城双活的部署方案的。不过，这里有一个小小不同之处，那就是自建机房依赖的数据库与公有云上的主库之间有一个主主同步，而不是主从同步，这是使用公有云上的工具来实现的。这么部署的主要原因在于，我们期望在自建机房保留完整的存储服务配置（主从配置），这样一旦云上服务出现问题时，我们可以随时把全部流量都切回到自建机房中。
+
+有了部署图之后，我们就需要逐一地来观察数据流转的链路上是不是存在瓶颈点，以上面的案例来看，你主要需要考虑以下几点：
+
+首先，对于入口的LVS服务，主要考虑入口和出口带宽上是否可能存在瓶颈。我们在之前的某一次流量高峰时就是这一层的带宽达到了上限，从而导致客户端访问服务的时候出现了大量的请求失败的情况，最后也是通过客户端的监控及时发现了问题。
+
+其次，在系统出现性能问题时，我们需要尽快确定瓶颈点是在LVS、Nginx还是在服务层。一个简单的做法是收集这三层的访问日志，从中计算出请求量、响应时间以及慢请求数量，而问题一定出现在出现慢请求的最下一层上。比如，如果服务没有慢请求，但是Nginx有慢请求，那么就很有可能是Nginx有了问题。我们之前就遇到过类似的情况，后续果然是部署Nginx的云服务器挂载的云盘带宽到达了瓶颈，影响了服务器的I/O，造成了服务的不稳定。
+
+再者，你需要关注链路上的网络带宽以及线路的稳定性。无论是在自建机房还是云机房，机房网络的拓扑结构都会是比较复杂的，任何一段线路或者是网络设备都有可能出现问题，而一旦它们出现问题，你的服务也会随之受到影响。比如我的公司自建机房有多个，几个机房之间以专线相连，那么当服务存在跨机房的服务调用时（当然，你需要首先了解系统依赖的服务部署在哪个机房），就要关注专线的带宽和稳定性了。
+
+当然，如果想要系统化地了解系统中可能出现的问题点，全链路压力测试依然是最主要的一个途径。
+
+## 如何制定抵御高并发流量的预案
+
+了解了系统的瓶颈点之后，我们就可以有针对性地制定预案了。在我看来，在不对系统架构做大调整的前提下，我们能够采用的方案并不多，总结起来主要有以下几点。
+
+**切流，也就是把流量从一个机房切换到另一个机房。** 这种方法比较通用，你的服务或者依赖的组件出现容量问题时都可以采用这种方法，但前提是你的服务是多机房部署的。**切流的方式一般有两种：**
+
+一种是全部流量流经一个机房的入口，然后在入口下面的某一层负载均衡层转到另一个机房，这种方式优点是流量的切换比较快速，基本上可以在秒级就完成，而缺点则是需要依赖专线，这是因为流量从一个机房转到另一个机房需要跨专线，如果专线的稳定性存在问题，那么流量的切换也会有问题。另外，跨专线之后也会增加服务接口的响应时间。
+
+另一种方式是从域名解析也就是流量的最前端切换，我们可以配置某些地区或者全部地区的一定百分比的流量切换到另一个机房，这种方式的优点是不依赖机房之间的专线，当然了，服务响应时间不会增加，缺点则是流量不会被及时的切换过去，这是因为由于DNS缓存的存在，DNS更改的生效时间会在小时级别。在我看来，如果你部署的专线稳定性可以保证，也能够忍受服务接口的平均响应时间增加几毫秒，那么就可以采用第一种切流方式。
+
+**扩容，也就是通过增加冗余或者提升配置的方式，提升系统或者组件的流量承载能力。** 这里不仅仅包括横向扩展服务器的数量来提升服务的请求处理能力，还包括我们使用的组件的扩容。比如说，我们可以通过增加MySQL、Redis的从库来提升组件处理查询请求的能力，再比如我们可以增加多组Memcached的副本来提升Memcached抗并发的能力。
+
+**有一点你可能没有想到的就是专线的扩容，** 比如提升专线的带宽或者是部署双专线来提升专线的可用性。这里需要强调的是，需要扩容的资源一定要提前准备好，或者是提前扩容好，这样可以避免出现问题再扩容时的忙中出错。
+
+**降级，** 即暂时关闭次要功能来保障系统整体的稳定性，这种方式我们在课程的[34讲](https://time.geekbang.org/column/article/176917)中有过详细的介绍，这里就不再多说了。不过我需要强调的一点是，降级策略一定要经过验证，你可以在测试环境验证，也可以在业务低峰期验证。
+
+**限流。** 这一部分内容在[35讲](https://time.geekbang.org/column/article/177796)中也有过介绍，你可以提前在系统中埋下限流的代码，在系统遇到超过预期的流量，而你又没有办法通过切流或者扩容的方式解决的时候，启用限流的策略。
+
+以上几点就是几种常见的抵御非正常峰值流量的方法，你在实际的工作中可以灵活地使用。形象点儿说，系统的维护其实就是流量的操控艺术，你或是将流量切向别处（切流），或是提升流量处理能力（扩容），或是截断流量（降级），又或是限制丢弃流量（限流），直到你的系统能够处理分配给它的所有流量为止。
+
+## 课程小结
+
+以上就是本讲的全部内容了。本讲我带你了解了在峰值流量到来的时候，如何迅速确定系统的瓶颈点，并制定相应的预案。这里你需要了解的几个重点是：
+
+<li>
+梳理数据流经的链路可以帮助你了解系统的全貌，也能够让你避免因遗漏了某些组件而没有制定相应的预案；
+</li>
+<li>
+在高并发流量流经你的系统时，线路上的每一个组件、设备、线路都有可能成为你的系统的瓶颈点，你一定要小心评估，避免遗漏；
+</li>
+<li>
+切流、扩容、降级和限流是几种常见的抵御高并发冲击的方案，你可以结合你的项目来灵活使用。
+</li>
+
+总之，预案是你针对活动或者节日突发流量的准备，关系到你的系统的生命线，因此你在制定预案的时候一定要考虑全面而仔细，不放过每一个可能出现问题的点，并且将压测作为发现问题的常规手段，不断地调整和完善，这样你在经历流量高峰的时候，才能够真正做到“泰山崩于前而色不变，麋鹿兴于左而目不瞬”。
+
+## 一课一思
+
+结合实际工作谈一谈你在面对突发的流量冲击的时候是如何制定预案的呢？欢迎在留言区和我一起讨论，或者将你的实战经验分享给更多的人。
+
+最后，感谢你的阅读，虽然课程结束了，但我一直关注着留言，与你同在。

极客时间专栏/geek/高并发系统设计40问/结束语/春节特别策划 | 高并发下如何发现和排查问题？.md

@@ -0,0 +1,79 @@
+<audio id="audio" title="春节特别策划 | 高并发下如何发现和排查问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f4/85/f4e8f150dc20d51de43137da7d2f5a85.mp3"></audio>
+
+你好，我是唐扬，新年快乐！
+
+过年嘛，都要吃好玩好，给自己一年的辛苦付出“加餐”，那咱们的课程也不例外，在新的一年里，我为你策划了两期加餐，今天先来聊聊在高并发下，我们如何发现和排查问题。
+
+为什么要讲这个问题呢？是因为我在课程结束之后，发现有同学反馈说：
+
+虽然课程里几乎涵盖了高并发系统设计的全部方面（比如数据库、缓存和队列的使用、分布式系统主要组件的原理，以及系统运维方面需要关注的重点），但自己按照课程中提供的方式正确使用了组件，在实际工作中仍然会发现系统中各种各样的问题，比如服务性能衰减、依赖资源的抖动甚至是服务整体故障。
+
+尤其在高并发环境下，由于并发请求更多，对于资源和服务的压力更大，所以原本隐藏在冰山下的问题又都会在某一时间突然浮出水面。
+
+**这其实就像墨菲定律说的那样：** 如果事情有变坏的可能，不管这种可能性有多小，它总会发生。这不是一个数据概率问题，也不是一个心理学效应，而是一种必然的法则。
+
+在高并发场景下，一些细微的问题可能会迅速恶化，并且对系统中多个模块的SLA带来巨大的影响。比如，业务仅仅缓存的平均响应时间增加1ms或者缓存命中率下降1个百分点，都会带来灾难性的影响。这不仅增加了问题排查的难度，也对问题排查的及时性提出了更高的要求。
+
+那么作为团队核心开发成员的你，在系统存在隐患的时候，如何快速发现问题？在出现问题的时候又要如何排查呢？接下来，我就结合课程中讲到的一些知识，通过一些实际案例，再带你深入了解一下。
+
+## 如何及时发现问题
+
+这一点我们在课程中已经有过介绍了，在我看来，主要有两个手段：监控和压测。在这期加餐中，我再用几个实际的案例强调一些你容易忽视的点。
+
+首先，你需要格外重视客户端的监控（也就是我在[31讲](https://time.geekbang.org/column/article/174617)中提到的监控），因为这一级的监控是最靠近用户的，也最能真实反映用户的使用体验，有时候你发现后端的监控一切正常，但其实在用户这一侧已经存在比较严重的问题了。我分享一下这几天在项目中发生的事情。
+
+我的项目最近在做上云的迁移，在迁移到云上之后，我们会使用某公有云的外网负载均衡服务。在这个负载均衡服务上，我们购买了一定量的外网带宽包，这样就可以让内网应用和外网通信了。但是，当流量超过了这个带宽包中提供的带宽总量，就会产生丢包的现象。而在元旦节日的高峰期时，这个带宽包就达到了瓶颈，但是从服务端监控来看，所有的性能指标都显示正常，但是在客户端这边已经有用户感觉到接口响应时间缓慢了。
+
+从客户端监控来看，在带宽被打满的那段时间里，客户端请求服务接口会有大量504的响应码，如果我们可以针对客户端监控做一些及时的报警，就会很容易发现这个问题了。
+
+另一方面，压测也是一种常规的发现系统问题和隐患的手段（在课程中我也介绍了应该如何实现全链路压测系统，以及在实现中需要注意的点）。而在最近的迁移上云项目中，我也着重对云上部署的服务做了一次完善的全链路压测，在压测的过程中确实发现了很多云上服务和组件隐藏的问题，下面我就分享一个真实的案例。
+
+在我现在维护的项目中，会重度依赖Redis缓存作为提升数据读取速率的手段，而在我们做全链路压测过程中，当我们的压测流量到达一定的量级，会出现访问某一个或者几个Redis组件时，平均响应时间有比较大波动的情况，有比较多的慢请求，影响了请求的响应时间。
+
+发现这个问题之后，我们首先看了一下Redis的监控，发现在波动期间，Redis的CPU使用率会有大幅度的上升，接近100%，同时观察到Redis会逐出大量的Key，所以推断逐出Key时会消耗大量的CPU时间，从而导致CPU负载升高。进一步通过观察监控发现，在逐出大量的Key之前，Redis的连接数会有比较大的上涨。
+
+我们和公有云维护同学讨论后确认了原因：由于我们的Redis内存使用率接近100%，那么当连接数大量上涨的时候，Redis需要逐出Key，释放出内存资源，从而保存连接信息，**那么为什么Redis的连接数会大涨呢？** 进一步观察业务错误日志，同时排查Redis客户端代码之后我们发现，在连接数上涨之前，业务服务在访问Redis的时候会有一些慢请求，这些慢请求会导致业务认为与Redis的连接出现问题，会重新建立新的连接，并且异步关闭现有连接，从而导致连接会在短时间之内有大幅度的上升。
+
+而我们通过使用tcpdump抓取网络包发现，在这一段时间，Redis的响应时间确实有比较大幅度的升高。通过进一步排查Redis的实现逻辑我们发现，在Redis3.0版本中使用的jemalloc在释放内存时，会存在偶发的卡顿情况，会导致短时间内，访问Redis的所有请求全部阻塞，从而导致响应时间升高，这样我们就找到了这个问题的根本原因。
+
+而在云厂商解决了这个问题之后，我们再次压测发现问题不再复现。你看，在这个案例中，我们正是通过全链路的压力测试发现了问题，并且压测也能够帮助我们验证优化方案是否可行。
+
+## 排查问题的方法是怎样的
+
+那么，发现了问题之后，有哪些排查问题的方法呢？
+
+其实问题（尤其是性能问题），比较难排查的原因在于：我们通常看到的是问题的外在表象，比如，接口响应时间长了、系统的SLA下降了、消息队列堆积了等等，而我们想要从表象推理出根本原因就需要分析能力、归纳总结能力以及一些经验的积累了。这就好比你可以从表情和语气推断出女朋友生气了，但要花费很多的精力再加上之前的一些经验总结，才能够推断出女朋友为什么生气。
+
+当然，监控和日志依然是我们排查问题的主要手段，大部分的问题我们都可以通过监控和日志来找到根本原因。比如我在刚刚维护现在的项目时，发现每天凌晨2点的时候，系统的SLA会有一个抖动，于是我追查系统的错误日志，发现那段时间访问Redis会有少量的慢请求，进一步与DBA确认那段时间Redis在做BGSAVE，Redis Server会有短暂时间的阻塞，这就解释了Redis的慢请求以及SLA的下降。
+
+而有些问题需要我们做一些归纳总结，针对性地分析问题发生的一些共性特点。比如，是不是只有某几台服务器存在这个问题，或者出现问题的间隔时间是不是固定的等等。
+
+**我在之前维护一套注册中心的时候，遇到过这么一个问题：** 注册中心总是在每天晚上的时候，出现大量节点被标记为不可用，并且很快又被标记可用的情况，直到过了凌晨0点才会恢复。
+
+拿到这个问题之后，我首先考虑的就是，如何找到问题每次发生的共性特点，于是我查看了注册中心服务标记节点的时间，发现只有一台服务器是在标记节点不可用，并且节点被标记之后，其他的服务器又很快地将它们恢复。我们在[24讲](https://time.geekbang.org/column/article/167151)，讲注册中心时曾经提到，注册中心是通过心跳机制来检测节点是否可用的，注册中心服务会比较上次心跳的时间，以及服务器本地时间，如果两者相差超过一定阈值，就标记服务节点不可用。
+
+于是，我在确认了心跳时间正确的前提下，判断是服务器本地时间的问题。经过进一步排查，我们发现，标记节点不可用的注册中心服务器的系统时间是错误的，而它的系统时钟对时间隔是一天，而其它服务器是一个小时，这也解释了为什么过了凌晨之后就恢复了（时钟重新对时后系统时间就正确了）。于是我们修改了时钟对时的间隔，问题果然就不再出现了。
+
+除了监控和日志以外，一些常见的工具也是问题排查的重要手段，当我们通过监控找不到思路的时候，我们不妨看一看系统的CPU、内存、磁盘和网络等等是否存在错误，饱和度如何，也许可以给我们的问题排查提供一些线索。这就需要你在实际工作中不断地积累，熟悉常见工具的使用方法和场景了。
+
+比如，我们想要查看CPU的负载情况，我们都知道可以使用top命令；而如果你是Java应用，你还可以结合jstack命令来查看CPU使用率比较高的线程正在执行什么操作。但这些并不够，你还可以使用pidstat、vmstat、mpstat来查看CPU的运行队列、阻塞进程数、上下文切换的数量，这些都会给你的问题排查提供线索。同时，Perf也是一个常见的工具，可以帮助你排查哪些系统调用或者操作消耗了更多的CPU时间，这样你就可以有针对性地做调整和优化了。
+
+再比如，我在面试的时候经常会问面试者如何来排查内存泄漏的问题，大部分的Java面试者可以回答使用jmap命令dump出内存信息，然后使用类似MAT的工具来分析。
+
+这种分析方法只对java堆有效，如果是堆外内存的泄漏我们要如何排查呢？也许你可以使用pmap和GDB来查看堆外内存都有哪些数据，这样也可以给我们的排查提供思路。
+
+## 课程小结
+
+以上就是本节课的全部内容了。本节课我带你了解了发现和排查问题的方式和手段，这里你需要了解的几个重点是：
+
+- 监控和压测是发现系统性能问题的两个最重要的手段，尤其我们不能忽略客户端监控，否则我们可能会错过一些问题；
+- 利用监控和日志，总结出问题的共性特点，是我们排查问题的主要手段；
+- 熟悉常见的分析工具会让我们的问题排查过程事半功倍。
+
+问题的排查过程虽然痛苦，但是你每一次的排查经历都是在为你的下一次排查积累经验，同时也能让你更加熟悉工具的使用，慢慢地你就会发现，问题的排查关键在于你是否熟练，“无他，唯手熟尔”。
+
+## 一课一思
+
+在你开发和维护项目的过程中，你都遇到过哪些诡异的问题呢？你又是通过什么样的方法来发现和排查的呢？欢迎在留言区和我一起讨论，或者将你的实战经验分享给更多的人。
+
+最后，感谢你的阅读，我们下期见。

极客时间专栏/geek/高并发系统设计40问/结束语/结束语 | 学不可以已.md

@@ -0,0 +1,51 @@
+<audio id="audio" title="结束语 | 学不可以已" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/df/d5/df0ff46fe9c0ae05e88427645ed27bd5.mp3"></audio>
+
+你好，我是唐扬。
+
+时间一晃而过，四个月的学习已经接近尾声了，在103个日夜里，我们共同学习了45篇高并发系统设计的相关文章，从基础篇，逐渐扩展到演进篇，最终进行了实战分析和讲解。
+
+这段日子里，我们一起沟通交流，很多同学甚至在凌晨还在学习、留言，留言区里经常会看到熟悉的身影，比如@小喵喵，@吃饭饭，@Keith。还有一些同学分享了一些新的知识，比如@蓝魔，是你们的积极和努力鼓励我不断前进，让我明白知识无止境。在写稿之余，我也订阅了几节极客时间的课程，也买了几本相关的书籍，努力为你们交付高质量的内容。这103个日夜虽然辛苦，但也是充满感恩的，在这里，我由衷感谢你的一路相伴！
+
+我知道，有一些同学希望多一些实践的案例分析，我是这样思考的，古人常说“源不深而望流之远，根不固而求木之长，不可”。一些理论基础是必要的，如水之源、树之根，是不能跨越的。另外，一个实践案例不能完全涵盖一个理论，相反一个理论可以支撑很多的实践案例。正所谓授之以鱼不如授之以渔，我们上数学课不也是要先讲公式的来源，再解决实际问题吗？相信对理论知识活学活用后，你在实际工作中，会收获难能可贵的经验财富，也会做出更好的技术方案。
+
+回顾这些年的工作，我想和你分享几点我个人的看法。我刚开始工作时，经常听别人说程序员是有年龄限制的，35岁是程序员的终结年龄，那时说实话我心里是有一些忐忑的，可随着年龄不断增长，我看到越来越多的人在35岁之后还在行业中如鱼得水，我想，35这个数字并非强调个人的年龄，而是泛指一个阶段，强调在那个阶段，我们可能会因为个人的种种原因安于现状，不再更新自己的知识库，这是非常错误的。
+
+**化用《礼记》中的话，首先，我们要博学之。** 你要不断革新知识，所谓的天花板其实更多的是知识性的天花板，活到老学到老才是你在这个行业的必胜法宝，所以，我们应该利用各种优质平台以及零散的时间学习，但是同时你要注意，现在的知识偏向碎片化，如何有条理、系统地学习，将知识梳理成体系，化作自己的内功，是比较关键和困难的。**在这里我给你几点建议：**
+
+1. 基础知识要体系化，读书是一种很好的获取体系化知识的途径，比如研读《算法导论》提升对数据结构和算法的理解，研读《TCP/IP协议详解》深入理解我们最熟悉的TCP/IP协议栈等等；
+1. 多读一些经典项目的源代码，比如Dubbo，Spring等等，从中领会设计思想，你的编码能力会得到极大的提高；
+1. 多利用碎片化的时间读一些公众号的文章，弥补书里没有实践案例的不足，借此提升技术视野。
+
+**其次要慎思之。** 诚然，看书拓展知识的过程中我们需要思考，在实际工作中我们也需要深入思考。没有一个理论可以适应所有的突发状况，高并发系统更是如此。它状况百出，我们最好的应对方法就是在理论的指导下，对每一次的突发状况都进行深入的总结和思考。
+
+**然后是审问之。** 这种问既是“扪心自问”：
+
+- 这次的突发问题的根本原因是什么？
+- 以后如何避免同类问题的再次发生？
+- 解决这个问题最优的思路是什么？
+
+同时，也应该是一种他问，是与团队合作，头脑风暴之后的一种补充，我们说你有一个苹果，我有一个苹果我们相互交换，每个人依然只有一个苹果，但是你有一种思想，我也有一种思想，我们相互交换，每个人就有两种思想，所以不断进行团队交流也是一种好的提升自我的方式。
+
+**接着是明辨之。** 进行了广泛的阅读，积累了大量的工作案例，还要将这些内化于心的知识形成清晰的判断力。某个明星微博的突然沦陷，社区系统的突然挂掉，只是分分钟的事情，要想成为一个优秀的架构师，你必须运用自身的本领进行清晰的判断，快速找到解决方案，只有这样才能把损失控制在最小的范围内。而这种清晰的判断力绝对是因人而异的，你有怎样的知识储备，有怎样的深入思考，就会有怎样清晰的判断力。
+
+**最后要笃行之。** 学了再多的理论，做了再多的思考，也不能确保能够解决所有问题，对于高并发问题，我们还需要在实践中不断提升自己的能力。
+
+相信你经常会看到这样的段子，比如很多人会觉得我们的固定形象就是“带着眼镜，穿着格子衬衫，背着双肩包，去优衣库就是一筐筐买衣服”。调侃归调侃，我们不必认真，也不必对外在过于追求，因为最终影响你职业生涯的，是思考、是内涵、是知识储备。**那么如何让自己更精锐呢？**
+
+我想首先要有梯度。我们总希望任何工作都能有个进度条，我们的职业生涯也应该有一个有梯度的进度条，比如，从职场菜鸟到大神再到财务自由，每一步要用多久的时间，如何才能一步一步上升，当然，未必人人能够如鱼得水，但有梦想总是好的，这样你才有目标，自己的生活才会有奔头。
+
+有了梯度的目标之后，接下来要有速度，就像产品逼迫你一样，你也要逼迫自己，让自己不断地加油，不断地更新、提升、完善，尽快实现自己的职业目标。
+
+具备了这两点，就有了一定的高度，你是站在一个目标高度俯视自己的生涯，是高屋建瓴，而不是盲目攀爬。之后你需要做到的是深度，有的朋友总想横向拓展自己的知识面，想要学习一些新奇的知识，这会提升技术视野，原本是无可厚非的，可如果因为追逐新的技术而放弃深入理解基础知识，那就有些得不偿失了。要知道，像是算法、操作系统、网络等基础知识很重要，只有在这些知识层面上有深入的理解，才能在学习新技术的时候举一反三，加快学习的速度，能够帮助你更快地提升广度。
+
+你还要有热度。我们白天和产品经理“相爱相杀”，晚上披星戴月回家与家人“相爱相杀”，如果没有足够的工作热度，这样的日子循环往复，你怎么可能吃得消？而只有当你在自己的行业里规划了梯度、提升了速度、强化了深度、拓宽了广度，才会有足够的自信度，而当你有了自信，有了话语权，那时你就有了幸福感，自然会保有热度。在热度的烘焙下，你又开始新一轮规划，如此良性循环，你才会在工作上游刃有余，生活也会幸福快乐。
+
+在文章结尾，我为你准备了一份调查问卷，题目不多，希望你能抽出两三分钟填写一下。我非常希望听听你对这个专栏的意见和建议，期待你的反馈！专栏的结束，也是另一种开始，我会将内容进行迭代，比如11月中旬到12月末，我有为期一个月的封闭期，在这期间没有来得及回复的留言，我会花时间处理完；再比如，会针对一些同学的共性问题策划一期答疑或者加餐。
+
+最后，我想再次强调一下为什么要努力提升自己，提升业务能力，**直白一点儿说，那是希望我们都有自主选择的权利，而不是被迫谋生；我有话语权，而不是被迫执行，随着年龄的增加，我越发觉得成就感和尊严，能够带给我们快乐。**
+
+衷心祝愿我们都能够快乐幸福地工作，感谢你的聆听，与你同在。
+
+**点击图片，填写问卷：**
+
+[<img src="https://static001.geekbang.org/resource/image/9b/37/9b9ce297ecfc044db67aaf3a90de0537.jpg" alt="">](https://jinshuju.net/f/KSNLyH)

极客时间专栏/geek/高并发系统设计40问/结束语/结课问卷获奖用户名单.md

@@ -0,0 +1,10 @@
+
+你好！从12月27日更新结束语到今天，我们一共收到了128位同学填写的问卷。在这里，我们由衷感谢各位同学给我们的反馈。这些反馈无比真诚，有的同学指出了我们做得很好的地方，也有的同学指出了我们可以继续优化的地方。
+
+本着“对课程后续优化最有帮助”的原则，我们与老师一起，从中挑选了5位用户，送出“数据结构与算法知识地图（上+下）”或者价值99元的极客时间课程兑换码。中奖名单如下：
+
+<img src="https://static001.geekbang.org/resource/image/9d/af/9d63ac8d81d39ac90e1c020e1cb39daf.jpg" alt="">
+
+由衷感谢这5位同学提出的优化意见，再次恭喜他们！
+
+当然，后续我们还是会和唐扬老师继续迭代以及优化课程内容，唐扬老师也会持续关注你在留言区的留言，所以希望你继续关注本专栏，不断将自己的意见和建议反馈给我们哦！