高性能服务器架构想路「不仅是思路」

在服务器端法式开发领域，性能问题一直是备受关注的重点。业界有大量的框架、组件、类库都是以性能为卖点而广为人知。然而，服务器端法式在性能问题上应该有何种基本思路，这个却很少被这些项目的文档提及。

本文正式希望先容服务器端解决性能问题的基本计谋和经典实践，并分为几个部门来说明：1.缓存计谋的观点和实例2.缓存计谋的难点：差别特点的缓存数据的清理机制3.漫衍计谋的观点和实例4.漫衍计谋的难点：共享数据宁静性与代码庞大度的平衡缓存缓存计谋的观点我们提到服务器端性能问题的时候，往往会混淆不清。因为当我们会见一个服务器时，泛起服务卡住不能获得数据，就会认为是“性能问题”。可是实际上这个性能问题可能是有差别的原因，体现出来都是针对客户请求的延迟很长甚至中断。

我们来看看这些原因有哪些：第一个是所谓并发数不足，也就是同时请求的客户过多，导致凌驾容纳能力的客户被拒绝服务，这种情况往往会因为服务器内存耗尽而导致的；第二个是处置惩罚延迟过长，也就是有一些客户的请求处置惩罚时间已经凌驾用户可以忍受的长度，这种情况经常体现为CPU占用满额100%。我们在服务器开发的时候，最常用到的有下面这几种硬件：CPU、内存、磁盘、网卡。其中CPU是代表盘算机处置惩罚时间的，硬盘的空间一般很大，主要是读写磁盘会带来比力大的处置惩罚延迟，而内存、网卡则是受存储、带宽的容量限制的。

所以当我们的服务器泛起性能问题的时候，就是这几个硬件某一个甚至几个都泛起负荷占满的情况。这四个硬件的资源一般可以抽象成两类：一类是时间资源，好比CPU和磁盘读写；一类是空间资源，好比内存和网卡带宽。所以当我们的服务器泛起性能问题，有一个最基本的思路，就是——时间空间转换。

我们可以举几个例子来说明这个问题。水坝就是用水库空间来换流量时间的例子当我们会见一个WEB的网站的时候，输入的URL地址会被服务器酿成对磁盘上某个文件的读取。

如果有大量的用户会见这个网站，每次的请求都市造成对磁盘的读操作，可能会让磁盘不堪重负，导致无法即时读取到文件内容。可是如果我们写的法式，会把读取过一次的文件内容，长时间的生存在内存中，当有另外一个对同样文件的读取时，就直接从内存中把数据返回给客户端，就无需去让磁盘读取了。由于用户会见的文件往往很集中，所以大量的请求可能都能从内存中找到生存的副本，这样就能大大提高服务器能承载的会见量了。这种做法，就是用内存的空间，换取了磁盘的读写时间，属于用空间换时间的计谋。

利便面预先缓存了大量的烹饪操作举另外一个例子：我们写一个网络游戏的服务器端法式，通过读写数据库来提供玩家资料存档。如果有大量玩家进入这个服务器，肯定有许多玩家的数据资料变化，好比升级、获得武器等等，这些通过读写数据库来实现的操作，可能会让数据库历程负荷过重，导致玩家无法即时完成游戏操作。

我们会发现游戏中的读操作，大部门都是针是对一些静态数据的，好比游戏中的关卡数据、武器道具的详细信息；而许多写操作，实际上是会笼罩的，好比我的履历值，可能每打一个怪都市增加几十点，可是最后记载的只是最终的一个履历值，而不会记载下打怪的每个历程。所以我们也可以使用时空转换的计谋来提供性能：我们可以用内存，把那些游戏中的静态数据，都一次性读取并生存起来，这样每次读这些数据，都和数据库无关了；而玩家的资料数据，则不是每次变化都去写数据库，而是先在内存中保持一个玩家数据的副本，所有的写操作都先去写内存中的结构，然后定期再由服务器主动写回到数据库中，这样可以把多次的写数据库操作酿成一次写操作，也能节约许多写数据库的消耗。这种做法也是用空间换时间的计谋。

拼装家具很省运输空间，可是安装很费时最后说说用时间换空间的例子：假设我们要开发一个企业通讯录的数据存储系统，客户要求我们能生存下通讯录的每次新增、修改、删除操作，也就是这个数据的所有变换历史，以便可以让数据回退到任何一个已往的时间点。那么我们最简朴的做法，就是这个数据在任何变化的时候，都拷贝一份副本。

可是这样会很是的浪费磁盘空间，因为这个数据自己变化的部门可能只有很小一部门，可是要拷贝的副本可能很大。这种情况下，我们就可以在每次数据变化的时候，都记下一条记载，内容就是数据变化的情况：插入了一条内容是某某的联系方法、删除了一条某某的联系方法……，这样我们记载的数据，仅仅就是变化的部门，而不需要拷贝许多份副本。当我们需要恢复到任何一个时间点的时候，只需要按这些记载依次对数据修改一遍，直到指定的时间点的记载即可。

这个恢复的时间可能会有点长，可是却可以大大节约存储空间。这就是用CPU的时间来换磁盘的存储空间的计谋。我们现在常见的MySQL InnoDB日志型数据表，以及SVN源代码存储，都是使用这种计谋的。另外，我们的Web服务器，在发送HTML文件内容的时候，往往也会先用ZIP压缩，然后发送给浏览器，浏览器收到后要先解压，然后才气显示，这个也是用服务器和客户端的CPU时间，来换取网络带宽的空间。

