发布订阅(pub/sub)是一种消息通信模式，本质是实现队列（先进先出）的远程操作功能。

使用 redis 实现发布订阅有 3 种方式：

1. 使用列表（list）数据结构，通过 lpush、rpop（brpop）实现队列先进先出
2. 使用 redis 发布/订阅功能
3. 使用 redis 5.0 stream 数据结构（功能）

结论：虽然 redis 可以作为消息队列，但是严谨的生产环境还是应该选择专业的 MQ，因为可靠性是软件的基石。

redis 有三种缓存淘汰策略，分别是 noeviction、volatile、allkeys。

noeviction

noeviction 策略是 Redis 默认的淘汰策略。 它可以继续接受请求，但只执行读请求，不执行写请求， 这样做可以保证内存中的数据不会被修改和删除。

volatile

volatile 只淘汰设置了过期时间的 key。有三种算法实现:

1. volatile-lru:根据 lru 算法淘汰设置了过期时间的 key，lru 算法优先删除最近最少使用的 key。
2. volatile-ttl:根据 key 的过期时间的长短 淘汰设置了过期时间的 key，过期时间越小的 key 优先被删除。
3. volatile-random:随机淘汰设置了过期时间的 key。

allkeys

allkeys 对所有 key 无差别淘汰。有两种算法实现:

1. allkeys-lru: 根据 lru 算法淘汰所有的 key，最近最少使用的 key 优先被删除。
2. allkeys-random:随机淘汰所有的 key。

你是否也有一些疑问：

无论前后端，大家在提到性能时总爱用 QPS，这样表达性能合理吗？

QPS 与 TPS，它们的区别是什么？

是什么

• QPS
  • Query Per Second 每秒查询数量，最初是用在表示数据执行每秒执行的 SQL 数，表示数据的查询能力，现在已经是一个通用名词了
• TPS
  • Transactions Per Second 每秒事务数。事务大家很熟悉，就是一组操作要么完成要么失败，TPS 就是表示这种事务单元的处理能力。
  • 它的意义在于表达完成某件事的能力
    • 后端角度，通常表示业务接口的性能。比如创建工单接口，该接口是写接口，读写 db，并且在创建完毕后给负责任发消息，这是一组操作集合，它的 TPS 代表了系统创建工单的能力上限。
    • 前端角度，一批接口的性能，往往代表系统用户承载量。
• 吞吐量/吞吐率
  • 系统的吞吐量（承压能力）与 request 对 CPU 的消耗、外部接口、IO 等等紧密关联。单个 request 对 CPU 消耗越高，外部系统接口、IO 速度越慢，系统吞吐能力越低，反之越高。
  • 经常用 QPS、TPS 表示

协程本质上和线程是一类概念，本质上是编程过程中对并发计算任务的一种抽象，只不过协程在调度层面上更轻量。

线程的调度由于是操作系统实施的，有时间片/中断等较为复杂的机制，因此调度点对用户是透明的，可以认为调度理论上可以在任何地方触发。而协程的调度点往往是用户代码显式通过触发的（发生在用户态），需要用户代码自己相互“协作”来完成任务的调度和执行，这也是协程中”协“的来源。

Rebalance 是指，将一个 Topic 下的多个队列，在同一个消费组的多个成员之间进行重新分配。

比如，一个 Topic 下 8 个队列，只有一个消费者时，一个消费者将处理 8 个队列的消息。如果在组内增加一个消费者，在不重启服务的情况，将 8 个队列分配给两个消费者，从而支持动态的并行处理消息。

上周末和朋友一起去了乌兰察布，广袤的草原和火山，整个景色给人的感觉很空旷，让人很放松，工作久了出来转一转还不错。我们游玩的顺序是：乌兰哈达的 5 号火山 -> 2 号火山 -> Day2 -> 黄花谷，整个旅程中除了在路上花费了一些时间外，体验还是不错的。

在下面还有一些拍的视频。

当我们说一个组织是一个具有适应性的复杂系统时，我们指的是：

• 它包含许多相互依赖的部分（比如人员、技术、流程、文化等）。
• 各个部分可以自行改变自己的行为，并适应系统的变化。

宇宙中充满了这类的系统，而且关于复杂性的研究已成为一门成熟的科学学科。 就连你自己也是一个具有适应性的复杂系统。你可能认为自己是一个单元（即一个自我），但是“自我”只是一种抽象。实际上，你是有机细胞的集合，尽管这个细胞集合拥有许多惊人的能力：思考、移动、感知，并作为一个全新的整体对外部做出反应。从细胞的角度来说，你的每个细胞都有专门的作用，细胞会进行新陈代谢，细胞群通过协同工作对你的身体产生巨大的影响。你体内生物系统的复杂性使得你的身体具有高度的弹性和适应性。虽然你不能长生不老，但由于体内复杂的生物系统，你仍然可以承受巨大的环境变化，甚至是人身伤害。

有时候批量处理任务无法观察执行情况，例如处理进度、处理数量、耗时等，这种“不确定性”会隐藏 bug，等到出问题就晚了。今天，这篇文章的“主角” —— 进度条工具 —— 就是为了解决这个问题。

进度条工具输出预览：

 1[4B645A43] 远程请求记录: [####                ] - 22.91% (9835/42920), 耗时: 2m32s
 2   (1)        (2)               (3)               (4)       (5)          (6)
 3
 4各部分说明：
 5
 6(1) Trace ID
 7(2) 进度条名称
 8(3) 进度条面板
 9(4) 执行占比
10(5) 执行数量细节
11(6) 执行耗时

视频，阅读全文查看。

《Software Engineering at Google》。

这本书从三个角度说明了软件工程是什么，分别是：时间、规模、权衡。时间应该是软件工程中最大的变量，随着时间推移新需求会出现，框架和库会升级打补丁，而原先的产品设计、服务端的算法、机器资源可能已经不再适合，这些变化需要维护，如何应对解决这些问题呢？当产品及业务扩大时，对应资源开销也会逐渐增大，资源包括人力和硬件资源（内存、CPU、存储、带宽），当这些规模不断增大如何保障相应的效率、成本？当面临这些问题时，往往不止一个方案，没有银弹，我们需要权衡利弊然后再再行动。在软件开发中会遇到许多诸如以上的问题，从这个角度可以窥探软件工程一些细节。