转载自https://www.cnblogs.com/wetest/p/6806506.html 和https://www.cnblogs.com/dudu0614/p/8821811.html
什么是分布式系统
分布式这一观点，一贯都是后端工程师绕不过去的一个坎，本日，我们就一起来看看到底什么是分布式系统，又有哪些分布式技能世我们须要学习的。
根据百度百科的先容，分布式系统（distributed system）是建立在网络之上的软件系统。正是由于软件的特性，以是分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的差异更多的在于高层软件（特殊是操作系统），而不是硬件。
从分布式系统的出身提及
我们常常会听说，某个互联网运用的做事器端系统多么牛逼，比如QQ、微信、淘宝。那么，一个互联网运用的做事器端系统，到底牛逼在什么地方？为什么海量的用户访问，会让一个做事器端系统变得更繁芜？本文便是想从最基本的地方开始，探寻做事器端系统技能的根本观点。
承载量是分布式系统存在的缘故原由
当一个互联网业务得到大众欢迎的时候，最显著碰到的技能问题，便是做事器非常繁忙。当每天有1000万个用户访问你的网站时，无论你利用什么样的做事器硬件，都不可能只用一台机器就承载的了。因此，在互联网程序员办理做事器端问题的时候，必须要考虑如何利用多台做事器，为同一种互联网运用供应做事，这便是所谓“分布式系统”的来源。
然而，大量用户访问同一个互联网业务，所造成的问题并不大略。从表面上看，要能知足很多用户来自互联网的要求，最基本的需求便是所谓性能需求：用户反应网页打开很慢，或者网游中的动作很卡等等。而这些对付“做事速率”的哀求，实际上包含的部分却是以下几个：高吞吐、高并发、低延迟和负载均衡。
高吞吐，意味着你的系统，可以同时承载大量的用户利用。这里关注的全体系统能同时做事的用户数。这个吞吐量肯定是不可能用单台做事器办理的，因此须要多台做事器协作，才能达到所须要的吞吐量。而在多台做事器的协作中，如何才能有效的利用这些做事器，不致于个中某一部分做事器成为瓶颈，从而影响全体系统的处理能力，这便是一个分布式系统，在架构上须要仔细权衡的问题。
高并发是高吞吐的一个延伸需求。当我们在承载海量用户的时候，我们当然希望每个做事器都能尽其所能的事情，而不要涌现无谓的花费和等待的情形。然而，软件系统并不是大略的设计，就能对同时处理多个任务，做到“只管即便多”的处理。很多时候，我们的程序会由于要选择处理哪个任务，而导致额外的花费。这也是分布式系统办理的问题。
低延迟对付人数稀少的做事来说不算什么问题。然而，如果我们须要在大量用户访问的时候，也能很快的返回打算结果，这就要困难的多。由于除了大量用户访问可能造成要求在排队外，还有可能由于排队的长度太长，导致内存耗尽、带宽占满等空间性的问题。如果由于排队失落败而采纳重试的策略，则全体延迟会变的更高。以是分布式系统会采取很多要求分拣和分发的做法，尽快的让更多的做事器来出来用户的要求。但是，由于一个数量弘大的分布式系统，一定须要把用户的要求经由多次的分发，全体延迟可能会由于这些分发和转交的操作，变得更高，以是分布式系统除了分发要求外，还要只管即便想办法减少分发的层次数，以便让要求能尽快的得到处理。
由于互联网业务的用户来自全天下，因此在物理空间上可能来自各种不同延迟的网络和线路，在韶光上也可能来自不同的时区，以是要有效的应对这种用户来源的繁芜性，就须要把多个做事器支配在不同的空间来供应做事。同时，我们也须要让同时发生的要求，有效的让多个不同做事器承载。所谓的负载均衡，便是分布式系统与生俱来须要完成的作业。
由于分布式系统，险些是办理互联网业务承载量问题，的最基本方法，以是作为一个做事器端程序员，节制分布式系统技能就变得非常主要了。然而，分布式系统的问题，并非是学会用几个框架和利用几个库，就能轻易办理的，由于当一个程序在一个电脑上运行，变成了又无数个电脑上同时协同运行，在开拓、运维上都会带来很大的差别。
分布式系统提高承载量的基本手段
分层模型（路由、代理）
利用多态做事器来协同完成打算任务，最大略的思路便是，让每个做事器都能完玉成体的要求，然后把要求随机的发给任何一个做事器处理。最早期的互联网运用中，DNS轮询便是这样的做法：当用户输入一个域名试图访问某个网站，这个域名会被阐明成多个IP地址中的一个，随后这个网站的访问要求，就被发往对应IP的做事器了，这样多个做事器（多个IP地址）就能一起办理处理大量的用户要求。
然而，纯挚的要求随机转发，并不能办理统统问题。比如我们很多互联网业务，都是须要用户登录的。在登录某一个做事器后，用户会发起多个要求，如果我们把这些要求随机的转发到不同的做事器上，那么用户登录的状态就会丢失，造成一些要求处理失落败。大略的依赖一层做事转发是不足的，以是我们会增加一批做事器，这些做事器会根据用户的Cookie，或者用户的登录凭据，来再次转发给后面详细处理业务的做事器。
除了登录的需求外，我们还创造，很多数据是须要数据库来处理的，而我们的这些数据每每都只能集中到一个数据库中，否则在查询的时候就会丢失其他做事器上存放的数据结果。以是每每我们还会把数据库单独出来成为一批专用的做事器。
至此，我们就会创造，一个范例的三层构造涌现了：接入、逻辑、存储。然而，这种三层结果，并不就能包医百病。例如，当我们须要让用户在线互动（网游便是范例） ，那么分割在不同逻辑做事器上的在线状态数据，是无法知道对方的，这样我们就须要专门做一个类似互动做事器的专门系统，让用户登录的时候，也同时记录一份数据到它那里，表明某个用户登录在某个做事器上，而所有的互动操作，要先经由这个互动做事器，才能精确的把转发到目标用户的做事器上。
又例如，当我们在利用网上论坛（BBS）系统的时候，我们发的文章，不可能只写入一个数据库里，由于太多人的阅读要求会拖去世这个数据库。我们常常会按论坛板块来写入不同的数据库，又或者是同时写入多个数据库。这样把文章数据分别存放到不同的做事器上，才能应对大量的操作要求。然而，用户在读取文章的时候，就须要有一个专门的程序，去查找详细文章在哪一个做事器上，这时候我们就要架设一个专门的代理层，把所有的文章要求先转交给它，由它按照我们预设的存储操持，去找对应的数据库获取数据。
根据上面的例子来看，分布式系统虽然具有三层范例的构造，但是实际上每每不止有三层，而是根据业务需求，会设计成多个层次的。为了把要求转交给精确的进程处理，我们而设计很多专门用于转发要求的进程和做事器。这些进程我们常常以Proxy或者Router来命名，一个多层构造常常会具备各种各样的Proxy进程。这些代理进程，很多时候都是通过TCP来连接前后两端。然而，TCP虽然大略，但是却会有故障后不随意马虎规复的问题。而且TCP的网络编程，也是有点繁芜的。——以是，人们设计出更好进程间通讯机制：行列步队。
只管通过各种Proxy或者Router进程能组建出强大的分布式系统，但是其管理的繁芜性也是非常高的。以是人们在分层模式的根本上，想出了更多的方法，来让这种分层模式的程序变得更大略高效的方法。
并发模型（多线程、异步）
当我们在编写做事器端程序是，我们会明确的知道，大部分的程序，都是会处理同时到达的多个要求的。因此我们不能彷佛HelloWorld那么大略的，从一个大略的输入打算出输出来。由于我们会同时得到很多个输入，须要返回很多个输出。在这些处理的过程中，每每我们还会碰到须要“等待”或“壅塞”的情形，比如我们的程序要等待数据库处理结果，等待向其余一个进程要求结果等等……如果我们把要求一个挨着一个的处理，那么这些空闲的等待韶光将白白摧残浪费蹂躏，造成用户的相应延时增加，以及整体系统的吞吐量极度低落。
以是在如何同时处理多个要求的问题上，业界有2个范例的方案。一种是多线程，一种是异步。在早期的系统中，多线程或多进程是最常用的技能。这种技能的代码编写起来比较大略，由于每个线程中的代码都肯定是按先后顺序实行的。但是由于同时运行着多个线程，以是你无法保障多个线程之间的代码的先后顺序。这对付须要处理同一个数据的逻辑来说，是一个非常严重的问题，最大略的例子便是显示某个新闻的阅读量。两个++操作同时运行，有可能结果只加了1，而不是2。以是多线程下，我们常常要加很多数据的锁，而这些锁又反过来可能导致线程的去世锁。
因此异步回调模型在随后比多线程更加盛行，除了多线程的去世锁问题外，异步还能办理多线程下，线程反复切换导致不必要的开销的问题：每个线程都须要一个独立的栈空间，在多线程并走运行的时候，这些栈的数据可能须要来回的拷贝，这额外花费了CPU。同时由于每个线程都须要占用栈空间，以是在大量线程存在的时候，内存的花费也是巨大的。而异步回调模型则能很好的办理这些问题，不过异步回调更像是“手工版”的并行处理，须要开拓者自己去实现如何“并行”的问题。
异步回调基于非壅塞的I/O操作（网络和文件），这样我们就不用在调用读写函数的时候“卡”在那一句函数调用，而是急速返回“有无数据”的结果。而Linux的epoll技能，则利用底层内核的机制，让我们可以快速的“查找”到有数据可以读写的连接\文件。由于每个操作都是非壅塞的，以是我们的程序可以只用一个进程，就处理大量并发的要求。由于只有一个进程，以是所有的数据处理，其顺序都是固定的，不可能涌现多线程中，两个函数的语句交错实行的情形，因此也不须要各种“锁”。从这个角度看，异步非壅塞的技能，是大大简化了开拓的过程。由于只有一个线程，也不须要有线程切换之类的开销，以是异步非壅塞成为很多对吞吐量、并发有较高哀求的系统首选。
int epoll_create(int size)；//创建一个epoll的句柄，size用来见告内核这个监听的数目一共有多大
int epoll_ctl(int epfd, int op, int fd, struct epoll_event event)；
int epoll_wait(int epfd, struct epoll_event events, int maxevents, int timeout);
缓冲技能
在互联网做事中，大部分的用户交互，都是须要急速返回结果的，以是对付延迟有一定的哀求。而类似网络游戏之类做事，延迟更是哀求缩短到几十毫秒以内。所以为了降落延迟，缓冲是互联网做事中最常见的技能之一。
早期的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的时候，如何让数据库存放更多的数据，承载更多的连接，很多团队都是绞尽脑汁。乃至于有很多业务，紧张的数据存储办法是文件，数据库反而变成是赞助的举动步伐了。
然而，当NoSQL兴起，大家溘然创造，实在很多互联网业务，其数据格式是如此的大略，很多时候根部不须要关系型数据库那种繁芜的表格。对付索引的哀求每每也只是根据主索引搜索。而更繁芜的全文搜索，本身数据库也做不到。以是现在相称多的高并发的互联网业务，首选NoSQL来做存储举动步伐。最早的NoSQL数据库有MangoDB等，现在最盛行的彷佛便是Redis了。乃至有些团队，把Redis也当成缓冲系统的一部分，实际上也是认可Redis的性能上风。
NoSQL除了更快、承载量更大以外，更主要的特点是，这种数据存储办法，只能按照一条索引来检索和写入。这样的需求约束，带来了分布上的好处，我们可以按这条主索引，来定义数据存放的进程（做事器）。这样一个数据库的数据，就能很方便的存放在不同的做事器上。在分布式系统的一定趋势下，数据存储层终于也找到了分布的方法。
分布式系统在可管理性上造成的问题
分布式系统并不是大略的把一堆做事器一起运行起来就能知足需求的。比拟单机或少量做事器的集群，有一些特殊须要办理的问题等待着我们。
硬件故障率
所谓分布式系统，肯定就不是只有一台做事器。假设一台做事器的均匀故障韶光是1%，那么当你有100台做事器的时候，那就险些总有一台是在故障的。虽然这个比方不一定很准确，但是，当你的系统所涉及的硬件越来越多，硬件的故障也会从有时势宜变成一个一定事宜。一样平常我们在写功能代码的时候，是不会考虑到硬件故障的时候该当怎么办的。而如果在编写分布式系统的时候，就一定须要面对这个问题了。否则，很可能只有一台做事器出故障，全体数百台做事器的集群都事情不正常了。
除了做事器自己的内存、硬盘等故障，做事器之间的网络线路故障更加常见。而且这种故障还有可能是偶发的，或者是会自动规复的。面对这种问题，如果只是大略的把“涌现故障”的机器剔除出去，那还是不足的。由于网络可能过一下子就又规复了，而你的集群可能由于这一下的临时故障，丢失了过半的处理能力。
如何让分布式系统，在各种可能随时涌现故障的情形下，只管即便的自动掩护和坚持对外做事，成为了编写程序就要考虑的问题。由于要考虑到这种故障的情形，以是我们在设计架构的时候，也要故意识的预设一些冗余、自我掩护的功能。这些都不是产品上的业务需求，完备便是技能上的功能需求。能否在这方面提出对的需求，然后精确的实现，是做事器端程序员最主要的职责之一。
资源利用率优化
在分布式系统的集群，包含了很多个做事器，当这样一个集群的硬件承载能力到达极限的时候，最自然的想法便是增加更多的硬件。然而，一个软件系统不是那么随意马虎就可以通过“增加”硬件来提高承载性能的。由于软件在多个做事器上的事情，是须要有繁芜细致的折衷事情。在对一个集群扩容的时候，我们每每会要停掉全体集群的做事，然后修正各种配置，末了才能重新启动一个加入了新的做事器的集群。
由于在每个做事器的内存里，都可能会有一些用户利用的数据，以是如果冒然在运行的时候，就试图修正集群中供应做事的配置，很可能会造成内存数据的丢失和缺点。因此，运行时扩容在对无状态的做事上，是比较随意马虎的，比如增加一些Web做事器。但如果是在有状态的做事上，比如网络游戏，险些是不可能进行大略的运行时扩容的。
分布式集群除了扩容，还有缩容的需求。当用户人数低落，做事器硬件资源涌现空闲的时候，我们每每须要这些空闲的资源能利用起来，放到其余一些新的做事集群里去。缩容和集群中有故障须要容灾有一定类似之处，差异是缩容的韶光点和目标是可预期的。
由于分布式集群中的扩容、缩容，以及希望只管即便能在线操作，这导致了非常繁芜的技能问题须要处理，比如集群中相互干联的配置如何精确高效的修正、如何对有状态的进程进行操作、如何在扩容缩容的过程中担保集群中节点之间通信的正常。作为做事器端程序员，会须要花费大量的经历，来对多个进程的集群状态变革，造成的一系列问题进行专门的开拓。
软件做事内容更新
现在都盛行用敏捷开拓模式中的“迭代”，来表示一个做事不断的更新程序，知足新的需求，改动BUG。如果我们仅仅管理一台做事器，那么更新这一台做事器上的程序，是非常大略的：只要把软件包拷贝过去，然后修正下配置就好。但是如果你要对成百上千的做事器去做同样的操作，就不可能每台做事器登录上去处理。
做事器真个程序批量安装支配工具，是每个分布式系统开拓者都须要的。然而，我们的安装事情除了拷贝二进制文件和配置文件外，还会有很多其他的操作。比如打开防火墙、建立共享内存文件、修正数据库表构造、改写一些数据文件等等……乃至有一些还要在做事器上安装新的软件。
如果我们在开拓做事器端程序的时候，就考虑到软件更新、版本升级的问题，那么我们对付配置文件、命令行参数、系统变量的利用，就会预先做一定的方案，这能让安装支配的工具运行更快，可靠性更高。
除了安装支配的过程，还有一个主要的问题，便是不同版本间数据的问题。我们在升级版本的时候，旧版本程序天生的一些持久化数据，一样平常都是旧的数据格式的；而我们升级版本中如果涉及修正了数据格式，比如数据表结果，那么这些旧格式的数据，都要转换改写成新版本的数据格式才行。这导致了我们在设计数据构造的时候，就要考虑清楚这些表格的构造，是用最大略直接的表达办法，来让将来的修正更大略；还是一早就估量到修正的范围，专门预设一些字段，或者利用其他形式存放数据。
除了持久化数据以外，如果存在客户端程序（如受击APP），这些客户端程序的升级每每不能和做事器同步，如果升级的内容包含了通信协议的修正，这就造成了我们必须为不同的版本支配不同的做事器端系统的问题。为了避免同时掩护多套做事器，我们在软件开拓的时候，每每方向于所谓“版本兼容”的协议定义办法。而若何设计的协议才能有很好的兼容性，又是做事器端程序须要仔细考虑的问题。
数据统计和决策
一样平常来说，分布式系统的日志数据，都是被集中到一起，然后统一进行统计的。然而，当集群的规模到一定程度的时候，这些日志的数据量会变得非常胆怯。很多时候，统计一天的日志量，要花费打算机运行一天以上的韶光。以是，日志统计这项事情，也变成一门非常专业的活动。
经典的分布式统计模型，有Google的Map Reduce模型。这种模型既有灵巧性，也能利用大量做事器进行统计事情。但是缺陷是易用性每每不足好，由于这些数据的统计和我们常见的SQL数据表统计有非常大的差异，以是我们末了还是常常把数据丢到MySQL里面去做更细层面的统计。
由于分布式系统日志数量的弘大，以及日志繁芜程度的提高。我们变得必须要节制类似Map Reduce技能，才能真正的对分布式系统进行数据统计。而且我们还须要想办法提高统计事情的事情效率。
办理分布式系统可管理性的基本手段
目录做事（ZooKeeper）
分布式系统是一个由很多进程组成的整体，这个整体中每个成员部分，都会具备一些状态，比如自己的卖力模块，自己的负载情形，对某些数据的节制等等。而这些和其他进程干系的数据，在故障规复、扩容缩容的时候变得非常主要。
大略的分布式系统，可以通过静态的配置文件，来记录这些数据：进程之间的连接对应关系，他们的IP地址和端口，等等。然而一个自动化程度高的分布式系统，一定哀求这些状态数据都是动态保存的。这样才能让程序自己去做容灾和负载均衡的事情。
一些程序员会专门自己编写一个DIR做事（目录做事），来记录集群中进程的运行状态。集群中进程会和这个DIR做事产生自动关联，这样在容灾、扩容、负载均衡的时候，就可以自动根据这些DIR做事里的数据，来调度要求的发送目地，从而达到绕开故障机器、或连接到新的做事器的操作。
然而，如果我们只是用一个进程来充当这个事情。那么这个进程就成为了这个集群的“单点”——意思便是，如果这个进程故障了，那么全体集群可能都无法运行的。以是存放集群状态的目录做事，也须要是分布式的。幸好我们有ZooKeeper这个精良的开源软件，它正是一个分布式的目录做事区。
ZooKeeper可以大略启动奇数个进程，来形成一个小的目录做事集群。这个集群会供应给所有其他进程，进行读写其巨大的“配置树”的能力。这些数据不仅仅会存放在一个ZooKeeper进程中，而是会根据一套非常安全的算法，让多个进程来承载。这让ZooKeeper成为一个精良的分布式数据保存系统。
由于ZooKeeper的数据存储构造，是一个类似文件目录的树状系统，以是我们常常会利用它的功能，把每个进程都绑定到个中一个“分枝”上，然后通过检讨这些“分支”，来进行做事器要求的转发，就能大略的办理要求路由（由谁去做）的问题。其余还可以在这些“分支”上标记进程的负载的状态，这样负载均衡也很随意马虎做了。
目录做事是分布式系统中最关键的组件之一。而ZooKeeper是一个很好的开源软件，恰好是用来完成这个任务。
行列步队做事（ActiveMQ、ZeroMQ、Jgroups）
两个进程间如果要跨机器通讯，我们险些都会用TCP/UDP这些协议。但是直策应用网络API去编写跨进程通讯，是一件非常麻烦的事情。除了要编写大量的底层socket代码外，我们还要处理诸如：如何找到要交互数据的进程，如何保障数据包的完全性不至于丢失，如果通讯的对方进程挂掉了，或者进程须要重启该当若何等等这一系列问题。这些问题包含了容灾扩容、负载均衡等一系列的需求。
为理解决分布式系统进程间通讯的问题，人们总结出了一个有效的模型，便是“行列步队”模型。行列步队模型，便是把进程间的交互，抽象成对一个个的处理，而对付这些，我们都有一些“行列步队”，也便是管道，来对进行暂存。每个进程都可以访问一个或者多个行列步队，从里面读取消息（消费）或写入（生产）。由于有一个缓存的管道，我们可以放心的对进程状态进行变革。当进程起来的时候，它会自动去消费就可以了。而本身的路由，也是由存放的行列步队决定的，这样就把繁芜的路由问题，变成了如何管理静态的行列步队的问题。
一样平常的行列步队做事，都是供应大略的“投递”和“收取”两个接口，但是行列步队本身的管理办法却比较繁芜，一样平常来说有两种。一部分的行列步队做事，提倡点对点的行列步队管理办法：每对通信节点之间，都有一个单独的行列步队。这种做法的好处是不同来源的，可以互不影响，不会由于某个行列步队的过多，挤占了其他行列步队的缓存空间。而且处理的程序也可以自己来定义处理的优先级——先收取、多处理某个行列步队，而少处理其余一些行列步队。
但是这种点对点的行列步队，会随着集群的增长而增加大量的行列步队，这对付内存占用和运维管理都是一个繁芜的事情。因此更高等的行列步队做事，开始可以让不同的行列步队共享内存空间，而行列步队的地址信息、建立和删除，都采取自动化的手段。——这些自动化每每须要依赖上文所述的“目录做事”，来登记行列步队的ID对应的物理IP和端口等信息。比如很多开拓者利用ZooKeeper来充当行列步队做事的中心节点；而类似Jgropus这类软件，则自己掩护一个集群状态来存放各节点今昔。
其余一种行列步队，则类似一个公共的邮箱。一个行列步队做事便是一个进程，任何利用者都可以投递或收取这个进程中的。这样对付行列步队的利用更简便，运维管理也比较方便。不过这种用法下，任何一个从发出到处理，最少进过两次进程间通信，其延迟是相比拟较高的。并且由于没有预定的投递、收取约束，以是也比较随意马虎出BUG。
不管利用那种行列步队做事，在一个分布式做事器端系统中，进程间通讯都是必须要办理的问题，以是作为做事器端程序员，在编写分布式系统代码的时候，利用的最多的便是基于行列步队驱动的代码，这也直接导致了EJB3.0把“驱动的Bean”加入到规范之中。
事务系统
在分布式的系统中，事务是最难办理的技能问题之一。由于一个处理可能分布在不同的处理进程上，任何一个进程都可能涌现故障，而这个故障问题则须要导致一次回滚。这种回滚大部分又涉及多个其他的进程。这是一个扩散性的多进程通讯问题。要在分布式系统上办理事务问题，必须具备两个核心工具：一个是稳定的状态存储系统；其余一个是方便可靠的广播系统。
事务中任何一步的状态，都必须在全体集群中可见，并且还要有容灾的能力。这个需求，一样平常还是由集群的“目录做事”来承担。如果我们的目录做事足够健壮，那么我们可以把每步事务的处理状态，都同步写到目录做事上去。ZooKeeper再次在这个地方能发挥主要的浸染。
如果事务发生了中断，须要回滚，那么这个过程会涉及到多个已经实行过的步骤。大概这个回滚只须要在入口处回滚即可（加入那里有保存回滚所需的数据），也可能须要在各个处理节点上回滚。如果是后者，那么就须要集群中涌现非常的节点，向其他所有干系的节点广播一个“回滚！
事务ID是XXXX”这样的。这个广播的底层一样平常会由行列步队做事来承载，而类似Jgroups这样的软件，直接供应了广播做事。
虽然现在我们在谈论事务系统，但实际上分布式系统常常所需的“分布式锁”功能，也是这个别系可以同时完成的。所谓的“分布式锁”，也便是一种能让各个节点先检讨后实行的限定条件。如果我们有高效而单子操作的目录做事，那么这个锁状态实际上便是一种“单步事务”的状态记录，而回滚操作则默认是“停息操作，稍后再试”。这种“锁”的办法，比事务的处理更大略，因此可靠性更高，以是现在越来越多的开拓职员，乐意利用这种“锁”做事，而不是去实现一个“事务系统”。
自动支配工具（Docker）
由于分布式系统最大的需求，是在运行时（有可能须要中断做事）来进行做事容量的变更：扩容或者缩容。而在分布式系统中某些节点故障的时候，也须要新的节点来规复事情。这些如果还是像老式的做事器管理办法，通过填表、报告、进机房、装做事器、支配软件……这一套做法，那效率肯定是弗成。
在分布式系统的环境下，我们一样平常都是采取“池”的办法来管理做事。我们预先会申请一批机器，然后在某些机器上运行做事软件，其余一些则作为备份。显然我们这一批做事器不可能只为某一个业务做事，而是会供应多个不同的业务承载。那些备份的做事器，则会成为多个业务的通用备份“池”。随着业务需求的变革，一些做事器可能“退出”A做事而“加入”B做事。
这种频繁的做事变革，依赖高度自动的软件支配工具。我们的运维职员，该当节制这开拓职员供应的支配工具，而不是厚厚的手册，来进行这类运维操作。一些比较有履历的开拓团队，会统一所有的业务底层框架，以期大部分的支配、配置工具，都能用一套通用的系统来进行管理。而开源界，也有类似的考试测验，最广为人知的莫过于RPM安装包格式，然而RPM的打包办法还是太繁芜，不太符合做事器端程序的支配需求。所往后来又涌现了Chef为代表的，可编程的通用支配系统。
然而，当NoSQL兴起，大家溘然创造，实在很多互联网业务，其数据格式是如此的大略，很多时候根部不须要关系型数据库那种繁芜的表格。对付索引的哀求每每也只是根据主索引搜索。而更繁芜的全文搜索，本身数据库也做不到。以是现在相称多的高并发的互联网业务，首选NoSQL来做存储举动步伐。最早的NoSQL数据库有MangoDB等，现在最盛行的彷佛便是Redis了。乃至有些团队，把Redis也当成缓冲系统的一部分，实际上也是认可Redis的性能上风。
NoSQL除了更快、承载量更大以外，更主要的特点是，这种数据存储办法，只能按照一条索引来检索和写入。这样的需求约束，带来了分布上的好处，我们可以按这条主索引，来定义数据存放的进程（做事器）。这样一个数据库的数据，就能很方便的存放在不同的做事器上。在分布式系统的一定趋势下，数据存储层终于也找到了分布的方法。
为了管理大量的分布式做事器端进程，我们确实须要花很多功夫，其优化其支配管理的事情。统一做事器端进程的运行规范，是实现自动化支配管理的基本条件。我们可以根据“操作系统”作为规范，采取Docker技能；也可以根据“Web运用”作为规范，采取某些PaaS平台技能；或者自己定义一些更详细的规范，自己开拓完全的分布式打算平台。
日志做事（log4j）
做事器真个日志，一贯是一个既主要又随意马虎被忽略的问题。很多团队在刚开始的时候，仅仅把日志视为开拓调试、打消BUG的赞助工具。但是很快会创造，在做事运营起来之后，日志险些是做事器端系统，在运行时可以用来理解程序情形的唯一有效手段。
只管我们有各种profile工具，但是这些工具大部分都不适宜在正式运营的做事上开启，由于会严重降落其运行性能。以是我们更多的时候须要根据日志来剖析。只管日志从实质上，便是一行行的文本信息，但是由于其具有很大的灵巧性，以是会很受开拓和运维职员的重视。
日志本身从观点上，是一个很模糊的东西。你可以随便打开一个文件，然后写入一些信息。但是当代的做事器系统，一样平常都会对日志做一些标准化的需求规范：日志必须是一行一行的，这样比较方便日后的统计剖析；每行日志文本，都该当有一些统一的头部，比如日期韶光便是基本的需求；日志的输出该当是分等级的，比如fatal/error/warning/info/debug/trace等等，程序可以在运行时调度输出的等级，以便可以节省日志打印的花费；日志的头部一样平常还须要一些类似用户ID或者IP地址之类的头信息，用于快速查找定位过滤某一批日志记录，或者有一些其他的用于过滤缩小日志查看范围的字段，这叫做染色功能；日志文件还须要有“回滚”功能，也便是保持固定大小的多个文件，避免长期运行后，把硬盘写满。
由于有上述的各种需求，以是开源界供应了很多游戏的日志组件库，比如大名鼎鼎的log4j，以及成员浩瀚的log4X家族库，这些都是运用广泛而饱受好评的工具。
不过比拟日志的打印功能，日志的搜集和统计功能却每每比较随意马虎被忽略。作为分布式系统的程序员，肯定是希望能从一个集中节点，能搜集统计到全体集群日志情形。而有一些日志的统计结果，乃至希望能在很短韶光内反复获取，用来监控全体集群的康健情形。要做到这一点，就必须有一个分布式的文件系统，用来存放源源不断到达的日志（这些日志每每通过UDP协议发送过来）。而在这个文件系统上，则须要有一个类似Map Reduce架构的统计系统，这样才能对海量的日志信息，进行快速的统计以及报警。有一些开拓者会直策应用Hadoop系统，有一些则用Kafka来作为日志存储系统，上面再搭建自己的统计程序。
日志做事是分布式运维的仪表盘、潜望镜。如果没有一个可靠的日志做事，全体系统的运行状况可能会是失落控的。以是无论你的分布式系统节点是多还是少，必须花费主要的精力和专门的开拓韶光，去建立一个对日志进行自动化统计剖析的系统。
分布式系统在开拓效率上造成的问题和解决思路
根据上文所述，分布式系统在业务需求的功能以为，还须要增加额外很多非功能的需求。这些非功能需求，每每都是为了一个多进程系统能稳定可靠运行而去设计和实现的。这些“额外”的事情，一样平常都会让你的代码更加繁芜，如果没有很好的工具，就会让你的开拓效率严重低落。
微做事框架：EJB、WebService
当我们在谈论做事器端软件分布的时候，做事进程之间的通信就难免了。然而做事进程间的通讯，并不是大略的收发就能完成的。这里还涉及了的路由、编码解码、做事状态的读写等等。如果全体流程都由自己开拓，那就太累人了。
以是业界很早就推出了各种分布式的做事器端开拓框架，最著名的便是“EJB”——企业JavaBean。但凡冠以“企业”的技能，每每都是分布式下所需的部分，而EJB这种技能，也是一种分布式工具调用的技能。我们如果须要让多个进程互助完成任务，则须要把任务分解到多个“类”上，然后这些“类”的工具就会在各个进程容器中存活，从而协作供应做事。这个过程很“面向工具”。每个工具都是一个“微做事”，可以供应某些分布式的功能。
而其余一些系统，则走向学习互联网的基本模型：HTTP。以是就有了各种的WebService框架，从开源的到商业软件，都有各自的WebService实现。这种模型，把繁芜的路由、编解码等操作，简化成常见的一次HTTP操作，是一种非常有效的抽象。开拓职员开拓和支配多个WebService到Web做事器上，就完成了分布式系统的搭建。
不管我们是学习EJB还是WebService，实际上我们都须要简化分布式调用的繁芜程度。而分布式调用的繁芜之处，便是由于须要把容灾、扩容、负载均衡等功能，领悟到跨进程调用里。以是利用一套通用的代码，来为所有的跨进程通讯（调用），统一的实现容灾、扩容、负载均衡、过载保护、状态缓存命中等等非功能性需求，能大大简化全体分布式系统的繁芜性。
一样平常我们的微做事框架，都会在路由阶段，对全体集群所有节点的状态进行不雅观察，如哪些地址上运行了哪些做事的进程，这些做事进程的负载状况如何，是否可用，然后对付有状态的做事，还会利用类似同等性哈希的算法，去只管即便试图提高缓存的命中率。当集群中的节点状态发生变革的时候，微做事框架下的所有节点，都能尽快的得到这个变革的情形，重新根据当前状态，重新方案往后的做事路由方向，从而实现自动化的路由选择，避开那些负载过高或者失落效的节点。
有一些微做事框架，还供应了类似IDL转换成“骨架”、“桩”代码的工具，这样在编写远程调用程序的时候，完备无需编写那些繁芜的网络干系的代码，所有的传输层、编码层代码都自动的编写好了。这方面EJB、Facebook的Thrift，Google gRPC都具备这种能力。在具备代码天生能力的框架下，我们编写一个分布式下可用的功能模块（可能是一个函数或者是一个类），就彷佛编写一个本地的函数那样大略。这绝对是分布式系统下非常主要的效率提升。
异步编程工具：协程、Futrue、Lamda
在分布式系统中编程，你不可避免的会碰到大量的“回调”型API。由于分布式系统涉及非常多的网络通信。任何一个业务命令，都可能被分解到多个进程，通过多次网络通信来组合完成。由于异步非壅塞的编程模型大行其道，以是我们的代码也每每动不动就要碰到“回调函数”。然而，回调这种异步编程模型，是一种非常不利于代码阅读的编程方法。由于你无法从头到尾的阅读代码，去理解一个业务任务，是若何被逐步的完成的。属于一个业务任务的代码，由于多次的非壅塞回调，从而被分割成很多个回调函数，在代码的各处被串接起来。
更有甚者，我们有时候会选择利用“不雅观察者模式”，我们会在一个地方注册大量的“事宜-相应函数”，然后在所有须要回调的地方，都发出一个事宜。——这样的代码，比纯挚的注册回调函数更难明得。由于事宜对应的相应函数，常日在发失事宜处是无法找到的。这些函数永久都会放在其余的一些文件里，而且有时候这些函数还会在运行时改变。而事宜名字本身，也每每是匪夷所思难以理解的，由于当你的程序须要成千上百的事宜的时候，起一个随意马虎理解名符实在的名字，险些是不可能的。
为理解决回调函数这种对付代码可读性的毁坏浸染，人们发明了很多不同的改进方法。个中最著名的是“协程”。我们以前常常习气于用多线程来办理问题，以是非常熟习以同步的办法去写代码。协程正是延续了我们的这一习气，但不同于多线程的是，协程并不会“同时”运行，它只是在须要壅塞的地方，用Yield()切换出去实行其他协程，然后当壅塞结束后，用Resume()回到刚刚切换的位置连续往下实行。这相称于我们可以把回调函数的内容，接到Yield()调用的后面。这种编写代码的方法，非常类似于同步的写法，让代码变得非常易读。但是唯一的缺陷是，Resume()的代码还是须要在所谓“主线程”中运行。用户必须自己从壅塞规复的时候，去调用Resume()。协程其余一个缺陷，是须要做栈保存，在切换到其他协程之后，栈上的临时变量，也都须要额外占用空间，这限定了协程代码的写法，让开发者不能用太大的临时变量。
而其余一种改进回调函数的写法，每每叫做Future/Promise模型。这种写法的基本思路，便是“一次性把所有回调写到一起”。这是一个非常实用的编程模型，它没有让你去彻底干掉回调，而是让你可以把回调从分散各处，集中到一个地方。在同一段代码中，你可以清晰的看到各个异步的步骤是如何串接、或者并行实行的。
末了说一下lamda模型，这种写法盛行于js措辞的广泛运用。由于在其他措辞中，定一个回调函数是非常费事的：Java措辞要设计一个接口然后做一个实现，切实其实是五星级的费事程度；C/C++支持函数指针，算是比较大略，但是也很随意马虎导致代码看不懂；脚本措辞相对好一些，也要定义个函数。而直接在调用回调的地方，写回调函数的内容，是最方便开拓，也比较利于阅读的。更主要的，lamda一样平常意味着闭包，也便是说，这种回调函数的调用栈，是被分别保存的，很多须要在异步操作中，须要建立一个类似“会话池”的状态保存变量，在这里都是不须要的，而是可以自然生效的。这一点和协程有异曲同工之妙。
不管利用哪一种异步编程办法，其编码的繁芜度，都是一定比同步调用的代码高的。以是我们在编写分布式做事器代码的时候，一定要仔细方案代码构造，避免涌现随意添加功能代码，导致代码的可读性被毁坏的情形。不可读的代码，便是不可掩护的代码，而大量异步回调的做事器端代码，是更随意马虎涌现这种情形的。
云做事模型：IaaS/PaaS/SaaS
在繁芜的分布式系统开拓和利用过程中，如何对大量做事器和进程的运维，一贯是一个贯穿个中的问题。不管是利用微做事框架、还是统一的支配工具、日志监控做事，都是由于大量的做事器，要集中的管理，是非常不随意马虎的。这里背后的缘故原由，紧张是大量的硬件和网络，把逻辑上的打算能力，切割成很多小块。
随着打算机运算能力的提升，涌现的虚拟化技能，却能把被分割的打算单元，更智能的统一起来。个中最常见的便是IaaS技能：当我们可以用一个做事器硬件，运行多个虚拟的做事器操作系统的时候，我们须要掩护的硬件数量就会成倍的低落。而PaaS技能的盛行，让我们可以为某一种特定的编程模型，统一的进行系统运行环境的支配掩护。而不须要再一台台做事器的去装操作系统、配置运行容器、上传运行代码和数据。在没有统一的PaaS之前，安装大量的MySQL数据库，曾经是花费大量韶光
和精力的事情。
当我们的业务模型，成熟到可以抽象为一些固定的软件时，我们的分布式系统就会变得更加易用。我们的打算能力不再是代码和库，而是一个个通过网络供应做事的云——SaaS，这样利用者根本来掩护、支配的事情都不须要，只要申请一个接口，填上预期的容量额度，就能直策应用了。这不仅节省了大量开拓对应功能的事宜，还即是把大量的运维事情，都交出去给SaaS的掩护者——而他们做这样的掩护会更加专业。
在运维模型的进化上，从IaaS到PaaS到SaaS，其运用范围大概是越来越窄，但利用的便利性却成倍的提高。这也证明了，软件劳动的事情，也是可以通过分工，向更专业化、更细分的方向去提高效率。
总结
总结分布式系统问题的办理路径
构建分布式系统的目的
提高整体架构的吞吐量，做事更多的并发和流量。
大流量处理，通过集群技能把大规模并发要求的负载分散到不同的机器上。
提高系统的稳定性，让系统的可用性更高。
关键业务保护。提高后台做事的可用性，把故障隔离起来阻挡多米诺骨牌效应(雪崩效应)，如果流量过大，须要对业务降级，以保护关键业务
提高系统的性能
缓存系统：缓存分区、缓存更新、缓存命中
负载均衡系统(网关系统)：负载均衡、做事路由、做事创造
异步调用：行列步队、持久、异步事务
数据镜像：数据同步、读写分流、数据同等性
数据分区：分区策略、数据访问层、数据同等性
缓存系统
可以提高快速访问能力。
从前端浏览器、网络、后端做事、底层数据库、文件系统、硬盘和CPU，全都有缓存。
对付分布式缓存系统，首先须要一个缓存集群，个中须要一个Proxy来做缓存的分片和路由
负载均衡
是做水平扩展的关键技能。
异步调用
通过行列步队来对要求做排队处理，把前端要求进行削峰，后端要求根据自己的处理速率来处理要求。
优点：增加系统的吞吐量
缺陷：实时性比较差，同时还会引入丢失的问题，以是须要对进行持久化，这会造成有状态的节点，从而增加做事调度的难度。
数据分区和数据镜像
把数据按照一定的办法分成多个区，不同的数据来分担不同区的流量，这须要一个数据路由的中间件，会导致跨库Join和跨库事务非常繁芜。
数据镜像：把多个数据库备份，多个节点可以供应数据读写功能，节点间在内部实现数据同步。缺陷：数据同等性问题。
在初期利用读写分离的数据镜像办法，后期采取分库分表办法。
提高系统稳定性
做事拆分(做事管理)：做事调用、做事依赖、做事隔离
做事冗余(做事调度)：弹性伸缩、故障转移、做事创造
限流降级：异步队列、降级掌握、做事熔断
高可用架构：多租户系统、灾备多活、高可用做事
高可用运维：全栈监控、DevOps、自动化运维
做事拆分
隔离故障
重用做事模块
做事拆分完之后，会引入做事调用间的依赖问题。
做事冗余
去除单点故障，并可以支持做事的弹性伸缩以及故障转移。
对付一些有状态的做事来说，冗余这些有状态的做事会带来更高的繁芜性。
当个中一个进行弹性伸缩时，须要考虑数据的复制或重新分片，迁移的时候还要迁移数据到其他机器上。
限流降级
当系统流量超过系统承载时，只能通过限流或者功能降级的办法来处理。
高可用架构
紧张时为了不涌现单点故障。
高可用运维
DevOps中的CI(持续集成)/CD(持续支配)。
该当有一条很流畅的软件发布管线，包括足够的自动化测试，还可以做好相应的灰度发布，以及线上系统的自动化掌握。
