面向分布式系统工程师的ATProto

# 面向分布式系统工程师的 Atproto - AT Protocol 如果你曾经构建过带有[流处理](https://milinda.pathirage.org/kappa-architecture.com/)的后端，那么你对我们即将探讨的这类系统应该不会陌生。如果没有——也没关系！我们会一步步讲解。 经典的、令人愉快的 Web 架构是应用服务器背后的“一个大型 SQL 数据库”。应用与数据库通信，并处理来自前端的请求。 随着应用的增长，我们会遇到一些性能瓶颈，于是我们在技术栈中加入了一些缓存。 然后，假设我们通过分片和副本对数据库进行水平扩展。 这已经相当不错了，但我们要构建的是一个拥有数亿用户的社交网络；即便这个模型也会遇到瓶颈。问题在于，我们的 SQL 数据库是“[强一致性](https://en.wikipedia.org/wiki/Strong_consistency)”的，这意味着系统中的状态必须保持统一同步。维护强一致性会带来性能开销，而这正是我们的瓶颈所在。 如果我们能让系统放宽为“[最终一致性](https://en.wikipedia.org/wiki/Eventual_consistency)”，就能进一步扩展。我们首先切换到 NoSQL 集群。 这更有利于扩展，但没有 SQL 后，构建查询变得愈发困难。事实证明，SQL 数据库有许多有用的特性，比如 JOIN 和聚合查询。实际上，我们的 NoSQL 数据库本质上只是一个键值存储。编写功能变成了一件痛苦的事！ 为了解决这个问题，我们需要编写程序来生成数据集的预计算视图。这些视图本质上类似于缓存查询。我们甚至将权威数据复制到这些视图中，因此它们非常快。 我们将这些称为视图服务器（View servers）。 现在我们注意到，让视图