RocketMQ开发者沙龙-20180901

作者: MisterCH | 来源:发表于2018-09-01 14:21 被阅读25次
    RocketMQ开发者沙龙

    待询问的问题:

    1. 安全
    2. 插件
    3. CHAS
    4. 备机接管

    暖场

    1. 目前正在考虑多语言的支持,后续新增C++, PYTHON, NODE.JS等客户端.
    2. OpenMessaging v1.0 Pre-Review版本即将发布

    PS:主持人真的是技术出身,暖场略尴尬。

    1. Apache RocketMQ 101 ——刘振东

    问题场景

    1. 异步、解耦
    2. 削峰填谷
    3. 排队引擎

    Comment:我自己总结的大约是4种能力:异步解耦;削峰填谷;压力转移;任务分配。

    基本概念

    概念模型 Producer----Topic----Consumer


    基本模型
    存储模型
    • Pub-Sub / Producer / Consumer
    • Topic / MessageQueue
    • CommitLog / ConsumerQueue/Offset
    • Broker / Nameserver

    mqadmin工具,可远程访问NameServer,查询集群状态等丰富的功能。


    好用的mqadmin工具

    NameServer保存的是所有的信息,那是否有一定上限?
    回答:NameServer只存储broker的路由信息,不保存consumer offset。

    最常用的功能:

    1. 发送消息,查看消息在不在
    2. Broker状态
    3. 消费消息,查看还有多少消息

    使用消息系统时容易碰到的问题

    1. 幂等
      通过业务ID解决
    2. 顺序
      分区有序,非严格有序
      顺序消息的扩容:
      停写:保证消息消费完成后再扩Queue
      不停写:成倍扩容可以保证哈希不会到错位的queue
    3. 消费位点重置
      可以消费者在线实现位点重置
    4. 补数
      黑科技:%RETRY%CLIENT可以指定消费者补数

    特性

    1. Schedule
      分级定时机制,时间轮特性,未发布


      时间轮
    2. Batch
      通过Batch实现原子一致性

    3. Filtered by Tag
      通过Tag进行消息过滤
      支持SQL语法

    4. 事务

    2. Sentinel

    负责流量的控制,限流,熔断降级
    通过令牌机制来进行流量控制

    Hystrix VS Sentinel

    • 设计理念不同
    • 熔断概念不同
    • 目标集不同

    可集成到RocketMQ的客户端中

    1. 引入Jar包
    2. 增加代码
      客户端级别的削峰填谷


      RocketMQ的客户端监控
      客户端的流控

    3. 通过RMQ构建企业级别的消息平台

    STAGE 0. 各个应用使用各自的消息队列
    STAGE 1. TOPIC数量增加导致Kafka无法承载,设置Producer-Proxy来解决Kafka 0.8的bug
    STAGE 2. 调研选择一个MQ引擎


    STAGE 2

    STAGE 3. 数据迁移、功能迭代优化、服务化

    消息平台架构很完整


    平台架构

    当时使用RocketMQ面临的挑战

    • 多语言支持
    • 研发人员少
    • 无源码阅读
    • 时间紧张
    • 99.995%的可用性要求

    策略:

    1. 先跑起来
      使用THRIFT实现简单的功能
      客户端最简化
      最小化用户功能
    2. 迁移
      将应用逐步迁移到RocketMQ上
      Producer Proxy和Consumer Proxy支持数据的双写双读,同时从Kafka和RocketMQ上写数据读数据。

    自己实现的功能:

    1. 主备自动切换
    2. BATCH的扩展,支持不同TOPIC不同QUEUE的写入
    3. 百万TOPIC的支持:元数据管理的优化
    4. 集成内部监控和部署工具
    5. BUG-FIX

    踩过的坑:

    1. 读老数据:random IO导致。通过在备机做操作来实现。同步主备会有影响。
    2. 删除过期数据导致IO飚高:默认保存72小时,默认凌晨4点删除。FILERESERVEDTIME, DELETEWHEN, DELETECOMMITLOGFILESINTERVAL, DELETECONSUMERQUEUEFILESINTERVAL.
      可通过设置多个删除时间点来缓解
    3. 消息索引的建立可以放在备机上实现。

    4. 事务消息

    XA事务(两阶段提交)带来的问题:资源的阻塞
    三阶段提交增加pre-commit和pre-rollback可以达到最终一致性。

    XA、SAGA、TCC

    RocketMQ的处理方式

    关键点:

    1. Half Topic。由Broker拦截,并保存事务消息到Half Topic
    2. Op Topic:状态消息的偏移量,服务端启动扫描half和op topic的差异,判断half topic里的消息是否需要投递到真实的user topic中。
    生产者最佳实践 消费者及broker的最佳实践

    5. MQTT Bridge for Apache RocketMQ

    核心问题:可用性、实时性、可靠性

    可用性
    服务发现问题:使用DNS server进行bridge的注册
    快速故障恢复:通过无状态+共享存储实现

    实时性
    通过解耦消费者的ack实现

    高可靠
    消息存储实现。

    bridge模型

    6. 流处理

    • RMQ + STORM
    • RMQ + SPARK
    • RMQ + FLINK
    • RMQ + AVRO


      一个使用flink与rmq结合的案例

    话说听到这里已经听了3个小时,我的状态已经有点懵逼了……

    干货满满,感谢。


    讲师

    相关文章

      网友评论

        本文标题:RocketMQ开发者沙龙-20180901

        本文链接:https://www.haomeiwen.com/subject/bdxuwftx.html