在我们的盘算机体系中，缓存的思路险些无处不在，好比我们的CPU内里就有1级缓存、2级缓存，他们就是为了用这些快速的存储空间，换取对内存这种相对比力慢的存储空间的等候时间。我们的显示卡内里也带有大容量的缓存，他们是用来存储显示图形的运算效果的。通往大空间的郊区路上容易交通堵塞缓存的本质，除了让“已经处置惩罚过的数据，不需要重复处置惩罚”以外，另有“以快速的数据存储读写，取代较慢速的存储读写”的计谋。

我们在选择缓存计谋举行时空转换的时候，必须明确我们要转换的时间和空间是否合理，是否能到达效果。好比早期有一些人会把WEB文件缓存在漫衍式磁盘上（例如NFS），可是由于通过网络会见磁盘自己就是一个比力慢的操作，而且还会占用可能就不丰裕的网络带宽空间，导致性能可能变得更慢。在设计缓存机制的时候，我们还容易遇到另外一个风险，就是对缓存数据的编程处置惩罚问题。

如果我们要缓存的数据，并不是完全无需处置惩罚直接读写的，而是需要读入内存后，以某种语言的结构体或者工具来处置惩罚的，这就需要涉及到“序列化”和“反序列化”的问题。如果我们接纳直接拷贝内存的方式来缓存数据，当我们的这些数据需要跨历程、甚至跨语言会见的时候，会泛起那些指针、ID、句柄数据的失效。因为在另外一个历程空间里，这些“标志型”的数据都是不存在的。

因此我们需要更深入的对数据缓存的方法，我们可能会使用所谓深拷贝的方案，也就是随着那些指针去找出目的内存的数据，一并拷贝。一些更现代的做法，则是使用所谓序列化方案来解决这个问题，也就是用一些明确界说了的“拷贝方法”来界说一个结构体，然后用户就能明确的知道这个数据会被拷贝，直接取消了指针之类的内存地址数据的存在。好比著名的Protocol Buffer就能很利便的举行内存、磁盘、网络位置的缓存；现在我们常见的JSON，也被一些系统用来作为缓存的数据花样。可是我们需要注意的是，缓存的数据和我们法式真正要操作的数据，往往是需要举行一些拷贝和运算的，这就是序列化和反序列化的历程，这个历程很快，也有可能很慢。

所以我们在选择数据缓存结构的时候，必须要注意其转换时间，否则你缓存的效果可能被这些数据拷贝、转换消耗去许多，严重的甚至比不缓存更差。一般来说，缓存的数据越解决使用时的内存结构，其转换速度就越快，在这点上，Protocol Buffer接纳TLV编码，就比不上直接memcpy的一个C结构体，可是比编码成纯文本的XML或者JSON要来的更快。

因为编解码的历程往往要举行庞大的查表映射，列表结构等操作。缓存计谋的难点虽然使用缓存思想似乎是一个很简朴的事情，可是缓存机制却有一个焦点的难点，就是——缓存清理。我们所说的缓存，都是生存一些数据，可是这些数据往往是会变化的，我们要针对这些变化，清理掉生存的“脏”数据，却可能不是那么容易。

首先我们来看看最简朴的缓存数据——静态数据。这种数据往往在法式的运行时是不会变化的，好比Web服务器内存中缓存的HTML文件数据，就是这种。事实上，所有的不是由外部用户上传的数据，都属于这种“运行时静态数据”。一般来说，我们对这种数据，可以接纳两种建设缓存的方法：一是法式一启动，就一股脑把所有的静态数据从文件或者数据库读入内存；二就是法式启动的时候并不加载静态数据，而是等有用户会见相关数据的时候，才去加载，这也就是所谓lazy load的做法。

第一种方法编程比力简朴，法式的内存启动后就稳定了，不太容易泛起内存毛病（如果加载的缓存太多，法式在启动后连忙会因内存不足而退出，比力容易发现问题）；第二种方法法式启动很快，但要对缓存占用的空间有所限制或者计划，否则如果要缓存的数据太多，可能会耗尽内存，导致在线服务中断。一般来说，静态数据是不会“脏”的，因为没有用户会去写缓存中的数据。

可是在实际事情中，我们的在线服务往往会需要“连忙”变换一些缓存数据。好比在门户网站上公布了一条新闻，我们会希望连忙让所有会见的用户都看到。

按最简朴的做法，我们一般只要重启一下服务器历程，内存中的缓存就会消失了。对于静态缓存的变化频率很是低的业务，这样是可以的，可是如果是新闻网站，就不能每隔几分钟就重启一下WEB服务器历程，这样会影响大量在线用户的会见。

常见的解决这类问题有两种处置惩罚计谋：第一种是使用控制下令。简朴来说，就是在服务器历程上，开通一个实时的下令端口，我们可以通过网络数据包（如UDP包），或者Linux系统信号（如kill SIGUSR2历程号）之类的手段，发送一个下令消息给服务器历程，让历程开始清理缓存。

这种清理可能执行的是最简朴的“全部清理”，也有的可以细致一点的，让下令消息中带有“想清理的数据ID”这样的信息，好比我们发送给WEB服务器的清理消息网络包中会带一个字符串URL，表现要清理哪一个HTML文件的缓存。这种做法的利益是清理的操作很精准，可以明确的控制清理的时间和数据。可是缺点就是比力繁琐，手工去编写发送这种下令很烦人，所以一般我们会把清理缓存下令的事情，编写到上传静态数据的工具当中，好比联合到网站的内容公布系统中，一旦编辑提交了一篇新的新闻，公布系统的法式就自动的发送一个清理消息给WEB服务器。第二种是使用字段判断逻辑。

