31 篇博文 含有标签「system design」

动机​

如何在规模上保持用户的观看数据（每天数十亿事件）？

在这里，观看数据指的是...

1. 观看历史。我看过哪些标题？
2. 观看进度。我在某个标题中停留在哪里？
3. 正在观看的内容。我的账户现在还在观看什么？

架构​

观看服务有两个层次：

1. 有状态层 = 活动视图存储在内存中

   • 为什么？为了支持最高的读/写量
   • 如何扩展？
     • 按照 account_id mod N 分区为 N 个有状态节点
       • 一个问题是负载分布不均，因此系统容易出现热点
     • 在 CAP 定理 下选择 CP 而非 AP，并且没有活动状态的副本。
       • 一个失败的节点将影响 1/n 的成员。因此，他们使用过时的数据以优雅地降级。

2. 无状态层 = 数据持久性 = Cassandra + Memcached

   • 使用 Cassandra 进行非常高的写入量和低延迟。
     • 数据均匀分布。由于使用虚拟节点进行一致性哈希来分区数据，因此没有热点。
   • 使用 Memcached 进行非常高的读取量和低延迟。
     • 如何更新缓存？
       • 在写入 Cassandra 后，将更新的数据写回 Memcached
       • 最终一致性，以处理多个写入者，具有短的缓存条目 TTL 和定期的缓存刷新。
     • 将来，优先考虑 Redis 的追加操作到时间排序列表，而不是 Memcached 中的“读-修改-写”。

为什么API会不可靠？

1. 网络会出错
2. 服务器会出错

怎么解决这个问题呢？三个原则

1. 客户端用“重试”来保证状态的一致性

2. 重试的请求里要有==幂等的唯一性ID==

   1. 在 RESTful API 设计里面，PUT 和 DELETE 的语义本身是幂等的
   2. 但是 POST 在在线支付领域可能会导致==“重复付两次钱”的问题==，所以我们用“幂等的唯一性ID”来识别某个请求是否被发了多次
      1. 如果错误发生在到达服务器之前，重试过后，服务器第一次见到它，正常处理
      2. 如果错误发生在服务器，基于这个“唯一性ID”，用 ACID 的数据库保证这个事务只发生一次
      3. 如果错误发生在服务器返回结果之后，重试过后，服务器只需要返回缓存过的成功的结果

3. 重试要负责任，比如遵循==指数退避算法==，因为不希望一大波客户端同时重试。

举个例子，Stripe 的客户端是这样计算重试的等待时间的：

def self.sleep_time(retry_count)
  # Apply exponential backoff with initial_network_retry_delay on the
  # number of attempts so far as inputs. Do not allow the number to exceed
  # max_network_retry_delay.
  sleep_seconds = [Stripe.initial_network_retry_delay * (2 ** (retry_count - 1)), Stripe.max_network_retry_delay].min

  # Apply some jitter by randomizing the value in the range of (sleep_seconds
  # / 2) to (sleep_seconds).
  sleep_seconds = sleep_seconds * (0.5 * (1 + rand()))

  # But never sleep less than the base sleep seconds.
  sleep_seconds = [Stripe.initial_network_retry_delay, sleep_seconds].max

  sleep_seconds
end

==一个字：拆==

==AKF扩展立方==告诉了我们"拆"的三个纬度：

1. ==水平扩展== 把很多无状态的服务器放在负载均衡器或者反向代理的后面，这样每个请求都能被其中任意一个服务器受理，就不会有单点故障了。
2. ==业务拆分== 典型的按照功能分的微服务，比如 auth service, user profile service, photo service, etc
3. ==数据分割== 分割出整套技术栈和数据存储专门给特定的一大组用户，比如优步有中国和美国的数据中心，每个数据中心内部有不同的 Pod 给不同的城市或地区。

KV Cache的本质是为了减少访问数据的延迟。比如，把存在又贵又慢的媒体上的数据库的O(logN)的读写和复杂的查询，变成存在又快又贵的媒体上的 O(1)的读写。cache 的设计有很多策略，常见的有 read-through/write-through(or write-back) 和 cache aside.

常见的互联网服务读写比是 100:1 到 1000:1，我们常常对读做优化。

在分布式系统中，这些 pattern 的组合都是 consistency, availability, partition tolerance 之间的 trade-off，要根据你的业务需求具体 选择。

一般的策略​

• 读
  • Read-through: clients 和 databases 之间加一层 cache layer，clients 不直接访问数据库，clients 通过 cache 间接访问数据库。 读的时候 cache 里面没有东西则从database更新再返回，有则直接返回。
• 写
  • Write-through: clients 先写数据到 cache，cache 更新 database，只有 database 最终更新了，操作才算完成。
  • write-behind/Write-back: clients 先写数据到 cache，先返回。回头将 cache 异步更新到 database. 一般来讲 write-back 是最快的
  • Write-around: client 写的时候绕过 cache 直接写数据库。

cache aside pattern​

Cache 不支持 read-through 和 write-through/write-behind 的时候用 Cache aside pattern

读数据? 命中 cache 读 cache，没命中 cache 读 database 存 cache 改数据? 先改 database，后删除 cache entry

为什么不是写完数据库后更新缓存？主要是怕两个并发的 database 写操作导致两个并发的 cache 更新导致脏数据。

是不是Cache Aside这个就不会有并发问题了？还是有很低的概率有可能发生脏数据，就是一边读 database 并更新 cache 的时候，一边更新 database 并删除 cache entry

缓存放在哪？​

• client side,
• distinct layer
• server side

