集群之我见

    随着大数据的发展及互联网高并发的需求量暴增，单点模式逐渐难以解决当前系统的应用，随之而出现的解决方案是集群的方案。根据本人对集群的大致了解，分享部分心得。大体来说集群主要解决问题包括以下几点：

一、高可用(High Availability，简称HA)

    相对于单点服务器来说，集群的单点故障显的尤为重要。假设服务器的故障率为1%，单点服务能保持99%的可用性。但在集群中，双节点可用性为98%，感觉差距不大？但假设扩大到500个节点，可用性瞬间降低到0.7%。这种可用性的降低是致命的。而采用HA后，同样1%故障率的服务器，双节点可用性为99.99%，三节点为99.9999%。所以针对大规模的集群，首先需要解决的就是HA的方案。根据实际应用的规模跟应用场景，HA一般有以下几种：

    1、双机热备。通过软件或者硬件实现数据增量同步，实现两台主机的数据一致性，通过故障转移（link fault pass through简称LFP），实现当某台主机down机或者网络故障自动切换，通过集群虚拟IP及集群虚路由实现IP地址自动跳转（如：Keepalived）。此方案适用于小型集群应用，且对数据安全性要求高的。能解决数据容灾，故障转移，及自动切换等功能，相对投资较少，配置简单，通过上面的出故障率为1%的双机服务器，能达到99.99%的可用性，对于完全不可丢失的数据，还可以通过远程容灾的手段保证数据安全。缺点也很明显，首先两台热备的方案必定造成服务器资源的浪费，始终有一台主机处于空闲无用的状态。另外一个致命弱点就是双机模式如果互相之间的通讯出现问题，就会发生脑裂，所谓脑裂就是两台主机分别以为对方down掉，各自认为自己应该充当master而去互相竞争资源或重启对方，这样的情况出现对于实时应用的系统，往往是非常致命的。

    2、双机服务集群。跟双机热备类似，但不是针对整个服务器做热备，而是单独针对某个服务做集群，这样做可以解决核心服务down掉带了的后果。此方案同样可能会出现脑裂问题，但是在不需要做数据存储共享的服务中是最简单有效且节约成本的方案，适合不需要做数据共享，数据写入及轻量级的应用，比如nginx的HA。此服务器同时可以采取其他方案同时做别的任务节点，比如hadoop等。

    3、集群选举服务。此方案需要3个以上奇数个节点来实现高可用，解决前面两点出现的脑裂问题。此模式下节点成员通过成员投票机制来发起投票，当投票超过半数以后才会重新选举出新的mater接管服务器，要求奇数个节点也是因为产生的投票不会产生相等而设计的。比如：zookeeper、Consul及redis3.x新出的HA都是采用此方案。该方案适用于大型集群的应用，提供高性能的高可用方案，但由于至少要3个节点，对服务器跟网络资源要求会更高，小型的应用反而造成成本浪费。

