系统架构图：
系统及需求简介如下，
（姑且把Internet上面部分称做云端，但实际上Terminal Node也是属于系统的一部分，没有Terminal Node则整个系统就没有意义了）
1，如上系统架构图所示，云端服务器数量相对较少，不做赘述；
2，Terminal Node数量大，我期望的是发展到上万级别，目前还只数千计，离上万级别还遥远，并且没希望了（我已撤退）；
3，每个Terminal Node都具备计算与存储能力（有限）；
4，Terminal Node通过Open API与云端通信交互，当然，与云端的网络通信也是没问题的；
5，需求：目前需要计算Terminal Node端的用户交互数据（记录存储在Terminal Node本地）；
6，云端可以简单快速的控制Terminal Node端更新程序等。
最初的设计（我做的计划）：
1，更新Terminal Node端程序，让每个Terminal Node计算出需要计算的用户交互数据集（是否有点类似于Hadoop的Map呢？）；
2，Terminal Node将计算的用户交互数据集通过Open API传递到云端；
3，云端的计算程序Ap根据Terminal Node计算的用户交互数据集再做计算（是否有点类似于Hadoop的Reduce），得出需求的数据结果。
如果按以上设计实现，Terminal Node端与云端的程序都会非常简单，效率没问题，开发容易，实施容易。
（Terminal Node端的计算方法已经实现，云端的计算只剩下简单的汇总分组而也，很轻松）
但实际实施过程没能按如上设计执行。。。
实际是这样实施执行的：
1，Terminal Node端通过Open API与Ftp将用户交互数据传递到云端；
2，云端（目前还没有分布式文件系统，分布式计算基础构件等）把这一大堆数据按大数据对待，专门开发计算程序Ap处理这一大堆数据；
牢骚：
这个设计不是我做的，当然也不是我认可的，但没有办法（公司调整，技术开发目前由技术还完全未入行的人负责，还把自己当专家了），以上Ap程序是难点（只做空头设计的人也把这个列为难点），这个是硬交给我负责实现的（甚至还让我把这个程序移交给之前完全不了解这玩意的开发C来实现，并且限制3天时间/根本就不可能的事，要分析计算好几十项数据呢，遇到这样的同事真的很恼火啊），最后我没办法只能咬牙自己花了3天时间赶，基本实现了对几十项数据的分析计算，再花了一周多时间测试修改BUG，两周后上线，上线后我再将程序交给了开发C负责，交给开发C后，开发C问我，为什么不在Terminal Node端做计算，真是哭笑不得啊！
后记：
0，本来很好的一次分布式计算，最后被做烂（项目完成上线成功，但事实上已经与分布式计算无关了）。在完全不懂的人看来这就是大数据与分布式了，虽然我也还没搞懂大数据与分布式，但我知道，这不是！无语。
1，以上开发，为了效率，我大量使用了内存缓存，只在程序初始化读入配置与相关数据时访问一下数据库，分析计算过程全部是抛开数据库处理，这部分效率没有问题；
2，将一个Terminal Node分析计算后存入数据库，也没有问题，因为数据量不大；
3，但是，将多个Terminal Node分析计算后一起存入数据库，数据库就有点吃不消了。。。
程序上线运行后发现，瓶颈在数据库，只能放在后半夜，系统空闲的时候计算，需要两个小时。。。如果没有数据库瓶颈，也就是十几二十分钟的事。。。如果玩真的分布式，就是分分钟的事了。
总结：猪一样的队友不可怕，但是遇到技术问题时，应该坚决制止，一定不能让猪队捣乱，拖累团队，拖累公司。