也就是服务器历程，会在每次读取缓存前，凭据一些特征数据，快速的判断内存中的缓存和源数据内容，是否有纷歧致（是否脏）的地方，如果有纷歧致的地方，就自动清理这条数据的缓存。这种做法会消耗一部门CPU，可是就不需要人工去处置惩罚清理缓存的事情，自动化水平很高。现在我们的浏览器和WEB服务器之间，就有用这种机制：检查文件MD5；或者检查文件最后更新时间。详细的做法，就是每次浏览器提倡对WEB服务器的请求时，除了发送URL给服务器外，还会发送一个缓存了此URL对应的文件内容的MD5校验串、或者是此文件在服务器上的“最后更新时间”（这个校验串和“最后更新时间”是第一次获的文件时一并从服务器获得的）；服务器收到之后，就会把MD5校验串或者最后更新时间，和磁盘上的目的文件举行对比，如果是一致的，说明这个文件没有被修悔改（缓存不是“脏”的），可以直接使用缓存。

否则就会读取目的文件返回新的内容给浏览器。这种做法对于服务器性能是有一定消耗的，所以如果往往我们还会搭配其他的缓存清理机制来用，好比我们会在设置一个“超时检查”的机制：就是对于所有的缓存清理检查，我们都简朴的看看缓存存在的时间是否“超时”了，如果凌驾了，才举行下一步的检查，这样就不用每次请求都去算MD5或者看最后更新时间了。

可是这样就存在“超时”时间内缓存变脏的可能性。WEB服务器静态缓存例子上面说了运行时静态的缓存清理，现在说说运行时变化的缓存数据。

在服务器法式运行期间，如果用户和服务器之间的交互，导致了缓存的数据发生了变化，就是所谓“运行时变化缓存”。好比我们玩网络游戏，登录之后的角色数据就会从数据库里读出来，进入服务器的缓存（可能是堆内存或者memcached、共享内存），在我们不停举行游戏操作的时候，对应的角色数据就会发生修改的操作，这种缓存数据就是“运行时变化的缓存”。这种运行时变化的数据，有读和写两个方面的清理问题：由于缓存的数据会变化，如果另外一个历程从数据库读你的角色数据，就会发现和当前游戏里的数据纷歧致；如果服务器历程突然竣事了，你在游戏里升级，或者捡道具的数据可能会从内存缓存中消失，导致你白忙活了半天，这就是没有回写（缓存写操作的清理）导致的问题。

这种情况在电子商务领域也很常见，最典型的就是火车票网上购置的系统，火车票数据缓存在内存必须有合适的清理机制，否则让两个买了同一张票就贫苦了，但如果不缓存，大量用户同时抢票，服务器也应对不外来。因此在运行时变化的数据缓存，应该有一些特此外缓存清理计谋。在实际运行业务中，运行变化的数据往往是凭据使用用户的增多而增多的，因此首先要思量的问题，就是缓存空间不够的可能性。

我们不太可能把全部数据都放到缓存的空间里，也不行能清理缓存的时候就全部数据一起清理，所以我们一般要对数据举行支解，这种支解的计谋常见的有两种：一种是按重要级来支解，一种是按使用部门支解。先举例说说“按重要级支解”，在网络游戏中，同样是角色的数据，有些数据的变化可能会每次修改都连忙回写到数据库（清理写缓存），其他一些数据的变化会延迟一段时间，甚至有些数据直到角色退出游戏才回写，如玩家的品级变化（升级了），武器装备的获得和消耗，这些玩家很是看重的数据，基本上会连忙回写，这些就是所谓最重要的缓存数据。而玩家的履历值变化、当前HP、MP的变化，就会延迟一段时间才写，因为就算丢失了缓存，玩家也不会太过关注。

最后有些好比玩家在房间（地域）里的X/Y坐标，对话谈天的记载，可能会退出时回写，甚至不回写。这个例子说的是“写缓存”的清理，下面说说“读缓存”的按重要级支解清理。

如果我们写一个网店系统，内里容纳了许多产物，这些产物有一些会被用户频繁检索到，比力热销，而另外一些商品则没那么热销。热销的商品的余额、销量、评价都市比力频繁的变化，而滞销的商品则变化很少。

所以我们在设计的时候，就应该根据差别商品的会见频繁水平，来决议缓存哪些商品的数据。我们在设计缓存的结构时，就应该构建一个可以统计缓存读写次数的指标，如果有些数据的读写频率过低，或者空闲（没有人读、写缓存）时间超长，缓存应该主动清理掉这些数据，以便其他新的数据能进入缓存。这种计谋也叫做“冷热交流”计谋。实现“冷热交流”的计谋时，关键是要界说一个合理的冷热统盘算法。

一些牢固的指标和算法，往往并不能很好的应对差别硬件、差别网络情况下的变化，所以现在人们普遍会用一些动态的算法，如Redis就接纳了5种，他们是：1.凭据逾期时间，清理最长时间没用过的2.凭据逾期时间，清理即将逾期的3.凭据逾期时间，任意清理一个4.无论是否逾期，随机清理5.无论是否逾期，凭据LRU原则清理：所谓LRU，就是Least Recently Used，最近最久未使用过。这个原则的思想是：如果一个数据在最近一段时间没有被会见到，那么在未来他被会见的可能性也很小。

LRU是在操作系统中很常见的一种原则，好比内存的页面置换算法（也包罗FIFO,LFU等），对于LRU的实现，还是很是有技巧的，可是本文就不详细去说明如何实现，留待大家上网搜索“LRU”关键字学习。数据缓存的清理计谋其实远不止上面所说的这些，要用好缓存这个武器，就要仔细研究需要缓存的数据特征，他们的读写漫衍，数据之中的差异。然后最大化的使用业务领域的知识，来设计最合理的缓存清理计谋。这个世界上不存在万能的优化缓存清理计谋，只存在针对业务领域最优化的计谋，这需要我们法式员深入明白业务领域，去发现数据背后的纪律。

