01 认识redis

## Netflix's Tech Stack
这篇文章是基于许多Netflix工程博客和开源项目的研究。如果你发现任何不准确的地方，请随时告诉我们。




![image.png](/static/img/841b3a9218a2603015bad049ae50044d.image.webp)

* 移动和网页：Netflix采用Swift和Kotlin构建原生移动应用。对于其网页应用，它使用React。

* 前端/服务器通信：Netflix使用GraphQL。

* 后端服务：Netflix依赖ZUUL、Eureka、Spring Boot框架等技术。

* 数据库：Netflix使用EV缓存、Cassandra、CockroachDB等数据库。

* 消息/流媒体：Netflix使用Apache Kafka和Fink进行消息传递和流媒体传输。

* 视频存储：Netflix使用S3和Open Connect进行视频存储。

* 数据处理：Netflix使用Flink和Spark进行数据处理，然后使用Tableau进行可视化。Redshift用于处理结构化数据仓库信息。

* CI/CD：Netflix使用JIRA、Confluence、PagerDuty、Jenkins、Gradle、Chaos Monkey、Spinnaker、Atlas等多种工具进行CI/CD流程。

## Twitter Architecture 2022
Yes, this is the real Twitter architecture. It is posted by Elon Musk and redrawn by us for better readability.


![image.png](/static/img/2bbbb5abd68163f934137c69bf42a4e9.image.webp)


## Evolution of Airbnb’s microservice architecture over the past 15 years
Airbnb’s microservice architecture went through 3 main stages.


![image.png](/static/img/69bacabfcfc90059986aa70555efd186.image.webp)

### 单体（2008 - 2017）

Airbnb最初是一个简单的房东和客人市场。这是在一个Ruby on Rails应用程序中构建的 - 单体。

挑战是什么？

* 混乱的团队所有权 + 无主代码
* 部署缓慢
### 微服务（2017 - 2020）

微服务旨在解决这些挑战。在微服务架构中，关键服务包括：

* 数据获取服务
* 业务逻辑数据服务
* 写入工作流服务
* UI聚合服务
* 每个服务都有一个拥有团队

>挑战是什么？

数百个服务和依赖关系对人类来说难以管理。

### 微 + 宏服务（2020 - 现在）

这就是Airbnb现在正在做的。微服务和宏服务的混合模型专注于API的统一。

## Monorepo vs. Microrepo.

![image.png](/static/img/bfb1bb4e4e635eebc479f370e7d15eb5.image.webp)

Monorepo并不是新概念；Linux和Windows都是使用Monorepo创建的。为了提高可扩展性和构建速度，Google开发了其内部的专用工具链，以更快地扩展它，并制定了严格的编码质量标准以保持一致性。

亚马逊和Netflix是微服务理念的主要倡导者。这种方法自然地将服务代码分离到单独的仓库中。它扩展得更快，但可能会导致后期的治理痛点。

在Monorepo中，每个服务都是一个文件夹，每个文件夹都有一个BUILD配置和OWNERS权限控制。每个服务成员负责自己的文件夹。

另一方面，在Microrepo中，每个服务负责自己的仓库，构建配置和权限通常为整个仓库设置。

在Monorepo中，无论你的业务如何，依赖关系在整个代码库中共享，所以当有版本升级时，每个代码库都会升级他们的版本。

在Microrepo中，依赖关系在每个仓库内控制。企业根据自己的时间表选择何时升级版本。

Monorepo有标准的签入流程。Google的代码审查过程以设定高标准而闻名，确保Monorepo的一致质量标准，无论业务如何。

Microrepo可以设定自己的标准，也可以通过整合最佳实践采用共享标准。它可以更快地为业务扩展，但代码质量可能会有所不同。Google工程师构建了Bazel，Meta构建了Buck。还有其他开源工具可用，包括Nx、Lerna等。

多年来，Microrepo有了更多的支持工具，包括Java的Maven和Gradle，NodeJS的NPM，C/C++的CMake等。


## How will you design the Stack Overflow website?

