集群
分担请求的压力，也就是在几个服务器上部署相同的应用程序，来分担客户端请求
同一个业务，部署在多个服务器上
高可用：业务系统被部署在多个机器上，
1. 如果某些出现故障，其他机器任然提供完整服务
2. 由于一般服务做负载均衡，均衡器往往是一个单点，存在高可用问题
3. 针对均衡器的单点，可以使用备机的方式，来做故障转移的集群可以解决
高并发：业务系统被拆在多个系统中，
1. 提高并发效果明显
高性能：业务系统被拆在多个系统中，
1. 没太多机器做的事没啥区别，性能方面没什么变化
定时任务执行问题
问题描述
一个系统读取需要执行的任务放在内存中没有问题
系统部署为集群系统就存在问题，两个系统的两个内存中存储的数据不同，执行可能存在问题
解决思路
将存储在内存中数据存储在一个位置，两个系统读取同一份数据，不会存在两份数据的问题
两个系统相当于同时读取系统，定时任务中很可能希望不要重复读取，这里其实是一个队列数据的消费问题
redis的简单可以实现简单的队列
消息队列有比较完善的消息队列，业务系统的消息队列可以考虑使用rabbitmq
会话问题
问题描述
单体应用用，session存储在一个应用上没有问题
集群系统，各个节点存储各自的session，请求被路由到各个节点时会存在登录会话无法保持的问题
解决思路
session 复制：基本上可以不考虑
粘性会话：在特定的场景中可以使用 ??
session 集中存储：可以将session存储在redis中存储
有效期问题，可以设置会话的有效期
访问刷新有效期问题，如果需要此效果，需要拦截请求更新会话有效期
上传附件的问题
问题描述：
单体应用，一个应用存储在本服务器中
集群系统中，各个节点存储在各自的服务器中，会导致有的文件访问不到
解决思路
使用分布式文件系统
1. 上传文件存储到一个地方
- 可以使用网络文件系统 （NFS，Samba），需要挂在到应用系统
- 可以上传到FTP服务器，java有相关的API可以进行操作
2. 访问时可以各自的应用都进行映射
3. 访问时可以同一个一个访问出口映射
4. 存在单点问题，可以考虑使用备份机器，定时备份
5. 底层硬件采用raid等技术，保证数据恢复
6. 故障转移，可以使用虚拟IP结合心跳检测的技术
日志问题
ElasticSearch + Kibana + logstash 收集所有的日志，使用kibana进行日志查看,实际效果未知