漫衍漫衍计谋的观点任何的服务器的性能都是有极限的，面临海量的互联网会见需求，是不行能单靠一台服务器或者一个CPU来负担的。所以我们一般都市在运行时架构设计之初，就思量如何能使用多个CPU、多台服务器来分管负载，这就是所谓漫衍的计谋。漫衍式的服务器观点很简朴，可是实现起来却比力庞大。

因为我们写的法式，往往都是以一个CPU，一块内存为基础来设计的，所以要让多个法式同时运行，而且协调运作，这需要更多的底层事情。首先泛起能支持漫衍式观点的技术是多历程。

在DOS时代，盘算机在一个时间内只能运行一个法式，如果你想一边写法式，同时一边听mp3，都是不行能的。可是，在WIN95操作系统下，你就可以同时开多个窗口，背后就是同时在运行多个法式。

在Unix和厥后的Linux操作系统内里，都普遍支持了多历程的技术。所谓的多历程，就是操作系统可以同时运行我们编写的多个法式，每个法式运行的时候，都似乎自己独占着CPU和内存一样。在盘算机只有一个CPU的时候，实际上盘算时机分时复用的运行多个历程，CPU在多个历程之间切换。

可是如果这个盘算机有多个CPU或者多个CPU核，则会真正的有几个历程同时运行。所以历程就似乎一个操作系统提供的运行时“法式盒子”，可以用来在运行时，容纳任何我们想运行的法式。

当我们掌握了操作系统的多历程技术后，我们就可以把服务器上的运行任务，分为多个部门，然后划分写到差别的法式里，使用上多CPU或者多核，甚至是多个服务器的CPU一起来负担负载。多历程使用多CPU这种划分多个历程的架构，一般会有两种计谋：一种是按功效来划分，好比卖力网络处置惩罚的一个历程，卖力数据库处置惩罚的一个历程，卖力盘算某个业务逻辑的一个历程。另外一种计谋是每个历程都是同样的功效，只是分管差别的运算任务而已。

使用第一种计谋的系统，运行的时候，直接凭据操作系统提供的诊断工具，就能直观的监测到每个功效模块的性能消耗，因为操作系统提供历程盒子的同时，也能提供对历程的全方位的监测，好比CPU占用、内存消耗、磁盘和网络I/O等等。可是这种计谋的运维部署会稍微庞大一点，因为任何一个历程没有启动，或者和其他历程的通信地址没设置好，都可能导致整个系统无法运作；而第二种漫衍计谋，由于每个历程都是一样的，这样的安装部署就很是简朴，性能不够就多找几个机械，多启动几个历程就完成了，这就是所谓的平行扩展。现在比力庞大的漫衍式系统，会联合这两种计谋，也就是说系统既按一些功效划分出差别的详细功效历程，而这些历程又是可以平行扩展的。

固然这样的系统在开发和运维上的庞大度，都是比单独使用“按功效划分”和“平行划分”要更高的。由于要治理大量的历程，传统的依靠设置文件来设置整个集群的做法，会显得越来越不实用：这些运行中的历程，可能和其他许多历程发生通信关系，当其中一个历程变换通信地址时，势必影响所有其他历程的设置。所以我们需要集中的治理所有历程的通信地址，当有变化的时候，只需要修改一个地方。

在大量历程构建的集群中，我们还会遇到容灾和扩容的问题：当集群中某个服务器泛起故障，可能会有一些历程消失；而当我们需要增加集群的承载能力时，我们又需要增加新的服务器以及历程。这些事情在恒久运行的服务器系统中，会是比力常见的任务，如果整个漫衍系统有一个运行中的中心历程，能自动化的监测所有的历程状态，一旦有历程加入或者退出集群，都能即时的修改所有其他历程的设置，这就形成了一套动态的多历程治理系统。开源的ZooKeeper给我们提供了一个可以充当这种动态集群中心的实现方案。由于ZooKeeper自己是可以平行扩展的，所以它自己也是具备一定容灾能力的。

现在越来越多的漫衍式系统都开始使用以ZooKeeper为集群中心的动态历程治理计谋了。动态历程集群在挪用多历程服务的计谋上，我们也会有一定的计谋选择，其中最著名的计谋有三个：一个是动态负载平衡计谋；一个是读写分散计谋；一个是一致性哈希计谋。动态负载平衡计谋，一般会搜集多个历程的服务状态，然后挑选一个负载最轻的历程来分发服务，这种计谋对于比力同质化的历程是比力合适的。读写分散计谋则是关注对持久化数据的性能，好比对数据库的操作，我们会提供一批历程专门用于提供读数据的服务，而另外一个（或多个）历程用于写数据的服务，这些写数据的历程都市每次写多份拷贝到“读服务历程”的数据区（可能就是单独的数据库），这样在对外提供服务的时候，就可以提供更多的硬件资源。

一致性哈希计谋是针对任何一个任务，看看这个任务所涉及读写的数据，是属于哪一片的，是否有某种可以缓存的特征，然后按这个数据的ID或者特征值，举行“一致性哈希”的盘算，分管给对应的处置惩罚历程。这种历程挪用计谋，能很是的使用上历程内的缓存（如果存在），好比我们的一个在线游戏，由100个历程负担服务，那么我们就可以把游戏玩家的ID，作为一致性哈希的数据ID，作为历程挪用的KEY，如果目的服务历程有缓存游戏玩家的数据，那么所有这个玩家的操作请求，都市被转到这个目的服务历程上，缓存的掷中率大大提高。

