## Data is cached everywhere



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

流程中存在多个层次。

1. 客户端应用：HTTP响应可以被浏览器缓存。首次通过HTTP请求数据时，返回的数据带有HTTP头中的过期策略；再次请求数据时，客户端应用会先尝试从浏览器缓存中检索数据。
2. CDN：CDN缓存静态网络资源。客户端可以从附近的CDN节点检索数据。
3. 负载均衡器：负载均衡器也可以缓存资源。
4. 消息基础设施：消息代理首先将消息存储在磁盘上，然后消费者以自己的速度检索它们。根据保留策略，数据在Kafka集群中被缓存一段时间。
5. 服务：服务中存在多层缓存。如果数据未缓存在CPU缓存中，服务将尝试从内存中检索数据。有时服务还有第二级缓存，用于在磁盘上存储数据。
6. 分布式缓存：像Redis这样的分布式缓存在内存中保存多个服务的键值对。它提供比数据库更好的读/写性能。
7. 全文搜索：我们有时需要使用全文搜索，如Elasticsearch进行文档搜索或日志搜索。数据的副本也被索引到搜索引擎中。
8. 数据库：即使在数据库中，我们也有不同级别的缓存：
9. WAL（预写式日志）：在构建B树索引之前，数据首先被写入WAL。
10. 缓冲池：用于缓存查询结果的内存区域。
11. 物化视图：预先计算查询结果，并将其存储在数据库表中，以提高查询性能。
12. 事务日志：记录所有事务和数据库更新。
13. 复制日志：用于记录数据库集群中的复制状态。
## Why is Redis so fast?
There are 3 main reasons as shown in the diagram below.

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

* Redis是基于RAM的数据存储。RAM访问速度至少比随机磁盘访问快1000倍。
* Redis利用IO多路复用和单线程执行循环来提高执行效率。
* Redis利用了几种高效的低层数据结构。
> Question: Another popular in-memory store is Memcached. Do you know the differences between Redis and Memcached?

> You might have noticed the style of this diagram is different from my previous posts. Please let me know which one you prefer.

Redis和Memcached都是流行的内存键值数据存储，但它们有一些区别：

数据类型：Redis支持更复杂的数据类型，如字符串、列表、集合、有序集合、哈希、位图和地理空间索引，而Memcached只支持简单的键值对。

持久性：Redis通过将数据写入磁盘提供持久性，而Memcached没有内置的持久性特性。

数据驱逐策略：Redis允许更复杂的数据驱逐策略，而Memcached使用简单的LRU（最近最少使用）算法进行数据驱逐。

复制：Redis支持主从复制和自动分区，而Memcached没有内置的复制支持。

内置数据操作：Redis内置支持排序、排名和范围查询等操作，而这些功能在Memcached中不可用。
## How can Redis be used?

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

Redis不仅仅是用于缓存。

如图所示，Redis可以在各种场景下使用。

1. 会话：我们可以使用Redis在不同服务之间共享用户会话数据。
2. 缓存：我们可以使用Redis缓存对象或页面，特别是对于热点数据。
3. 分布式锁：我们可以使用Redis字符串在分布式服务之间获取锁。
4. 计数器：我们可以统计文章的点赞次数或阅读次数。
5. 速率限制器：我们可以为特定用户IP应用速率限制器。
6. 全局ID生成器：我们可以使用Redis Int作为全局ID。
7. 购物车：我们可以使用Redis Hash来表示购物车中的键值对。
8. 计算用户留存：我们可以使用Bitmap表示用户每日登录情况并计算用户留存。
9. 消息队列：我们可以使用List作为消息队列。
10. 排名：我们可以使用ZSet对文章进行排序。


## Top caching strategies
Designing large-scale systems usually requires careful consideration of caching. Below are five caching strategies that are frequently utilized.

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

05 Cache

## A nice cheat sheet of different databases in cloud services
云服务中不同数据库的便捷速查表



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

为您的项目选择合适的数据库是一项复杂的任务。许多数据库选项，每个都适合不同的用例，可能会迅速导致决策疲劳。

我们希望这个速查表能为您提供高层次的指导，以确定符合您项目需求的正确服务，并避免潜在的陷阱。

注意：谷歌对其数据库用例的文档有限。尽管我们尽力查看了可用内容并得出了最佳选项，但某些条目可能需要更准确。

## 8 Data Structures That Power Your Databases
数据库索引格式的选择取决于您的具体使用场景。数据可以在内存中或在磁盘上进行索引。同样，数据格式也各不相同，例如数字、字符串、地理坐标等。系统可能是写操作密集型或读操作密集型。所有这些因素都会影响您对数据库索引格式的选择。

