服务端技术进阶(四)一文读懂分布式系统本质：高吞吐、高可用、可扩展

根据上面的例子来看，分布式系统虽然具有三层典型的结构，但是实际上往往不止有三层，而是根据业务需求，会设计成多个层次的。为了把请求转交给正确的进程处理，我们设计很多专门用于转发请求的进程和服务器。这些进程我们常常以Proxy或者Router来命名，一个多层结构常常会具备各种各样的Proxy进程。这些代理进程，很多时候都是通过TCP来连接前后两端。然而，TCP虽然简单，但是却存在发生故障后不易恢复的问题。而且TCP的网络编程也是有点复杂的。——所以，人们设计出更好进程间通讯机制：消息队列。

尽管通过各种Proxy或者Router进程能组建出强大的分布式系统，但是其管理的复杂性也是非常高的。所以人们在分层模式的基础上想出了更多的方法，来让这种分层模式的程序变得更简单高效。

三、并发模型（多线程、异步）

当我们在编写服务器端程序时会明确地知道大部分的程序都是会处理同时到达的多个请求的。因此我们不能好像Hello World那么简单的从一个简单的输入计算出输出来。因为我们会同时获得很多个输入，需要返回很多个输出。在这些处理的过程中，往往我们还会碰到需要“等待”或“阻塞”的情况，比如我们的程序要等待数据库处理结果，等待向另外一个进程请求结果等等……如果我们把请求一个挨着一个的处理，那么这些空闲的等待时间将白白浪费，造成用户的响应延时增加，以及整体系统的吞吐量极度下降。

所以在如何同时处理多个请求的问题上，业界有2个典型的方案。一种是多线程，一种是异步。在早期的系统中，多线程或多进程是最常用的技术。这种技术的代码编写起来比较简单，因为每个线程中的代码都肯定是按先后顺序执行的。但是由于同时运行着多个线程，所以你无法保障多个线程之间的代码的先后顺序。这对于需要处理同一个数据的逻辑来说，是一个非常严重的问题，最简单的例子就是显示某个新闻的阅读量。两个++操作同时运行，有可能结果只加了1，而不是2。所以多线程下，常常要加很多数据的锁，而这些锁又反过来可能导致线程的死锁。

因此异步回调模型在随后比多线程更加流行，除了多线程的死锁问题外，异步还能解决多线程下，线程反复切换导致不必要开销的问题：每个线程都需要一个独立的栈空间，在多线程并行运行的时候，这些栈的数据可能需要来回的拷贝，这额外消耗了CPU。同时由于每个线程都需要占用栈空间，所以在大量线程存在的时候，内存的消耗也是巨大的。而异步回调模型则能很好的解决这些问题，不过异步回调更像是“手工版”的并行处理，需要开发者自己去实现如何“并行”的问题。

异步回调基于非阻塞的I/O操作（网络和文件），这样我们就不用在调用读写函数的时候“卡”在那一句函数调用，而是立刻返回“有无数据”的结果。而Linux的epoll技术，则利用底层内核的机制，让我们可以快速的“查找”到有数据可以读写的连接\文件。由于每个操作都是非阻塞的，所以我们的程序可以只用一个进程就可以处理大量并发的请求。因为只有一个进程，所以所有的数据处理，其顺序都是固定的，不可能出现多线程中，两个函数的语句交错执行的情况，因此也不需要各种“锁”。从这个角度看，异步非阻塞的技术大大简化了开发的过程。由于只有一个线程，也不需要有线程切换之类的开销，所以异步非阻塞成为很多对吞吐量、并发有较高要求的系统首选。

四、缓冲技术

在互联网服务中，大部分的用户交互都是需要立刻返回结果的，所以对于延迟有一定的要求。而类似网络游戏之类服务，延迟更是要求缩短到几十毫秒以内。所以为了降低延迟，缓冲是互联网服务中最常见的技术之一。

早期的WEB系统中，如果每个HTTP请求的处理，都去数据库（MySQL）读写一次，那么数据库很快就会因为连接数占满而停止响应。因为一般的数据库支持的连接数都只有几百，而WEB应用的并发请求轻松能到几千。这也是很多设计不良的网站在访问数量骤增就卡死的最直接原因。为了尽量减少对数据库的连接和访问，人们设计了很多缓冲系统——把从数据库中查询的结果存放到更快的设施上，如果没有相关联的修改，就直接从这里读。

最典型的WEB应用缓冲系统是Memcache。由于PHP本身的线程结构是不带状态的。早期PHP本身甚至连操作“堆”内存的方法都没有，所以那些持久的状态就一定要存放到另外一个进程里。而Memcache就是一个简单可靠的存放临时状态的开源软件。很多PHP应用现在的处理逻辑都是先从数据库读取数据，然后写入Memcache；当下次请求来的时候，先尝试从Memcache里面读取数据，这样就有可能大大减少对数据库的访问。