而使用“一致性哈希”，而不是其他哈希算法，或者取模算法，主要是思量到，如果服务历程有一部门因故障消失，剩下的服务历程的缓存依然可以有效，而不会整个集群所有历程的缓存都失效。详细有兴趣的读者可以搜索“一致性哈希”一探究竟。以多历程使用大量的服务器，以及服务器上的多个CPU焦点，是一个很是有效的手段。

可是使用多历程带来的分外的编程庞大度的问题。一般来说我们认为最好是每个CPU焦点一个历程，这样能最好的使用硬件。

如果同时运行的历程过多，操作系统会消耗许多CPU时间在差别历程的切换历程上。可是，我们早期所获得的许多API都是阻塞的，好比文件I/O，网络读写，数据库操作等。

如果我们只用有限的历程来执行带这些阻塞操作的法式，那么CPU会大量被浪费，因为阻塞的API会让有限的这些历程停着等候效果。那么，如果我们希望能处置惩罚更多的任务，就必须要启动更多的历程，以便充实使用那些阻塞的时间，可是由于历程是操作系统提供的“盒子”，这个盒子比力大，切换泯灭的时间也比力多，所以大量并行的历程反而会无谓的消耗服务器资源。

加上历程之间的内存一般是隔离的，历程间如果要交流一些数据，往往需要使用一些操作系统提供的工具，好比网络socket，这些都市分外消耗服务器性能。因此，我们需要一种切换价格更少，通信方式更便捷，编程方法更简朴的并行技术，这个时候，多线程技术泛起了。

在历程盒子内里的线程盒子多线程的特点是切换价格少，可以同时会见内存。我们可以在编程的时候，任意让某个函数放入新的线程去执行，这个函数的参数可以是任何的变量或指针。如果我们希望和这些运行时的线程通信，只要读、写这些指针指向的变量即可。

在需要大量阻塞操作的时候，我们可以启动大量的线程，这样就能较好的使用CPU的空闲时间；线程的切换价格比历程低得多，所以我们能使用的CPU也会多许多。线程是一个比历程更小的“法式盒子”，他可以放入某一个函数挪用，而不是一个完整的法式。一般来说，如果多个线程只是在一个历程内里运行，那其实是没有使用到多核CPU的并行利益的，仅仅是使用了单个空闲的CPU焦点。

可是，在JAVA和C#这类带虚拟机的语言中，多线程的实现底层，会凭据详细的操作系统的任务调理单元（好比历程），只管让线程也成为操作系统可以调理的单元，从而使用上多个CPU焦点。好比Linux2.6之后，提供了NPTL的内核线程模型，JVM就提供了JAVA线程到NPTL内核线程的映射，从而使用上多核CPU。而Windows系统中，听说自己线程就是系统的最小调理单元，所以多线程也是使用上多核CPU的。

所以我们在使用JAVAC#编程的时候，多线程往往已经同时具备了多历程使用多核CPU、以及切换开销低的两个利益。早期的一些网络谈天室服务，联合了多线程和多历程使用的例子。一开始法式会启动多个广播谈天的历程，每个历程都代表一个房间；每个用户毗连到谈天室，就为他启动一个线程，这个线程会阻塞的读取用户的输入流。这种模型在使用阻塞API的情况下，很是简朴，但也很是有效。

当我们在广泛使用多线程的时候，我们发现，只管多线程有许多优点，可是依然会有显着的两个缺点：一个内存占用比力大且不太可控；第二个是多个线程对于用一个数据使用时，需要思量庞大的“锁”问题。由于多线程是基于对一个函数挪用的并行运行，这个函数内里可能会挪用许多个子函数，每挪用一层子函数，就会要在栈上占用新的内存，大量线程同时在运行的时候，就会同时存在大量的栈，这些栈加在一起，可能会形成很大的内存占用。而且，我们编写服务器端法式，往往希望资源占用只管可控，而不是动态变化太大，因为你不知道什么时候会因为内存用完而当机，在多线程的法式中，由于法式运行的内容导致栈的伸缩幅度可能很大，有可能超出我们预期的内存占用，导致服务的故障。

而对于内存的“锁”问题，一直是多线程中庞大的课题，许多多线程工具库，都推出了大量的“无锁”容器，或者“线程宁静”的容器，而且还大量设计了许多协调线程运作的类库。可是这些庞大的工具，无疑都是证明晰多线程对于内存使用上的问题。同时排多条队就是并行由于多线程还是有一定的缺点，所以许多法式员想到了一个釜底抽薪的方法：使用多线程往往是因为阻塞式API的存在，好比一个read()操作会一直停止当前线程，那么我们能不能让这些操作酿成不阻塞呢？——selector/epoll就是Linux退出的非阻塞式API。

如果我们使用了非阻塞的操作函数，那么我们也无需用多线程来并发的等候阻塞效果。我们只需要用一个线程，循环的检查操作的状态，如果有效果就处置惩罚，无效果就继续循环。这种法式的效果往往会有一个大的死循环，称为主循环。

在主循环体内，法式员可以摆设每个操作事件、每个逻辑状态的处置惩罚逻辑。这样CPU既无需在多线程间切换，也无需处置惩罚庞大的并行数据锁的问题——因为只有一个线程在运行。这种就是被称为“并发”的方案。服务员兼了点菜、上菜就是并发实际上盘算机底层早就有使用并发的计谋，我们知道盘算机对于外部设备（好比磁盘、网卡、显卡、声卡、键盘、鼠标），都使用了一种叫“中断”的技术，早期的电脑使用者可能还被要求设置IRQ号。