![image.png](/static/img/eb83b8cde5e563bc80905c4c8a03e707.image.webp)
以下是一些用于索引数据的最流行的数据结构：

* 跳跃表：一种常见的内存中索引类型。在Redis中使用
* 哈希索引：“映射”数据结构（或“集合”）的一种非常常见的实现
* SSTable：不可变的磁盘上“映射”实现
* LSM树：跳跃表+SSTable。高写入吞吐量
* B树：基于磁盘的解决方案。一致的读写性能
* 倒排索引：用于文档索引。在Lucene中使用
* 后缀树：用于字符串模式搜索
* R树：多维搜索，例如查找最近邻居

## How is an SQL statement executed in the database?
下面这张图展示了这个过程。请注意，不同数据库的架构是不同的，这张图展示了一些常见的设计。

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

第一步 - 通过传输层协议（例如TCP）将SQL语句发送到数据库。

第二步 - SQL语句被发送到命令解析器，在那里它经过语法和语义分析，然后生成查询树。

第三步 - 查询树被发送到优化器。优化器创建执行计划。

第四步 - 执行计划被发送到执行器。执行器从执行中检索数据。

第五步 - 访问方法提供执行所需的数据获取逻辑，从存储引擎检索数据。

第六步 - 访问方法决定SQL语句是否是只读的。如果查询是只读的（SELECT语句），它将被传递给缓冲区管理器进行进一步处理。缓冲区管理器在缓存或数据文件中查找数据。

第七步 - 如果语句是UPDATE或INSERT，它将被传递给事务管理器进行进一步处理。

第八步 - 在事务期间，数据处于锁定模式。这是由锁管理器保证的。它还确保事务的ACID属性。

## CAP theorem
CAP定理是计算机科学中最著名的术语之一，但我敢打赌不同的开发者有不同的理解。让我们来探讨一下它是什么以及为什么它可能会令人困惑。

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

CAP定理指出，一个分布式系统不能同时提供以下三个保证中的两个以上。

* 一致性：一致性意味着所有客户端在任何时间点都能看到相同的数据，无论它们连接到哪个节点。
* 可用性：可用性意味着任何请求数据的客户端都会得到响应，即使某些节点宕机。
* 分区容错性：分区表示两个节点之间的通信中断。分区容错性意味着系统在网络分区的情况下继续运行。

“三选二”的表述可能是有用的，但这种简化可能会产生误导。

1. 选择一个数据库并不容易。仅仅基于CAP定理来证明我们的选择是不够的。例如，公司不会仅仅因为Cassandra是一个AP系统就选择它用于聊天应用。有一系列良好的特性使得Cassandra成为存储聊天消息的理想选择。我们需要更深入地挖掘。

2. “CAP只禁止了设计空间的一小部分：在存在分区的情况下实现完美的可用性和一致性，这种情况很少见。”引自论文：CAP十二年后：规则如何改变。

3. 该定理关注的是100%的可用性和一致性。一个更现实的讨论应该是在没有网络分区的情况下，延迟和一致性之间的权衡。更多细节请参见PACELC定理。

> CAP定理真的有用吗？

我认为它仍然有用，因为它为我们打开了一系列权衡讨论的思路，但它只是故事的一部分。在选择正确的数据库时，我们需要更深入地挖掘。
## Types of Memory and Storage

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

## Visualizing a SQL query

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

SQL语句的执行涉及多个步骤，包括：

1. 解析SQL语句并检查其有效性；
2. 将SQL转换为内部表示形式，如关系代数；
3. 优化内部表示并创建利用索引信息的执行计划；
4. 执行计划并返回结果。

SQL的执行非常复杂，涉及许多考虑因素，例如：

1. 索引和缓存的使用；
2. 表连接的顺序；
3. 并发控制；
4. 事务管理。
## SQL language
在1986年，SQL（结构化查询语言）成为了一个标准。在接下来的40年里，它成为了关系数据库管理系统的主导语言。阅读最新的标准（ANSI SQL 2016）可能会很耗时。我该如何学习它？
![image.png](/static/img/f01faa58f4c165c9d0a8f175e3610db2.image.webp)


SQL语言有5个组成部分：

1. DDL：数据定义语言，如CREATE、ALTER、DROP
2. DQL：数据查询语言，如SELECT
3. DML：数据操作语言，如INSERT、UPDATE、DELETE
4. DCL：数据控制语言，如GRANT、REVOKE
5. TCL：事务控制语言，如COMMIT、ROLLBACK

作为一个后端工程师，你可能需要了解其中的大部分。作为一个数据分析师，你可能需要对DQL有很好的理解。选择与你最相关的主题进行学习。