缓存大小不够用的话怎么办？缓存回收策略(cache replacement policies)​

• LRU - least-recently used 看时间，只保留最近时间使用的，回收最近时间没使用的
• LFU - least-frequently used 看次数，只保留使用次数最多的，回收使用次数最少的
• ARC 性能比LRU好，大致做法是既保持 RU，又保持 FU，还记录了最近回收的历史。

缓存用起来谁家强？​

为什么要重视软技能？​

因为你的工作会被软技能强的人抢走。

美国人的讲话能力非常强，从小学校教育就重视表达，一说话都是一套一套的。那么在同等情况下，哪怕中国人的技术更好，工作机会也被美国人抢走了。这个其实不是种族歧视，是自我表达能力的问题。

像印度人，在美国的势力非常强大，尤其是在高科技公司管理层这一块，中国人的势力远远不如印度人。这也是因为印度人讲故事的能力特别强。印度人的英语发音并不标准，但是他们敢说，而且往往能说到点子上。所以我们经常看到的局面就是一个印度经理欺负他手下几个技术比他好的中国员工。我们经常嘲笑印度人是 “PPT 治国”，但是这个讲故事的能力你不可不察。

这也说明“自由技艺”的软技能，是我们当代中国人的一个短板。

面试的本质是回答下面三个问题​

1. 能干不能干
2. 想干不想干
3. 合拍不合拍

如何回答这三个问题？​

面试的五个谈话点。

1.逆境。强调的可不是困难有多大，而是你是如何战胜这些困难的。你要证明自己不但没被逆境杀死，而且更强大了。最好举重若轻，把明明很大的困难轻描淡写，充满乐观情绪。然后你要顺便感谢一下在困境中曾经帮助过你的人，让人感觉到你是一个懂得感恩的人。

2.影响力。所有的交流问题本质上都是领导力问题，所有的领导力问题本质上就是交流问题。如果你善于说服别人，说明你天生就具备领导力。

3.技术水平。有什么故事能够展现你的技术水平？

4.合拍。美国联邦调查局（FBI）以前面试人的时候，喜欢问应聘者看过什么书。应聘者就会报一大堆书名，但其实 FBI 最想听的是他们看过汤姆.克兰西（Tom Clancy）的间谍小说。有一段时间，凡是说看过克兰西间谍小说的人都容易被录取。后来这个内部信息被传出去了，然后每个来面试的人都这么说，这招就不好使了。

5.成就。和别人相比，你有没有什么出类拔萃的地方。这就是你吹嘘以往成就的机会。成就不一定是实际的工作经验。

再往大了说，连美国总统竞选也是这个套路。奥巴马说，我父亲是一个移民，后来他抛弃了我妈妈，我从小在一个单亲家庭长大我是一个黑人我怎么怎么不容易……但是这些都不叫事儿现在的我就是这么乐观而又强大。特朗普说我做过这个项目这个项目和这个项目，现在我想做造福美国的大项目。

如何准备这五个谈话点？​

• 多尝试，经历失败，丰富你的人生经验；
• 多跟人交往，练习交流和组织能力；
• 学点技术，掌握一些实用工具；
• 要善于做调研，了解你所在的领域正在发生什么事儿；找机会取得能让自己脱颖而出的成绩。

ACID（一致性优先于可用性）

• 原子性确保事务要么完全成功，要么完全失败。
• 一致性：在 ACID 中，C 表示事务保留所有数据库规则，如唯一键、触发器、级联等。相比之下，CAP 中的 C 仅指单一副本一致性，是 ACID 一致性的严格子集。
• 隔离性确保并发执行的事务使数据库保持在与顺序执行事务相同的状态。
• 持久性确保一旦事务提交，即使在系统故障（如断电或崩溃）情况下也会保持提交状态。

BASE（可用性优先于一致性）

• 基本可用表示系统确保可用。
• 软状态表示系统的状态可能随时间变化，即使没有输入。这主要是由于最终一致性模型导致的。
• 最终一致性表示只要系统在一定时间内不接收输入，系统最终将达到一致状态。

虽然大多数 NoSQL 采用 BASE 原则，但它们正逐渐学习或转向 ACID，例如，Google Spanner 提供强一致性，MongoDB 4.0 增加了对多文档 ACID 事务的支持。

Availability patterns​

• Health Endpoint Monitoring: Implement functional checks in an application that external tools can access through exposed endpoints at regular intervals.
• Queue-Based Load Leveling: Use a queue that acts as a buffer between a task and a service that it invokes in order to smooth intermittent heavy loads.
• Throttling: Control the consumption of resources used by an instance of an application, an individual tenant, or an entire service.

Data Management patterns​

• Cache-Aside: Load data on demand into a cache from a data store
• Command and Query Responsibility Segregation: Segregate operations that read data from operations that update data by using separate interfaces.
• Event Sourcing: Use an append-only store to record the full series of events that describe actions taken on data in a domain.
• Index Table: Create indexes over the fields in data stores that are frequently referenced by queries.
• Materialized View: Generate prepopulated views over the data in one or more data stores when the data isn't ideally formatted for required query operations.
• Sharding: Divide a data store into a set of horizontal partitions or shards.
• Static Content Hosting: Deploy static content to a cloud-based storage service that can deliver them directly to the client.

Security Patterns​

• Federated Identity: Delegate authentication to an external identity provider.
• Gatekeeper: Protect applications and services by using a dedicated host instance that acts as a broker between clients and the application or service, validates and sanitizes requests, and passes requests and data between them.
• Valet Key: Use a token or key that provides clients with restricted direct access to a specific resource or service.