2022-02-10_星期四

我们为什么睡觉

两大主要因素决定了你什么时候想睡觉,什么时候想醒来。

  1. 大脑深处的 24 小时生物钟发射出的信号。
  2. 一种在你的大脑中积聚的化学物质(腺苷),会制造出“睡眠压力”

阳光就像转动时不准确的手表侧面的食指和大拇指,有条不紊地每天重置我们不准确的内部时钟,将其“调”回精确的24小时,而不是大约的24小时。

日光是我们所处环境中最可靠的重复性信号。

咖啡因的摄入代表了有史以来针对人类进行的历史最久、规模最大的无监管药物研究之一,也许只有酒精能与之匹敌,而且现在仍是如此。

“半衰期”指集体代谢掉药物浓度的 50%所消耗的时间。咖啡因平均半衰期为 5~7 小时。

年龄越大,大脑和身体消除咖啡因需要的时间也越长,因此随着年龄增长,咖啡因对睡眠的干扰也会变得越明显。

Pasted image 20220210114248.png

双相睡眠模式是一种一段较长时间的连续睡眠加上较短的午后小睡。

在我们的睡眠时间中,有 20%~25%的时间是快速眼动睡眠,而其他所有灵长类动物的快速眼动睡眠平均只有 9%。

进化让我们古老的睡眠形式在持续时间上变短了,但强度增加了,特别是通过丰富我们在夜间进入的快速眼动睡眠。

从树档到地面的睡眠重构是一个重要的触发点,它使智人到达了进化的金字塔顶端。

快速眼动睡眠可以精确地重新调整和校准人类大脑的情感回路。

快速眼动睡眠所赋予的准确识别和理解的能力,使我们能够做出更明智的决定和行动。

非快速眼动睡眠会帮助将新信息安全地转移到大脑的长期储存处。但快速眼动睡眠才会让这些刚刚产生的记忆开始与你生命中全部的自传内容发生碰撞。

快速服动睡眼甚至可以站远一点,感知总体的洞见和本质:类似于一般的常识——即一组信息的整体含义,而不仅是死板的事件清单。我们可以在第二天早晨醒来,用新的方法解决以前棘手的问题,甚至注入全新的、原创的想法。

国家睡眠基金会和疾病控制与预防中心向所有成年人推荐的睡眠机会是:躺在床上 7-9 个小时

少数的迫使各种动物睡眠量少于正常量的通用方法之一,是限制食物,施加一定程度的饥饿。当食物变得稀少时,睡眠也就变得稀少,因为动物会试图保持更长的清醒来觅食。

饥饿感会影响睡

不论是现代生活还是尚未工业化生活中的人类,需要少于 7 个小时的睡眠似乎只是一种得意的自负,以及小报中的流言。

疾病,特别是激发强大免疫反应的疾病会激发更多的睡眠。

由此造成的错觉是,睡眠过多导致过早死亡。但更为可信的结论是,尽管有益的睡眠延长做出了所有与之对抗的努力,但病情依然太重了。尚未发现任何生物机制显示睡眠有什么坏处

后端技术面试 38 讲

RAID 的核心思路其实是利用文件系统将数据写入硬盘中不同数据块的特性,将多块硬盘上的空闲空间看做一个整体,进行数据写入,也就是说,一个文件的多个数据块可能写入多个硬盘。

根据硬盘组织和使用方式不同,常用 RAID 有五种

  • RAID 0
  • RAID 1
  • RAID 10
  • RAID 5
  • RAID 6

Pasted image 20220210145052.png

Hadoop 分布式文件系统 HDFS 为例,看下分布式文件系统的具体架构设计 Pasted image 20220210150100.png

消息队列高手课

一个严格意义的事务实现,应该具有 4 个属性:原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 特性。

  • 原子性,是指一个事务操作不可分割,要么成功,要么失败,不能有一半成功一半失败的情况。
  • 一致性,是指这些数据在事务执行完成这个时间点之前,读到的一定是更新前的数据,之后读到的一定是更新后的数据,不应该存在一个时刻,让用户读到更新过程中的数据。
  • 隔离性,是指一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对正在进行的其他事务是隔离的,并发执行的各个事务之间不能互相干扰,这个有点儿像我们打网游中的副本,我们在副本中打的怪和掉的装备,与其他副本没有任何关联也不会互相影响。
  • 持久性,是指一个事务一旦完成提交,后续的其他操作和故障都不会对事务的结果产生任何影响。

用消息队列来实现分布式事务:

Pasted image 20220210153742.png 半消息和普通消息的唯一区别是,在事务提交之前,对于消费者来说,这个消息是不可见的。

如果在第四步提交事务消息时失败了怎么办?对于这个问题,Kafka 和 RocketMQ 给出了 2 种不同的解决方案。

  • Kafka 的解决方案比较简单粗暴,直接抛出异常,让用户自行处理。我们可以在业务代码中反复重试提交,直到提交成功,或者删除之前创建的订单进行补偿。
  • 在 RocketMQ 中的事务实现中,增加了事务反查的机制来解决事务消息提交失败的问题。如果 Producer 也就是订单系统,在提交或者回滚事务消息时发生网络异常,RocketMQ 的 Broker 没有收到提交或者回滚的请求,Broker 会定期去 Producer 上反查这个事务对应的本地事务的状态,然后根据反查结果决定提交或者回滚这个事务。
    • 业务代码需要实现一个反查本地事务状态的接口,告知 RocketMQ 本地事务是成功还是失败。

使用 RocketMQ 事务消息功能实现分布式事务的流程如下图: Pasted image 20220210153907.png

updatedupdated2022-03-092022-03-09