【3.工程开发】-mq-kafka/rocketmq

本篇是消息队列中的一节，为什么讲到消息队列见：https://segmentfault.com/a/11...。其中流处理的数据传播用到消息队列。另外消息队列还可以作用于异步处理，流量削峰，多系统同步等。另一篇介绍了传统的JMS(activemq),AMQP(rabbitmq)，本篇介绍kafka,robbitmq,ddmq，另外简单说下bridgemq以及常见mq的综合对比。同其他系统一样，终点关注架构组件，功能（生产消费等），分布式的高可用，扩展性，一致性等

kafka

官方：发布订阅，流处理管道和存储
https://kafka.apache.org/docu...

组件

• broker：负责消息存储转发，包含topic(一个queue)=》partition(物理分布，一个topic包含一个或多个partition,可以分布在不同的broker上)
• producer（与broker leader直连，负载均衡指定partition,可批次发，可设置要ack的副本数）
• consumer/consumer group.同一group中只有一个c可以消费一个p，负载均衡，此时若这组cg的线程多于p会有空等线程。但是多个cg可以同时消费一个p不受影响。因此在考虑为了消费更快下，对于partition的分区和c的线程数可以一致。
• 其中partition的集群和单机物理结构如下：
  

• index全部映射到内存，每个partition下自增id
• 元数据放在zk上.分partition,每个partition副本分散在broker上，单partition+单消费才能保证顺序(rocketmq一样)。每个partition一个索引，顺序写一个文件。流处理+批量处理（累计部分数据才发送），实时上有取舍。

https://kafka.apache.org/docu...

高可用和可扩展

1) Producer端使用zookeeper用来"发现"broker列表,以及和Topic下每个partition leader建立socket连接并发送消息.
2) Broker端使用zookeeper用来注册broker信息,以及监测partition leader存活性.所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，成功的为Broker controller，失效后zk后发现重新注册节点，controller负责各broker内partition的选主（ISR中，记录replica进度，随便选）ISR，在这个集合中的节点都是和leader保持高度一致的，任何一条消息必须被这个集合中的每个节点读取并追加到日志中了，才回通知外部这个消息已经被提交了。因此这个集合中的任何一个节点随时都可以被选为leader.如果ISR的大小超过某个最小值，则分区将仅接受写入，以防止丢失仅写入单个副本的消息（只关注ISR，而不是共识多个都写入，多数（两个故障需要5个副本，一个要三个）对于主数据的写代价大）【与ES类似都使用的Microsoft的PacificA】
3) Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息。
broker,partition,customer组内线程可扩展。

消费

只保证一个partition被一个customer消费有序
producter推，customer拉（拉需要存日志）
partition中的每个message只能被组（Consumer group ）中的一个consumer（consumer 线程）消费，若多个同时要配多个Consumer group。
kafka中的消息是批量(通常以消息的条数或者chunk的尺寸为单位)发送给consumer，当消息被consumer接收之后,负责维护消息的消费记录（JMS等都是broker维护），consumer可以在本地保存最后消息的offset,并间歇性的向zookeeper注册offset.也没有ACK
消息消费的可靠性，消费者控制，最多一次，先保存offset再处理；至少一次，先处理再保存offset；只一次：最少1次＋消费者的输出中额外增加已处理消息最大编号

日志压缩

确保有每个分区数据日志中每个key有最后已知值，offset不能变。对同一partition的多个文件一起压缩合并。
position是文件的bytes偏移吧？压缩过程中要重建索引和位置？【个人理解是要重建的】
active不动（不影响写入），对cleaner point后面的做压缩，选择日志tail和header比例小的，合并压缩每组log不超过1G，index不超过10M。

对于tail的压缩过程：【position不变？？？个人理解这是错误的，position是变得】
每个日志清理线程会使用一个名为“SkimpyOffsetMap”的对象来构建key与offset的映射关系的哈希表。日志清理需要遍历两次日志文件，第一次遍历把每个key的哈希值和最后出现的offset都保存在SkimpyOffsetMap中，映射模型如下图所示。第二次遍历检查每个消息是否符合保留条件，如果符合就保留下来，否则就会被清理掉

rocketmq

activemq 不能分片。kafka性能（上面知道基本上partition和consumer需要配置一样的，一个consumer group的线程数和partition数量一致,受partition限制，rocketmq多partition的扩展在于都用一个commitlog，而不是一个partition单独一份顺序log,对于磁盘多个文件是随机写入的，随机高性能不好不能linux组提交，cq只存储位置，在commitlog中找数据，一份完全顺序的写入提高性能。对于消费顺序和kafka都是一样的保证，cq都是负载均衡，只保证一个cq顺序。在消费时，需要先读取cq上个的offset再读commitlog。http://rocketmq.apache.org/ro...）