如果你的答案是本地服务器和单体（在下图底部），你可能会在面试中失败，但这实际上就是它的构建方式！


![image.png](/static/img/b06da7a5d004024d5f4e63baab94829a.image.webp)

人们认为它应该是什么样子

面试官可能期望的是图片顶部的样子。

* 微服务用于将系统分解为小的组件。
* 每个服务都有自己的数据库。大量使用缓存。
* 服务是分片的。
* 服务通过消息队列异步地相互通信。
* 服务使用带有CQRS的事件源实现。
* 展示对分布式系统的知识，如最终一致性、CAP定理等。

>它实际上是什么

Stack Overflow仅用9台本地Web服务器就服务于所有流量，而且它是单体的！它有自己的服务器，不在云上运行。

这与我们当今的所有流行观念相反。



## Why did Amazon Prime Video monitoring move from serverless to monolithic? How can it save 90% cost?

The diagram below shows the architecture comparison before and after the migration.


![image.png](/static/img/bbd8f26a57b7cf8bfc2bfed92882de37.image.webp)

什么是亚马逊Prime Video监控服务？

Prime Video服务需要监控数千个实时流的质量。监控工具会自动实时分析流，并识别质量问题，如块损坏、视频冻结和同步问题。这对客户满意度来说是一个重要的过程。

有三个步骤：媒体转换器、缺陷检测器和实时通知。

> 旧架构有什么问题？

旧架构基于Amazon Lambda，这对于快速构建服务是有好处的。然而，在大规模运行架构时，它并不具有成本效益。两个最昂贵的操作是：

1. 编排工作流 - AWS步骤函数按状态转换向用户收费，而编排每秒执行多次状态转换。

2. 分布式组件之间的数据传递 - 中间数据存储在Amazon S3中，以便下一阶段可以下载。当数据量很大时，下载可能会很昂贵。

> 单体架构节省了90%的成本

单体架构旨在解决成本问题。仍然有3个组件，但媒体转换器和缺陷检测器部署在同一个进程中，节省了通过网络传递数据的成本。令人惊讶的是，这种部署架构变更的方法导致了90%的成本节省！

这是一个有趣且独特的案例研究，因为微服务已经成为科技行业的一种首选和时尚选择。很高兴看到我们正在进行更多关于架构演进的讨论，并进行更多关于其优缺点的诚实讨论。将组件分解为分布式微服务是有成本的。

> 亚马逊领导层对此有何评论？

亚马逊首席技术官Werner Vogels：“构建可演进的软件系统是一种策略，而不是一种宗教。带着开放的心态重新审视你的架构是必须的。”

前亚马逊可持续发展副总裁Adrian Cockcroft：“Prime Video团队遵循了我称之为无服务器优先的路径……我不提倡仅使用无服务器。”

## How does Disney Hotstar capture 5 Billion Emojis during a tournament?


![image.png](/static/img/43e253b2ce0dda44b697bd59f32c8ac2.image.webp)


1. 客户端通过标准HTTP请求发送表情符号。你可以把Golang服务看作是一个典型的Web服务器。选择Golang是因为它很好地支持并发。Golang中的线程很轻量级。

2.  由于写入量非常大，所以使用Kafka（消息队列）作为缓冲区。

3. 表情符号数据由一个名为Spark的流处理服务进行聚合。它每2秒聚合一次数据，这是可配置的。根据间隔需要进行权衡。较短的间隔意味着表情符号更快地传递给其他客户端，但这也意味着需要更多的计算资源。

4. 聚合后的数据被写入另一个Kafka。

5. PubSub消费者从Kafka拉取聚合后的表情符号数据。

6. 表情符号通过PubSub基础设施实时传递给其他客户端。PubSub基础设施很有趣。Hotstar考虑了以下协议：Socketio、NATS、MQTT和gRPC，并最终选择了MQTT。

LinkedIn采用了类似的设计，每秒流式传输一百万个赞。

## How Discord Stores Trillions Of Messages
The diagram below shows the evolution of message storage at Discord:


![image.png](/static/img/503fd43ee5ea93552067bb38380954d4.image.webp)

MongoDB ➡️ Cassandra ➡️ ScyllaDB

2015年，Discord的第一个版本是在单个MongoDB副本之上构建的。大约在2015年11月，MongoDB存储了1亿条消息，RAM无法再容纳数据和索引。延迟变得不可预测。消息存储需要迁移到另一个数据库。选择了Cassandra。

2017年，Discord有12个Cassandra节点，存储了数十亿条消息。

在2022年初，它有177个节点，存储了数万亿条消息。此时，延迟变得不可预测，维护操作变得过于昂贵而无法运行。

问题的原因有几个：

* Cassandra使用LSM树作为内部数据结构。读取比写入更昂贵。在有成百上千用户的服务器上，可能会有许多并发读取，导致热点。
* 维护集群，如压缩SSTables，会影响性能。
* 垃圾收集暂停会导致显著的延迟峰值
ScyllaDB是一个用C++编写的与Cassandra兼容的数据库。Discord重新设计了其架构，拥有一个整体式API，一个用Rust编写的数据服务，以及基于ScyllaDB的存储。

ScyllaDB的p99读取延迟为15ms，而Cassandra为40-125ms。p99写入延迟为5ms，而Cassandra为5-70ms。

## How do video live streamings work on YouTube, TikTok live, or Twitch?

直播与普通流媒体的不同之处在于，视频内容是通过互联网实时发送的，通常只有几秒钟的延迟。

下面的图表解释了幕后发生了什么，使这成为可能。


![image.png](/static/img/ea27a045c0d22255dd99174caa168631.image.webp)

* 第一步：原始视频数据由麦克风和摄像头捕获。数据被发送到服务器端。

* 第二步：视频数据被压缩和编码。例如，压缩算法将背景和其他视频元素分开。压缩后，视频被编码为H.264等标准。经过这一步骤后，视频数据的大小要小得多。

* 第三步：编码后的数据被分割成较小的片段，通常长度为几秒钟，因此下载或流式传输所需的时间要少得多。

* 第四步：分段数据被发送到流媒体服务器。流媒体服务器需要支持不同的设备和网络条件。这被称为“自适应比特率流媒体”。这意味着我们需要在第二步和第三步中生成不同比特率的多个文件。

* 第五步：实时流媒体数据被推送到CDN（内容分发网络）支持的边缘服务器。数百万观众可以从附近的边缘服务器观看视频。CDN显著降低了数据传输延迟。

* 第六步：观众的设备解码和解压缩视频数据，并在视频播放器中播放视频。

* 第七步和第八步：如果需要存储视频以供回放，编码后的数据将被发送到存储服务器，观众稍后可以从中请求回放。

实时流媒体的标准协议包括：

* RTMP（实时消息传输协议）：最初由Macromedia开发，用于在Flash播放器和服务器之间传输数据。现在它被用于通过互联网传输视频数据。请注意，像Skype这样的视频会议应用程序使用RTC（实时通信）协议以降低延迟。
* HLS（HTTP实时流媒体）：它需要H.264或H.265编码。苹果设备只接受HLS格式。
* DASH（动态自适应流媒体）：DASH不支持苹果设备。
* HLS和DASH都支持自适应比特率流媒体。

13 Real World Case Studies

## How does HTTPS work?

超文本传输安全协议（HTTPS）是超文本传输协议（HTTP）的扩展。HTTPS使用传输层安全性（TLS）传输加密数据。如果数据在网上被劫持，所有劫持者得到的只是二进制代码。





![image.png](/static/img/0d6322893641a1f1e737a0f59df855fd.image.webp)

数据是如何加密和解密的？

* 步骤1 - 客户端（浏览器）和服务器建立TCP连接。

* 步骤2 - 客户端向服务器发送“客户端问候”。消息包含一组必要的加密算法（密码套件）和它支持的最新TLS版本。服务器响应“服务器问候”，以便浏览器知道它是否可以支持这些算法和TLS版本。

    
    然后服务器将SSL证书发送给客户端。证书包含公钥、主机名、到期日期等信息。客户端验证证书。

