Feed消息队列架构分析
- - Tim[后端技术]最近一两年，大部分系统的数据流由基于日志的离线处理方式转变成实时的流式处理方式，并逐渐形成几种通用的使用方式，以下介绍微博的消息队列体系. 当前的主要消息队列分成如图3部分. 1、feed信息流主流程处理，图中中间的流程，通过相关MQ worker将数据写入cache、Redis及MySQL，以便用户浏览信息流.
Feed消息队列架构分析
标签：
data
kafka
mq
storm
| 发表时间：2014-12-11 23:30 | 作者：Tim
出处：http://timyang.net
最近一两年，大部分系统的数据流由基于日志的离线处理方式转变成实时的流式处理方式，并逐渐形成几种通用的使用方式，以下介绍微博的消息队列体系。
当前的主要消息队列分成如图3部分
1、feed信息流主流程处理，图中中间的流程，通过相关MQ worker将数据写入cache、Redis及MySQL，以便用户浏览信息流。
2、流式计算，图中左边的流程，主要进行大数据相关实时处理。
3、多机房处理，将数据分发到多个机房，由于微博使用了一种多机房数据对等架构，通过消息队列将数据同步到多个机房。
系统的主要单元
mq：消息队列，新浪的memcacheq，是一种单机的类似redis queue的一个队列系统。
firehose：微博数据统一队列，使用http及memcache协议，且支持at-least-once投递保证，类似Apache Kafka
worker：队列处理程序，自己开发的程序，完成特定的任务如数据入库，类似Apache Storm的bolt。
架构主要特点
实时性：所有的数据在100ms之内处理完成，包括存储型任务。
可扩展性：系统主要单元mq, firehose, worker都是无状态设计，因此可以线性扩展。
可用性：由于上述的无状态设计，可用性可达 99.999%，自动failover，无单点。
数据流设计特点
统一的数据推送通道 firehose
统一的标准化的格式，所有数据采用内部的protocol buffers格式输出
目前在实时数据流及处理方面存在多种技术，为什么没有采用相关成熟的解决方案？
LinkedIn Databus
LinkedIn databus主要原理是基于数据库变化事件的触发写入一个统一的databus，所有的业务都消费databus，和firehose解决的问题比较类似，不过firehose是业务主动写入的事件，在早期做多机房架构时候也曾经尝试过类似databus数据库触发方案，但在一个高度拆分的数据库场景中，一个业务的操作可能对应多个数据库操作（比如修改索引表和实体表），多个数据库操作并没有严格的时序性。因此基于数据库的变化的事件比较难实时合并成一个完整的业务事件。而通过业务写入事件只需要一个简单的mq操作写入即可，因此在数据库有复杂拆分的场景下，业务独立写入变化事件结构上更简单，也保证了事件本身的原子性。
Storm
Apache Storm是和微博架构同一时间发展的技术，主要对worker的管理抽象成一个框架，支持任务调度，任务容灾，任务多级传递（bolt A处理完后传递给bolt B），数据转换从worker中分离出来变成独立的spout。对于一个复杂且数据源多样的环境，Storm确实具有更好的优势。
Kafka
Apache Kafka是一个分布式的消息队列产品，支持按照partition线性扩展，投递上也默认at-least-once。而图中Firehose是一种面向feed业务的消息服务，同时根据社交关系的特点，还具备根据关系将数据fan-out的能力。
PS：
1、上述内容会在 2014.12.19 ArchSummit Beijing 大数据feed架构演讲中介绍，欢迎参会的同行前来交流。
2、有关大数据及流式计算，可参阅前微博同事张俊林的《 大数据日知录》一书。
相关 [feed 消息队列 架构] 推荐：
Feed架构-我们做错了什么
- - Tim[后端技术]在过去几年，所在的微博技术团队在一定程度成功解决了feed架构的扩展性与性能的问题，大部分精力已经从应对峰值性能或者数据扩展中解放出来. 几天前，拿着上面这张架构图问内部一些架构师，目前完成的工作及存在的主要问题是什么. 完成的工作不出意料，大家的观点比较类似，主要在架构的工程成熟度方面. 解决了数据规模大且长尾访问的问题，通过按时间线的冷热分区设计，在MySQL等数据库上成功实现了低成本的长尾分区实现.
Pinterest的Feed架构与算法
- - 后端技术 by Tim YangPinterest首页的Feed消息流，最早是按照用户的关注对象的Pin（类似微博）聚合后按时间进行排序（自然序，类似朋友圈），后来版本的feed系统放弃了自然序，而是根据一定规则及算法来设计，内部称之为Smart feed，其算法及架构根据其公开资料整理如下，值得业界做信息流产品的技术架构师参考.
微博feed系统的推(push)模式和拉(pull)模式和时间分区拉模式架构探讨
- 荷泽 - 博客园-草屋主人的blog微博feed系统的推(push)模式和拉(pull)模式和时间分区拉模式架构探讨. [文章作者：孙立 链接：http://www.cnblogs.com/sunli/ 更新时间：2010-08-24]. sns系统，微博系统都应用到了feed（每条微博或者sns里的新鲜事等我们称作feed）系统，不管是twitter.com或者国内的新浪微博，人人网等，在各种技术社区，技术大会上都在分享自己的feed架构，也就是推拉模式（timyang上次也分享了新浪微薄的模式）.
快速的消息队列 SquirrelMQ
- Le - 开源中国社区最新软件SquirrelMQ是一个快速的消息队列. SquirrelMQ VS Redis 入队列： SquirrelMQ：100万条数据，105S，内存使用84MB. Redis：100万条数据，156S，内存使用127MB. 出队列： SquirrelMQ：100万条数据，230S. Redis：100万条数据，163S.
redis作为消息队列的使用
- - ITeye博客在redis支持的数据结构中，有一个是集合list. 对List的操作常见的有lpush lrange等. 在这种常见的操作时，我们是把集合当做典型意义上的‘集合’来使用的. 往往容易被忽视的是List作为“队列”的使用情况. 反编译redis的jar包，会发现：. pop意为“弹”，是队列里的取出元素.
高可用消息队列框架ZBUS
- - 企业架构 - ITeye博客我们在日常开发中可以需要用到消息队列 当然我们完全可以自己写一个生产者-消费者框架 但是高可用性、实时性已经大量数据堆积时候就显得问题捉襟见肘了下面推荐的框架在我时间项目中和测试中都是非常不错那么他是什么框架呢. zbus git地址. http://git.oschina.net/rushmore/zbus ZBUS=MQ+RPC 服务总线 1)支持消息队列, 发布订阅, RPC, 交易系统队列适配 2)亿级消息堆积能力、支持HA高可用 3)无依赖单个Jar包 ~300K 4)丰富的API--JAVA/C/C++/C#/Python/Node.JS多语言接入，支持HTTP等协议长连接入.
[转]消息队列的两种模式
- -Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信. 点对点与发布订阅最初是由JMS定义的. 这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅).
消息队列设计精要
- - 美团点评技术团队消息队列已经逐渐成为企业IT系统内部通信的核心手段. 它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一. 当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发的Notify、MetaQ、RocketMQ等.
深入浅出 消息队列 ActiveMQ
- - 编程语言 - ITeye博客ActiveMQ 是Apache出品，最流行的、功能强大的. 即时通讯和集成模式的开源服务器. ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现. 提供客户端支持跨语言和协议，带有易于在充分支持JMS 1.1和1.4使用J2EE企业集成模式和许多先进的功能.