学习本文后，您可以获得以下好处：1.了解如何设计大型系统。作为系统设计的新手，我们首先需要对一般原则有一个基本的了解，它们是什么，如何使用它们，以及它们的缺点。话不多说，让我们进入正题。VerticalScalingHorizo??ntalScalingCachingLoadBalancingDatabaseReplicationDatabasePartitioningCoverage:首先可以看ScalabilityVideoLectureHarvardScalabilityLecturehttps://www.youtube.com/watch?v=-W9F__D3oY4查看可扩展性文章可用的Scalabilityhttp://www.lecloud.net/tagged/scalability/chrono了解了以上知识之后，接下来我们需要更高层次的权衡性能和可扩展性LatencyandthroughputAvailabilityandconsistencyTopicsCoveredbyCloneDatabaseCacheAsynchronyPerformanceandScalabilityAserviceismost如果它提高性能与添加的资源成比例，则可扩展。**一般来说，提高性能意味着服务更多的工作单元，但也可以处理更大的工作单元，例如当数据集增长时。另一种查看性能与可伸缩性的方法：如果你有性能问题，你的系统对于单个用户来说很慢。如果你有可伸缩性问题，你的系统对单个用户来说很快，但在重负载下会很慢。我们可以进一步阅读以了解延迟和吞吐量https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput可扩展性、可用性、稳定性、模式http://www.slideshare.net/jboner/scalability-availability-stability-patterns/延迟与吞吐量延迟是执行某些操作或产生某些结果所需的时间。吞吐量是每单位时间此类操作或结果的数量。通常，您应该以可接受的延迟获得最大吞吐量。深入学习可以进一步阅读以了解延迟和吞吐量https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput可用性和一致性CAP来源（CAP定理再访）：http://robertgreiner.com/2014/08/cap-theorem-revisited在分布式计算机系统中，您只能支持以下两种保证：一致性-每次读取都会收到最近写入或错误的可用性-每个请求都会收到响应，但不能保证包含最新版本的信息Partitiontolerance-尽管由于网络故障而任意分区，系统仍继续运行网络不可靠，因此需要支持分区容错。您需要在一致性和可用性之间进行软件权衡。CP-ConsistencyandPartitionTolerance等待分区节点的响应可能会导致超时错误。如果你的业务需要原子读写，CP是一个不错的选择。AP-可用性和分区容忍度响应返回任何节点上可用的最容易获得的数据版本，这可能不是最新的。解析分区后，写入可能需要一些时间才能传播。如果业务需求允许最终一致性，或者当系统需要在出现外部错误时继续工作时，AP是一个不错的选择。延伸阅读：重温CAP定理http://robertgreiner.com/2014/08/cap-theorem-revisited/)CAP定理简单英文介绍http://ksat.me/a-plain-english-introduction-to-cap-theoremCAPFAQhttps://github.com/henryr/cap-faCAPTheoremhttps://www.youtube.com/watch?v=k-Yaq8AHlFConsistency有一致的数据视图。回忆一下CAP定理中一致性的定义——每次读取都会收到最近的写入或错误。在弱一致性写入之后，读取可能会或可能不会看到它。采取了尽力而为的方法。在memcached等系统中可以看到这种方法。弱一致性适用于实时用例，例如VoIP、视频聊天和实时多人游戏。例如，如果您正在打电话并失去信号几秒钟，当您重新连接时，您将听不到断开连接时所说的话。在最终一致的写入之后，读取最终会看到它（通常在几毫秒内）。数据是异步复制的。这种方法在DNS和电子邮件等系统中都有看到。最终一致性在高可用性系统中运行良好。强一致性写入后，读取将看到它。数据是同步复制的。这种方法出现在文件系统和RDBMS中。强一致性在需要事务的系统中效果很好。在这里，我们可以进一步了解跨数据中心的事务http://snarfed.org/transactions_across_datacenters_io.html支持高可用性的可用性模式有两种互补模式：故障转移和复制。主动-被动故障转移对于主动-被动故障转移，心跳在备用主动服务器和被动服务器之间发送。如果心跳中断，被动服务器接管主动服务器的IP地址并恢复服务。停机时间的长短取决于无源服务器是否已经在“热”备用服务器上运行，或者是否需要从“冷”备用服务器启动。只有活动服务器处理流量。主动-被动故障转移也可以称为主从故障转移。主动-主动在主动-主动中，两台服务器都在管理流量，在它们之间分配负载。如果服务器面向公众，则DNS需要知道两台服务器的公共IP。如果服务器面向内部，则应用程序逻辑需要了解这两个服务器。Active-activefailover也可以称为active-activefailover。缺点：故障转移故障转移增加了更多的硬件和额外的复杂性。如果主动系统在任何新写入的数据可以复制到被动系统之前发生故障，数据可能会丢失。复制主从复制和主从复制数据库部分将进一步讨论这个主题：主从复制https://github.com/donnemartin/system-design-primer#master-slave-replicationmaster-masterreplicationhttps://github.com/donnemartin/system-design-primer#master-master-replicationSharding分片将数据分布在不同的数据库中，这样每个数据库只能管理数据的一个子集。以用户数据库为例，随着用户数量的增加，集群中会加入更多的分片。分片导致更少的读写流量、更少的复制和更多的缓存命中。索引大小也减少了，这通常会通过更快的查询来提高性能。如果一个分片出现故障，其他分片仍然可以运行，但您需要添加某种形式的复制以避免数据丢失。与联邦一样，没有单一的中央主机来序列化写入，从而允许您并行写入并提高吞吐量。对用户表进行分片的一种常见方法是按用户的姓名首字母或用户的地理位置。缺点：分片重新平衡增加了额外的复杂性。基于一致性哈希的分片功能可以减少传输的数据量。您需要更新应用程序逻辑以使用分片，这可能会导致复杂的SQL查询。分片中的数据分布可能变得不平衡。例如，与其他分片相比，分片上的一组高级用户可能会导致该分片上的负载增加。连接来自多个分片的数据更加复杂。分片增加了更多的硬件和额外的复杂性。域名系统域名系统(DNS)将www.example.com等域名转换为IP地址。DNS是分层的，在顶部有一些权威服务器。您的路由器或ISP提供有关要联系哪些DNS服务器进行查找的信息。较低级别的DNS服务器缓存映射，这些映射可能会由于DNS传播延迟而变得陈旧。DNS结果也可以由您的浏览器或操作系统缓存一段时间，由生存时间(TTL)决定。NS记录（名称服务器）-为您的域/子域指定DNS服务器。MX记录（邮件交换）-指定接受邮件的邮件服务器。record(address)-将名称指向IP地址。CNAME（规范）-将名称指向另一个名称或CNAME（example.com到www.example.com）或A记录。CloudFlare和Route53等服务提供托管DNS服务。一些DNS服务可以通过多种方法路由流量：加权循环法防止流量进入维护中的服务器不同集群大小之间的平衡A/B测试上述缓存可以减轻这种延迟。DNS服务器管理可能很复杂，通常由政府、ISP和大公司管理。DNS服务最近遭到DDoS攻击，导致用户无法在不知道Twitter的IP地址的情况下访问Twitter等网站。内容网络分发源（WhyUseaCDN）：https://www.creative-artworks.eu/why-use-a-content-delivery-network-cdn/内容分发网络（CDN）是一个全球分布式代理服务器web，从更靠近用户的位置提供内容。通常，静态文件（如HTML/CSS/JS、照片和视频）由CDN提供，尽管一些CDN（如亚马逊的CloudFront）支持动态内容。该站点的DNS解析将告诉客户端联系哪个服务器。从CDN提供内容可以通过两种方式显着提高性能：用户从靠近他们的数据中心接收内容您的服务器不必为CDN完成的请求提供服务PushCDNsPushCDNs在您的服务器每次更改时接收新内容。您全权负责提供内容、直接上传到CDN以及重写??URL以指向CDN。您可以配置内容何时过期以及何时更新。仅在内容是新内容或更改时才上传内容，最大限度地减少流量但最大化存储空间。流量较低或内容更新不频繁的站点与推送CDN配合得很好。内容只放置在CDN上一次，而不是定期重新拉取。PullCDN当第一个用户请求内容时，PullCDN从您的服务器获取新内容。您将内容留在服务器上并重写URL以指向CDN。这会导致请求变慢，直到内容缓存在CDN上。生存时间(TTL)决定了内容的缓存时间。从CDN拉取可最大限度地减少CDN上的存储空间，但如果文件过期并在文件实际更改之前被拉取，则会产生冗余流量。高流量网站可以很好地与拉取式CDN配合使用，因为流量分布更均匀并且只有最近请求的内容保留在CDN上。缺点：CDNCDN的成本可能取决于流量，尽管这应该与不使用CDN的额外成本进行权衡。如果内容在TTL到期之前更新，则内容可能已过时。CDN需要将静态内容的URL更改为指向CDN。来源和进一步阅读全球分布式内容交付推送和拉取CDN之间的差异维基百科负载均衡器来源（来源：可扩展系统的设计模式）：http://horicky.blogspot.com/2010/10/scalable-system-design-patterns。html负载平衡器将传入的客户端请求分发到应用程序服务器和数据库等计算资源。在每种情况下，负载均衡器都会将来自计算资源的响应返回给适当的客户端。负载均衡器在以下方面有效：防止请求进入不健康的服务器防止资源过载帮助消除单点故障负载均衡器可以使用硬件（昂贵）或软件（例如HAProxy）来实现。其他好处包括：SSL终止-解密传入请求并加密服务器响应，因此后端服务器不必执行这些可能代价高昂的操作无需在每个服务器上安装X.509证书然后发出cookie并请求特定客户端被路由到同一个实例。为了防止故障，通常会设置多个负载平衡器，无论是主动-被动模式还是主动-主动模式。负载均衡器可以根据多种指标路由流量，包括：随机负载最小负载轮询或加权轮询传输层负载应用层负载均衡缺点：如果负载均衡器没有足够的资源或配置不正确，它可能成为性能瓶颈。引入负载平衡器来帮助消除单点故障会增加复杂性。单个负载均衡器是单点故障，配置多个负载均衡器会进一步增加复杂性。缓存缓存可以缩短页面加载时间并减少服务器和数据库负载。在这个模型中，调度器会先查找之前是否有请求，并尝试找到之前的结果返回保存实际执行。数据库通常受益于跨分区的均匀分布的读取和写入。热点项目会扭曲分布，造成瓶颈。将缓存放在数据库前面可以帮助吸收不均匀的负载和流量峰值。客户端缓存CDN缓存Web服务器缓存数据库缓存中间件缓存缺点一致性问题节点故障引入延迟额外开销和编码复杂性在线执行。他们还可以通过提前完成耗时的工作来提供帮助，例如定期汇总数据。消息队列消息队列接收、存储和传递消息。如果操作太慢而无法在线执行，您可以使用具有以下工作流程的消息队列：应用程序将作业发布到队列，然后通知用户作业状态工作人员从队列中取出作业，处理它，然后发出作业完成信号用户不是被阻止，作业在后台处理。在此期间，客户端可以选择性地进行少量处理以使任务看起来已完成。例如，如果您发布一条推文，该推文可能会立即发布到您的时间线，但您的推文可能需要一些时间才能真正到达您的所有关注者。Redis作为简单的消息代理很有用，但消息可能会丢失。RabbitMQ很流行，但需要你适应“AMQP”协议并管理你自己的节点。AmazonSQS是托管的，但可能具有高延迟并且可能会传递两次消息。任务队列任务队列接收任务及其相关数据，运行它们，并交付它们的结果。它们可以支持调度并可用于在后台运行计算密集型作业。Celery支持调度，主要是在python中。背压如果队列开始显着增长，队列大小会变得比内存大，导致缓存未命中、磁盘读取，甚至性能下降。背压可以通过限制队列大小来提供帮助，从而为队列中的作业保持高吞吐量和良好的响应时间。队列填满后，客户端会收到服务器忙或HTTP503状态代码，以便稍后重试。客户端可以稍后重试请求，可能使用指数退避。缺点：由于引入队列会增加延迟和复杂性，异步廉价计算和实时工作流等用例可能更适合同步操作。安全安全是一个广泛的话题。除非您拥有丰富的经验、安全背景，或者正在申请需要安全知识的职位，否则您可能只需要了解基础知识：传输加密和静态加密。清理所有用户输入或向用户公开的任何输入参数，以防止XSS和SQL注入。使用参数化查询来防止SQL注入。使用最小特权原则。以上就是系统设计的大致模块，大家快来学习吧。