* 步骤3 - 在验证SSL证书后，客户端生成一个会话密钥，并使用公钥对其进行加密。服务器接收加密的会话密钥，并使用私钥对其进行解密。

* 步骤4 - 现在客户端和服务器都持有相同的会话密钥（对称加密），加密数据在一个安全的双向通道中传输。

> 为什么HTTPS在数据传输期间切换到对称加密？有两个主要原因：

安全性：非对称加密只能单向进行。这意味着如果服务器试图将加密的数据发送回客户端，任何人都可以使用公钥解密数据。

服务器资源：非对称加密增加了相当多的数学开销。它不适合长时间会话中的数据传输。


## Oauth 2.0 Explained With Simple Terms.
OAuth 2.0是一个强大且安全的框架，允许不同的应用程序代表用户安全地相互交互，而无需共享敏感凭据。


![image.png](/static/img/4a8efb9bb979789aead7088415bd55d0.image.webp)

参与OAuth的实体是用户、服务器和身份提供商（IDP）。

OAuth令牌能做什么？

当你使用OAuth时，你会得到一个代表你的身份和权限的OAuth令牌。这个令牌可以做几件重要的事情：

* 单点登录（SSO）：有了OAuth令牌，你可以只用一次登录就登录多个服务或应用，让生活更轻松、更安全。

* 跨系统授权：OAuth令牌允许你在各种系统之间共享你的授权或访问权限，所以你不必在每个地方单独登录。

* 访问用户资料：拥有OAuth令牌的应用可以访问你允许的某些部分的用户资料，但它们不会看到所有内容。

请记住，OAuth 2.0的目标是在保持你和你的数据安全的同时，让你的在线体验在不同应用和服务之间无缝且无忧。


## Top 4 Forms of Authentication Mechanisms

![image.png](/static/img/1a6b4b01bf69455cd5f94718c614c0c7.image.webp)

1. SSH密钥：加密密钥用于安全地访问远程系统和服务器

2. OAuth令牌：令牌提供对第三方应用程序上用户数据的有限访问

3. SSL证书：数字证书确保服务器和客户端之间的安全和加密通信

4. 凭据：用户认证信息用于验证和授予对各种系统和服务的访问权限



## Session, cookie, JWT, token, SSO, and OAuth 2.0 - what are they?

这些术语都与用户身份管理有关。当你登录一个网站时，你声明你是谁（识别）。你的身份被验证（认证），并且你被授予必要的权限（授权）。过去已经提出了许多解决方案，而且这个列表还在不断增长。


![image.png](/static/img/6d596ff544a3b2a503d48ba64b45a9d7.image.webp)

从简单到复杂，这是我对于用户身份管理的理解：

* WWW-Authenticate是最基本的方法。浏览器会要求你输入用户名和密码。由于无法控制登录生命周期，现在很少使用。

*  对登录生命周期有更精细的控制是session-cookie。服务器维护会话存储，浏览器保存会话的ID。cookie通常只适用于浏览器，对移动应用不友好。

* 为了解决兼容性问题，可以使用token。客户端将token发送到服务器，服务器验证token。缺点是token需要加密和解密，这可能会很耗时。

* JWT是表示token的标准方式。这些信息可以被验证和信任，因为它经过了数字签名。由于JWT包含签名，因此无需在服务器端保存会话信息。

* 通过使用SSO（单点登录），你只需要登录一次就可以登录多个网站。它使用CAS（中央认证服务）来维护跨站点信息。

* 通过使用OAuth 2.0，你可以授权一个网站访问你在另一个网站上的信息。

## How to store passwords safely in the database and how to validate a password?


![image.png](/static/img/54f38711caee96d32fcdda7220b8c4bf.image.webp)

不应该做的事情

* 将密码以明文形式存储不是一个好主意，因为任何有内部访问权限的人都能看到它们。

