在基础组件层,我们直接使用了一些业界著名的框架和类库,比如 IoC 框架 Spring、日志
Log4J 等;同时也基于一些框架进行了二次开发,比如基于 Redis 提供了分布式会话和分
布式缓存,有效地解决单机内存及 I/O 瓶颈问题。在数据存储层,我们数据存储主要使用
关系数据库 MySQL、文档数据库 MongoDB、分布式存储 HDFS 以及自行研发的 DFS 文
件系统。在数据访问层,基于 MySQL 数据库和 MongoDB 数据库,分别提供了一套分库
分表框架,使得其支持海量数据存储,同时也分别提供了 ORM 框架,使得能够很容易地
完成数据库中的数据到对象的映射。在数据计算层,离线计算方案主要使用了
HadoopMapReduce 框架,流式计算方案主要使用了 Kafka 和 Storm。在接口交互层,提
供了三种框架,分别支持 Thrift、WebServices 和 HTTP/JSON 三种交互方式。在基础服务
层,提供了认证、授权、配置、分布式任务调度、消息、图片、短信和邮件等多种基础服
务。
下面分别介绍我们在数据库分库分表框架、分布式任务调度平台和分布式 RPC 框架上的实
践。
数据库分库分表框架:Compass
互联网领域针对大数据存储,基于 NoSQL 的数据库越来越多,然而,在一致性、事务性、
可靠性等方面,特别是在较复杂的业务场景中,关系数据库仍起着不可替代的作用。在关
系数据库领域,MySQL 数据库基本上主导了市场。然而,互联网面临着用户多、数据量大
等的挑战,一组 MySQL 数据库集群无法支撑如此大的 PV 及 I/O,因此对单表的数据量以
及每台机器的数据分布需要做一定的预估。在我们的实践中,对于单表的数据量有一些约
束。一般说来,对于定长的记录,单表数据量最好不超过 800W,极限不超过 1000W;对
于不定长记录,单表数据量最好不超过 500W,极限不超过 800W,否则在较复杂的业务
场景中,可能会引起性能下降。
对于大规模数据的存储和访问,一般都采用分库分表的方案解决。主流互联网公司都提供
了各自的解决方案,比如淘宝分布式数据层 TDDL、百度 Dbproxy 等。我们也研发了数据
库分库分表框架 Compass,支持和满足内部的一些需求。
一般来说,数据库分布分表框架的设计有两种方案:独立中间件层方式和嵌入式应用框架
方式。独立中间件层方式采用独立的部署,后端数据库对应用程序是透明的,其扩容对应
用的可用性不会有明显的影响。嵌入式应用框架方式是独立的类库,应用需要显式地配置
后端的单个或者多个数据库。独立中间件层方式的开发和维护成本都较高,且多了一层网
络开销;嵌入式应用框架方式数据库配置较为复杂一些,但其开发维护成本低,并且对单
元化架构的支持也不错,因此 Compass 选用了嵌入式应用框架方式。
评论0
最新资源