精华内容
下载资源
问答
  • 常见的冲突类型及原因
    千次阅读
    2020-12-26 20:14:12

    在使用优化库的过程中,因为要配置优化库所以需要链接库,但是配置完成后一直显示计算机类型“X86”与目标计算机类型“X64”冲突的问题,搜集了很多解决办法最后终于找到问题了,所以总结一下避免后面的人踩坑。

    首先,讲一下我自己的原因。主要是因为选择错了目录的类型了。
    在这里插入图片描述
    如图所示,我把X64的不知道怎么了,电脑默认成X86了,所以一直没有找到问题,改一下这个地方就行了。还有上面的配置平台也不能选错了。
    X86对应的咱们说的Win32位的平台。X64对应咱们的X64平台。

    下面介绍一下网上比较好的解决办法:
    模块计算机类型“X86”与目标计算机类型“X64”冲突的原因分析与解决方案
    我觉得这个是最好的,从根本上报出来的错误来找到原因,分析VS报的error来分析原因,找到自己对应的问题。
    下面的几个也是这个错误常见的问题。
    fatal error LNK1112: 模块计算机类型“X86”与目标计算机类型“x64”冲突——我的解决方案
    OpenCV2.4.11+VS2012的环境配置+“fatal error LNK1112: 模块计算机类型“X86”与目标计算机类型“x64”冲突”的问题解决

    主要原因就是:第一、平台选择不对。第二、库的版本与平台对应不上。第三、选的库的类型(X86、X64)的区别。

    更多相关内容
  • 常见索引类型

    千次阅读 2021-02-15 15:44:17
    日常开发工作中,涉及到的数据存储,要做查询优化或想深入了解存储引擎,需要对索引知识有个起码的了解,下面介绍下最常见的四种索引结构。 位图索引 哈希索引 BTREE索引 倒排索引 1、位图索引(BitMap) 位图...

    日常开发工作中,涉及到的数据存储,要做查询优化或想深入了解存储引擎,需要对索引知识有个起码的了解,下面介绍下最常见的四种索引结构。

    • 位图索引
    • 哈希索引
    • BTREE索引
    • 倒排索引

    1、位图索引(BitMap)

    位图索引适用于字段值为可枚举的有限个数值的情况

    位图索引使用二进制的数字串(bitMap)标识数据是否存在,1标识当前位置(序号)存在数据,0则表示当前位置没有数据。
    在这里插入图片描述

    ​图1 为用户表,存储了性别和婚姻状况两个字段。

    ​图2中 分别为性别和婚姻状态建立了两个位图索引;

    例如:性别->男对应索引为:101110011,表示第1、3、4、5、8、9个用户为男性。其他属性以此类推。

    使用位图索引查询:

    男性 并且已婚 的记录 = 101110011 & 11010010 = 100100010,即第1、4、8个用户为已婚男性。

    女性 或者未婚的记录 = 010001100 | 001010100 = 011011100, 即第2、3、5、6、7个用户为女性或者未婚。

    注:位图索引查询主要进行“与/或”操作,性能非常高;并且空间占用少;一个常见的场景就是用着统计标签化用户上,对用户进行分类;Redis提供了方便的位图操作命令,使用很方便;但位图“位资源”的回收不方便,且稀松的位图会浪费空间,位图进行非运算较困难

    2、哈希索引

    顾名思义,是指使用某种哈希函数实现key->value 映射的索引结构。

    哈希索引适用于等值检索,通过一次哈希计算即可定位数据的位置。

    下图3 展示了哈希索引的结构,与JAVA中HashMap的实现类似,是用冲突表的方式解决哈希冲突的。

    在这里插入图片描述

    3、BTREE索引

    BTREE索引是关系型数据库最常用的索引结构,方便了数据的查询操作。

    BTREE: 有序平衡N叉树, 每个节点有N个键值和N+1个指针, 指向N+1个子节点

    一棵BTREE的简单结构如下图4所示,为一棵2层的3叉树,有7条数据:

    在这里插入图片描述

    以Mysql最常用的InnoDB引擎为例,描述下BTREE索引的应用。

    在这里插入图片描述

    Innodb下的表都是以索引组织表形式存储的,也就是整个数据表的存储都是B+tree结构的,如图5所示。

    ​主键索引为图5的左半部分(如果没有显式定义自主主键,就用不为空的唯一索引来做聚簇索引,如果也没有唯一索引,则innodb内部会自动生成6字节的隐藏主键来做聚簇索引),叶子节点存储了完整的数据行信息(以主键 + row_data形式存储)。

    ​二级索引也是以B+tree的形式进行存储,图5右半部分,与主键不同的是二级索引的叶子节点存储的不是行数据,而是索引键值和对应的主键值,由此可以推断出,二级索引查询多了一步查找数据主键的过程。

    ​维护一颗有序平衡N叉树,比较复杂的就是当插入节点时节点位置的调整,尤其是插入的节点是随机无序的情况;而插入有序的节点,节点的调整只发生了整个树的局部,影响范围较小,效率较高。

    可以参考红黑树的节点的插入算法:https://en.wikipedia.org/wiki/Red%E2%80%93black_tree

    ​因此如果innodb表有自增主键,则数据写入是有序写入的,效率会很高;如果innodb表没有自增的主键,插入随机的主键值,将导致B+tree的大量的变动操作,效率较低。这也是为什么会建议innodb表要有无业务意义的自增主键,可以大大提高数据插入效率。

    Mysql Innodb使用自增主键的插入效率高。

    使用类似Snowflake的ID生成算法,生成的ID是趋势递增的,插入效率也比较高。

    4、倒排索引(反向索引)

    ​倒排索引也叫反向索引,可以相对于正向索引进行比较理解。

    ​正向索引反映了一篇文档与文档中关键词之间的对应关系;给定文档标识,可以获取当前文档的关键词、词频以及该词在文档中出现的位置信息,如图6 所示,左侧是文档,右侧是索引。

    在这里插入图片描述

    ​ 反向索引则是指某关键词和该词所在的文档之间的对应关系;给定了关键词标识,可以获取关键词所在的所有文档列表,同时包含词频、位置等信息,如图7所示。

    图7

    ​ 反向索引(倒排索引)的单词的集合和文档的集合就组成了如图8所示的”单词-文档矩阵“,打钩的单元格表示存在该单词和文档的映射关系。

    图8

    倒排索引的存储结构可以参考图9。其中词典是存放的内存里的,词典就是整个文档集合中解析出的所有单词的列表集合;每个单词又指向了其对应的倒排列表,倒排列表的集合组成了倒排文件,倒排文件存放在磁盘上,其中的倒排列表内记录了对应单词在文档中信息,即前面提到的词频、位置等信息。

    图9

    下面以一个具体的例子来描述下,如何从一个文档集合中生成倒排索引。
    如图10,共存在5个文档,第一列为文档编号,第二列为文档的文本内容。

    图10

    将上述文档集合进行分词解析,其中发现的10个单词为:[谷歌,地图,之父,跳槽,Facebook,加盟,创始人,拉斯,离开,与],以第一个单词”谷歌“为例:首先为其赋予一个唯一标识 ”单词ID“, 值为1,统计出文档频率为5,即5个文档都有出现,除了在第3个文档中出现2次外,其余文档都出现一次,于是就有了图11所示的倒排索引。

    在这里插入图片描述

    展开全文
  • 偏离分支,合并分支带来的冲突,fetch,merge,pull,push带来的冲突冲突原因以及如何手动解决冲突

    前言

    简单介绍偏离分支,合并分支带来的冲突,fetch,merge,pull,push带来的冲突。冲突的原因以及如何手动解决冲突。

    冲突出现的原因(Merge)

    同一个文件的同一行代码,分别有两个commit对其修改,若对其进行合并(merge),就会出现冲突。

    由一个拉代码时出现的常见错误引入

    拉代码出现如图错误:
    在这里插入图片描述

    该问题解决方案很简单,依次执行下面代码,然后解决冲突即可:

    git config pull.ff false   
    git pull
    

    但是原因的分析却耐人寻味。

    前置知识:

    • git pull = git fetch + git merge

    • git fetch 是将远程主机的最新内容拉到本地,用户在检查了以后决定是否合并到工作本机分支中。如果决定合并到本地分支,可以使用git merge 就可以合并到工作本机分支!

    • git-merge 命令是用于从指定的 commit(s) 合并到当前分支的操作。

    • git merge有两种情况,一种是git merge和 cherry-pick的用法(用于从一个分支到另一个分支的合并)。
      另一种是用于 git-pull 中,来整合另一代码仓库中的变化(即:git pull = git fetch + git merge)

    该问题出现的原因(非常重要)

    有了上面的前置知识,可以知道git pull 失败的原因:不是因为pull失败,而是merge失败。执行pull的时候,git merge尝试将远程主机的commit(下图蓝色的三次commit)merge到本地分支。但是你本地分支已经git add 和 git commit 了一次提交。所以导致本地的分支和远程的分支进行了一次合并。一般情况下,这种合并不会出现问题,但是如果出现下面这种情况,就会出现冲突。下面继续看冲突出现的原因:

    冲突出现的原因(Merge)

    同一个文件的同一行代码,分别有两个commit对其修改,若对其进行合并(merge),就会出现冲突。

    上文绿色字体提到的merge的两种情况 (包括merge 和 cherry-pick) ,都有可能出现冲突!

    有了上面的知识,配合下图就可以理解错误出现的原因了:

    在这里插入图片描述

    两种冲突处理方式的思考

    解决方法1: 优先 git merge(git pull 包含了 merge),然后再git add 和 git commit。这种情况只有在开发人员较少(只有你自己)才可以这么干。因为这样做有丢失代码的风险!

    如果你本地写了代码,没有git add 和 git commit,别人在远程修改了同样位置的代码,你拉下来(执行了merge),就有可能把你的代码给冲掉,或者直接报冲突。

    该方法一般不可取。直接看方法二。

    解决方法2:就是写完代码,优先add 和 commit ,然后执行merge操作(git pull 包含了merge),然后就会出现冲突。出现冲突不可怕,解决就是了。看下文如何手动解决冲突:

    git 手动解决冲突:

    介于 <<<<<<<HEAD 和 ======= 之间的内容是代码块A中内容
    介于 ======= 和 >>>>>>> 之间的内容是代码块B中内容
    如下图所示:
    在这里插入图片描述
    解决方案:手动删除A代码块内容,或者手动删除B代码块内容; 或者A和B合并一下代码

    然后把多余的 >>>>> 符号 和 ====== 符号都删光

    最后暂存,提交 即可。

    展开全文
  • 第一,你无法控制所创建的 queue 实际分布在 cluster 里的哪个 node 上(一般使用 HAProxy + cluster 模型时都是这样),这可能会导致各种跨地域访问时的常见问题;第二,Erlang 的 OTP 通信框架对延迟的容忍度有限...

    RabbitMQ面试题以及答案整理【最新版】RabbitMQ高级面试题大全(2021版),发现网上很多RabbitMQ面试题都没有答案,所以花了很长时间搜集,本套RabbitMQ面试题大全

    如果不背 RabbitMQ 面试题的答案,肯定面试会挂!

    这套RabbitMQ面试题大全,希望对大家有帮助哈~

    博主已将以下这些面试题整理成了一个Java面试手册,是PDF版的

    1、RabbitMQ routing路由模式

    1、 消息生产者将消息发送给交换机按照路由判断,路由是字符串(info) 当前产生的消息携带路由字符(对象的方法),交换机根据路由的key,只能匹配上路由key对应的消息队列,对应的消费者才能消费消息;

    2、 根据业务功能定义路由字符串

    3、 从系统的代码逻辑中获取对应的功能字符串,将消息任务扔到对应的队列中。

    4、 业务场景:error 通知;EXCEPTION;错误通知的功能;传统意义的错误通知;客户通知;利用key路由,可以将程序中的错误封装成消息传入到消息队列中,开发者可以自定义消费者,实时接收错误;

    2、消息怎么路由?

    消息提供方->路由->一至多个队列消息发布到交换器时,消息将拥有一个路由键(routing key),在消息创建时设定。通过队列路由键,可以把队列绑定到交换器上。消息到达交换器后,RabbitMQ 会将消息的路由键与队列的路由键进行匹配(针对不同的交换器有不同的路由规则);

    常用的交换器主要分为一下三种:

    1、 fanout:如果交换器收到消息,将会广播到所有绑定的队列上

    2、 direct:如果路由键完全匹配,消息就被投递到相应的队列

    3、 topic:可以使来自不同源头的消息能够到达同一个队列。 使用 topic 交换器时,可以使用通配符

    3、RabbitMQ publish/subscribe发布订阅(共享资源)

    1、 每个消费者监听自己的队列;

    2、 生产者将消息发给broker,由交换机将消息转发到绑定此交换机的每个队列,每个绑定交换机的队列都将接收到消息。

    4、能够在地理上分开的不同数据中心使用 RabbitMQ cluster 么?

    不能。第一,你无法控制所创建的 queue 实际分布在 cluster 里的哪个 node 上(一般使用 HAProxy + cluster 模型时都是这样),这可能会导致各种跨地域访问时的常见问题;第二,Erlang 的 OTP 通信框架对延迟的容忍度有限,这可能会触发各种超时,导致业务疲于处理;第三,在广域网上的连接失效问题将导致经典的“脑裂”问题,而RabbitMQ 目前无法处理(该问题主要是说 Mnesia)。

    5、RabbitMQ有那些基本概念?

    1、 Broker:简单来说就是消息队列服务器实体

    2、 Exchange:消息交换机,它指定消息按什么规则,路由到哪个队列

    3、 Queue:消息队列载体,每个消息都会被投入到一个或多个队列

    4、 Binding:绑定,它的作用就是把exchange和queue按照路由规则绑定起来

    5、 Routing Key:路由关键字,exchange根据这个关键字进行消息投递

    6、 VHost:vhost 可以理解为虚拟 broker ,即 mini-RabbitMQ server。其内部均含有独立的 queue、exchange 和 binding 等,但最最重要的是,其拥有独立的权限系统,可以做到 vhost 范围的用户控制。当然,从 RabbitMQ 的全局角度,vhost 可以作为不同权限隔离的手段(一个典型的例子就是不同的应用可以跑在不同的 vhost 中)。

    7、 Producer:消息生产者,就是投递消息的程序

    8、 Consumer:消息消费者,就是接受消息的程序

    9、 Channel:消息通道,在客户端的每个连接里,可建立多个channel,每个channel代表一个会话任务

    ExchangeQueueRoutingKey三个才能决定一个从Exchange到Queue的唯一的线路。

    6、什么情况下会出现 blackholed 问题?

    blackholed 问题是指,向 exchange 投递了 message ,而由于各种原因导致该message 丢失,但发送者却不知道。可导致 blackholed 的情况:1.向未绑定 queue 的exchange 发送 message;2.exchange 以 binding_key key_A 绑定了 queue queue_A,但向该 exchange 发送 message 使用的 routing_key 却是 key_B。

    7、什么是消费者Consumer?

    消费消息,也就是接收消息的一方。

    消费者连接到RabbitMQ服务器,并订阅到队列上。消费消息时只消费消息体,丢弃标签。

    8、消息如何分发?

    1、 若该队列至少有一个消费者订阅,消息将以循环(round-robin)的方式发送给消费者。每条消息只会分发给一个订阅的消费者(前提是消费者能够正常处理消息并进行确认)。

    2、 通过路由可实现多消费的功能

    9、Basic.Reject 的用法是什么?

    该信令可用于 consumer 对收到的 message 进行 reject 。若在该信令中设置

    requeue=true,则当 RabbitMQ server 收到该拒绝信令后,会将该 message 重新发送到下一个处于 consume 状态的 consumer 处(理论上仍可能将该消息发送给当前consumer)。若设置 requeue=false ,则 RabbitMQ server 在收到拒绝信令后,将直接将该message 从 queue 中移除。

    另外一种移除 queue 中 message 的小技巧是,consumer 回复 Basic.Ack 但不对获取到的message 做任何处理。而 Basic.Nack 是对 Basic.Reject 的扩展,以支持一次拒绝多条 message 的能力。

    10、什么是Binding绑定?

    通过绑定将交换器和队列关联起来,一般会指定一个BindingKey,这样RabbitMq就知道如何正确路由消息到队列了。

    11、如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,怎么办?

    消息积压处理办法:临时紧急扩容:

    1、 先修复 consumer 的问题,确保其恢复消费速度,然后将现有 cnosumer 都停掉。

    2、 新建一个 topic,partition 是原来的 10 倍,临时建立好原先 10 倍的 queue 数量。

    3、 然后写一个临时的分发数据的 consumer 程序,这个程序部署上去消费积压的数据,消费之后不做耗时的处理,直接均匀轮询写入临时建立好的 10 倍数量的 queue。

    4、 接着临时征用 10 倍的机器来部署 consumer,每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍,以正常的 10 倍速度来消费数据。

    5、 等快速消费完积压数据之后,得恢复原先部署的架构,重新用原先的 consumer 机器来消费消息。

    6、 MQ中消息失效:假设你用的是 RabbitMQ,RabbtiMQ 是可以设置过期时间的,也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被 RabbitMQ 给清理掉,这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq 里,而是大量的数据会直接搞丢。我们可以采取一个方案,就是批量重导,这个我们之前线上也有类似的场景干过。就是大量积压的时候,我们当时就直接丢弃数据了,然后等过了高峰期以后,比如大家一起喝咖啡熬夜到晚上12点以后,用户都睡觉了。这个时候我们就开始写程序,将丢失的那批数据,写个临时程序,一点一点的查出来,然后重新灌入 mq 里面去,把白天丢的数据给他补回来。也只能是这样了。假设 1 万个订单积压在 mq 里面,没有处理,其中 1000 个订单都丢了,你只能手动写程序把那 1000 个订单给查出来,手动发到 mq 里去再补一次。

    mq消息队列块满了:

    如果消息积压在 mq 里,你很长时间都没有处理掉,此时导致 mq 都快写满了,咋办?这个还有别的办法吗?没有,谁让你第一个方案执行的太慢了,你临时写程序,接入数据来消费,消费一个丢弃一个,都不要了,快速消费掉所有的消息。然后走第二个方案,到了晚上再补数据吧。

    12、为什么说保证 message 被可靠持久化的条件是 queue 和 exchange 具有durable 属性,同时 message 具有 persistent 属性才行?

    binding 关系可以表示为 exchange – binding – queue 。从文档中我们知道,若要求投递的 message 能够不丢失,要求 message 本身设置 persistent 属性,要求 exchange和 queue 都设置 durable 属性。

    其实这问题可以这么想,若 exchange 或 queue 未设置durable 属性,则在其 crash 之后就会无法恢复,那么即使 message 设置了 persistent 属性,仍然存在 message 虽然能恢复但却无处容身的问题;同理,若 message 本身未设置persistent 属性,则 message 的持久化更无从谈起。

    13、如何自动删除长时间没有消费的消息?

    // 通过队列属性设置消息过期时间
    Map<String, Object> argss = new HashMap<String, Object>();
    argss.put("x-message-ttl",6000);
    
    // 对每条消息设置过期时间
    AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
        .expiration("10000") // TTL

    14、RabbitMQ 概念里的 channel、exchange 和 queue 这些东东是逻辑概念,还是对应着进程实体?这些东东分别起什么作用?

    queue 具有自己的 erlang 进程;exchange 内部实现为保存 binding 关系的查找表;channel 是实际进行路由工作的实体,即负责按照 routing_key 将 message 投递给queue 。由 AMQP 协议描述可知,channel 是真实 TCP 连接之上的虚拟连接,所有AMQP 命令都是通过 channel 发送的,且每一个 channel 有唯一的 ID。

    一个 channel 只能被单独一个操作系统线程使用,故投递到特定 channel 上的 message 是有顺序的。但一个操作系统线程上允许使用多个 channel 。channel 号为 0 的 channel 用于处理所有对于当前 connection 全局有效的帧,而 1-65535 号 channel 用于处理和特定 channel 相关的帧。AMQP 协议给出的 channel ,其中每一个 channel 运行在一个独立的线程上,多线程共享同一个 socket。

    15、消费者获取消息的方式?

    16、使用RabbitMQ有什么好处?

    1、 解耦,系统A在代码中直接调用系统B和系统C的代码,如果将来D系统接入,系统A还需要修改代码,过于麻烦!

    2、 异步,将消息写入消息队列,非必要的业务逻辑以异步的方式运行,加快响应速度

    3、 削峰,并发量大的时候,所有的请求直接怼到数据库,造成数据库连接异常

    17、mq的缺点

    系统可用性降低

    系统引入的外部依赖越多,越容易挂掉,本来你就是A系统调用BCD三个系统的接口就好了,人ABCD四个系统好好的,没啥问题,你偏加个MQ进来,万一MQ挂了咋整?MQ挂了,整套系统崩溃了,你不就完了么。

    系统复杂性提高

    硬生生加个MQ进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?头大头大,问题一大堆,痛苦不已

    一致性问题

    1、 A系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是BCD三个系统那里,BD两个系统写库成功了,结果C系统写库失败了,咋整?你这数据就不一致了。

    2、 所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,最好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了10倍。但是关键时刻,用,还是得用的

    18、死信队列?

    DLX,全称为 Dead-Letter-Exchange,死信交换器,死信邮箱。当消息在一个队列中变成死信 (dead message) 之后,它能被重新被发送到另一个交换器中,这个交换器就是 DLX,绑定 DLX 的队列就称之为死信队列。

    19、Binding绑定?

    通过绑定将交换器和队列关联起来,一般会指定一个BindingKey,这样RabbitMq就知道如何正确路由消息到队列了。

    20、消息传输保证层级?

    At most once:最多一次。消息可能会丢失,单不会重复传输。

    At least once:最少一次。消息觉不会丢失,但可能会重复传输。

    Exactly once: 恰好一次,每条消息肯定仅传输一次。

    21、vhost 是什么?起什么作用?

    vhost 可以理解为虚拟 broker ,即 mini-RabbitMQ server。其内部均含有独立的queue、exchange 和 binding 等,但最最重要的是,其拥有独立的权限系统,可以做到vhost 范围的用户控制。

    当然,从 RabbitMQ 的全局角度,vhost 可以作为不同权限隔离的手段(一个典型的例子就是不同的应用可以跑在不同的 vhost 中)。

    22、AMQP协议3层?

    1、 Module Layer:协议最高层,主要定义了一些客户端调用的命令,客户端可以用这些命令实现自己的业务逻辑。

    2、 Session Layer:中间层,主要负责客户端命令发送给服务器,再将服务端应答返回客户端,提供可靠性同步机制和错误处理。

    3、 TransportLayer:最底层,主要传输二进制数据流,提供帧的处理、信道服用、错误检测和数据表示等。

    23、RabbitMQ topic 主题模式(路由模式的一种)

    1、 星号井号代表通配符

    2、 星号代表多个单词,井号代表一个单词

    3、 路由功能添加模糊匹配

    4、 消息产生者产生消息,把消息交给交换机

    5、 交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息消费

    在我的理解看来就是routing查询的一种模糊匹配,就类似sql的模糊查询方式

    24、RabbitMQ基本概念

    1、 Broker: 简单来说就是消息队列服务器实体

    2、 Exchange: 消息交换机,它指定消息按什么规则,路由到哪个队列

    3、 Queue: 消息队列载体,每个消息都会被投入到一个或多个队列

    4、 Binding: 绑定,它的作用就是把exchange和queue按照路由规则绑定起来

    5、 Routing Key: 路由关键字,exchange根据这个关键字进行消息投递

    6、 VHost: vhost 可以理解为虚拟 broker ,即 mini-RabbitMQ server。其内部均含有独立的 queue、exchange 和 binding 等,但最最重要的是,其拥有独立的权限系统,可以做到 vhost 范围的用户控制。当然,从 RabbitMQ 的全局角度,vhost 可以作为不同权限隔离的手段(一个典型的例子就是不同的应用可以跑在不同的 vhost 中)。

    7、 Producer: 消息生产者,就是投递消息的程序

    8、 Consumer: 消息消费者,就是接受消息的程序

    9、 Channel: 消息通道,在客户端的每个连接里,可建立多个channel,每个channel代表一个会话任务

    由Exchange、Queue、RoutingKey三个才能决定一个从Exchange到Queue的唯一的线路。

    25、消息如何被优先消费?

    生产者

    Map<String, Object> argss = new HashMap<String, Object>();
    argss.put("x-max-priority",10);

    消费者

    AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
        .priority(5) // 优先级,默认为5,配合队列的 x-max-priority 属性使用

    26、在单 node 系统和多 node 构成的 cluster 系统中声明 queue、exchange ,以及进行 binding 会有什么不同?

    当你在单 node 上声明 queue 时,只要该 node 上相关元数据进行了变更,你就会得到 Queue.Declare-ok 回应;而在 cluster 上声明 queue ,则要求 cluster 上的全部node 都要进行元数据成功更新,才会得到 Queue.Declare-ok 回应。

    另外,若 node 类型为 RAM node 则变更的数据仅保存在内存中,若类型为 disk node 则还要变更保存在磁盘上的数据。

    27、RabbitMQ消息是如何路由的?

    消息路由必须有三部分:交换器、路由、绑定。

    生产者把消息发布到交换器上,绑定决定了消息如何从路由器路由到特定的队列;消息最终到达队列,并被消费者接收。

    1. 消息发布到交换器时,消息将拥有一个 路由键(routing key) , 在消息创建时设定。
    2. 通过队列路由键,可以把队列绑定到交换器上。
    3. 消息到达交换器后,RabbitMQ会将消息的路由键与队列的路由键进行匹配(针对不同的交换器有不同的路由规则)。如果能够匹配到队列,则消息会投递到相应队列中;如果不能匹配到任何队列,消息将进入"黑洞"。

    常用的交换器主要分为以下三种:

    1. direct :如果路由键完全匹配,消息就会被投递到相应的队列;每个AMQP的实现都必须有一个direct交换器,包含一个空白字符串名称的默认交换器。声明一个队列时,会自动绑定到默认交换器,并且以队列名称作为路由键:channel -> basic_public($msg, '', 'queue-name')
    2. fanout : 如果交换器收到消息,将会广播到所有绑定的队列上;
    3. topic :可以使来自不同源头的消息能够到达同一个队列。使用topic交换器时,可以使用通配符,比如:"*" 匹配特定位置的任意文本,"." 把路由键分为了几个标识符, "#" 匹配所有规则等。
    4. 特别注意:发往topic交换器的消息不能随意的设置选择键(routing_key),必须是有"."隔开的一系列的标识符组成。

    28、交换器4种类型?

    主要有以下4种。

    fanout:把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。

    direct:把消息路由到BindingKey和RoutingKey完全匹配的队列中。

    topic:

    匹配规则:

    RoutingKey 为一个 点号'.': 分隔的字符串。 比如: java.xiaoka.show

    BindingKey和RoutingKey一样也是点号“.“分隔的字符串。

    BindingKey可使用 _ 和 # 用于做模糊匹配,_匹配一个单词,#匹配多个或者0个

    headers:不依赖路由键匹配规则路由消息。是根据发送消息内容中的headers属性进行匹配。性能差,基本用不到。

    29、交换器无法根据自身类型和路由键找到符合条件队列时,有哪些处理?

    mandatory :true 返回消息给生产者。

    mandatory: false 直接丢弃。

    30、RabbitMQ队列结构?

    通常由以下两部分组成:

    rabbit_amqqueue_process:负责协议相关的消息处理,即接收生产者的消息、向消费者交付消息、处理消息的确认(包括生产端的 confirm 和消费端的 ack) 等。

    backing_queue:是消息存储的具体形式和引擎,并向 rabbit amqqueue process 提供相关的接口以供调用。

    31、集群中的节点类型?

    内存节点:ram,将变更写入内存。

    磁盘节点:disc,磁盘写入操作。

    RabbitMQ要求最少有一个磁盘节点。

    32、集群节点类型有几种?

    内存节点:保存状态到内存,但持久化的队列和消息还是会保存到磁盘;

    磁盘节点:保存状态到内存和磁盘,一个集群中至少需要一个磁盘节点

    33、Consumer Cancellation Notification 机制用于什么场景?

    用于保证当镜像 queue 中 master 挂掉时,连接到 slave 上的 consumer 可以收到自身 consume 被取消的通知,进而可以重新执行 consume 动作从新选出的 master 出获得消息。若不采用该机制,连接到 slave 上的 consumer 将不会感知 master 挂掉这个事情,导致后续无法再收到新 master 广播出来的 message 。另外,因为在镜像 queue 模式下,存在将 message 进行 requeue 的可能,所以实现 consumer 的逻辑时需要能够正确处理出现重复 message 的情况。

    34、消息传输保证层级?

    1、 At most once:最多一次。消息可能会丢失,单不会重复传输。

    2、 At least once:最少一次。消息觉不会丢失,但可能会重复传输。

    3、 Exactly once:恰好一次,每条消息肯定仅传输一次。

    35、事务机制?

    RabbitMQ 客户端中与事务机制相关的方法有三个:

    channel.txSelect 用于将当前的信道设置成事务模式。

    channel 、txCommit 用于提交事务 。

    channel 、txRollback 用于事务回滚,如果在事务提交执行之前由于 RabbitMQ 异常崩溃或者其他原因抛出异常,通过txRollback来回滚。

    36、如何避免消息重复投递或重复消费?

    在消息生产时,MQ内部针对每条生产者发送的消息生成一个inner-msg-id,作为去重和幂等的依据(消息投递失败并重传),避免重复的消息进入队列;在消息消费时,要求消息体中必须要有一个bizId(对于同一业务全局唯一,如支付ID、订单ID、帖子ID等)作为去重和幂等的依据,避免同一条消息被重复消费。

    这个问题针对业务场景来答分以下几点:

    1、 拿到这个消息做数据库的insert操作。然后给这个消息做一个唯一主键,那么就算出现重复消费的情况,就会导致主键冲突,避免数据库出现脏数据。

    2、 拿到这个消息做Redis的set的操作,因为你无论set几次结果都是一样的,set操作本来就算幂等操作。

    3、 如果上面两种情况还不行。准备一个第三方介质,来做消费记录。以Redis为例,给消息分配一个全局id,只要消费过该消息,将<id,message>以K-V形式写入Redis。那消费者开始消费前,先去Redis中查询有没消费记录即可。

    37、routing_key 和 binding_key 的最大长度是多少?

    255 字节。

    38、RabbitMQ消息确认过程?

    消费者收到的每一条消息都必须进行确认(自动确认和自行确认)

    消费者在声明队列时,可以置顶autoAck参数,当autoAck = false时,RabbitMQ会等待消费者显式发送回 ack 信号后才从内存(和磁盘,如果是持久化消息的话)中删除消息,否则RabbitMQ会在队列中消息被消费后立即删除它。

    采用消息确认机制后,只要使 autoAck = false,消费者就有足够的时间处理消息(任务),不用担心处理消息过程中消费者进程挂掉后消息丢失的问题,因为RabbitMQ会一直持有消息直到消费者显式调用basicAck为止。

    当autoAck = false时,对于RabbitMQ服务器端而言,队列中的消息分成了两部分:一部分是等待投递给消费者的消息;一部分是已经投递给消费者,但是还没有收到消费者ack信号的消息。如果服务器端一直没有收到消费者的ack信号,并且消费此消息的消费者已经断开连接,则服务器端会安排该消息 重新进入队列,等待投递给下一个消费者(也可能还是原来的那个消费者)。

    RabbitMQ不会为 ack消息设置超时时间,它判断此消息是否需要重新投递给消费者的唯一依据是消费该消息的消费者连接是否已经断开。这么设计的原因是RabbitMQ允许消费者消费一条消息的时间可以很久很久。

    39、RabbitMQ如何实现延时队列?

    利用TTL(队列的消息存活时间或者消息存活时间),加上死信交换机

    // 设置属性,消息10秒钟过期
    AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
    .expiration("10000") // TTL
    
    // 指定队列的死信交换机
    Map<String,Object> arguments = new HashMap<String,Object>();
    arguments.put("x-dead-letter-exchange","DLX_EXCHANGE");

    40、消息怎么路由?

    从概念上来说,消息路由必须有三部分:交换器、路由、绑定。生产者把消息到交换器上;绑定决定了消息如何从路由器路由到特定的队列;消息最终到达队列,并被消费者接收。

    消息到交换器时,消息将拥有一个路由键(routing key),在消息创建时设定。通过队列路由键,可以把队列绑定到交换器上。消息到达交换器后,RabbitMQ会将消息的路由键与队列的路由键进行匹配(针对不同的交换器有不同的路由规则)。如果能够匹配到队列,则消息会投递到相应队列中;如果不能匹配到任何队列,消息将进入 “黑洞”。

    常用的交换器主要分为一下三种:

    1、 direct:如果路由键完全匹配,消息就被投递到相应的队列

    2、 fanout:如果交换器收到消息,将会广播到所有绑定的队列上

    3、 topic:可以使来自不同源头的消息能够到达同一个队列。使用topic交换器时,可以使用通配符。比如:“*” 匹配特定位置的任意文本, “.” 把路由键分为了几部分,“#” 匹配所有规则等。特别注意:发往topic交换器的消息不能随意的设置选择键(routing_key),必须是由"."隔开的一系列的标识符组成。

    更对 RabbitMQ 面试题 50道

    01、 死信队列和延迟队列的使用?
    02、 RabbitMQ的集群模式有几种?
    03、 无法被路由的消息去了哪里?
    04、 向不存在的 exchange 发 publish 消息会发生什么?向不存在的 queue 执行consume 动作会发生什么?
    05、 消息如何保证幂等性?
    06、 生产者消息如何运转?
    07、 优先级队列?
    08、 消费者某些原因无法处理当前接受的消息如何来拒绝?
    09、 消息基于什么传输?
    10、 rabbitmq的集群

    11、 集群中的节点类型?
    12、 集群节点类型有几种?
    13、 Consumer Cancellation Notification 机制用于什么场景?
    14、 消息传输保证层级?
    15、 事务机制?
    16、 如何避免消息重复投递或重复消费?
    17、 routing_key 和 binding_key 的最大长度是多少?
    18、 RabbitMQ消息确认过程?
    19、 RabbitMQ如何实现延时队列?
    20、 消息怎么路由?

    21、 vhost 是什么?起什么作用?
    22、 AMQP协议3层?
    23、 RabbitMQ topic 主题模式(路由模式的一种)
    24、 RabbitMQ基本概念
    25、 消息如何被优先消费?
    26、 在单 node 系统和多 node 构成的 cluster 系统中声明 queue、exchange ,以及进行 binding 会有什么不同?
    27、 RabbitMQ消息是如何路由的?
    28、 交换器4种类型?
    29、 交换器无法根据自身类型和路由键找到符合条件队列时,有哪些处理?
    30、 RabbitMQ队列结构?

    31、 RabbitMQ routing路由模式
    32、 消息怎么路由?
    33、 RabbitMQ publish/subscribe发布订阅(共享资源)
    34、 能够在地理上分开的不同数据中心使用 RabbitMQ cluster 么?
    35、 RabbitMQ有那些基本概念?
    36、 什么情况下会出现 blackholed 问题?
    37、 什么是消费者Consumer?
    38、 消息如何分发?
    39、 Basic.Reject 的用法是什么?
    40、 什么是Binding绑定?

    41、 如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,怎么办?
    42、 为什么说保证 message 被可靠持久化的条件是 queue 和 exchange 具有durable 属性,同时 message 具有 persistent 属性才行?
    43、 如何自动删除长时间没有消费的消息?
    44、 RabbitMQ 概念里的 channel、exchange 和 queue 这些东东是逻辑概念,还是对应着进程实体?这些东东分别起什么作用?
    45、 消费者获取消息的方式?
    46、 使用RabbitMQ有什么好处?
    47、 mq的缺点
    48、 死信队列?
    49、 Binding绑定?
    50、 消息传输保证层级?

     如果不背 RabbitMQ 面试题的答案,肯定面试会挂!

    这套RabbitMQ面试题大全,希望对大家有帮助哈~

    博主已将以下这些面试题整理成了一个Java面试手册,是PDF版的

    展开全文
  • 流水带来了冲突。本节课解决结构冲突与数据冲突
  • Git常见冲突解决

    千次阅读 2017-01-08 09:44:11
    两个用户修改了同一个文件的同一块区域,git会报告内容冲突。我们常见的都是这种,后面的解决办法也主要针对这种冲突
  • 原标题:避免创业合伙人之间...创业合伙人之间的矛盾冲突是由多方面原因引起的,有自己的原因也有对方的原因,还可能有其它的原因。要顺利地化解矛盾,就应该从自我批评开始。这样,会给对方也造成愧疚感,也会坦...
  • Jar包冲突问题解决方案!

    千次阅读 2021-05-20 10:51:55
    Jar包冲突是老生常谈的问题,几乎每一个Java程序猿都不可避免地遇到过,并且也都能想到通常的原因一般是同一个Jar包由于maven传递依赖等原因被引进了多个不同的版本而导致,可采用依赖排除、依赖管理等常规方式来...
  • git rebase 的常见冲突及解决办法

    千次阅读 2017-10-08 10:53:00
     解决合并冲突几个常见的办法是: 手动编辑冲突文件,手动删除或者保留冲突的代码; 对于“both added”、“both deleted”、“both modified”等类型冲突,若想完整地保留某一方的修改可以执行git checkout ...
  • 数据库常见死锁原因及处理

    万次阅读 多人点赞 2017-07-08 10:22:40
    数据库和操作系统一样,是一个多用户使用的共享资源...在实际应用中经常会遇到的与锁相关的异常情况,当两个事务需要一组有冲突的锁,而不能将事务继续下去的话,就会出现死锁,严重影响应用的正常执行。  在数据库中
  • 有时使用HttpWebRequest对象会出现错误有三种服务器提交了协议冲突/基础连接已经关闭:连接被意外关闭/无法发送具有此谓词类型的内容正文,感兴趣的朋友可以参考下本
  • 关于哈希函数的选取,可以参见这篇文章,另外常见的字符串哈希函数c++代码实现可以看这里 主要有:常用的字符串Hash函数还有ELFHash,APHash等等,都是十分简单有效的方法。这些函数使用位运算使得每一个字符都对...
  • 冲突域和广播域 联网中继设备 集线器(hub) 交换机(switch) 路由器(route) 三者的异同 1)工作层次不同 2)数据转发依据对象不同 3)分割冲突域,广播域 4)防火墙功能 参考文献 冲突域和广播域 在介绍...
  • 常见软件测试类型分类

    万次阅读 2018-09-20 09:48:05
    软件测试类型 1)回归测试 回归测试: (regression testing): 回归测试有两类:用例回归和错误回归;用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试,看看会重新发现问题。错误回归,就是在新...
  • Idea中Git的使用和两种类型冲突解决

    万次阅读 多人点赞 2017-06-16 17:35:03
    一、Git冲突解决 在idea开发工具中使用Git时,主要用到的快捷按钮如下五个: 这五个按钮的使用说明在idea中如何配置和使用git可参考...
  • 而“如何处理冲突”这个主题又可以衍生出许多不同类型的问题。   下面我们就举几个例子,来看看面试官一般会怎样问与这个主题有关的问题。   一、与“如何处理冲突”主题有关的问题   在团队项目中,当你...
  • 【转载】Jar包冲突问题解决方案

    千次阅读 2018-06-08 13:02:34
    作者:sherlockyb ...关于JAR包冲突问题,几乎是...Jar包冲突是老生常谈的问题,几乎每一个Java程序猿都不可避免地遇到过,并且也都能想到通常的原因一般是同一个Jar包由于maven传递依赖等原因被引进了多个不同的版...
  • 常见的加密算法分类介绍

    千次阅读 2021-03-04 14:20:00
    单向散列函数一般用于产生消息摘要,密钥加密等,常见的有: MD5(Message Digest Algorithm 5):是RSA数据安全公司开发的一种单向散列算法,非可逆,相同的明文产生相同的密文。 SHA(Secure Hash Algorithm):...
  • 常见编程错误解决方法,避免踩雷

    千次阅读 多人点赞 2021-03-25 22:24:09
    编程常见问题分析,以及错误解决办法! 作为程序员,如果哪一天没有了错误或警告的提示,一定会有一种不祥的预感吧,自从开始编程以来,碰到过很多问题,在遇到错误的时候不要慌,首先看报错,中文直接看,英文翻译看...
  • 100道最新Java面试题,常见面试题答案汇总

    万次阅读 多人点赞 2022-03-31 08:01:53
    BLOCKED:这种状态指的是处于RUNNING状态的线程,出于某种原因,比如调用了sleep方法、等待用户输入等而让出当前的CPU给其他的线程。 Q58:定义了类的显式构造函数之后,还可以使用默认构造函数吗? 答案:如果没有...
  • 在实际应用中经常会遇到的与锁 相关的异常情况,当两个事务需要一组有冲突的锁,而不能将事务继续下去的话,就会出现死锁,严重影响应用的正常执行。 在数据库中有两种基本的锁类型:排它锁(Exclusive Locks,即X锁...
  • 在我们实际开发过程中,我们往往会遇到需要引用...常见的jar包冲突的2种异常:对于这种问题相信大家时长遇到,当我们在使用一些开源工具时,他们内部引入的基础能力jar包版本往往会不一致,如: 像上面这两个依赖在sp
  • 常见的退避类型 8.1 根据延时窗口的大小划分 8.2 根据延时时间与冲突次数的关系划分 第1章 以太网概述 1.1 以太网概述 以太网是现实世界中最普遍的一种计算机网络。 (1)根据网络的架构,以太网分为 第一类是总线型...
  • 性能测试常见瓶颈分析调优方法

    千次阅读 2020-11-16 10:38:42
    性能测试出现的原因及其定位十分复杂,这里只是简单介绍常见的几种瓶颈类型和特征,而性能测试所需要做的就是根据各种情况因素综合考虑,然后协助开发人员\DBA\运维人员一起定位性能瓶颈。 一般性能问题调优的步骤...
  • 如何解决git提交代码冲突

    千次阅读 2020-12-19 11:35:11
    2016-12-29 回答冲突的产生很多命令都可能出现冲突,但从根本上来讲,都是merge 和 patch(应用补丁)时产生冲突。而rebase就是重新设置基准,然后应用补丁的过程,所以也会...冲突类型逻辑冲突git自动处理(合并/...
  • 重新看待Jar包冲突问题解决方案

    万次阅读 2017-09-03 09:29:01
    Jar包冲突是老生常谈的问题,几乎每一个Java程序猿都不可避免地遇到过,并且也都能想到通常的原因一般是同一个Jar包由于maven传递依赖等原因被引进了多个不同的版本而导致,可采用依赖排除、依赖管理等常规方式来...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 155,268
精华内容 62,107
热门标签
关键字:

常见的冲突类型及原因