一些胡乱的想法与实现
场景：生产者与消费者模型，前端一台ftpServer接收文件，一个文件接收完成后由一个后台进程对其进行业务处理。
1. 简单架构
这种设计下，不存在负载均衡，所有接收完成的文件，全部由业务处理进程加工。
业务处理进行的工作：定时任务取可处理文件，取到后进行处理，一个文件可重试N次后决定其处理结果。
2. 带负载架构
这种设计下，每个业务处理进程在不同的调度点，从数据库中取一定数量的文件进行处理。每个业务处理进程完成的工作都是相同的，一个结点挂了，不应响其他结点处理。
3. 按业务类别进行负载
随着业务需求的变化，对接收完成的文件按其类别进行不同的业务处理操作。可以考虑按业务类别进行负载。可能带来的好处，当某类业务处理操作消耗资源校多时，可考虑增加部署资源。
a.
b. 增加了中间层服务器，由其负责连接数据库，获取待处理文件资源。中间层服务器可以横向扩展进行负载，业务处理进程可从基础服务处得到中间层服务器列表，取其一可用IP进行访问。 中间层做横向扩展时，待处理文件资源需要做同步操作。
后记，随着业务处理进程的增多，随着各种服务器的增加，当设备数量增长到一定程度时。对服务器的快速管理、部署、排错等运维需求将浮出水面。感觉需要这么一套IT运维管理的机制与系统。或者是不是可以考虑类似hadoop项目这种分布式处理方案？