随着大数据的日益普及，很多人对大数据越来越感兴趣，有些程序开发者也跃跃欲试，但是苦于不会搭建集群环境，而常常被拦在大数据的门槛之外。
通过这次疫情，我相信各位也看见了，大数据真的很重要。从患者数字地图，到疑似患者追踪，再到可视化，都体现着大数据的作用，我也相信，在未来的5-10年里，大数据会有非常非常多的应用与发展。
大数据里最难的就是怎么保持数据查询的稳定性，那么集群就很重要了。
先来给大家讲讲集群吧。
传统的系统架构就是经典的三层结构，就一个项目跑在一个tomcat中，但是随着用户数量的增加，一个服务器一个tomcat肯定是不靠谱的，如果乡村教师马云在杭州一个小地方，搞了一台服务器，一个tomcat，跑天猫的代码，然后让我们去访问，那我们估计是不可能看到网站首页的，一直处于宕机状态。哈哈！
这时候可以使用集群的架构，就是说现在马云狠着买了5台服务器，每台服务器都跑天猫的代码，然后又搞了一个Nginx做负载均衡，这时候我们的请求由五台服务器完成的，第一次请求是第一台服务器响应，第二次请求是由第二台服务器响应，这样可以应对的并发量就是之前的5倍，马云很开心，美滋滋。
总结：多台服务器跑的都是一套完整的代码，这就叫集群。
那大数据的稳定集群方案怎么搭建呢？
别急，我今天就给大家讲讲国内顶尖的大数据和商业智能（BI）领跑者：帆软公司，来看看他们的集群方案是怎么架构的。
先来介绍一下帆软吧。IDC认证国内BI市场占有率第一，注意是IDC认证，可不是什么垃圾机构的证书。其次，超11000家大中型企业选择，为38000个信息化项目提供BI支持，数字背后的实力不容小嘘。
不说别的，就B端这种商业智能的公司，年销售额达到5个亿就已经很牛了，国内除了它就没别的。不信？那就透明透明财务咯。
再来看看集群方案选择。
帆软集群架构简单概述就是负载均衡+状态服务器+文件服务器/节点间同步+外置数据库，架构很明了，不过架构中各个应用组件，我们需要针对不同场景进行选择和搭配。
本文将介绍如何选择集群方案，以及各种方案的优劣势，为IT人员规划设计集群方案时提供一些有效的指引。
1. 选择操作系统
帆软集群方案对于windows系统和Linux系统均能支持，列举一下两类操作系统下可以选择的方案（标红为推荐或较常用方案）：
考虑到稳定性和性能情况，推荐选用Linux系统作为服务器的操作系统。下面简单介绍Linux系统作为服务器操作系统对比windows系统的两大特性：
1.1 稳定性
- Linux系统稳定性极佳，大部分硬件和配置更新无需重启；
- Linux系统相对Windows系统，宕机机率更低，常常一年都不用关机；
1.2 性能优势
- Linux系统处理多线程比Windows要好的多，是真正的多用户多线程，而windows是单用户伪多线程；
- Linux系统不像Windows系统必备图形化操作界面，因此占用资源会少一些，性能也更好；
- 内存管理和调度方式优秀，有效利用一切硬件资源；
但是影响我们最终哪种系统的因素，还有一个最关键的点——运维能力，如果公司不具备Linux系统的运维能力，那只能选择Windows系统了。
2. 选择负载均衡
负载均衡分为软件负载均衡和硬件负载均衡，两种负载均衡核心作用是一样的，负载均衡作为集群的入口，起到请求分发和节点健康检查的作用。
2.1 硬件负载均衡
硬件负载均衡很稳定，性能也相对较好，但是成本也高，最常用的负载均衡就是F5。若公司有硬件负载均衡且具备较好的配置和运维能力，确认硬件负载均衡具备主动健康检查功能后，即可选择使用硬件负载均衡。
简单介绍一下硬件负载均衡的优缺点：
- 优点：能够直接通过智能交换机实现,处理，而且与系统无关，负载性能强更适用于一大堆设备、大访问量、简单应用；
- 缺点：成本高，除设备价格高昂，而且配置冗余．很难想象后面服务器做一个集群，但最关键的负载均衡设备却是单点配置；无法有效掌握服务器及应用状态；
使用文档：负载均衡配置指导
2.2 软件负载均衡
简单介绍一下软件负载均衡的优缺点：
- 优点：基于系统与应用的负载均衡，能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的，性价比高，实际上如果只有几台服务器，用F5之类的硬件产品显然有些浪费，而用软件就要划算的多，因为服务器同时还可以跑应用做集群（虽然不太推荐），或者仅提供一般配置的服务器来给负载均衡应用。
- 缺点：负载能力会受服务器本身性能的影响。
帆软官方验证过的软件负载均衡有两种：Treafik和Nginx，两种均为开源软件，更新频率和维护力度稳定，下面说一下两个负载均衡的适用场景。
2.2.1 Nginx
Nginx作为负载均衡在Linux系统上具备很好的并发性能，并且占用极小的内存。许多大公司都在用，稳定性和性能是经过充分验证的。但是在Windows系统上并不支撑较高并发，所以在Windows系统上选用Nginx作为负载均衡，需要考虑并发情况，若并发需求低于200，部署集群仅以热备为目的，则可选用Nginx作为负载均衡，若并发需求超过200，则不建议使用Nginx，须换用其他负载均衡。
如果希望Nginx层面也具备高可用性，避免单点故障，那么可以再做一个Keepalived+Nginx方案，确保一个Nginx服务宕机或异常后，有备用的Nginx服务可以接手。
使用文档：Linux 系统安装配置 Nginx、Windows系统安装配置Nginx、Keepalived+Nginx部署方案
2.2.2 Treafik
Traefik是Go语言编写的单一可执行文件，无需安装，只要在命令行里执行即可，部署和使用非常简单，适用于对运维能力要求不高的用户使用。和Nginx相比，有两大优点：
- 在Windows系统上具备良好的性能，因此Windows系统推荐使用Treafik；
- 支持自动化更新反向代理和负载均衡配置；
使用文档：windows系统安装配置Treafik
Nginx在Linux系统下的性能和稳定性、Treafik在Windows系统下的性能和稳定性，帆软都已经进行了测试和验证。理论上Treafik在Linux系统上也具备较好的性能，但是为了避免方案的繁杂以及考虑维护成本，未对Treafik在Linux系统上的性能和稳定性做充分的验证。
总的来说，Linux系统推荐选用Nginx作为负载均衡，Windows系统不建议选择Nginx，推荐选用Treafik。
3. 选择Redis方案
帆软集群方案里，状态服务器是用Redis实现的，常用的Redis方案有Redis单机、Redis集群、Redis哨兵三种，这里对如何选择三种方案进行介绍。
如果公司已有Redis服务，不管是下面哪一种，都可以直接使用，这样可以减少额外维护一个应用的成本，但是如果没有Redis服务，我们为了使用集群，就要新安装Redis服务了。
3.1 Redis单机
Redis单机指的是只部署一个Redis应用，此种方案简单易部署，运维成本低，能够保证集群的可用性。
使用文档：Linux 系统安装配置单机 Redis
3.2 Redis集群
如果对于系统/方案的高可用性要求高，希望能够避免单点故障，那么Redis集群可以很好地满足需求。
3.2.1 架构介绍
Redis 集群结构是N个平权主节点（master），每个主节点对应M个从节点（slave），由于Redis集群的投票机制，N须为奇数，且必须大于等于3，否则创建集群时会失败。
业界经过大量检验最常用的Redis集群架构是3主3从。
3.2.2 资源需求
部署3主3从的Redis集群时，建议至少主从3台服务器，主从节点在构建Redis集群时会进行随机分配。
如果想要达到更加极致的高可用，避免主节点和从节点刚好分配到一台机器并且遇到服务器宕机导致整个Redis集群不可用的情况发生，可以准备6台服务器来做3主3从的Redis集群，这样任何一台服务器宕机都不会影响Redis集群对外提供服务。
3.2.3 优缺点说明
优点：
- 主节点宕机后，基于投票机制从节点可自动上升为主节点，可让Redis服务更加高可用；
- 数据分区存储在不同的主节点上，可以大幅度提升Redis服务的性能支撑；
缺点：
- 由于数据分区存储，所以当一个主节点及其对应的从节点全部宕机后，整个Redis集群将不能使用；
- 当存活的主节点数小于总节点数的一半时，整个Redis集群也会无法提供服务；
- 不管是3台服务还是6台服务器，我们都能感受到Redis集群对资源的要求是比较多的，且运维成本也会比Redis单机更高；
使用文档：linux系统安装配置Redis集群
简单总结，Redis集群方案可以让Redis服务更加高可用，但是运维和资源成本更高，建议选择时仔细考虑。
3.3 Redis哨兵
3.3.1 架构介绍
Redis哨兵模式是基于Redis主从模式的方案，Redis 2.8及以后版本提供了哨兵工具来实现自动化的系统监控和故障恢复功能。哨兵的作用就是监控master、slave是否正常运行，master出现故障后自动将slave转换为master。
目前帆软暂未提供Redis哨兵的部署方案，但是如果想自己部署Redis哨兵服务的话，建议至少使用2个哨兵（因为哨兵模式中将主服务器判断为失效至少需要 2 个 Sentinel 同意，所以我们至少要部署两个及以上的Sentinel ），
最常用的Redis哨兵方案为1主2从3哨兵，能够做到较好的高可用。
3.3.2 资源需求
可以将主节点、从节点、哨兵节点部署在一台或多台服务器上，但是和Redis集群一样，如果我们想要达到极致的高可用，避免一台服务器宕机就导致整个Redis服务不可用，那么就把每个节点部署在一个独立的服务器上。
3.3.3 优缺点说明
优点：
- 主从可以自动切换，故障可以转移，系统可用性更好；
- 哨兵模式是主从模式的升级，系统更健壮，可用性更高。
缺点：
- 不能支持高并发，能提供写入功能的也就只有主节点。
说明：FineReport和FineBI产品需要安装Redis哨兵插件来对接Redis哨兵服务，插件还在测试阶段，暂未对外发布。
简单总结，Redis哨兵模式也可以让Redis服务更加高可用，但是也是比较耗费运维和资源的，而且与Redis集群相比最大的缺点就是性能和单机一样，无法提升Redis服务的性能。
4. 选择文件一致性方案
集群一致性里有一个很关键的点就是文件一致性，帆软提供了多种方案来保障节点间资源文件的一致性。我们可以基于运维能力，实际场景来进行选择。
4.1 节点间同步
节点间同步是保障节点间资源文件一致性的最简单的方案了。
优点：
- 无须开启文件服务器，无须做任何配置即可使用，无运维成本，使用成本很低。
- 各个节点均存储有文件，因此可以达到热备的效果，具备高可用性。
缺点：
- 节点间同步方案不适用于多节点，建议仅在使用两节点时选用节点间同步方案，因为节点越多，由于通信和同步效率等原因，可能会同步失败或者由于同步不及时影响使用；
简单总结，节点间自动同步的方案能够满足双机热备的需求，运维和使用成本很低，无须额外维护组件，但是不适用于多节点，建议仅在两个节点时选用。
4.2 文件服务器
帆软支持多种文件服务器，下面会对各个类型的文件服务器优缺点进行说明。
4.2.1 共性优缺点
先说明一下文件服务器共性的优缺点，共性优缺点指不管选择哪种文件服务器，都具备的。
优点：
- 文件一致性高，由于各个节点都是从同一个文件服务器读取资源文件，不涉及到同步，各个节点读取的资源文件永远会保持一致性；
- 适用于多节点、超多节点的场景；
缺点：
- 使用成本比节点间同步高，由于额外使用一个组件，导致部署运维成本会略高一些，需要更多的资源支撑这些组件；
4.2.2 特性优缺点
总结一下，当我们有超过2个节点时，为了保证各个节点文件的高一致性，建议使用文件服务器。基于高可用性、性能需求，以及公司实际的情况（是否已有文件服务器），再选择对应的文件服务器。
5. 选择缓存模式
5.1 缓存功能
缓存的资源文件：包含报表文件、仪表板文件、配置文件、地图数据等，目前是"reportlets/" ,"resources/", "assets/"，"dashboards"四个文件夹。
主动缓存：缓存所有资源文件；
被动缓存：仅对访问到的资源文件进行缓存；
5.2 缓存作用
优点：
- 提高文件服务器的高可用性，若使用文件服务器时开启了缓存，当文件服务器宕机时，系统从缓存中读取资源文件，仍可正常对外提供服务；
- 提高工程的性能，无法充分从节点下或者文件服务器中读取文件，可大幅提高模板的访问性能；
缺点：
- 缓存会占用系统内存资源；
总结一下，开启缓存功能可以大幅提高工程的性能，并且配合文件服务器使用时，可提高系统的高可用性，建议使用文件服务器时开启缓存。
6. 选择外置数据库
外置数据库在集群方案里也是很关键的点，由于各个节点均使用同一个外置数据库，因此节点间的配置可以保持一致性。FineReport和FineBI对常用的数据库都可以支持，包括MySQL、SqlServer、Oracle、DB2，这里不作详细介绍。若公司已有数据库服务，数据库版本符合帆软的要求则可直接使用，若需要新部署数据库服务，则建议部署mysql，部署比较简单。
使用文档：配置外接数据库
7. 通信协议
帆软集群支持TCP和UDP两种通信协议，目前默认是TCP协议，下面列举两种协议的区别：
其中需要注意的是，大部分云服务器（阿里云、亚马逊云等）都不支持UDP协议，因此只能选择TCP协议。
若服务器对TCP/UDP协议均支持，当节点数较少时选择TCP/UDP协议差异不大， 当节点数较多时，建议选择UDP协议，通信效率更高。