* 直接存储密码哈希值是不够的，因为它容易受到预计算攻击，如彩虹表。

* 为了减轻预计算攻击，我们对密码进行加盐处理。

> 什么是盐？

根据OWASP指南，“盐是一个唯一的、随机生成的字符串，作为哈希过程的一部分添加到每个密码中”。

> 如何存储密码和盐？

1. 哈希结果对于每个密码都是唯一的。
2. 密码可以使用以下格式存储在数据库中：hash(password + salt)。
如何验证密码？

要验证密码，可以经过以下过程：

1. 客户端输入密码。
2. 系统从数据库中获取相应的盐。
3. 系统将盐附加到密码并进行哈希处理。让我们称哈希值为H1。
4. 系统将H1与H2进行比较，其中H2是存储在数据库中的哈希值。如果它们相同，则密码有效。

## Explaining JSON Web Token (JWT) to a 10 year old Kid

![image.png](/static/img/1e4dc7af26b8abc63c44225e551f519c.image.webp)

想象一下，你有一个特殊的盒子，叫做JWT。在这个盒子里面，有三个部分：一个头部，一个有效载荷和一个签名。

1. 头部就像盒子外面的标签。它告诉我们盒子的类型以及它的保护方式。它通常以一种叫做JSON的格式编写，这是一种使用大括号{ }和冒号:来组织信息的方式。

2. 有效载荷就像你想要发送的实际消息或信息。它可以是你的名字、年龄或任何你想要分享的其他数据。它也是用JSON格式编写的，所以它很容易理解和使用。现在，签名是让JWT安全的关键。它就像一个特殊的封条，只有发送者知道如何创建。签名是使用一个秘密代码创建的，有点像密码。这个签名确保了没有人可以在发送者不知情的情况下篡改JWT的内容。

3. 当你想要将JWT发送给服务器时，你将头部、有效载荷和签名放入盒子中。然后你将它发送给服务器。服务器可以轻松地读取头部和有效载荷，以了解你是谁以及你想要做什么。

## How does Google Authenticator (or other types of 2-factor authenticators) work?

当启用双因素认证时，Google Authenticator通常用于登录我们的账户。它是如何保证安全的呢？

Google Authenticator是一个基于软件的身份验证器，实现了两步验证服务。下面的图表提供了详细信息。


![image.png](/static/img/44c34751f9ea9c1bd394b6d14f5cdf83.image.webp)

这个过程涉及到两个阶段：

* 阶段1 - 用户启用Google两步验证。
* 阶段2 - 用户使用身份验证器进行登录等操作。
让我们来看看这些阶段。

> 阶段1

* 步骤1和2：Bob打开网页启用两步验证。前端请求一个秘钥。身份验证服务为Bob生成一个秘钥并将其存储在数据库中。

* 步骤3：身份验证服务将一个URI返回给前端。URI由一个密钥发行者、用户名和秘钥组成。URI以二维码的形式显示在网页上。

* 步骤4：Bob然后使用Google身份验证器扫描生成的二维码。秘钥被存储在身份验证器中。

>阶段2 
* 步骤1和2：Bob想要使用Google两步验证登录一个网站。为此，他需要密码。每30秒，Google身份验证器使用TOTP（基于时间的一次性密码）算法生成一个6位数的密码。Bob使用这个密码进入网站。

* 步骤3和4：前端将Bob输入的密码发送给后端进行身份验证。身份验证服务从数据库中读取秘钥，并使用与客户相同的TOTP算法生成一个6位数的密码。

* 步骤5：身份验证服务比较客户端和服务器生成的两个密码，并将比较结果返回给前端。只有当两个密码匹配时，Bob才能继续登录过程。

> 这种身份验证机制安全吗？

* 其他人能否获得秘钥？我们需要确保秘钥是通过HTTPS传输的。身份验证器客户端和数据库存储秘钥，我们需要确保秘钥是加密的。

* 黑客能否猜出6位数的密码？不能。密码有6位数，所以生成的密码有100万种可能的组合。此外，密码每30秒变化一次。如果黑客想在30秒内猜出密码，他们需要每秒输入30,000种组合。

