分布式消息总线比较"/>
分布式消息总线比较
应用场景:
l分布式组件/系统相互通信 l数据复制、同步 ldelay queue l广播通知
案例分析:基于消息的分布式架构
对分布式消息系统机制的分析好文:
.shtml:
我们再来看微博的方案,所以我们自己实现了一个多机房同步的方案。就是我们前端应用将数据写到数据库,再通过一个消息代理,相当于通过我们自己开发的一个技术,将数据广播到多个机房。这个不但可以做到两个机房,而且可以做到三个、四个。具体的方式就是通过消息广播方式将数据多点分布,就是说我们的数据提交给一个代理,这个代理帮我们把这些数据同步到多个机房,那我们应用不需要关心这个数据是怎么样同步过去的。
用这种消息代理方式有什么好处呢?可以看一下Yahoo是怎么来做的?第一个是数据提供之后没有写到db之后是不会消失的,我只要把数据提交成功就可以了,不需要关心数据怎么到达机房。第二个特点YMB是一款消息代理的产品,但是它唯一神奇的地方是为广域网设计的,它可以把多机房应用归到内部,我们应用不需要关注这个问题。这个原理跟我们目前自己开发的技术相似。
我们看一下推送架构怎么从架构底层做到实时性的。从左上角的一条微博在我们系统发布之后,我们把它放在一个消息队列里面,然后会有一个消息队列的处理程序把它拿过来,处理以后放到db里面。假如说我们不做持久化,因为我们推送数据也不能丢失,我们就要写一个很复杂的程序,将数据异步去存,这样就会非常复杂,而且系统也会有不稳定的因素。从另外一个角度来说,我们做持久化也是做过测试的。我们推送整个流程可以做到100毫秒和200毫秒之间,就是说我们在这个时间能把数据推送出去。
对于一些商业网站,其需要在上海、北京、美国等多点部署,采用消息总线可以解决数据一致性问题,当发生写操作时,数据除了被存储到本地,同时放到消息队列中,这样可同步到其他数据中心。
Kafka
Kafka Architecture Design:.html#design
译文:
=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global
Apache Kafka:下一代分布式消息系统
Kafka是一个消息系统,原本开发自LinkedIn,用作LinkedIn的活动流(activity stream)和运营数据处理管道(pipeline)的基础。现在它已为多家不同类型的公司 作为多种类型的数据管道(data pipeline)和消息系统使用。 活动流数据是所有站点在对其网站使用情况做报表时要用到的数据中最常规的部分。活动数据包括页面访问量(page view)、被查看内容方面的信息以及搜索情况等内容。这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件,然后周期性地对这些文件进行统计分析。运营数据指的是服务器的性能数据(CPU、IO使用率、请求时间、服务日志等等数据)。运营数据的统计方法种类繁多。 近年来,活动和运营数据处理已经成为了网站软件产品特性中一个至关重要的组成部分,这就需要一套稍微更加复杂的基础设施对其提供支持。 |
活动流和运营数据的若干用例
|
支持多数据中心,但采用镜像技术,实时性等各方面会有问题,本质还是各中心独立
Hedwig
.html
.0.0/hedwigUser.html
RabbitMQ
/(负面消息)
ActiveMQ
使用到消息总线的场景:
l分布式事务 l数据复制 l日志同步 ldelay queue l广播通知更多推荐
分布式消息总线比较
发布评论