在企业应用中，通常单机配置有限，企业应用需要高并发。这时就会使用计算机集群来增加并发数，从而提高整体的应用服务性能。集群是将多台计算机作为一个整体来提供相关应用的服务。FineBI支持多机服务的集群部署，通过集群部署，利用有限的计算机资源，有效提升整体应用的并发性能。本文主要介绍FineBI集群整体的思路。FineBI采用负载均衡集群模式，创建多台服务器作为集群服务器。这里有几个问题：1）web项目的存储问题：FineBI在集群中，由于自身问题，需要多台服务器读取同一个web项目。因此，实现web项目共享是很有必要的。2）系统数据一致性：FineBI在运行过程中，存在读写操作，同时需要将一些数据配置文件写入数据库。在集群的情况下，需要保证系统数据的一致性。3）负载均衡：一方面通过负载均衡来处理会话问题，另一方面可以实现负载均衡的集群环境。使用代理服务器可以将请求转发到集群内部的服务器，可以结合负载均衡和代理服务器的缓存技术。结合起来，它们提供有益的性能。4）FS平台集群：如果FineBI使用FS平台，FS平台的各种配置也需要集群。下图是FineBI进入架构的案例示意图。这样web项目就通过NFS文件共享进行处理。Web项目存储问题Web项目存储，我们要解决的是保证多台服务器可以读取同一个Web项目。我们可以用ceph做成多个物理硬盘和一个逻辑硬盘，这样所有的节点都在访问同一个地址；我们也可以利用linux本身的nfs共享文件服务来实现访问同一个web项目。无论使用哪种方式，都要保证：1）访问同一个web项目2）存储地址一致因为同一个web项目下，要求cube的存储地址一致，所以cube的存储地址立方体必须相同。在实际使用的时候，ceph的实现至少需要三台电脑才能实现，但是在实际的企业应用中，使用三台的情况比较少见；并且可以使用nfs而且是Linux本身，所以使用了“nfs”方案。当系统数据配置为单节点时，通过操作系统的文件系统使用缓存和保存数据的方式不再适用于集群模式。主要原因是数据的一致性。多个节点可能同时读写，改变系统数据，最终导致整体数据不一致。最好的解决方案是将所有系统配置数据交给MySQL等关系型数据库进行管理。但由于工程量大，主要是很多代码缺乏维护，贸然改动可能会带来意想不到的bug。所以我们采用了折衷的方法。在集群中选择一个节点作为主节点，简称M。其余节点作为子节点，简称S。所有在S上更改系统配置相关的操作都发送给M进行处理。M负责改变系统状态，维护整个系统的状态一致。S节点放弃所有缓存数据，在读取状态时，不再读取自己的数据，而是向M发送读取请求，获取M上的数据。M节点本身可能存储缓存数据。其他数据S节点相当于M节点，没有隶属关系。因此，根据以上原因，我们提供以下解决方案：1）数据库：将原web项目中finedb的配置信息转移到mysql数据库中。因为finedb数据库只能有一个连接，不能同时被多个节点读取，mysql数据库是不存在的。logdb也需要迁移；2）主子节点：我们使用主子节点来配置集群，系统数据的更改都在主节点上进行，子节点只读取主节点上的数据；3）Zookeeper：为了保证读写在这种情况下，主子节点保证数据的一致性，同时还需要zookeeper进行通信，起到文件锁的作用。负载均衡在FineBI的集群环境中，我们可以使用任何支持负载均衡的服务器来完成轮询任务，保证会话粘性。这里我们使用nginx反向代理，利用IP标识轮换来保证同一个用户在同一个session中。（在一台服务器和一个节点的情况下，相同的IP保证会话粘性）。FS平台集群使用FS平台集群插件配置FS平台以满足集群需求。在FS平台集群中，FS平台的所有操作都发送给master节点进行操作；子节点仅用作计算服务器。