04 Database

## MVC, MVP, MVVM, MVVM-C, and VIPER
These architecture patterns are among the most commonly used in app development, whether on iOS or Android platforms. Developers have introduced them to overcome the limitations of earlier patterns. So, how do they differ?

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



MVC是最古老的模式，可以追溯到大约50年前。

每个模式都有一个“视图”（V），负责显示内容和接收用户输入。

大多数模式包括一个“模型”（M）来管理业务数据。

“控制器”、“演示者”和“视图模型”是在视图和模型（在VIPER模式中为“实体”）之间起中介作用的翻译器。
## 18 Key Design Patterns Every Developer Should Know

模式是针对常见设计问题的可复用解决方案，能够使开发过程更加顺畅和高效。它们作为构建更好软件结构的蓝图。以下是一些最流行的模式：

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

* 抽象工厂：家族创造者 - 创建相关项目的组。

* 建造者：乐高大师 - 逐步构建对象，保持创建和外观分离。

* 原型：克隆制造者 - 创建完全准备好的示例的副本。

* 单例：唯一的一个 - 一个只有一个实例的特殊类。

* 适配器：通用插头 - 连接具有不同接口的事物。

* 桥接：功能连接器 - 将对象的工作方式与其功能联系起来。

* 组合：树形构建器 - 形成简单和复杂部分的树状结构。

* 装饰器：定制器 - 在不改变其核心的情况下为对象添加功能。

* 外观：一站式商店 - 用一个简化的接口代表整个系统。

* 享元：空间节省者 - 高效共享小的、可重用的项目。

* 代理：替身演员 - 代表另一个对象，控制访问或动作。

* 责任链：请求中继 - 通过对象链传递请求，直到被处理。

* 命令：任务包装器 - 将请求转化为一个准备行动的对象。

* 迭代器：集合探索者 - 一次访问集合中的一个元素。

* 中介者：通信中心 - 简化不同类之间的交互。

* 备忘录：时间胶囊 - 捕获并恢复对象的状态。

* 观察者：新闻广播员 - 通知类关于其他对象的变化。

* 访问者：熟练的客人 - 在不改变类的情况下为其添加新的操作。

03 Architecture patterns

[参考链接](https://github.com/ByteByteGoHq/system-design-101?tab=readme-ov-file#cicd)
## CI/CD Pipeline Explained in Simple Terms


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



> 第1节 - 使用CI/CD的软件开发生命周期（SDLC）

软件开发生命周期（SDLC）包括几个关键阶段：开发、测试、部署和维护。CI/CD自动化并整合这些阶段，以实现更快、更可靠的发布。

当代码被推送到git仓库时，它会触发一个自动化的构建和测试过程。运行端到端（e2e）测试用例来验证代码。如果测试通过，代码可以自动部署到预生产/生产环境。如果发现问题，代码会被送回开发环节进行修复。这种自动化为开发者提供了快速反馈，并降低了生产环境中出现bug的风险。

> 第2节 - CI和CD的区别

持续集成（CI）自动化了构建、测试和合并过程。每当代码提交时，它都会运行测试以尽早发现集成问题。这鼓励频繁提交代码和快速反馈。

持续交付（CD）自动化了发布过程，如基础设施变更和部署。它确保软件可以通过自动化工作流在任何时间可靠地发布。CD还可以自动化在生产部署之前所需的手动测试和批准步骤。

> 第3节 - CI/CD管道

典型的CI/CD管道有几个连接的阶段：

* 开发人员将代码更改提交到源代码控制
* CI服务器检测到更改并触发构建
* 代码被编译和测试（单元测试、集成测试）
* 测试结果报告给开发人员
* 成功后，构件被部署到预生产环境
* 在发布之前，可能在预生产环境中进行进一步测试
* CD系统将批准的更改部署到生产环境

## Netflix Tech Stack (CI/CD Pipeline)

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

* 规划：Netflix工程团队使用JIRA进行规划，使用Confluence进行文档记录。

* 编码：Java是后端服务的主要编程语言，而其他语言则用于不同的用例。

* 构建：主要使用Gradle进行构建，并构建了Gradle插件以支持各种用例。

* 打包：将包和依赖项打包成Amazon机器映像（AMI）以供发布。

* 测试：测试强调生产文化对构建混沌工具的关注。

* 部署：Netflix使用其自建的Spinnaker进行金丝雀发布部署。

* 监控：监控指标集中在Atlas中，Kayenta用于检测异常。

* 事件报告：根据优先级分派事件，使用PagerDuty进行事件处理。