互联网网站架构升级----消息中间件的实现方案

标签: 互联网 网站 架构 | 发表时间:2011-08-11 01:31 | 作者:(author unknown) liu
出处:http://www.iteye.com

    最近一直比较忙,前面设计的架构完成了基本的实现,最近工作重心发生了点转变,偷闲来继续前面的话题;

    这一篇博客准备聊聊消息系统,消息中间件对目前大中型互联网来说是非常重要的,在业务数据流动中仅次于RPC服务调用,担负着越来越复杂的网站业务从主流程上解耦的重要责任;

    从目前互联网对消息中间件的需求来看应该分为两种类型,一种是和钱相关的需求,一种是和钱无关的需求;和钱相关的需求消息的可靠性是放在第一位的,和钱无关的需求是速度放在第一位的,但这两种需求又是矛盾的,很难设计出一种既可靠又高效的系统,除非将两套方案捏合成一个系统,通过配置来选择不同方案,但从实现上说还是两种实现。所以目前业界有几种不同的设计方式来满足不同的需求。

下面看看以下几种典型实现方案:

1、以ActiveMQ为代表的可靠性优先的设计原理:

    此种方案将所有的消息数据和消息的发送状态都存储在消息服务器上,可以在消息服务上通过多种手段来保证消息的可靠性,但增加了众多复杂的可靠性保证手段后,消息从发布者到订阅者的速度势必会受到影响;此种方式发布者将消息推向消息服务器,消息服务器再将消息推向订阅者,为消息发送策略提供了很好的可扩展性;

2、以KafKa为代表的速度优先的设计原理:



    此种方式将消息的发送状态保存在客户端,同时客户端用拉的模式从消息服务器上获取消息,由于是顺序读,同时还采取了很多保证速度的策略,如zero-copy,所以此种方案速度比较快,但牺牲了很多可靠性方面的保证,比较适合Web2.0网站,这些网站对消息的可靠性要求不是很高,同时由于产生了大量的和用户状态相关的消息,需要一个高效的系统来处理这些消息;另外这种方案也比较适合日志消息的收集;


3、传统的系解耦方案:



    此种方式是不用消息中间件直接用数据库存储做的解耦,随着消息中间件的出现,这种方式的使用越来越少,但现在由于MongoDB和Redis等的兴起,一些基于这些Nosql数据库的消息应用逐渐兴起,由于消息数据和消息状态都存储在DB上,所以效率和速度在上面两种方案之间;

 

    那么有没有一种更高效的方式呢?

 

    答案是肯定的,但那可能要进一步降低可靠性!

 

    看看Facebook的Scribe日志收集系统的原理:

 

 

    如果Scribe Server正常工作,Scribe Client将App的日志(可以看成一个消息)推送到Scribe Server端,如果不正常,则写到本地文件,当Scribe Server恢复正常时再将其推送过去;这里使用本地文件作为缓冲,那么能否综合Scribe和Kafka的优点来设计一个消息系统(或日志收集系统,改造一下可以互用),看下面的方案:

    上面的MQ暂且叫他FastMQ吧,中消息发布端直接写本地文件,同时消息订阅者通过Zookeeper协调,向相关消息发布者的Agent拉消息,并在本地记录消息指针状态;

    如果嫌在消息发布端开启MQ Agent麻烦,那么如中消息拉取协议使用SCP或FTP协议,用这些Linux必备的协议提供者作为Agent减少开发和部署的难度,在服务订阅端解析这些协议流,反序列化为消息供业务使用;

    如果觉得消息只存储在消息发布端的磁盘不可靠,那么如中可以在消息订阅者处理不及消息的时候,把消息数据缓冲在消息订阅端的磁盘上来备份数据,不过这样做就使系统变的复杂,虽然提高了可靠性,但是速度就会有所降低;

 

    此种方案可以使消息分散的存储在业务本身的磁盘上,避免集中存储相互影响的缺点,同时又可以有效利用业务机器的磁盘(大部分业务机器磁盘基本没使用),另外还可以减少一次网络通信的过程,使从发送到接收的速度更快;但其本身也有不少缺点,要做好监控,避免消息大量积压的时候业务磁盘过度使用,对业务造成影响。

 

     目前我们的监控日志收集系统使用的是和中类似的方案,消息系统使用的是3方案,后期可能会将可靠性要求高的向1方案过度,可靠性要求不高的向最下面介绍这种过度!

 

 



作者: javatracker 
声明: 本文系ITeye网站发布的原创文章,未经作者书面许可,严禁任何网站转载本文,否则必将追究法律责任!

已有 9 人发表回复,猛击->>这里<<-参与讨论


ITeye推荐



相关 [互联网 网站 架构] 推荐:

互联网网站架构升级----消息中间件的实现方案

