海量数据处理和高并发处理

原文：http://blog.csdn.net/hawksoft/article/details/7192207

 

其实任何简单的问题，只要规模大了都会成为一个问题，就如中国人口多，很多小问题都会变成大问题一样。但处理这种海量数据的方法无非就是分治和”人海”战术。使用人海战术的前提是问题的划分能够支持这种人海战术，其手段无非是切割（纵向，横向）和负载均衡。纵向分隔主要是按业务（功能）来分，也就是所谓面向服务架构，横向分隔方式比较多，主要依赖于所处理的对象属性，比如时间属性或者特定业务数据属性划分（比如铁路客票的车次（每个车次的操作基本上是独立的））；负载均衡则可以是镜像（部署）分布（同样的功能部署几份）和计算分布（一个问题分几个子问题在不同的机器上运行，然后合并结果）。当然，这些手段是可以综合利用的，最终可以做成多流水线分布式计算模式。另一方面，在海里数据面前，通用的数据处理方式会很困难，高效的方法基本都是有业务针对性和数据针对性的。

1）海量数据处理的基本思想：分治（这种思想在日常生活中无处不在，蚂蚁都知道，一次运不完，分多次运）
2）海量数据处理的基本手段：切割和负载均衡（切割是降低规模，负载均衡是人海战术，人多力量大，同样，机器多也计算能力强）
3）海量数据处理的可靠性保障：多存几份（再好的机器也会坏，鸡蛋不要放在一个篮子里）
4）海量数据处理的最高境界：多流水线并行作业（很多工厂都这样干，用在计算机也没问题）
5）海量数据处理的最好方法：没有最好，只有适合（什么都想做好，基本等于什么都做不好）

....

至于高并发处理，最好的解决办法是针对特定的需求采用特定的方法，基本的方法包括加锁，排队等等。另外一个关键就是要尽量简化事务和减少事务。

 有这种意识，只要去想，总能解决，没必要把这些技术搞得很神，从技术上来讲，海量数据处理所涉及的思想和算法都不是很难。

 

PS：这些天很多人都在鄙视铁路网上售票系统，也有很多人在为其出主意，我觉得没必要，真的，这些思想和技术不是很难的，至少我都能想到，做网上售票的这般兄弟姐妹也一定可以想到，至于为什么是这个结果，他们也只是“被”没技术。铁路是讲政治的地方，何苦皇帝不急太监急呢？

 

数据划分补充：如果按时间划分，2种情况，分数据库（早期很多企业级级业务系统，特别是财务系统都是这样做），分表（这种一般只针对特定业务表来进行）。按时间划分的时候需要注意单笔业务跨时间段得问题（很多软件都是在通过关帐开账把这种数据转到新的时间段里）。

2012-1-11：补充数据划分，按特定属性划分，用得最多的是按数据归属来划分，比如原来的帐套，现在云计算下的多租赁用户ID（企业用户ID)，这种方式可以在三种级别上（表级，数据库（Oracle分用户）级，物理级（多数据库实例））实现，注意点缓存的话，利用负载均衡，可以无限扩展。这种基于现有数据库的模式，可靠性保证只能用数据库本身来实现，虽然用软件也可以实现同一份数据多地方存储，但比较复杂。另外，利用数据库的链接也可以实现纵向分库存放，而且对应用透明，但这种方式维护起来比较麻烦，很多时候也没有必要。(Oralce和SQLServer都可以，而且不同库之间还可以Join,看起来很方便，但不建议，业务紧密联系的还是要放在一起，不同库之间还是不要采用链接上Join，直接在内存中参照还快些)

 

上面都是说，等过两天有时间，我把我做的架构demo放出来，当然正式版是不能放的（也还没有），那也是公司的版权。

补充两个图：