这其中断技术的特点，就是CPU不会阻塞的一直停在等候外部设备数据的状态，而是外部数据准备好后，给CPU发一个“中断信号”，让CPU转去处置惩罚这些数据。非阻塞的编程实际上也是类似这种行为，CPU不会一直阻塞的等候某些I/O的API挪用，而是先处置惩罚其他逻辑，然后每次主循环去主动检查一下这些I/O操作的状态。多线程和异步的例子，最著名就是Web服务器领域的Apache和Nginx的模型。Apache是多历程/多线程模型的，它会在启动的时候启动一批历程，作为历程池，当用户请求到来的时候，从历程池中分配处置惩罚历程给详细的用户请求，这样可以节约多历程/线程的建立和销毁开销，可是如果同时有大量的请求过来，还是需要消耗比力高的历程/线程切换。

而Nginx则是接纳epoll技术，这种非阻塞的做法，可以让一个历程同时处置惩罚大量的并发请求，而无需重复切换。对于大量的用户会见场景下，apache会存在大量的历程，而nginx则可以仅用有限的历程（好比按CPU焦点数来启动），这样就会比apache节约了不少“历程切换”的消耗，所以其并发性能会更好。Nginx的牢固多历程，一个历程异步处置惩罚多个客户端Apache的多态多历程，一个历程处置惩罚一个客户在现代服务器端软件中，nginx这种模型的运维治理会更简朴，性能消耗也会稍微更小一点，所以成为最盛行的历程架构。

可是这种利益，会支付一些另外的价格：非阻塞代码在编程的庞大度变大。漫衍式编程庞大度以前我们的代码，从上往下执行，每一行都市占用一定的CPU时间，这些代码的直接顺序，也是和编写的顺序基本一致，任何一行代码，都是唯一时刻的执行任务。当我们在编写漫衍式法式的时候，我们的代码将不再似乎那些单历程、单线程的法式一样简朴。

我们要把同时运行的差别代码，在同一段代码中编写。就似乎我们要把整个交响乐团的每个乐器的曲谱，全部写到一张纸上。

为相识决这种编程的庞大度，业界生长出了多种编码形式。在多历程的编码模型上，fork()函数可以说一个很是典型的代表。

在一段代码中，fork()挪用之后的部门，可能会被新的历程中执行。要区分当前代码的所在历程，要靠fork()的返回值变量。

这种做法，即是把多个历程的代码都合并到一块，然后通过某些变量作为标志来划分。这样的写法，对于差别历程代码大部份相同的“同质历程”来说，还是比力利便的，最怕就是有大量的差别逻辑要用差别的历程来处置惩罚，这种情况下，我们就只能自己通过规范fork()四周的代码，来控制杂乱的局势。比力典型的是把fork()四周的代码弄成一个类似分发器（dispatcher）的形式，把差别功效的代码放到差别的函数中，以fork之前的标志变量来决议如何挪用。动态多历程的代码模式在我们使用多线程的API时，情况就会好许多，我们可以用一个函数指针，或者一个带回调方法的工具，作为线程执行的主体，而且以句柄或者工具的形式来控制这些线程。

作为开发人员，我们只要掌握了对线程的启动、停止等有限的几个API，就能很好的对并行的多线程举行控制。这对比多历程的fork()来说，从代码上看会更直观，只是我们必须要分清楚挪用一个函数，和新建一个线程去挪用一个函数，之间的差异：新建线程去挪用函数，这个操作会很快的竣事，并不会依序去执行谁人函数，而是代表着，谁人函数中的代码，可能和线程挪用之后的代码，交替的执行。由于多线程把“并行的任务”作为一个明确的编程观点界说了出来，以句柄、工具的形式封装好，那么我们自然会希望对多线程能更多庞大而细致的控制。因此泛起了许多多线程相关的工具。

比力典型的编程工具有线程池、线程宁静容器、锁这三类。线程池提供应我们以“池”的形态，自动治理线程的能力：我们不需要自己去思量怎么建设线程、接纳线程，而是给线程池一个计谋，然后输入需要执行的任务函数，线程池就会自动操作，好比它会维持一个同时运行线程数量，或者保持一定的空闲线程以节约建立、销毁线程的消耗。在多线程操作中，不像多历程在内存上完全是区离开的，所以可以会见同一份内存，也就是对堆内里的同一个变量举行读写，这就可能发生法式员所预计不到的情况（因为我们写法式只思量代码是顺序执行的）。

另有一些工具容器，好比哈希表和行列，如果被多个线程同时操作，可能还会因为内部数据对不上，造成严重的错误，所以许多人开发了一些可以被多个线程同时操作的容器，以及所谓“原子”操作的工具，以解决这样的问题。有些语言如Java，在语法层面，就提供了关键字来对某个变量举行“上锁”，以保障只有一个线程能操作它。多线程的编程中，许多并行任务，是有一定的阻塞顺序的，所以有种种各样的锁被发现出来，好比倒数锁、排队锁等等。

java.concurrent库就是多线程工具的一个大荟萃，很是值得学习。然而，多线程的这些五花八门的武器，其实也是证明晰多线程自己，是一种不太容易使用的顺手的技术，可是我们一下子还没有更好的替代方案而已。

多线程的工具模型在多线程的代码下，除了启动线程的地方，是和正常的执行顺序差别以外，其他的基本都还是比力近似单线程代码的。可是如果在异步并发的代码下，你会发现，代码一定要装入一个个“回调函数”里。这些回调函数，从代码的组织形态上，险些完全无法看出来其预期的执行顺序，一般只能在运行的时候通过断点或者日志来分析。

这就对代码阅读带来了极大的障碍。因此现在有越来越多的法式员关注“协程”这种技术：可以用类似同步的方法来写异步法式，而无需把代码塞到差别的回调函数内里。协程技术最大的特点，就是加入了一个叫yield的观点，这个关键字所在的代码行，是一个类似return的作用，可是又代表着后续某个时刻，法式会从yield的地方继续往下执行。

