第七篇:分布式组件(DubboNettyNigixZookeeperMQJob)

Posted 常大爷的美好时光海苔

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了第七篇:分布式组件(DubboNettyNigixZookeeperMQJob)相关的知识,希望对你有一定的参考价值。

第七篇 分布式组件 目录

一. Dubbo:高性能RPC框架

五. MQ:分布式消息中间件

1、MQ有哪些使用场景(优点)?(高频)

  • 异步处理 : 相对于同步提高了吞吐量 ;
    • 用户注册后 , 发送注册邮件和注册短信 . 用户注册完成后 , 提交任务到MQ , 发送模块并行获取MQ中的任务 ;
  • 系统解耦 : 系统间通过消息通信 , 不需要关系其他系统如何处理 ;
    • 比如注册完成后 , 再加一个发送微信通知 . 只需要新增发送微信消息模块 , 从MQ中读取任务 , 发送消息即可 , 无需改动注册模块的代码 , 这样注册模块与发送模块通过MQ解耦 ;
  • 流量削峰 : 可以使系统平稳的度过高峰期 ;
    • 秒杀和抢购活动 , 活动开始时流量暴增 , 用户的请求写入MQ , 超过MQ最大长度丢弃请求 , 业务系统接收MQ 中的消息进行处理 , 达到流量削峰 , 保证系统可用性的目的 ;
  • 日志处理 :
    • 日志采集方收集日志写入kafka的消息队列中 , 处理方订阅并消费kafka队列中的日志数据 ;
  • 消息通讯 : 点对点或者订阅发布模式 , 通过消息进行通讯 , 如微信的消息发送与接收 , 聊天室等 ;
  • 缺点 :
    • 一致性问题 : 多个系统订阅消息 , 有的消费成功 , 有的消费失败 , 就会出现数据一致性问题 ;
    • 系统可用性降低 : 如果MQ挂了 , 系统就不可用了 ;
    • 系统复杂度增大 : 需要考虑很多问题 , 比如数据一致性问题 , 如果避免重复消费 , 如何保证消息传输的可靠性等 ;

2. ActiveMQ、RabbitMQ、RocketMQ、Kafka的优缺点和适应场景?

  • ActiveMQ :
    • 是老牌的消息中间件,国内很多传统企业在用,但是ActiveMQ不适合互联网公司,因为它对高并发高负载的支持不是很理想 ;
  • RabbitMQ :
    • 可以支持高并发高负载高吞吐,并且开源社区也很活跃,较高频率的版本迭代来修复bug和优化,但是它是用erlang语言开发的,改造源码比较困难。一些中小型企业综合考虑会选择RabbitMQ ;
  • RocketMQ :
    • 是阿里开源的消息中间件,支持高并发高吞吐,以及分布式事务。而且RocketMQ是用java语言开发的,有需要可以对源码进行扩展和改造 ;
  • Kafka :
    • 主要用于超高吞吐量的日志采集、实时数据同步、实时数据计算等场景 ;

3. 简单介绍一些Rabbitmq的架构?(高频)

  • 架构图如下 :
  • 消息的发送消息流程 :
    • 生产者和 Rabbitmq服务端建立连接 , 然后获取通道 ;
    • 生产者发送消息发送给指定的虚拟机中的交换机 ;
    • 交换机根据消息的routingKey将消息转发给指定的队列 ;
  • 消费者消费消息流程 :
    • 消费者和Rabbitmq服务端建立连接 , 然后获取通道 ;
    • 消费者监听指定的队列 ;
    • 一旦队列有消息了 , 此时就会把消息推送给指定的消费者 ;

4. RabbitMq中交换机的类型有哪些?(高频)

主要有以下4种:

  • fanout : 把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。
  • direct : 把消息路由到BindingKey和RoutingKey完全匹配的队列中。
  • topic : 匹配规则:
    • RoutingKey 为一个 点号’.': 分隔的字符串。比如: java.xiaoka.show ;
    • BindingKey和RoutingKey一样也是点号“.“分隔的字符串 ;
    • BindingKey可使用 * 和 # 用于做模糊匹配,*匹配一个单词,#匹配多个或者0个;
  • headers : 不依赖路由键匹配规则路由消息。是根据发送消息内容中的headers属性进行匹配。性能差,基本用不到 ;

5. RabbitMq如何保证消息不丢失?(高频)



消息丢失时机 :

  • 生产者发送消息的时候 , 我们都知道网络是不稳定的 , 假设发生了网络抖动导致消息没有发送成功 ;
  • 消息发送到 Rabbitmq 以后 , Rabbitmq 宕机了 ;
  • 消费者获取到MQ中的消息以后 , 还没有及时处理 , 此时消费者宕机了 ;

