With the growing popularity of big data, many people are increasingly interested in big data, some application developers are also eager to build a cluster environment but do not suffer, and often stopped at the threshold of big data.
Through this epidemic, I believe you saw it, big data is really important. From the patient digital maps to track suspected patients, to visualize, embodies the role of big data, I also believe that in the next 5--10 years, the data will be very, very large number of applications and development.
The hardest big data in the data query is how to maintain stability, then the cluster is very important.
First to tell us something about the cluster it.
Traditional architecture is classic three-tier structure, it is a project run in a tomcat, but as the number of users, a server is a tomcat certainly do not fly, if you place a small rural teacher Jack Ma in Hangzhou, to engage in a server, a tomcat, running Lynx code, and then let us go to visit, we estimate that it is impossible to see the site's home page, has been in a down state. Haha!
This can be used when a cluster architecture that is now the ruthless Ma bought five servers, each server running Lynx code, and then engage in a Nginx to do load balancing, this time we request the completion of the five servers the first server in response to the first request, a second request response from the second server, which can cope with the amount of concurrency is five times before, Ma very happy, flattered.
Summary: run multiple servers are a complete set of code, which is called a cluster.
How to build stable clustering scheme that big data it?
Do not worry, I give you today to talk about the country's top big data and business intelligence (BI) leader: soft sail company, take a look at their cluster program is how architecture.
First to introduce soft sail it. IDC BI certification domestic market share of the first, note that IDC certification, certification bodies refuse what is not. Second, ultra 11,000 large and medium enterprises choose to provide BI support for the 38000 information technology projects, the strength behind the numbers can not be small Hush.
If nothing else, it is the B-side of this business intelligence company, with annual sales of 5 million has been very cattle, in addition to its domestic and nothing else. Do not believe? It is clear clear financial strategy.
Look at the cluster program selection.
Soft sail cluster architecture is a brief overview of the state of server load balancing + + between the file server / node synchronization + external database architecture is very clear, but the architecture of each application component, we need to select and match for different scenarios.
本文将介绍如何选择集群方案，以及各种方案的优劣势，为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协议，通信效率更高。
关注我，并转发该文章，私信回复“报表”，即可获得FineReport90天免费版企业抗疫应用方案。
