系统设计 system design 干货笔记

参考大佬的博客 https://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache

参考的github https://github.com/donnemartin/system-design-primer#step-2-review-the-scalability-article

scalability

1 Clone
每台服务器都包含完全相同的代码库，并且不会在本地磁盘或内存上存储任何与用户相关的数据，例如会话或个人资料图片。
会话需要存储在所有应用程序服务器都可以访问的集中式数据存储中。它可以是外部数据库或外部持久缓存，例如 Redis。

2 Database
MongoDB 或 CouchDB。现在需要在您的应用程序代码中完成连接。越早执行此步骤，将来需要更改的代码就越少。但是，即使您成功切换到最新最好的 NoSQL 数据库并让您的应用程序执行数据集连接，很快您的数据库请求将再次变得越来越慢。您将需要引入缓存。

3 Cache
对于“缓存”，我总是指内存中的缓存，例如Memcached或Redis。请永远不要做基于文件的缓存，会让服务器的克隆和自动缩放很痛苦。
缓存是一个简单的键值存储，它应该作为应用程序和数据存储之间的缓冲层。每当您的应用程序必须读取数据时，它首先应该尝试从缓存中检索数据。只有当它不在缓存中时，它才应该尝试从主数据源获取数据。你为什么要这样做？因为缓存快如闪电. 它将每个数据集保存在 RAM 中，并在技术上尽可能快地处理请求。例如，当 Redis 托管在标准服务器上时，每秒可以执行数十万次读取操作。写入，尤其是增量，也非常非常快。

4 Asynchronism
异步 就是进程不要一个接一个完成 而是一起自己管自己进行。RabbitMQ ActiveMQ，简单的Redis 都可以完成。
用消息队列来避免 A反复去询问 b是否已经完成。

Tradeoff

一些常见的 tradeoff， 系统设计中其实就是在寻找一种平衡。
Performance vs scalability:
Performance is about the resources used to service a single request. Scalability is about how resource consumption grows when you have to service more (or larger) requests.
单次性能可接受的范围内 处理大量request

Latency vs throughput:
aim for maximal throughput with acceptable latency. 可接受的延迟产生最多的输出。

Availability vs consistency
CAP定理：

• Consistency
• Availability
• Partition tolerance
  这三个指标不可能同时做到。这个结论就叫做 CAP 定理。
  看下三个东西的定义：
  Consistency - Every read receives the most recent write or an error 每次读都能读到最近的一次写结果
  Availability - Every request receives a response, without guarantee that it contains the most recent version of the information 每次请求都能有相应，不用保证得到什么，但要“有求必应“
  Partition Tolerance - The system continues to operate despite arbitrary partitioning due to network failures 当有通讯失败时 系统仍然可以运行