这样就把那些需要回调的代码，从函数中得以解放出来，放到yield的后面了。在许多客户端游戏引擎中，我们写的代码都是由一个框架，以每秒30帧的速度在重复执行，为了让一些任务，可以划分放在各帧中运行，而不是一直阻塞导致“卡帧”，使用协程就是最自然和利便的了——Unity3D就自带了协程的支持。在多线程同步法式中，我们的函数挪用栈就代表了一系列同属一个线程的处置惩罚。

可是在单线程的异步回调的编程模式下，我们的一个回调函数是无法简朴的知道，是在处置惩罚哪一个请求的序列中。所以我们往往需要自己写代码去维持这样的状态，最常见的做法是，每个并发任务启动的时候，就发生一个序列号（seqid），然后在所有的对这个并发任务处置惩罚的回调函数中，都传入这个seqid参数，这样每个回调函数，都可以通过这个参数，知道自己在处置惩罚哪个任务。如果有些差别的回调函数，希望交流数据，好比A函数的处置惩罚效果希望B函数能获得，还可以用seqid作为key把效果存放到一个公共的哈希表容器中，这样B函数凭据传入的seqid就能去哈希表中获得A函数存入的效果了，这样的一份数据我们往往叫做“会话”。

如果我们使用协程，那么这些会话可能都不需要自己来维持了，因为协程中的栈代表了会话容器，当执行序列切换到某个协程中的时候，栈上的局部变量正是之前的处置惩罚历程的内容效果。协程的代码特征为相识决异步编程的回调这种庞大的操作，业界还发现了许多其他的手段，好比lamda表达式、闭包、promise模型等等，这些都是希望我们，能从代码的外貌组织上，把在多个差别时间段上运行的代码，以业务逻辑的形式组织到一起。

最后我想说说函数式编程，在多线程的模型下，并行代码带来最大的庞大性，就是对堆内存的同时操作。所以我们才弄出来锁的机制，以及一大批敷衍死锁的计谋。

而函数式编程，由于基础不使用堆内存，所以就无需处置惩罚什么锁，反而让整个事情变得很是简朴。唯一需要改变的，就是我们习惯于把状态放到堆内里的编程思路。

函数式编程的语言，好比LISP或者Erlang，其焦点数据效果是链表——一种可以表现任何数据结构的结构。我们可以把所有的状态，都放到链表这个数据列车中，然后让一个个函数去处置惩罚这串数据，这样同样也可以通报法式的状态。这是一种用栈来取代堆的编程思路，在多线程并发的情况下，很是的有价值。

漫衍式法式的编写，一直都陪同着大量的庞大性，影响我们对代码的阅读和维护，所以我们才有种种各样的技术和观点，试图简化这种庞大性。也许我们无法找到任何一个通用的解决方案，可是我们可以通过明白种种方案的目的，来选择最适合我们的场景：l 动态多历程fork——同质的并行任务l 多线程——能明确划的逻辑庞大的并行任务l 异步并发回调——对性能要求高，但中间会被阻塞的处置惩罚较少的并行任务l 协程——以同步的写法编写并发的任务，可是不合适提倡庞大的动态并行操作。l 函数式编程——以数据流为模型的并行处置惩罚任务漫衍式数据通信漫衍式的编程中，对于CPU时间片的切分自己不是难点，最难题的地方在于并行的多个代码片段，如何举行通信。

因为任何一个代码段，都不行能完全单独的运作，都需要和其他代码发生一定的依赖。在动态多历程中，我们往往只能通过父历程的内存提供共享的初始数据，运行中则只能通过操作系统间的通讯方式了：Socket、信号、共享内存、管道等等。无论那种做法，这些都带来了一堆庞大的编码。这些方式大部门都类似于文件操作：一个历程写入、另外一个历程读出。

所以许多人设计了一种叫“消息行列”的模型，提供“放入”消息和“取出”消息的接口，底层则是可以用Socket、共享内存、甚至是文件来实现。这种做法险些能够处置惩罚任何状况下的数据通讯，而且有些还能生存消息。可是缺点是每个通信消息，都必须经由编码、解码、收包、发包这些历程，对处置惩罚延迟有一定的消耗。

如果我们在多线程中举行通信，那么我们可以直接对某个堆内里的变量直接举行读写，这样的性能是最高的，使用也很是利便。可是缺点是可能泛起几个线程同时使用变量，发生了不行预期的效果，为了敷衍这个问题，我们设计了对变量的“锁”机制，而如何使用锁又成为另外一个问题，因为可能泛起所谓的“死锁”问题。所以我们一般会用一些“线程宁静”的容器，用来作为多线程间通讯的方案。

为了协调多个线程之间的执行顺序，还可以使用许多种类型的“工具锁”。在单线程异步并发的情况下，多个会话间的通信，也是可以通过直接对变量举行读写操作，而且不会泛起“锁”的问题，因为本质上每个时刻都只有一个段代码会操作这个变量。然而，我们还是需要对这些变量举行一定计划和整理，否则种种指针或全局变量在代码中散布，也是很泛起BUG的。所以我们一般会把“会话”的观点酿成一个数据容器，每段代码都可以把这个会话容器作为一个“收件箱”，其他的并发任务如果需要在这个任务中通讯，就把数据放入这个“收件箱”即可。

在WEB开发领域，和cookie对应的服务器端Session机制，就是这种观点的典型实现。漫衍式缓存计谋在漫衍式法式架构中，如果我们需要整个体系有更高的稳定性，能够对历程容灾或者动态扩容提供支持，那么最难明决的问题，就是每个历程中的内存状态。因为历程一旦扑灭，内存中的状态会消失，这就很难不影响提供的服务。