然而Memcache本身是一个独立的服务器进程，这个进程自身并不带特别的集群功能。也就是说这些Memcache进程并不能直接组建成一个统一的集群。如果一个Memcache不够用，我们就要手工用代码去分配，哪些数据应该去哪个Memcache进程。——这对于真正的大型分布式网站来说，管理一个这样的缓冲系统，是一个很繁琐的工作。

因此人们开始考虑设计一些更高效的缓冲系统：从性能上来说，Memcache的每笔请求都要经过网络传输才能去拉取内存中的数据。这无疑是有一点浪费的，因为请求者本身的内存，也是可以存放数据的。——这就是促成了很多利用请求方内存的缓冲算法和技术，其中最简单的就是使用LRU算法，把数据放在一个哈希表结构的堆内存中。

而Memcache不具备集群功能也是一个痛点。于是很多人开始设计，如何让数据缓存分布到不同的机器上。最简单的思路是所谓读写分离，也就是缓存每次写，都写到多个缓冲进程上记录，而读则可以随机读任何一个进程。在业务数据有明显的读写不平衡差距上，效果是非常好的。

然而，并不是所有的业务都能简单的用读写分离来解决问题，比如一些在线互动的互联网业务，比如社区、游戏。这些业务的数据读写频率并没很大的差异，而且也要求很低的延迟。因此人们又再想办法，把本地内存和远端进程的内存缓存结合起来使用，让数据具备两级缓存。同时，一个数据不再同时存在所有的缓存进程上，而是按一定规律分布在多个进程上。——这种分布规律使用的算法，最流行的就是所谓“一致性哈希”。这种算法的好处是，当某一个进程失效挂掉，不需要把整个集群中所有的缓存数据重新修改一次位置。你可以想象一下，如果我们的数据缓存分布，是用简单的以数据ID对进程数取模，那么一旦进程数变化，每个数据存放的进程位置都可能变化，这对于服务器的故障容忍是不利的。

Orcale公司旗下有一款叫Coherence的产品，是在缓存系统上设计比较好的。这个产品是一个商业产品，支持利用本地内存缓存和远程进程缓存协作。集群进程是完全自管理的，还支持在数据缓存所在进程进行用户自定义的计算（处理器功能），这就不仅仅是缓存了，还是一个分布式的计算系统。

五、存储技术（NoSQL）

相信CAP理论大家已经耳熟能详，然而在互联发展的早期，大家都还在使用MySQL的时候，如何让数据库存放更多的数据，承载更多的连接，很多团队都是绞尽脑汁。甚至于有很多业务主要的数据存储方式是文件，数据库反而变成是辅助的设施了。

附:CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

然而，当NoSQL兴起，大家突然发现，其实很多互联网业务，其数据格式是如此简单，很多时候根本不需要关系型数据库那种复杂的表格。对于索引的要求往往也只是根据主索引搜索。而更复杂的全文搜索，本身数据库也做不到。所以现在相当多的高并发互联网业务首选NoSQL来做存储设施。最早的NoSQL数据库有MongoDB等，现在最流行的似乎就是Redis了。甚至有些团队把Redis也当成缓冲系统的一部分，实际上也是认可Redis的性能优势。

NoSQL除了更快、承载量更大以外，更重要的特点是这种数据存储方式只能按照一条索引来检索和写入。这样的需求约束带来了分布上的好处，我们可以按照这条主索引来定义数据存放的进程（服务器）。这样一个数据库的数据就能很方便的存放在不同的服务器上。在分布式系统的必然趋势下，数据存储层终于也找到了分布的方法。

六、布式系统在可管理性上造成的问题

分布式系统并不是简单的把一堆服务器一起运行起来就能满足需求的。对比单机或少量服务器的集群，有一些特别需要解决的问题等待着我们。

6.1 硬件故障率

所谓分布式系统，肯定就不是只有一台服务器。假设一台服务器的故障时间是1%，那么当你有100台服务器的时候，那就几乎总有一台是在故障状态的。虽然这个比方不一定很准确，但是，**当你的系统所涉及的硬件越来越多，硬件的故障也会从偶然事件变成一个必然事件。**一般我们在写功能代码的时候，是不会考虑到硬件故障的时候应该怎么办的。而如果在编写分布式系统的时候，就一定需要面对这个问题了。否则，很可能只有一台服务器出故障，整个数百台服务器的集群都工作不正常了。

除了服务器自己的内存、硬盘等故障，服务器之间的网络线路故障更加常见。而且这种故障还有可能是偶发的，或者是会自动恢复的。面对这种问题，如果只是简单的把“出现故障”的机器剔除出去，那还是不够的。因为网络可能过一会儿就又恢复了，而你的集群可能因为这一下的临时故障，丢失了过半的处理能力。

