消息队列高手课
对于 Kafka 来说，它的灵魂是这篇博文：The Log: What every software engineer should know about real-time data’s unifying abstraction ，对应的中文译稿在这里：《日志：每个软件工程师都应该知道的有关实时数据的统一抽象》 。
需要注意的是，你在读源码的时候，千万不要上来就找 main 方法这样泛泛地去看，程序的源代码是一个网状结构，关系错综复杂，所以这种结构是非常不适合人类去阅读的。你如果是泛泛去读源代码，很容易迷失在这个代码织成的网里面。
我推荐大家阅读源码的方式是，带着问题去读源码，最好是带着问题的答案去读源码。
一般开源项目需要增加一个新的功能或者特性的时候，都会创建一个 Improvement Proposal，一般标题都是"xIP- 新功能名称"，其中 IP 就是 Improvement Proposal 的缩写，x 一般就是这个开源项目的名称的首字母，比如 Kafka 中 Improvement Proposal 的标题就都是以 KIP 来开头。
如果你想了解一个开源项目，学习它的代码，最佳的切入点就是去读它的官方文档，这些文档里面，最重要的灵魂就是项目背后的那篇论文，它一般是这个开源项目的理论基础。
在阅读源码的时候呢，最佳的方式是带着问题去阅读，最好是带着问题的答案去读，这样难度低、周期短、收获快。不要想着一定要从总体上去全面掌握一个项目的所有源代码，也没有必要。
后端技术面试 38 讲
所谓软件建模，就是为要开发的软件建造模型（模型是对客观存在的抽象）。
- 地图，就是对地理空间的建模
- 图纸，机械装置的图纸、电子电路的图纸、建筑设计的图纸，也是对物理实体的建模
- 软件也可以通过各种图进行建模
通过建模，我们可以把握事物的本质规律和主要特征，正确建造模型和使用模型，以防在各种细节中迷失方向。
在软件开发中，有两个客观存在
- 一个是我们要解决的领域问题
- 另一个客观存在就是最终开发出来的软件系统
这两个方面客观存在的抽象，就是我们的软件模型
- 一方面我们要对领域问题和软件系统进行分析、设计、抽象
- 另一方面，我们根据抽象出来的模型开发，实现出最终的软件系统
软件建模比较知名的是 4+1 视图模型，准确地说，4+1 模型不是一种软件建模工具和方法，而是一种软件建模方法的方法，即建模方法论。
- 逻辑视图：描述软件的功能逻辑，由哪些模块组成，模块中包含哪些类，其依赖关系如何。
- 开发视图：包括系统架构层面的层次划分，包的管理，依赖的系统与第三方的程序包。开发视图某些方面和逻辑视图有一定重复性，不同视角看到的可能是同一个东西，开发视图中一个程序包，可能正好对应逻辑视图中的一个功能模块。
- 过程视图：描述程序运行期的进程、线程、对象实例，以及与此相关的并发、同步、通信等问题。
- 物理视图：描述软件如何安装并部署到物理的服务上，以及不同的服务器之间如何关联、通信。
- 场景视图：针对具体的用例场景，将上述 4 个视图关联起来，一方面从业务角度描述，功能流程如何完成，一方面从软件角度描述，相关组成部分如何互相依赖、调用。
4+1 视图模型也是通过多个角度描述软件系统的某个方面的抽象模型，最终组合起来构成一个软件完整的模型。
4+1 视图模型是一种方法论的原因，就在于这 5 种视图模型主要指导我们应该从哪些方面去对我们的业务和软件建模。
我们为什么睡觉
不同生物睡眠的区别：
- 总睡眠时间
- 睡眠的组成
- 睡觉的方式
当一个主题在进化史上无近缘故关系的独立分支中发生重复时，常常暗示着那是一个基本的需求。
如睡眠、视觉
酒精是我们目前所知的快速眼动睡眠强有力的抑制剂之一。
母亲喝下的酒会轻易地穿过胎盘屏障，因此会轻易进入正在发育的胎儿体内。
重度饮酒的母亲所生的新生儿，与孕期不喝酒的母亲所生的同龄婴儿相比，快速眼动睡眠活跃状态的持续时间要少得多。
酒精很容易进入母乳中，母乳中的酒精浓度与母亲血液中的浓度非常接近。
高并发架构实战课
正所谓：听过很多道理，依然过不好这一生。说到底，还是因为缺乏实践。
写东西可以帮助人更好地思考。技术人员如果不写设计文档，就会缺少对技术更深刻的思考，对技术方案的优点和缺点就缺乏系统的认识，也就不知道如何找到更好的技术和更合理的方案。
没有设计文档就没有设计，没有设计就没有技术的进步。
我们常说高并发、高性能、高可用，事实上，这三者并不是平行的关系。通常情况下，高并发是根源和核心。正是因为高并发，大量的用户同时请求我们的系统，导致系统资源快速消耗，服务器无法及时处理用户请求，响应变慢，系统出现性能问题。更进一步，性能继续恶化，导致服务器资源耗尽，就会出现系统崩溃，可用性也出现问题。