- liu - ITeye论坛最新讨论
    最近一直比较忙,前面设计的架构完成了基本的实现,最近工作重心发生了点转变,偷闲来继续前面的话题;.     这一篇博客准备聊聊消息系统,消息中间件对目前大中型互联网来说是非常重要的,在业务数据流动中仅次于RPC服务调用,担负着越来越复杂的网站业务从主流程上解耦的重要责任;.     从目前互联网对消息中间件的需求来看应该分为两种类型,一种是和钱相关的需求,一种是和钱无关的需求;和钱相关的需求消息的可靠性是放在第一位的,和钱无关的需求是速度放在第一位的,但这两种需求又是矛盾的,很难设计出一种既可靠又高效的系统,除非将两套方案捏合成一个系统,通过配置来选择不同方案,但从实现上说还是两种实现.

Facebook 网站架构

- - idea's blog
我收集到一些文章和视频, 可以带你窥探 Facebook 的架构. Facebook 承载了几十亿的用户, 它的架构(包括思想和实现)是非常值得参考的. 当然, 你要小心不要照搬 Facebook 的每一字一句, 因为任何思想和实现都是有自己的应用场景的.. Google Talk 界面开发分析. 使用Python POST任意的HTTP数据以及使用Cookie.

淘宝的可伸缩高性能互联网架构

- 浪客 - 博客园-首页原创精华区
一 应用无状态(淘宝session框架).          假如在session中保存了大量与客户端的状态信息,保存状态信息的server宕机时.          通常通过集群解决,不仅有负载均衡,更重要的是要有失效恢复failover.          tomcat用集群节点广播复制,jboss用配对复制等session状态复制策略,但严重影响系统的伸缩性,不能通过增加更多的机器达到良好的水平伸缩.

一个移动互联网应用地图服务架构

- Ian - 出家如初,成佛有余
    在移动互联网中,各种与位置相关的服务都严重依赖于地图服务,地图服务质量的好坏很大程度决定了所提供服务的高低. 尽管有Google Map等免费或收费的地图服务可供使用,但没有那一家地图服务提供商能够完整提供移动互联网应用所必须的各种地图服务及数据,尤其是针对那些垂直行业应用.     在中国特色的制度下,除了技术因素外,值得注意的是由于地图牌照发放问题带来的政策上的不确定性对架构实现的冲击和挑战.

中大型移动互联网公司技术架构选择

- - 五四陈科学院
以下内容由 [五四陈科学院]提供. 总结这些年经验,进行构架演进的方向选择时,大致要做到下面的目标:. 可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用,并可在公网访问). 天然可扩展(业务层无状态,尽可能全部放到最后). 自动化(内存不足了,除了报警,应该自动加点机器进去; 新的项目,基础代码应该都不用写,自动生成即可).

[转][转]互联网系统架构的演进

- - heiyeluren的blog(黑夜路人的开源世界)
来源: http://www.csdn.net/article/2013-08-27/2816716. 摘要:多终端接入、开放平台给互联网带来了前所未有的用户数量和访问规模,信息之多、传播速度之快,是传统网站难以想象的. 本文将从发展演进的角度,解读高性能互联网系统架构. 多终端接入、开放平台给互联网带来了前所未有的用户量级和访问规模,SNS网站产生了海量的UGC(用户产生内容),而且这些内容依托关 系链扩散速度之快、传播范围之广是传统网站难以想象的,海量数据的计算存储也一直是近年互联网领域的热点.

移动互联网系统架构十大陷阱

- - 五四陈科学院-坚信科学,分享技术
以下内容由 [五四陈科学院]提供. 过去的三年,54chen一直奋斗在中国移动互联网一线,历经各种坑爹的情况. Top 1.时不我待 连通性. cmwap cmnet这样的词语以后应该都会消失在人世间. 三年前,经常性地有移不动联不通手机连不上服务器机房的情况. 相信未来会越来越好,时代在召唤. Top 2.生不逢时 HTML5.

[转]各大互联网公司架构演进之路汇总

- - 鸟窝
原文地址: 各大互联网公司架构演进之路汇总 by HollisChuang. 请转载时务必保留文章的上述原始出处. 支付宝和蚂蚁花呗的技术架构及实践. 支付宝的高可用与容灾架构演进. 聚划算架构演进和系统优化 (视频+PPT). 淘宝交易系统演进之路 (专访). 淘宝技术发展历程和架构经验分享(视频+PPT)(2.3日更新).

互联网时代,我眼中的架构变迁

- - SegmentFault 最新的文章
作者简介:黄庆兵,网易蜂巢首席技术布道师,浙大硕士毕业,从事云计算、Docker、Go等相关开发及技术布道工作;喜欢开源,乐于分享,勤于布道,折腾过开源小工具,制作过Docker课程,分享过 Gopher Meetup. 互联网在变,架构也在变,架构的变迁亦是互联网的变迁. 所以,我们有必要来聊聊互联网的架构及其变迁.

互联网架构,如何进行容量设计?

- -
互联网公司,这样的场景是否似曾相识:. 场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题:. (2)如果扛不住,需要加多少台机器. 场景二:系统设计阶段,技术老大杀过来,又问了两个问题:. (2)如果需要分库,需要分几个库. 技术上来说,这些都是系统容量预估的问题,容量设计是架构师必备的技能之一.