H.E.'s Blog

   大型互联网站的数据存储与传统存储环境相比不仅是一个服务器、一个数据库那么简单，而是由网络设备、存储设备、应用服务器、公用访问接口、应用程序 等多个部分组成的复杂系统。分为 业务数据层、计算层、数据仓储、数据备份，通过应用服务器软件提供数据存储服务，并且通过监控工具对存储单元监控。

    随着系统中用户数据量的线性增长，数据量将会越来越多。在这样一个数据不断膨胀的环境中，数据已经如洪水般汹涌泛滥。数据查找和调用困难，在海量数据中一些用户提交的请求往往要等到第二天才能得知结果，直接影响到了用户满意度的提升和新业务的布局。在技术上而言，这一特点使得RDBMS在大型应用场景被大幅限制，唯一的可选方案是Scale Out,通过增加多个逻辑单元的资源,并使它们如同一个集中的资源那样提供服务来实现系统的扩展性。

   系统中的数据就好比我们家里的物品，衣服放在衣柜里，碟子放在碗橱里，数据库、存储系统就好比你的衣柜和碗橱是一个存放的容器，衣服和碟子就好比不同的数据，将不同类型的东西放入合适的存储空间里面，这样系统的效率和利用率将会更高，所以我们将会做出如下设计，如图所示：

查看大图请点击这里

对于大型系统存储单元的结构模型我们分为6个部分组成，清单如下：

1. 业务数据层
各类业务所产生的各种文件类型的数据，其中包含 用户信息、用户操作记录、实时业务数据、手机客户端升级应用程序、图片，等。

2. 计算层
针对不同的数据格式、不同类型的数据文件，通过不同的工具、计算方法进行操作，针对大量的数据计算采用一些分布式、并行计算的算法，例如：MapReduce，BSP。并且对一部分的数据进行缓存，缓解对存储应用服务器的压力。

3. 数据存储层
对于海量数据的查询与存储，特别是针对用户行为日志操作，需要使用到一些列式数据库服务器，对于处理业务和一些业务规则的数据依然存放在关系型数据库中，将采用MySQL来存储。

4. 数据仓储
数据存储主要是针对于用户行为日志和用户行为分析，也是系统中数据量产生较大的一个环节，将会采用Apache Hive、Pig、Mathout 对数据仓储进行构建。

5. 数据备份
分为在线数据备份和离线数据备份，数据备份环节需要经过运维经验的积累，根据业务和用户访问量进行定制合理的备份规律。

6. 硬件
硬件环境是存储单元最基础的部分，分为磁盘、内存、网络设备存储，将不同的业务数据、文件存储在不同的硬件设备上。

技术实现
对于系统不同的业务数据和应用服务器的架构需要采用不同的读写方式，以及数据存储类型存放，数据仓储构建，数据冷热分离、数据索引多个部分组成。例如：业务应用程序、日志采集代理、用户空间文件系统（Filesystem in Userspace）。Data Access Proxy Layer(DDAL/Cache Handler)、OLAP、日志服务器、Oracle(暂定)、MySQL、Redis、Hive、HDFS、Moosefs。

如图所示：

查看大图请点击这里

针对以上设计架构，描述清单如下：

1. Data Access Proxy Layer
统称数据访问代理层(简称 DAPL)，封装了DDAL和Cache Handler层，抽象的对编写的应用程序进行了划分，便于扩展和维护，例如：需要对HDFS或者图形数据库操作，上层不需要知道HDFS具体操作，只需要关注提供的接口。DAPL封装了很多访问各种数据源的读写策略。因此，可以保证对不同数据库、数据源操作的事务完整性。

2. DDAL
统称分布式数据访问层(简称 DDAL)主要针对关系数据库的读写分离操作，需要做到读写分离，首先需要对传入的SQL语句进行解析，并且采用Round-Robin算法负载分载对数据大量读取的操作，在代码实现中将使用MySQL-JDBC中的参数配置实现对MySQL-Slave的读取压力分载。

3. Cache Handler
与DDAL的相似，具体区别在于自己实现了Round-Robin算法负载分载对数据大量读取的操作，并且能在Redis Master当机的状态下重新指派新的Master进行写的操作。

4. Redis一主多从
对缓存数据进行读写分离，减少单台机器的I/O瓶颈，值得一提的是Cache不是可靠的存储，所以在设计时，需要容许Cache的数据丢失，因此，Cache的数据全部失效时，会从数据库里重新装载。

5. MySQL双主多从
这种方式是MySQL架构设计中最折中的方案，对数据的访问压力分载和数据的可靠性都有了相应的保障。前端2台Master MySQL相互进行数据备份，后端大量的Slave MySQL对Master写入的数据进行同步，所以每台机器节点上的MySQL数据库中的数据都是一致的，并且DDAL应用程序将数据轮询写入Master MySQL数据库中。

6. 数据库读写分离
主要采用mysql的策略，学习MySQL-Prxoy的策略，自己开发对MySQL书籍节点进行读写分离的方法，MySQL驱动支持读写分离的数据完整性，当数据量超大规模的时候将会采用Sharding策略。

7. 缓存读写分离
缓存Redis的策略，采用自己开发的应用程序需要实现Round Robin算法，对Redis Master和Slave缓存集群进行读写分离操作。

8. ETL Tools
采用Apache Hadoop项目中的Pig对海量的行为数据进行清洗，Pig可以针对有规律的半结构化数据执行类似SQL的脚本，并且可以将计算压力分载到每台服务器上进行分布式、并行处理。

9. Hive集群
针对数据仓库的建设由Apache Hive进行构建，是一个建立在Hadoop上的数据仓库框架，它提供了一个方便的数据集成方法和类似SQL的Hive QL查询语言，实现了Map/Reduce算法支持在Hadoop框架上进行大规模数据分析。

