小周的技术博客

困难是培养伟大心志的保姆,唯有这个冷酷的保姆才会不停地推着摇篮,培养一个勇敢、刚健的孩子。 ---------布赖恩特

【转载】数据平台技术架构

文章转载自: http://www.cnblogs.com/deane163/p/6865911.html

这位兄弟写的,感觉不错,就转载了。

1、系统架构图如下:

blob.png

2、系统各层介绍

 

以上采用五层的逻辑架构,第一层客户层,第二层前端优化层,第三层应用层,第四层服务层,第五层数据存储层,每层的介绍如下:

1、客户层:支持PC浏览器和手机APP,可以直接通过IP访问,反向代理服务器。

2、前端层:使用DNS负载均衡,CDN本地加速及反向代理服务。

3、应用层:网站应用集群;按照业务进行垂直拆分,比如应用商城,产品服务等。

4、服务层:提供公共服务,比如产品升级服务,搜索服务,账号管理服务等。

5、数据层:支持关系型数据库集群(支持读写分离),NOSQL集群,分布式文件系统集群,及分布式Cache

 

3、各部分技术介绍

 

3.1 基础设施技术介绍:

blob.png

分布式缓存

        在高并发环境下,大量的读、写请求涌向数据库,磁盘的处理速度和内存处理显然不在一个数量级,从减轻数据库压力和提高系统响应速度两个角度来考虑,一般都会在数据库之前加一层缓存。由于单台机器的内存资源和承载能力有限,并且如果大量使用本地缓存,也会使相同的数据被不同的节点存储多份,对内存资源造成较大的浪费,因此才催生出分布式缓存。

持久化存储

        随着科技的不断发展,越来越多的人参与到互联网中,人们在网络上的活动,如发表心情动态、微博、购物、评论等,这些信息最终被转换为二进制字节的数据存储下来。面对并发访问量的激增和数据几何级的增长,如何存储正在迅速膨胀并且不断积累的数据,以及应对日益增长的用户访问频次,成为亟待解决的问题。

消息系统

        在分布式系统中,消息系统应用十分广泛,消息可以作为应用间通信的一种方式,消息被保存在队列中,知道被接收者取出,由于消息发送者不需要同步等待消息接收者的响应,消息的异步接收降低了系统集成的耦合度,提升了分布式系统协作的效率,使得系统能够更快地响应用户,提供更高的吞吐。当系统处理峰值压力时,分布式消息队列还能够作为缓冲,削峰填谷,缓解集群的压力,避免整个系统被压垮。

        开源的消息系统有很多,包括Apache的ActiveMQ,Apache的Kafka、RabbitMQ、memcacheQ等。

搜索引擎

         这里说的垂直化搜索引擎,与大家所熟知的Google和Baidu等互联网搜索引擎存在着一些差别,垂直搜索引擎主要针对企业内部的自由数据的检索,而不像Google和Baidu等搜索平台,采用网络爬虫对全网数据进行爬取,从而建立索引并提供给用户进行检索、模糊匹配的需求,解决数据库like查询效率低下的问题,又能够解决分布式环境下,由于采用分库分表或者使用NoSQL数据库,导致无法进行多表联合查询或者进行复杂查询的问题。

其它

        除了前面所提到的分布式缓存、持久化存储、分布式消息系统、搜索引擎,大型的分布式系统的背后,还依赖于其他支撑系统,还包含实时计算、离线计算、分布式文件系统、日志收集系统、监控系统、数据仓库等,还有CDN系统、负载均衡系统、消息推送系统、自动化运维系统等。

 

3.2 基础设施技术技术特点

blob.png

4、开发中的故障案例分析

 

(1)写日志引发的故障:

故障分析:由于日志等级为info或debug,导致产生的日志异常多,磁盘被撑爆。

实例: 在图片服务器的Nginx服务器上,由于日志打印的过多,导致磁盘爆满,最终导致不能写入数据信息。

解决方案: 需要将Nginx的配置信息修改为Error,定时检测磁盘空间是否满,及时增加硬盘空间。

(2) 高并发访问数据库引发的故障:

故障分析:当SQL的执行频率非常高时,会使得数据库的Load持续升高,影响数据库的性能。

解决方案:尽量增加表的索引,减少全表扫描,尝试使用分布式缓存和缓存设备。

(3)高并发情况下,锁引发的故障:

故障分析:由于锁的使用,某个操作,执行时间较长(如远程过程调用),长期占有锁,导致程序阻塞,当这个锁被释放时,其它            线程得以执行。

解决方案:使用锁操作时要谨慎,慎之又慎。

(4)缓存应发的故障

故障分析:由于缓存服务器集群的关闭,导致数据查询的压力全部都到数据库层面,导致数据库的压力较大。

解决方案:缓存服务器是当今网站中不可或缺的一部分,我们要像管理其他服务器一样,认真管理缓存服务器。

(5)应用启动不同步引发的故障

故障分析:由于启动应用服务器的不同步,如 Apahce + Tomcat 应用,服务 Apache先启动,会导致过多的请求到Apache上,导致Tomcat已启动后,过多的请求压力到Tomcat上,严重情况下导致Tomcat的崩溃。

解决方案:要严格按照指定的顺序进行启动应用,避免“姑娘还没有穿好衣服,老鸨就把客人给领进来了”,所以老鸨领客人进来时,要先确认姑娘有没有准备好。

(6)大文件读写独占磁盘引起的故障

故障分析:文件服务器中保存的有大文件和小文件,小文件有几十K  到上百K,大文件有几十M到上百M,会导致用户下载大文件时,独占磁盘操作,影响小文件的读写操作。

解决方案:将图片服务器小的文件,使用专用的存储服务器如阿里的分布式文件服务器,大的文件使用分布式文件服务器如HDFS服务器

(7)滥用生产环境引起的故障

故障分析:开发人员尽量不要对运行环境进行处理

解决方案:将正式库的权限交给运维人员,严禁开发人员对正式数据进行处理。

(8)不规范流程引起的故障

故障分析:应用发布后,引起数据库LOAD迅速飙升,检查用户代码是否有变化,是否缓存给注释掉。如注释掉缓存代码。

解决方案:代码提交前一定要对代码进行DIFF比较,确认没有提交不该提交的代码(如测试注释的代码,正式部署需要使用的)

(9)不好的编程习惯引起的故障

故障分析:程序在处理一个输入的对象时,不明确输入的对象是否为空。

解决方案:要养成好的编码习惯,输入的对象尽量保证不为空,必要时构造空对象。

5、开发过程中的心得体会

blob.png




发表评论:

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。