RocketMQ
StackOverFlower
18年硕士毕业,就职于字节跳动,直播中台研发,负责榜单、红包等服务。
展开
-
分布式消息队列RocketMQ源码分析之2 -- Broker与NameServer心跳机制
我们知道,Kafka是通过ZK的临时节点来监测Broker的死亡的。当一个Broker挂了之后,ZK上面对应的临时节点被删除,同时其他Broker收到通知。 那么在RocketMQ中,对应的NameServer是如何判断一个Broker的死亡呢? NameSrv监测Broker的死亡 机制之一:监测连接断掉 当Broker和NameSrv之间的长连接断掉之后,下面的Chan转载 2017-04-19 23:02:16 · 926 阅读 · 0 评论 -
分布式消息队列RocketMQ源码分析之1 -- Topic路由数据结构解析 -- topicRoute与topicPublishInfo与queueId
在前1篇RokcetMQ与Kafka架构差异一文中,我们已经讨论了2者在Topic的路由结构,也即topic/partition与物理机器的映射关系上的巨大差异。这个差异也是2者在架构上的一个巨大差异点,也是导致RocketMQ可以去除ZK依赖的一个重要原因。 本篇将接着这个话题,进一步从源码角度深度解析Topic的路由数据结构。至所以把“topic路由结构“作为源码分析的首篇,是因为这个话转载 2017-04-16 16:49:21 · 2156 阅读 · 0 评论 -
分布式消息队列RocketMQ与Kafka架构上的巨大差异之1 -- 为什么RocketMQ要去除ZK依赖?
我们知道,在早期的RocketMQ版本中,是有依赖ZK的。而现在的版本中,是去掉了对ZK的依赖,转而使用自己开发的NameSrv。 并且这个NameSrv是无状态的,你可以随意的部署多台,其代码也非常简单,非常轻量。 那不禁要问了:ZooKeeper是业界用来管理集群的一个非常常用的中间件,比如Kafka就是依赖的ZK。那为什么RocketMQ要自己造轮子,自己做集群的管理呢?纯粹就是转载 2017-04-16 16:50:34 · 2151 阅读 · 0 评论 -
分布式消息队列RocketMQ--事务消息--解决分布式事务的最佳实践
说到分布式事务,就会谈到那个经典的”账号转账”问题:2个账号,分布处于2个不同的DB,或者说2个不同的子系统里面,A要扣钱,B要加钱,如何保证原子性? 一般的思路都是通过消息中间件来实现“最终一致性”:A系统扣钱,然后发条消息给中间件,B系统接收此消息,进行加钱。 但这里面有个问题:A是先update DB,后发送消息呢? 还是先发送消息,后update DB? 假设先updat转载 2017-04-22 18:57:58 · 1245 阅读 · 0 评论