消息队列高手课
在设计传输协议的时候，需要解决如何断句的问题，常见方法：
- 分隔符，如：HTTP1
- 前置长度，如：
03 下雨天 03 留客天 02 天留 03 我不留- 给每句话前面加一个表示这句话长度的数字，收到数据的时候，我们按照长度来读取就可以了
所谓的单工通信就是，任何一个时刻，数据只能单向传输，一个人说的时候，另外一个人只能听。
后端技术面试 38 讲
框架的一个特点是，当开发者使用框架开发一个应用程序时，无需在程序中调用框架的代码，就可以使用框架的功能特性。
依赖倒置原则：
- 高层模块不应该依赖低层模块，二者都应该依赖抽象
- 抽象不应该依赖具体实现，具体实现应该依赖抽象
依赖倒置原则通俗说就是，高层模块不依赖低层模块，而是都依赖抽象接口，这个抽象接口通常是由高层模块定义，低层模块实现。
依赖倒置原则中，除了具体实现要依赖抽象，最重要的是，抽象是属于谁的抽象。
- Web 开发中，Service 层依赖 DAO 层提供的抽象接口：这种并不是依赖倒置原则。
- 对于 Service 和 DAO 这个例子来说，就是 Service 定义接口，DAO 实现接口，这样才符合依赖倒置原则。
依赖导致原则示例
不符合
这样设计的问题在于：
- Button 依赖 Lamp，那么对 Lamp 的任何改动，都可能会使 Button 受到牵连，做出联动的改变
- 我们也无法重用 Button 类，比如，我们期望通过 Button 控制一个电机的启动或者停止，这种设计显然难以重用 Button，因为我们的 Button 还依赖着 Lamp 呢
符合
- 由 Button 定义一个抽象接口 ButtonServer；
- 在 ButtonServer 中描述抽象：打开、关闭目标对象。
- 由具体的目标对象，比如 Lamp 实现这个接口，从而完成 Button 控制 Lamp 这一功能需求。
依赖倒置原则也被称为好莱坞原则：Don’t call me，I will call you. 即不要来调用我，我会调用你。
遵循依赖倒置原则有这样几个编码守则：
- 应用代码中多使用抽象接口，尽量避免使用那些多变的具体实现类。
- 不要继承具体类，如果一个类在设计之初不是抽象类，那么尽量不要去继承它。对具体类的继承是一种强依赖关系，维护的时候难以改变。
- 不要重写（override）包含具体实现的函数。
高并发架构实战课
用户请求生成短 RUL 的过程：
对于用户通过客户端请求访问短 URL 的过程：
HTTP 重定向响应码有 301 和 302 两种
- 301 表示永久重定向，即浏览器一旦访问过该短 URL，就将重定向的原始长 URL 缓存在本地，此后不再请求短 URL 生成器，直接根据缓存在浏览器（HTTP 客户端）的长 URL 路径进行访问
- 302 表示临时重定向，每次访问短 URL 都需要访问短 URL 生成器
使用 301 状态码可以降低 Fuxi 服务器的负载压力，但无法统计短 URL 的使用情况
断舍离
放手一个无用之物，就腾出一点空间。处理一件多余之物，就减少一份负担。减少一次浪费，就恢复一分精气神。然后，翻开人生新篇章。
随着人们消费水平和购买力的提高，很多时候大家买一样东西，并不是真的需要它、会去使用它，而是渴望拥有和获得。
我们总是喜欢囤货、无法舍弃的主要原因有一下三点：
- 消费型社会里洪水般的物量
- 对居住空间的考量不足
- 上个时代的价值观
消费社会总是挖苦心思地对我们的心理需求“挖地三尺”，直到挑起我们的“对实际不需要的产品的购买欲”，让我们觉得好像就是自己本来特别想买的一样。
当我们面对“物质”时，不是从“这个东西需不需要”的角度，而是往往下意识地从“这个东西能不能用”的角度——以物质资料为基准轴的观点来进行取舍和判断。这就是 “物质轴”思维。这种思维方式就导致：如果这个东西还能用（或者即使不能用），我们就在“暂且”“好不容易”的心理暗示下，把这个东西留在身边。
人们总是习惯思考“有效性”，却往往忽略了作为“有效性”前提的“必要性”。
假如杂物遍地，家里塞得满满当当，那这些杂物给人的压迫感，以及狭窄的空间带来的阻塞感会逐渐让生活在这里的人思维迟钝，行动迟缓。长期以往，人们逐渐变得封闭，不想外出，进而演变成似愤懑抑郁的状态。