大数据环境下的高性能分布式计算&存储系统
来源:互联网 发布:现金返利系统源码 编辑:程序博客网 时间:2024/05/28 05:16
参考博文: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来解决)
事务支持较弱
- 大数据环境下的高性能分布式计算&存储系统
- 高性能分布式计算与存储系统设计概要(下)
- 高性能分布式存储系统的核心
- 高性能分布式计算与存储系统设计概要
- 高性能分布式计算与存储系统设计概要(上)
- 高性能分布式计算与存储系统设计概要
- “大数据分布式存储系统”培训
- 分布式存储系统大数据同步方面的两个问题
- 大数据存储系统(1)--- 分布式文件系统
- Tachyon:一个高性能、高容错、基于内存的开源分布式存储系统
- 【实践】基于Ceph打造高性能高可靠的分布式块存储系统
- 大数据,高并发环境下的数据问题解决
- 高并发分布式计算与存储系统设计(一)
- 高并发分布式计算与存储系统设计(二)
- 高性能、大数据、分布式运算概念入…
- 大数据环境下的云计算与物联网
- spark云计算环境下的大数据
- Google 三大论文中文版之一个分布式的结构化数据存储系统
- 走向大神之路的必备git命令操作
- Unity之性能优化——不断更新
- 漫谈数据质量监控
- python工作环境搭建----安装pyqt4(基于win10)
- Swift
- 大数据环境下的高性能分布式计算&存储系统
- 路过万重山
- 简单的理解Activity生命周期
- 3数和为0问题
- 6.错误处理
- Linux-sudo命令详解
- Centos7下多网卡的路由转发配置
- Leetcode: Search in Rotated Sorted Array & II
- npm源管理