组件

• broker :主从，topic,queue，tag
• nameserver:几乎无状态，可集群内部署，节点对等，不同步。数据是broker同步过来的
• producer:连接ns，主从brokers（心跳）,无状态
• consumer/group :连接ns，主从brokers（心跳）

高可用和可扩展

• 负载均衡
  Broker上存Topic信息，Topic由多个队列组成，队列会平均分散在多个Broker上，而Producer的发送机制保证消息尽量平均分布到所有队列中，最终效果就是所有消息都平均落在每个Broker上。
• 主从
  机器级别，不依赖zk，元数据:在 Broker 启动的时候，其会将自己在本地存储的配置文件 (默认位于$HOME/store/config/topics.json 目录) 中的所有话题加载到内存中去，然后会将这些所有的话题全部同步到所有的 Name 服务器中。与此同时，Broker 也会启动一个定时任务，默认每隔 30 秒来执行一次话题全同步.主从写commitlog保证持久性和同步和其他一样，就不再说了。
• Broker与Namesrv的心跳机制：
  单个Broker跟所有Namesrv保持心跳请求，心跳间隔为30秒，心跳请求中包括当前Broker所有的Topic信息。Namesrv会反查Broer的心跳信息，如果某个Broker在2分钟之内都没有心跳，则认为该Broker下线，调整Topic跟Broker的对应关系。但此时Namesrv不会主动通知Producer、Consumer有Broker宕机。
• 消息存储持久化
  所有broker上的所有topic都顺序写入内存文件mapedfile（1G），mapedfilelist记录每个mapedfile在磁盘的偏移量，新消息写入最后一个文件。
• 动态伸缩能力
  （非顺序消息，消息分散；有序消息只能放在一个queue中，切不支持迁移，只保证一个queue内顺序，但可以多消费线程保证顺序）：Broker的伸缩性体现在两个维度：Topic, Broker。
  1）Topic维度：假如一个Topic的消息量特别大，但集群水位压力还是很低，就可以扩大该Topic的队列数，Topic的队列数跟发送、消费速度成正比。
  2）Broker维度：如果集群水位很高了，需要扩容，直接加机器部署Broker就可以。Broker起来后想Namesrv注册，Producer、Consumer通过Namesrv发现新Broker，立即跟该Broker直连，收发消息。

消费

1. 消费者注册，消费者上有多有topic的broker地址和队列，消费者负载均衡选择；
   1）广播模式：每个costumer全量消费，消费偏移量保存在costumer中
   2）集群模式：constumer均匀消费部分，每个消息只有一个costumer消费，保存在broker上
2. 新消息发送到q：brocker上commit log和消费组信息

   
   每个commmit log消息发给topic的随机queue中（生产者的负载均衡，每个msg只发送到一个q中），每个queue有很多consumequeue，发给所有。广播模式，cq会在所有q上，集群模式cq会负载均衡到某个q上，消息根据这些配置数据落到q的所有cq上。
   

3. 消费
   3.1）普通的并发消费：queue的所有cq都直接发，所有cq发送后删除（q以TreeMap结构存储）。内部RocketMQ 的消息树是用 TreeMap 实现的，其内部基于消息偏移量维护了消息的有序性。每次消费请求都会从消息数中拿取偏移量最小的几条消息 (默认为 1 条)给用户，以此来达到有序消费的目的。
   3.2）有序消费：在3.1的基础上加两个锁，costumer client给消费的每个queue会加锁，保证同一时刻只有一个costumer client在消费queue(否则发给一个client删除了消息，此消息在另一个client和后面的client的消息无法保证顺序),默认20s加一次，queue检测60s没有就释放，每次成功后才取下一条，反正只有一个客户端消费。第二把锁是在client中，将堆积的消息按照顺序加锁的写入线程池task队列中。

其他

bridgequeue

内存。redis实现。适合小型系统

ddmq 对大型延时系统的支持，引入chronos

这里的kafka去掉了。普通的直接用哪个rocketmq.延时消息和事务消息

• 延时消息
  放入rocketmq一个内部的消费topic中，消费入chronos中（存RocksDB，seektimestamp, while从leveldb中取符合时间的再放入rocketmq中）
• 事务消息
  A执行后要发送消息给B，因为ddmq一旦接收是保证被消费的，所以增加发送方事务回查。
  

对比

分析：少topic时kafka性能好，rockemq需要读mq后去读一个大的cl。多topic是rockemq好，处理线程多。