所以我们需要一种方法，让历程的内存状态，不太影响整体服务，甚至最好能酿成“无状态”的服务。固然“状态”如果不写入磁盘，始终还是需要某些历程来承载的。在现在盛行的WEB开发模式中，许多人会使用PHP+Memcached+MySQL这种模型，在这里，PHP就是无状态的，因为状态都是放在Memcached内里。这种做法对于PHP来说，是可以随时动态的扑灭或者新建，可是Memcached历程就要保证稳定才行；而且Memcached作为一个分外的历程，和它通信自己也会消耗更多的延迟时间。

因此我们需要一种更灵活和通用的历程状态生存方案，我们把这种任务叫做“漫衍式缓存”的计谋。我们希望历程在读取数据的时候，能有最高的性能，最好能和在堆内存中读写类似，又希望这些缓存数据，能被放在多个历程内，以漫衍式的形态提供高吞吐的服务，其中最关键的问题，就是缓存数据的同步。PHP常用Memached做缓存为相识决这个问题，我们需要先一步步来剖析这个问题：首先，我们的缓存应该是某种特定形式的工具，而不应该是任意类型的变量。

因为我们需要对这些缓存举行尺度化的治理，只管C++语言提供了运算重载，我们可以对“=”号的写变量操作举行重新界说，可是现在基本已经没有人推荐去做这样的事。而我们手头就有最常见的一种模型，适合缓存这种观点的使用，它就是——哈希表。所有的哈希表（或者是Map接口），都是把数据的存放，分为key和value两个部门，我们可以把想要缓存的数据，作为value存放到“表”当中，同时我们也可以用key把对应的数据取出来，而“表”工具就代表了缓存。

其次我们需要让这个“表”能在多个历程中都存在。如果每个历程中的数据都毫无关联，那问题其实就很是简朴，可是如果我们可能从A历程把数据写入缓存，然后在B历程把数据读取出来，那么就比力庞大了。

我们的“表”要有能把数据在A、B两个历程间同步的能力。因此我们一般会用三种计谋：租约清理、租约转发、修改广播l 租约清理，一般是指，我们把存放某个key的缓存的历程，称为持有这个key的数据的“租约”，这个租约要挂号到一个所有历程都能会见到的地方，好比是ZooKeeper集群历程。那么在读、写发生的时候，如果本历程没有对应的缓存，就先去查询一下对应的租约，如果被其他历程持有，则通知对方“清理”，所谓“清理”，往往是指删除用来读的数据，回写用来写的数据到数据库等持久化设备，等清理完成后，在举行正常的读写操作，这些操作可能会重新在新的历程上建设缓存。

这种计谋在缓存掷中率比力高的情况下，性能是最好的，因为一般无需查询租约情况，就可以直接操作；但如果缓存掷中率低，那么就会泛起缓存重复在差别历程间“移动”，会严重降低系统的处置惩罚性能。l 租约转发。

同样，我们把存放某个KEY的缓存的历程，称为持有这个KEY数据的“租约”，同时也要挂号到集群的共享数据历程中。和上面租约清理差别的地方在于，如果发现持有租约的历程不是本次操作的历程，就会把整个数据的读、写请求，都通过网络“转发”个持有租约的历程，然后等候他的操作效果返回。这种做法由于每次操作都需要查询租约，所以性能会稍微低一些；但如果缓存掷中率不高，这种做法能把缓存的操作分管到多个历程上，而且也无需清理缓存，这比租约清理的计谋适应性更好。

l 修改广播。上面两种计谋，都需要维护一份缓存数据的租约，可是自己对于租约的操作，就是一种比力泯灭性能的事情。

所以有时候可以接纳一些更简朴，但可能蒙受一些纷歧致性的计谋：对于读操作，每个节点的读都建设缓存，每次读都判断是否凌驾预设的读冷却时间x，凌驾则清理缓存从持久化重建；对于写操作，么个节点上都判断是否凌驾预设的写冷却时间y，凌驾则展开清理操作。清理操作也分两种，如果数据量小就广播修改数据；如果数据量大就广播清理通知回写到持久化中。这样虽然可能会有一定的纷歧致风险，可是如果数据不是那种要求太高的，而且缓存掷中率又能比力有保障的话（好比凭据KEY来举行一致性哈希会见缓存历程），那么真正因为写操作广播不实时，导致数据纷歧致的情况还是会比力少的。

这种计谋实现起来很是简朴，无需一其中心节点历程维护数据租约，也无需庞大的判断逻辑举行同步，只要有广播的能力，加上对于写操作的一些设置，就能实现高效的缓存服务。所以“修改广播”计谋是在大多数需要实时同步，但数据一致性要求不高的领域最常见的手段。

著名的DNS系统的缓存就是靠近这种计谋：我们要修改某个域名对应的IP，并不是连忙在全球所有的DNS服务器上生效，而是需要一定时间广播修改给其他服务区。而我们每个DSN服务器，都具备了大量的其他域名的缓存数据。总结在高性能的服务器架构中，常用的缓存和漫衍两种计谋，往往是联合到一起使用的。

虽然这两种计谋，都有无数种差别的体现形式，成为种种各样的技术门户，可是只有清楚的明白这些技术的原理，而且和实际的业务场景联合起来，才气真正的做出满足应用要求的高性能架构。点击可相识更多详细内容https://yq.aliyun.com/go/articleRenderRedirect?url=https://chuangke.aliyun.com/invite?spm=a2c4e.11153940.0.0.2ee954f5ND73vn&userCode=gy5l4yp9作者：stefanie燕。

本文来源：kaiyun-www.fjpccoop.com