二、负载均衡（Load Balance）

    集群的另一个重要的作用是提供负载均衡。负载均衡也是集群布局里面最重要的考虑因素之一，通俗点将就是把请求、作业、数据平均分摊到不同的节点中执行。随着计算机及硬件的发展，各方面的速度都得到高速提升，但磁盘IO的性能一直是导致服务器性能的瓶颈，而随着互联网应用的发展，网络请求IO及高并发的场景也限制单点服务器极限。

    传统的方法通过服务器的横向发展，提升服务器的内存,CPU跟硬盘容量。但横向发展对服务器的升级维护造成一定的难度，虽然当下的各种云服务器解决了横向发展这个难题，但IO的瓶颈一样得不到解决。这时只能通过纵向发展(添加服务器集群节点）来提高性能。当然某些场景通过集群实现负载均衡的同时也会增加网络IO之间的通讯时间以及集群的原子性的一些列难题。所以根据当前需求做好合适的方向选择或者先横向再纵向的规划比较重要。

    常见的负载均衡场景有：

    1、客户端-反向代理。通过DNS轮询，在一个域名下配置多个解析IP地址，通过配置权重值保证每次域名请求访问不同的IP，从而均衡到各个不同的反向代理服务器中。

    2、反向代理-WEB服务器。跟1类似，区别是通过一个网络请求，按权重分配到不同的web服务器集群中，分担高并发下的请求。常见的有nginx+tomcat。

    3、web服务器-服务层。通过服务器连接池进行管理，web服务器请求的服务组件随机从连接池中获取服务层对象，每个服务层对象来自不同的集群节点。

    4、服务层-DB。当数据压力较大或者服务请求时，磁盘IO成为瓶颈时，可以考虑对数据进行负载均衡。在数据层进行负载均衡的过程中根据业务需求也可以考虑做读写分离。

   负载均衡确实能大大的提高系统的吞吐量，减轻单机服务器的压力，但同时对开发跟程序也有了新的要求，比如web服务器负载均衡时需要解决session共享的问题，集群中高并发下线程安全问题，数据一致性等都需要考虑（一般来说可以通过redis+消息队列解决）。负载均衡会在每个节点保留完整的且相同的内容，所以往往负载均衡与HA同时使用来达到双层目的。

三、切片。也可以认为通过集群对服务器做水平切分。通常是把数据按一定规律切分到不同的节点上，每个节点负责其中一部分，这样每个节点的应用功能更加专一，责任更加明确，同时减少数据容量也可以更快速的实现检索跟统计。常见的oracle集群，redis3.x集群等都有这样的实现。这样的方案对分片类的数据能大大的提高效率，但同时也会在跨分片数据整合的时候（比如所有数据的聚合，跨分片的数据连接）增加网络IO吞吐量，对客户端请求的开发内容也会增加麻烦。所以根据需求，选择在合适的场景使用此方案才能更好的体现它的好处。切片分两种，一直是各自独立运行，互不影响，各自负责各自数据，另一种是通过统一的任务分配管理程序进行调度。不管是前面哪个模式，一般会搭配HA的方案同事进行保证数据的高可用性。

四、分布式计算。分布式跟负载均衡看起来有点像，也是把数据做纵向拷贝，但应用场景却完全不同。负载均衡主要解决的是高并发的分发问题，解决单机服务器压力过大，性能不足的问题。每次请求或者作业是随机（或者按权重分配）给某一个节点单独去完成。比如有10w个并发请求，在一个10个节点的负载均衡集群中，如果设置相同的权重，每个服务器接收1w个请求，尽可能的让每个服务器平均去分配处理资源（理论上是降低服务器的负载），从而缓解单点服务器无法应付导致系统崩溃的麻烦。而分布式计算有点相反，它的发展虽然也是解决单点性能不足，但它却是想办法榨干服务器的性能，从而达到节省时间的目的，通常的利用资源是CPU或者磁盘IO。比如分析一个1GB的日志文件，传统的单机计算方式需要60分钟，但如果通过10个节点去完成，系统会把文件分成10个部分，编号1-10，然后每个节点各自去运算跟读取各自编号的内容，分析后的结果再汇总起来的出结果，这样理论的计算跟IO读取的速度会提高10倍（实际不会提高这么多）。把请求分配到每个节点，在节点中如何运算的过程叫map，而把所有节点汇总的结果取到再加以处理的过程叫reduce，这就是大名鼎鼎的rm框架。但是mp的过程中会产生更多的网络IO，以及会产生一些中间过程的磁盘IO，以及调度分配，这些也会产生耗时，所以如果是很简单的计算，反而会比单节点慢很多。常用的分布式计算应用有hadoop，hbase，spark等等，主要场景是做大数据查询、计算、分析以及科学计算、深度学习等。

综上，集群确实能解决很多生产上的问题，提高系统的可靠性及扩展性能，但同时也增加的维护、开发及运维成本，而且可以清楚的知道在某些运算度或并发度要求很低的情况下反而会导致性能下降，所以根据实际情况考虑是否选择集群以及使用集群解决哪方面的问题才是当前最重要的。