大数据环境下的高性能分布式计算&存储系统(初探)

参考博文：http://blog.csdn.net/fanyun_01/article/details/50946172

【这个系统的用途】

首先，这套系统是为高并发访问的web页面提供缓存服务的。什么样才算高并发、海量？比如每天的Page View成百万、上千万就肯定算了，高并发请求对数据库直接读/写，数据库肯定扛不住的，数据库挂了网站也挂了(因为前端用户没收到返回数据嘛)。那么就必须由这种缓存系统来为海量并发请求做分发，将不同的请求类型(读请求还是写请求)、按照不同的业务分发到不同的主机上，从而实现及时响应前端访问、均衡负载。

【这套缓存系统的位置】

逻辑上是位于web和数据库之间，那么缓存的数据怎么来？就是在服务器开启的时候，我们会把数据库的大部分数据加载到服务器的缓存中，专供前端的查询(读请求)，那么有新数据来了(例如写请求)也是先放到缓存，当缓存中的将要更新的数据(脏数据)达到一定量了，就批量持久化到数据库中。也就是说服务器的内存承载了读、写请求的缓存，这样一来，每天来自前端用户的几百万、千万次的数据库读/写请求就直接落到了服务器的缓存层，省掉了大量的资源申请、磁盘I/O。

【可行的架构】

【架构简介】

（1）当web后端接收到前端提交的请求，首先将根据一定的规则，通过负载均衡器(例如使用Nginx的DNS调度算法)把该请求送到送到相对“空闲”的master节点服务器。

（2）图中master节点服务器和slave节点服务器的功能

master节点：把已经通过负载均衡器的请求分发到某一个slave节点，再次实现了一道“负载均衡”。具体分发到哪一个具体的slave，是由master节点负责的，master会自动计算出分布式系统中哪台机器相对空闲，即资源充足（CPU、内存等资源）。在大数据场景下，master节点也负责分发需要分布式计算的任务，分发到若干个slave节点，之后再对结果进行合并返回（Map-Reduce原理）。

slave节点：这是实际处理前端请求的服务器。Slave角色的节点运行着管理本机缓存的服务，这样的节点一定是有多个的，以提供高并发和分布式计算的功能。

 

【写操作涉及的数据同步(一致性)问题】

slave节点中的服务进程处理写请求之前，仍然是先通过DNS负载均衡将这个写请求分配到合适的master节点，再由这个master节点将写请求分配到相对空闲的slave，再进一步由此节点中对应的服务进程处理。但是不会每来一个写请求就更新一次数据库，而是每隔一段时间或累积到一定数量的更新数据库任务，再批量地向数据库更新。为了防止还未完成DadaBase更新，slave就挂了，一般是每隔几秒就进行一个批量更新DB，间隔不要太久。

当写请求被负载均衡器经由master节点分配到某一台具体slave节点，再执行DB更新以后，其它slave节点的缓存、数据库也必须要同步更新才行，这就涉及数据同步了。如何做到数据同步？同步机制：当某个slave节点更新一条记录后，slave会向master节点提交Notificaion并通知其它slave节点：告知其他slave的缓存已经过期，需要更新。更新方式有2种：由刚才更新操作的slave节点发送缓存数据给其它slave节点，（2）刚才的slave完成DB更新之后，由其它slave节点从DB加载数据完成更新，这样也能间接地保证数据的一致性。

在大数据高并发场景下，需要将DB中的某些热门业务数据做成多个副本，每个副本分别存放在不同的slave节点的内存当中，那么依赖于这样的节点间的数据同步机制，就能响应频繁的、高并发的读请求了。 

 

【总结一下】

高并发下的大数据读写，尽可能的交给NoSQL型数据库，如HBase或者MongoDB数据库。对于强事务的数据操作，就用RDBMS就好了。MySQL不是不好，当表记录数超过500万，读写性能就疲软了，这时候应该考虑是否需要读写分离，从业务上是否需要考虑分割哪些数据经常要修改的、哪些数据会频繁被查询的、是否有大量的数据写入、是否有大量随机的数据读取。

最后，对比一下SQL型数据库和NoSQL型数据库各自的优势，可以应用到我们的大数据、高并发场景下的分布式存储。

关系型数据库的优点——

保持数据的一致性，可以进行复杂查询而且操作简单；

通用并且技术成熟。

关系型数据库的缺点——

数据读写必须经过sql解析，高并发下读写性能不足；

修改数据时需要加锁，影响并发操作；

无法适应非结构化存储；

扩展困难（最强的关系型数据库管理系统Oracle号称能扩展到100台的集群规模，但仍然无法适应海量数据的场景）

NoSQL数据库的优点——

高并发，大数据下读写能力较强。

支持分布式，易于扩展，可伸缩。

简单，弱结构化存储。

NoSQL数据库的缺点——

不能操作复杂的查询（这一点可以用Spark框架下面的一个组件叫sparkSQL来解决）

事务支持较弱