12 Security

## Visualize JSON files
嵌套的JSON文件很难阅读。

JsonCrack从JSON文件生成图形图表，使它们易于阅读。

此外，生成的图表可以下载为图像。



![image.png](/static/img/778ec8c5069fad2033fbbdd08e8e38fc.image.webp)

## Automatically turn code into architecture diagrams

![image.png](/static/img/6612e8105e3b888438e0797d6609f2f1.image.webp)

它是做什么的？

* 用Python代码绘制云系统架构。
* 图表也可以直接在Jupyter Notebooks中渲染。
* 无需设计工具。
* 支持以下提供商：AWS、Azure、GCP、Kubernetes、阿里云、Oracle云等。

[Git Repo](https://github.com/mingrammer/diagrams)


# linux
## Linux file system explained

![image.png](/static/img/78635ae3e41f2d93291de4194dfb6c89.image.webp)

Linux文件系统曾经像一个无序的小镇，每个人都可以在他们喜欢的任何地方建造自己的房子。然而，在1994年，文件系统层次结构标准（FHS）被引入，以给Linux文件系统带来秩序。

通过实施像FHS这样的标准，软件可以确保在各种Linux发行版之间保持一致布局。尽管如此，并非所有Linux发行版都严格遵守这一标准。他们经常加入自己独特的元素或满足特定的要求。要熟练掌握这个标准，你可以从探索开始。使用诸如“cd”用于导航和“ls”用于列出目录内容的命令。将文件系统想象成一棵树，从根（/）开始。随着时间的推移，它将成为你的第二天性，使你成为一个熟练的Linux管理员。

## 18 Most-used Linux Commands You Should Know

Linux命令是与操作系统交互的指令。它们帮助管理文件、目录、系统进程以及系统的许多其他方面。你需要熟悉这些命令，以便高效地导航和维护基于Linux的系统。

下面的图表显示了流行的Linux命令：


![image.png](/static/img/fb8cc4cc50830729e537dbf48f8ed8bd.image.webp)

ls - 列出文件和目录
cd - 更改当前目录
mkdir - 创建新目录
rm - 删除文件或目录
cp - 复制文件或目录
mv - 移动或重命名文件或目录
chmod - 更改文件或目录权限
grep - 在文件中搜索模式
find - 搜索文件和目录
tar - 操作tarball存档文件
vi - 使用文本编辑器编辑文件
cat - 显示文件内容
top - 显示进程和资源使用情况
ps - 显示进程信息
kill - 通过发送信号终止进程
du - 估计文件空间使用情况
ifconfig - 配置网络接口
ping - 测试主机之间的网络连接

11 Developer productivity tools

## A nice cheat sheet of different cloud services (2023 edition)




![image.png](/static/img/a08bcaff6f2a7e993ebc99f304775753.image.webp)


## What is cloud native?
Below is a diagram showing the evolution of architecture and processes since the 1980s.


![image.png](/static/img/0258b78c20140da788a6f12885ed7834.image.webp)

组织可以使用云原生技术在公共云、私有云和混合云上构建和运行可扩展的应用程序。

这意味着应用程序被设计为利用云特性，因此它们能够抵御负载并易于扩展。

云原生包括4个方面：

1. 开发过程：这个过程已经从瀑布式发展到敏捷再到DevOps。

2. 应用程序架构: 架构已经从单体发展到微服务。每个服务都被设计得很小，适应云容器中的有限资源。

3. 部署和打包:  应用程序过去通常部署在物理服务器上。然后在2000年左右，对延迟不敏感的应用程序通常部署在虚拟服务器上。对于云原生应用程序，它们被打包成Docker镜像并部署在容器中。

4. 应用程序基础设施: 应用程序大量部署在云基础设施上，而不是自托管服务器上。

redis特性

Netflix's Tech Stack

How does HTTPS work?

Visualize JSON files

A nice cheat sheet of different cloud services (2023 edition)