如何让分布式系统在各种可能随时出现故障的情况下，尽量的自动维护和维持对外服务，成为了编写程序时就要考虑的问题。由于要考虑到这种故障的情况，所以我们在设计架构的时候，也要有意识地预设一些冗余、自我维护的功能。这些都不是产品上的业务需求，完全就是技术上的功能需求。能否在这方面提出对的需求，然后正确的实现，是服务器端程序员最重要的职责之一。

6.2 资源利用率优化

分布式系统的集群包含了很多服务器，当这样一个集群的硬件承载能力到达极限的时候，最自然的想法就是增加更多的硬件。然而，一个软件系统并不是通过“增加”硬件就可以轻松提高承载性能的。因为软件在多个服务器上的工作需要复杂细致的协调工作。在对一个集群扩容的时候，我们往往会要停掉整个集群的服务，然后修改各种配置，最后才能重新启动一个加入了新的服务器的集群。

由于在每个服务器的内存里，都可能会有一些用户使用的数据，所以如果冒然在运行的时候，就试图修改集群中提供服务的配置，很可能会造成内存数据的丢失和错误。因此，运行时扩容在对无状态的服务是比较容易的，比如增加一些Web服务器。但如果是在有状态的服务上，比如网络游戏，几乎是不可能进行简单运行时扩容的。

分布式集群除了扩容，还有缩容的需求。当用户人数下降，服务器硬件资源出现空闲的时候，我们往往需要这些空闲的资源能利用起来，放到另外一些新的服务集群里去。缩容和集群中有故障需要容灾有一定类似之处，区别是缩容的时间点和目标是可预期的。

由于分布式集群中的扩容、缩容，以及希望尽量能在线操作，这导致了非常复杂的技术问题需要处理，比如集群中互相关联的配置如何正确高效的修改、如何对有状态的进程进行操作、如何在扩容缩容的过程中保证集群中节点之间通信的正常。作为服务器端程序员，会需要花费大量的精力来应对多个进程的集群状态变化造成的一系列问题。

6.3 软件服务内容更新

现在都流行用敏捷开发模式中的“迭代”，来表示一个服务不断的更新程序，满足新的需求，修正BUG。如果我们仅仅管理一台服务器，那么更新这一台服务器上的程序是非常简单的：只要把软件包拷贝过去，然后修改下配置就好。但是如果你要对成百上千的服务器去做同样的操作，就不可能每台服务器登录上去处理。

服务器端的批量程序安装部署工具，是每个分布式系统开发者都需要的。然而，我们的安装工作除了拷贝二进制文件和配置文件外，还会有很多其他的操作需要完成。比如打开防火墙、建立共享内存文件、修改数据库表结构、改写一些数据文件等等……甚至有一些还要在服务器上安装新的软件。

如果我们在开发服务器端程序的时候，就考虑到软件更新、版本升级的问题，那么我们对于配置文件、命令行参数、系统变量的使用，就会预先做一定的规划，这能让安装部署的工具运行更快，可靠性更高。

除了安装部署的过程，还有一个重要的问题，就是不同版本间数据的问题。我们在升级版本的时候，旧版本程序生成的一些持久化数据一般都是旧的数据格式；而我们的升级版本中如果涉及到了修改的数据格式，比如数据表结构，那么这些旧格式的数据都要转换改写成新版本的数据格式才行。这导致了我们在设计数据结构的时候，就要考虑清楚这些表格的结构，是用最简单直接的表达方式来让将来的修改更简单；还是一早就预计到修改的范围，专门预设一些字段，或者使用其他形式存放数据。

除了持久化数据以外，如果存在客户端程序（如手机APP），这些客户端程序的升级往往不能和服务器同步，如果升级的内容包含了通信协议的修改，这就造成了我们必须为不同的版本部署不同的服务器端系统的问题。为了避免同时维护多套服务器，我们在软件开发的时候，往往倾向于所谓“版本兼容”的协议定义方式。而怎样设计的协议才能有很好的兼容性，又是服务器端程序需要仔细考虑的问题。

6.4 数据统计和决策

一般来说，分布式系统的日志数据都是被集中到一起，然后统一进行统计的。然而，当集群的规模达到一定程度的时候，这些日志的数据量会变得非常恐怖。很多时候，统计一天的日志量要消耗计算机运行一天以上的时间。所以，日志统计这项工作，也变成一门非常专业的活动。

经典的分布式统计模型，有Google的Map Reduce模型。这种模型既有灵活性，也能利用大量服务器进行统计工作。但是缺点是易用性往往不够好，因为这些数据的统计和我们常见的SQL数据表统计有非常大的差异，所以我们最后还是常常把数据丢到MySQL里面去做更细层面的统计。

由于分布式系统日志数量的庞大，以及日志复杂程度的提高。我们变得必须要掌握类似Map Reduce技术，才能真正的对分布式系统进行数据统计。而且我们还需要想办法提高统计工作的工作效率。

对象篇

模块化编程-自研模块加载器

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】