2010冬日里的一次顾问咨询后记

大约在去年冬季受到一位仁兄的推荐，邀请我帮助某大型垄断国企做一次系统架构方面的优化工作，客户期望将原有分散在全身每个地市的oracle数据库进行集中，并对集中后的数据库构建集群环境，做到压力分载和失效转发的目的，在系统架构上做出了改动，所以免不

  大约在去年冬季受到一位仁兄的推荐，邀请我帮助某大型垄断国企做一次系统架构方面的优化工作，客户期望将原有分散在全身每个地市的oracle数据库进行集中，并对集中后的数据库构建集群环境，做到压力分载和失效转发的目的，在系统架构上做出了改动，所以免不了代码上也需要做出相应的修改，对方要求我包揽整个过程包裹顾问和方案实施，于是对方开出的实施顾问的价码足以让人信服，为了自己在朋友圈的口碑、为了对得起客户方开出的价码，克服一切困难将任务执行到底。
 
 我的废话：
  这个项目的难点在于
    1.关键性业务表每月每个地区产生的数据量有2T，13个地区就是26T的数据量，保存一年的数据，再乘以12个月，海量数据需要存储。
    2.BT要求，所有数据只允许放在一个数据库中，再多的机器也是从节点，对于海量查询需要根据业务进行SQL、数据库性能优化。
    3.全省所有的数据都集中后，存储量和计算的压力都在一个计算中心的节点上，数据量和访问量比以前大，不能比改造前的性能低。
    4.架构改动，代码必改，客户的领导发话又不让大改，所以2难。
    5.人事上，领导太多，领导与领导之间意见不统一，说起来话来都是专家，落实下去有点囧。
 
整个实施历经4月个还算顺利，本来想找个机会写写这次的经历心得，但是怕给自己或者朋友惹来不必要的麻烦而断了后续的服务，虽然脑海中一直不断回想当时的实施过程，有些地方还算做的不够完美，还可以继续优化，想把这些东西记录下来，但是思前顾后想来想去却不知如何去写。

正好前些日子有位网友看见了我的blog，向我提问关于日志系统需要使用到hadoop和mysql的问题，于是我回问到为何需要使用hadoop的原因，经过一番了解，我建议对方采用缓存+文档数据库的方案，我向这位网友提出的方案可以看做是那个大型垄断国企方案的一个缩小版，除了具体使用的具体技术和产品有差别以外，2者从总体设计思想上大同小异，而且场景也比较相似，对数据库读、写基本不在同一个时段，不论写和读对数据库的操作还是开销比较大的，因此我想借用这位网友的提问阐述对上一次实施中的部分经验分享。
 
这位网友在来信中写到：
    您好，我最近在处理web日志的事情，涉及大量日志的处理，然后在网上搜到你关于Hadoop和Mysql的文章，想向你请教如何将Hadoop和Mysql结合起来处理大批量数据的，网站每个新闻页嵌入了一段js统计代码，每次页面打开时这段代码会在apache服务器端的文件记录一条日志(关于访客的详细信息)，然后后台服务器每隔一段时间将日志文件打成压缩包；同时服务器端每隔一个小时会运行一个jar文件，这个jar文件作用是将压缩包解压，并解析每一条日志信息，同时将日志信息分解后插入mysql数据库。前台可以浏览日志分析图表。现在的问题是随着网站流量越来越大，单台服务器已经不能满足要求了，jar文件现在处理压缩包的时间越来越长，所以考虑网站流量未来几年的增长，想到用数台服务器来处理这个问题。想用hadoop来在每台机子上处理这个压缩包文件，同时将处理好的日志字段写入mysql中。不知道问题我是否解释清楚了。

我回信中写到：
    你好，我只能给你一个方向上的指引，首先hadoop做这样的事情不值得 ,有点大材小用，不是上pb级别的数据量使用hadoop划不来的。
    我建议你是否可以采用这样的一种方案：
        1.前端JS通过http协议调用 Java/REST程序，获得请求
        2.Java/REST程序将获得的数据写入memcached中，将memcached作为缓冲区，
        3.另一个程序作为一个轮询的定时器，可以根据时间范围或者数量级别判断memcached上限的阀值，
        4.到达上限的时候一次性将数据写入mongoDB，如果写入数量较大还可以采用多线程的方式，
        5.最后从mongDB中查询存储的结果。
        6.如果不想使用mongoDB使用mysql也可以，到时候再对mysql对优化，例如：多块物理磁盘分区，mysql参数调整，读写分离。

大致的系统架构：
                 |                                                                                                                             
                 |                   |—>tomcat 1   ———-                                                                       
       js—-http–>loadbalance|                           | ——>memcacheDB/NOSQL
                 |                   |—>tomcat  N+1——–                                    multithread
                 |

这样做的理由是 ：
    1.写入日志和分析读取日志不是实时的，完全可以采用异步架构，我建议中间通讯采用http，将来扩展方便。如果将来前端的请求日志系统的并发量很高，可以选用 类似 tomcat+haproxy、tomcat+apache的方案，分载前端请求压力。
    2.采用memcached是为了提高写入的效率，写入比读更占用O/I资源，将平凡写入的数据放入缓存/内存，让数据更靠近CPU这是黄金原则。
    3. 不论是nosql还是mysql批量写入和一次一次写入所产生的开销大小这个差距是不用质疑的。

我的废话：
    希望通过这个blog能与业内更多的同行们得到交流，再次感谢您的阅读。

–end–
 

原文地址：2010冬日里的一次顾问咨询后记, 感谢原作者分享。