解决方案 :

  • 生产者发送消息 :
    • 主流的MQ都有确认机制或事物机制 , 可以保证生产者将消息送达MQ ;
    • 如RabbitMQ 就提供了事物模式和publisher-confirm机制 ;
    • publisher-confirm机制必须给每个消息指定唯一ID ,消息发送到MQ以后 , 会返回一个结果给发送者 , 表示消息是否处理成功
    • 返回结果有两种方式 :
      • publisher-confirm ,发送者确认 :
        • 消息成功投递到交换机 , 返回ack ;
        • 消息未投递到交换机 , 返回nack ;
      • publisher-return ,发送者回执
        • 消息投递到交换机了 ,但是没有路由到队列 ,返回ack ,及路由失败原因 ;
  • MQ丢失消息 :
    • 开启MQ的持久化配置 (消息 , 队列 , 都需要进行持久化) ;
  • 消费者丢失消息 :
    • 改为手动确认模式 , 消费者成功消费消息再确认 ;

7. 消息大量积压怎么解决?(高频)

解决方案 :

  • 针对Rabbitmq可以使用惰性列队 , 让消息直接存储到磁盘中 ;
  • 增加消费者的数量 , 提升消费者的消费能力 ;

8. 导致的死信的几种原因 ?(高频)

  • 消息被拒 ;
  • 消息TTL过期 ;
  • 队列满了 , 无法再添加 ;

9. 什么是延迟队列以及具体的应用场景?(高频)

  • 概述:存储对应的延迟消息,指当消息被发送以后,并不想让消费者立刻拿到消息,而是等待特定时间后,消费者才能拿到这个消息进行消费。
    • 应用场景:订单超时未支付,文章的延迟发送 ;

10. 如何解决消息队列延时及过期问题?消息队列满了怎么处理?几百万消息队列积压了几小时怎么处理?

  • 分析 : 线上故障(消费者) , 几百万的消息MQ中挤压 ;
    1. 修复消费者 , 可能需要几个小时 ;
    1. 临时扩容 :
    • 一个消费者1秒消费1000条 , 3个消费者1秒消费3000条 , 一分钟18万条 ;
    • 900万条消息挤压 , 需要50分钟 ;
    • 借调机器 , 临时扩容10倍 , 队列10倍 , 消费者10倍 , 则处理时间 大概5分钟 ;
    • 消息堆积处理完成后切换到原来部署 ;

第七篇微信小程序-video组件

主要属性:

技术分享

效果图:

技术分享

 

ml:

<View>1.播放网络视频</View>
<view >
  <video style="width: 100%;height=400px;margin:1px;" src="http://wxsnsdy.tc.qq.com/105/20210/snsdyvideodownload?filekey=30280201010421301f0201690402534804102ca905ce620b1241b726bc41dcff44e00204012882540400&bizid=1023&hy=SH&fileparam=302c020101042530230204136ffd93020457e3c4ff02024ef202031e8d7f02030f42400204045a320a0201000400" binderror="videoErrorCallback"></video>
</view>
<View>2.播放本地视频</View>
<view  style="display: flex;flex-direction: column;">
  <video  style="width: 100%;height=400px;margin:1px;" src="{{src}}"></video>
  <view class="btn-area">
    <button bindtap="bindButtonTap">打开本地视频</button>
  </view>
</view>

 

js:

Page({
    data: {
        src: ‘‘
    },
    /**
     * 打开本地视频
     */
    bindButtonTap: function() {
        var that = this
        //拍摄视频或从手机相册中选视频
        wx.chooseVideo({
           //album 从相册选视频,camera 使用相机拍摄,默认为:[‘album‘, ‘camera‘]
            sourceType: [‘album‘, ‘camera‘],
            //拍摄视频最长拍摄时间,单位秒。最长支持60秒
            maxDuration: 60,
            //前置或者后置摄像头,默认为前后都有,即:[‘front‘, ‘back‘]
            camera: [‘front‘,‘back‘],
            //接口调用成功,返回视频文件的临时文件路径,详见返回参数说明
            success: function(res) {
              console.log(res.tempFilePaths[0])
                that.setData({
                    src: res.tempFilePaths[0]
                })
            }
        })
    },
    /**
     * 当发生错误时触发error事件,event.detail = {errMsg: ‘something wrong‘}
     */
    videoErrorCallback: function(e) {
      console.log(‘视频错误信息:‘)
      console.log(e.detail.errMsg)
    }
})

 

以上是关于第七篇:分布式组件(DubboNettyNigixZookeeperMQJob)的主要内容,如果未能解决你的问题,请参考以下文章

Flask 第七篇Flask中的wtforms使用

SpringCloud 第七篇: 高可用的分布式配置中心(Spring Cloud Config)

史上最简单的SpringCloud教程 | 第七篇: 高可用的分布式配置中心(Spring Cloud Config)

业余草 SpringCloud教程 | 第七篇: 高可用的分布式配置中心(Spring Cloud Config)(Finchley版本)

Spring Cloud第七篇 | 声明式服务调用Feign

C++初阶第七篇——C/C++的内存管理(C/C++动态内存分布+new和delete的用法和实现原理)