H-Store分布式内存数据库学习(一):从12306说起

标签：map   pad   本地   gfs   分析   一段   程序   分布   部署   

•        前言
        记得12306网站刚刚上线的那年，春节时的高峰购票让网站瘫痪，当时很多人愤愤于花了国家那么多钱，弄出的系统那么烂。作为程序人员的一员的我，却觉得很坦然。因为当时虽然淘宝能够经受住双12的冲击，但是购票业务的业务特征和购物差异很大，不是简单的更新库存这么简单，并且购票系统还有那么多窗口系统和各地代理系统的压力。作为首次接受大考，出现问题，很正常。不出现问题，那几乎只能说是做梦。何况当时的基于互联网架构的事务处理系统的技术，除了几个巨头之外，运用到炉火纯青地步的，没有几个。而业务特征的不适应，也让一些基于互联网的高性能技术无用武之地。所以，在当时有些人轻易抛出“要是给我XXXX,我一定XXXX”的豪言壮语一笑了之。
         时至今日，12306网站经过大规模的技术升级，其在购票高峰的的表现不得不让人刮目相看。我也从心底里佩服其采用的技术方案的优秀。作为技术人员，虽然多年碌碌无为，但是还是有一颗追求进步的心灵，所以，在这里记录下基于此而对于分布式内存数据库的学习，也算是一种自我激励吧。

•             12306的核心支点
            古代一位先哲说，他可以用一根棍子翘起地球，只要给他一个支点。而对于12306而言，这个支点是什么？？？答案是：GEM-FIRE。简单了说，它是一个分布式内存库。分布式内存的东东，可以说一点儿都不新鲜。因为MEMCACHE这个词让很多人耳朵都起茧子了估计，还有REDIS,对吧。 GEM-FIRE这个东东有些人听说过，不过有些人没有。但是很多人可能要喷说都是内存，分布式，而且REDIS很优秀了，LZ就不要再显摆了。但是，我真的要说，事情不是你想的那个样子的。为何我要提12306,只因为一个：OLTP. 我之所以要从12306说起，是因为其巨大的峰值事务处理需求，并且这种事务是复杂事务。一张车票含有很多个分段，每一段都可能发售，由于预售时间的安排导致的峰值冲击远远超过平常。做过电信或者金融类的兄弟可能对复杂事务有所体会。12306的峰值压力有人估算过，LZ记不太清楚了，但是请记住，比淘宝的面临的问题要复杂多。
           在12306首次考试没有及格之后，在广大群众的一片口水中，12306考察了不少商业的方案(12306自身的技术储备几乎不可能先考虑开源的方案)，最后，以x86通用服务器为硬件平台(成本低)，以分布式内存为特征的GEM-FIRE方案成功胜出，12306的主题支撑逐步过渡到以GEM- FIRE为核心的平台上。这也激发了lz的好奇心，圣人有言，身虽不至，而心向往之，咱自己虽然没那么厉害搞一个出来，总可以学习下吧。于是搜索带一个叫 voltDB的东东，进而搜索到H-Store这个东东。好了，开源就是好，这意味着智力成果的传播成本迅速降低，落后地区的文明水平可以更快的提高。好了，让我们开始吧。

•           GEMFIRE---来自Pivotal的礼物
           GEMFIRE是一个来自于Pivotal 公司的产品，Pivotal公司的一大股东是EMC,另一个是大名鼎鼎的VMware.同学们，尤其是对于hadoop,gfs,hdfs等词很熟悉的同学们，虽然我承认这些东西都很牛叉，但是，Pivotal 这个公司也同样牛叉，虽然他的东西没开源，虽然这个公司的名字没有gfs那么高的曝光率，但是，他们在云计算领域，尤其是商用领域的实力是很厉害的。 GEMFIRE相对于我们常见的分布式存储方案，比如REDIS这个目前为止开源的分布式内存解决方案中最优秀的产品，杀手的特点就是没有放弃或者弱化事务特征。虽然有人会拿CAP来说事，我不想说CAP，但是GEMFIRE就是针对性的高性能OLTP方案，而其他的内存解决方案是不会这么提的。亲们，OLTP这词都懂得是啥意思，但是你把握住本质了吗？至少我觉得Pivotal和他们的GEMFIRE把握住了---那就是T。下面简单的介绍下 GEMFIRE.它的曝光率不高，但是这不妨碍我们看看。当然，我这里的介绍也是引用，请勿鄙视，我也是学习。

下面是对于Gemfire的特性的一个梳理(素材来源于官网)。

H-Store分布式内存数据库学习(一):从12306说起

标签：map   pad   本地   gfs   分析   一段   程序   分布   部署   

原文地址：http://www.cnblogs.com/lanyuflying/p/4442896.html