10. HDFS分布式文件系统
Hive中的数据全部存储在Hadoop分布式文件系统中，所有被存储的数据都会有数据的存储副本，这样对数据的可靠性有了保障。

11. Moosefs分布式文件系统
与上面提到的HDFS一个文件系统是有区别的，Moosefs不需要任何客户端程序对分布式文件进行操作的服务器，可以直接与任何运行环境进行对接，而且服务端也有副本复制的功能。

12. 冷热数据分离
将系统中产生的进行归类存放，将用户更多关心、热门话题等内容 抽象为“最近几天”的“热数据”，而越早的数据我们在设计中抽象的分为“冷数据”。由此可见，“热节点”存放最新的、被访问频率较高的数据。对于这部分数据，我们希望能给用户提供尽可能快的查询速度，因此无论在硬件还是软件的选择上都会有了明显的区分，例如：最近常访问频率高的数据将会存储在系统缓存中，需要经常性被的业务数据将会存储在MySQL或者Oracle数据库系统中，

一个运营的系统在正式上线后将会遇到各种层级的高并发请求，因此我们必须对此做出相应的策略和技术解决方案，首先我们需要认清系统的高并发由3个层面导致：

1. 传输层
大量用户对系统请求后，将会造成网络带宽和Web服务器的I/O瓶颈。

2. 计算层
接收大量用户请求进行计算，将会造成业务服务器和业务支撑服务器的瓶颈。

3. 存储层
传输层和计算层将会产生大量的数据，数据量暴增，将会导致数据库和储存上的瓶颈。

针对以上将会造成的系统高并发瓶颈，我们需要采用不同的技术手段解决。

从总体上来看
1.首先需要解决网络带宽和Web请求的高并发，需要合理的加大服务器和带宽的投入，并且需要充分的利用系统中软件、硬件的缓存机制，将能缓存的内容都进行缓存存储，减少计算层和存储层的压力。

2.其次需要对业务服务器和业务支撑服务器进行合理的分层，并且采用并行计算和分布式算法对大量计算进行处理，并且在开发的过程中需要采用Java SDK中并发包(Concurrency)进行编码实现。

3.存储层需要采用分布式文件服务器和列式的存储服务器进行构建，支撑海量数据的存放和读取，并且还要对关系型数据进行深层次的配置参数优化。

4.我们还需要清楚的认识到，将来根据系统运行的状态以及平台中不同的业务场景循序渐进的进行调整和优化。

   对于大型系统来说，采用的技术是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：将会使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。

   但是除了这几个方面，还没法根本解决面临的高负载和高并发问题，所以需要将计算和负载的压力分载到每个计算机上，使用不同的服务器集群机组进行分布式和并行计算，面对所产生的压力，下面这张图清晰的描述了，我们对系统中不同的计算瓶颈采用的不同解决手段，如图所示：

查看大图请点击这里

 

以下描述是针对不同层面产生的计算压力所采用的计算策略，清单如下：

传输层

1. CDN

    网络链路出口进行压力分载，通过CDN让用户访问最近的数据缓存。

2. 智能双路

    针对电信、网通 不同的访问用户访问请求，对应用户访问请求进行服务器带宽的智能切换。

3. LVS

    对用户的请求进行压力分载，并且实现多种负载均衡的策略，也可以选择使用HA-Proxy实现。

4. HA-Proxy

   针对Web服务器进行方向代理，通过HA-Proxy将用户的请求分发到不同的Web服务器上。

5. Long-Polling

    在Web服务器上采用的一种策略，专门针对某个用户需要不断频繁的轮询访问。

6. Session2Cache

    将用户的会话进行集中处理，存放在中央式的缓存服务器当中，减少服务器之间的会话通信

 

计算层

1. MapReduce

   采用最经典的分布式算法对海量数据进行处理，将计算进行分载。

2. BSP

    BSP(Bulk Synchronous Parallel-大型同步模型)算法是基于MPI算法的基础进行演化，运用在系统中并行计算的部分。

3. Result Cache

    将计算的一部分结果进行缓存，缓解对存储层读取的请求。

4. Scatter/Gather

    中间通过一个服务器进行中转，将大量的请求分发给内部的服务器进行计算，类似前端的web反向代理。

 

存储层

1. 读写分离

    由于系统的读大于写的频率，数据库架构采用了1主/多从，双主多从的策略，所以我们将会将读和写进行分离，并且将大量的读请求分散给多台不同的(Slave)服务器。

2. 分区策略

    系统采用不同的时间段作为分区的主要策略，提高对数据的读写性能。

3. Sharding

    一台数据库将很快无法满足大量并发，需要使用库表散列，将数据库中的数据进行分散存储。

4. Column-Based

   使用在海量数据中的查询功能，采用列模式的存储方式将可以有效的提高系统查询效率。

 

 

–end–

 

 

 

无论是战争中的最后胜利，还是最终战死在沙场上，都是我生命中的骄傲。因此，我很喜欢乔布斯说的下面这段话，特别是其中这句“keep looking don't settle”。

   Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. You've got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don't settle.

   有些时候, 生活会拿起一块砖头向你的脑袋上猛拍一下。不要失去信心。我很清楚唯一使我一直走下去的，就是我做的事情令我无比钟爱。你需要去找到你所爱的东西。对于工作是如此, 对于你的爱人也是如此。你的工作将会占据生活中很大的一部分。你只有相信自己所做的是伟大的工作, 你才能怡然自得。如果你现在还没有找到, 那么继续找、不要停下来、全心全意的去找, 当你找到的时候你就会知道的。就像任何真诚的关系, 随着岁月的流逝只会越来越紧密。所以继续找，直到你找到它，不要停下来！

–end—