本文目录
一道真实的阿里面试题：如何保证消息队列的高可用性
面试官心理分析
如果有人问到你 MQ 的知识，高可用是必问的。上一讲提到，MQ 会导致系统可用性降低。所以只要你用了 MQ，接下来问的一些要点肯定就是围绕着 MQ 的那些缺点怎么来解决了。
要是你傻乎乎的就干用了一个 MQ，各种问题从来没考虑过，那你就杯具了，面试官对你的感觉就是，只会简单使用一些技术，没任何思考，马上对你的印象就不太好了。这样的同学招进来要是做个 20k 薪资以内的普通小弟还凑合，要是做薪资 20k+ 的高工，那就惨了，让你设计个系统，里面肯定一堆坑，出了事故公司受损失，团队一起背锅。
面试题剖析
这个问题这么问是很好的，因为不能问你 Kafka 的高可用性怎么保证？ActiveMQ 的高可用性怎么保证？一个面试官要是这么问就显得很没水平，人家可能用的就是 RabbitMQ，没用过 Kafka，你上来问人家 Kafka 干什么？这不是摆明了刁难人么。
所以有水平的面试官，问的是 MQ 的高可用性怎么保证？这样就是你用过哪个 MQ，你就说说你对那个 MQ 的高可用性的理解。
RabbitMQ 的高可用性
RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的，我们就以 RabbitMQ 为例子讲解第一种 MQ 的高可用性怎么实现。
RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。
单机模式
单机模式，就是 Demo 级别的，一般就是你本地启动了玩玩儿的😄，没人生产用单机模式。
普通集群模式（无高可用性）
普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你创建的 queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。
面试的时候一般要问哪些问题
我觉得问的再多，关键是对有无相关工作经验的阐述，毕竟大多单位，希望招聘的人员对自己的工作流程很熟。另外很多时候单位的试用，看的更多的是你的工作态度，如果试用期间，工作积极，哪么留下来的机会，会很大。
面试时经常被问到哪些问题
【温少爷观点】
分两种情况：
一、自己投简历（普通人才）
1、专业性问题；2、为什么跳槽；3、你期望的薪资是多少
二、猎头找你（高端人才）
1、专业性问题；2、项目规划问题
对于这问题，我还是比较熟悉，先说说我自己的经历。
我2014年毕业，至今已经过去5年，在这5年时间里，我共跳了3次槽，且每次跳槽，我的薪资和职位都会有一定上升，对于面试，面试官经常会问什么问题呢？
分两种情况。
一、自己投简历（普通人才）
很多面试者，都是通过网上投简历，然后通过公司进行简历筛选，最后被通知进行面试这样的流程。像这种情况，面试官一般会问以下问题。
1、专业性问题
公司招一个员工，首先考察的就是个人能力，毕竟公司是盈利性企业，不能招一个员工回来，啥都不会干，是吧？
面试的时候，面试官会对你之前的从事经历进行适当的提问，例如，你之前在什么企业工作，负责什么项目，做了什么业绩等等，这主要是考察你的能力是否与岗位匹配，能不能胜任此岗位。
2、为什么跳槽
当你的专业性得到面试官认可，这是第一步，然后，有些考官会问你，在之前公司做得好好的，为什么要跳槽呢？
这问题主要考察面试者的态度。
这种情形下，绝对不能说原先公司的坏话，面试官是很反感的。
你可以从自己的个人原因方面下手，打感情牌。
例如：我刚开始第一次跳槽的时候，面试官问我，在上一公司做的好好的，怎么就离开呢？
我是这样回答的：李总，是这样的，我在上一个公司，确实做的不错，工作能力得到上司认可，公司氛围也很适合工作，但是，因为，我爸妈年纪比较大，我又是独子，留他们在老家，不放心，刚好知道贵公司招这方面的人员，我就过来面试，希望贵公司能给我一个机会，成为公司的一份子。
我这样回答，一来，肯定了原公司的实力和氛围，二来，间接也说明，我是有能力胜任这岗位的。这样的回答是不是更有说服力？
3、你期望的薪资是多少
其实，岗位薪资多少，在招聘要求上都有显示的，那么，为什么面试的时候，还要问薪资呢？最本质的原因就是，公司想省成本。
公司都是以盈利为目的的，老板肯定会想尽一切办法压缩成本，实现利润最大化。
那么，对于这问题，我们应该怎么答比较合适？
我这里有一点小技巧，供大家参考。
你可以以原先公司的薪资作为参考，在这基础上涨1000--2000元左右，当然，这个度，需要你自己根据公司实力，岗位的稀缺性进行灵活调整。
二、猎头找你（高端人才）
我比较幸运，在第三次跳槽的时候，就是通过猎头牵线，直至今日，我都在这公司担任技术经理职位。
如果是猎头找到我们，我们在谈判上是有很大的优势的，特别是薪资这块。
猎头公司是怎么操作的，我简单说下流程。
一般猎头找到你，会先咨询你的基本情况，包括工作年限，工作能力、薪资要求及是否有跳槽意愿等等；
然后，猎头会与公司那边沟通，安排面试；
最后，面试通过，公司会出一份正式聘请书，三方各留一份。
通过猎头，你的薪资是不用你自己争取的，只要你通过面试，薪资这块是由他们进行沟通帮你争取。
1、专业性问题
这里的专业性问题，会比以上第一种情况稍微复杂一点。包括产品定位、行业前景等等。
只要你在一个行业做了3年以上，且认真观察思考的话，你会对行业的一些规则及行业未来有自己的见解。
你把你自己对产品定位及行业的前景的理解，按照一定的逻辑说出来就行了。这也是需要你的丰富经验及阅历才能做到的。
2、项目规划问题
通过猎头，一般找到的人才都是项目的负责人，那么面试的时候，你就要有自己一个规划。
我以我的项目经历，举个例子。
我现在做的项目主要分为两大块，一块是见效快的产品，另外一块是见效慢的产品。
那么，在项目前期，肯定是先推广见效快的产品，一来可以先让这个项目启动起来，把业务量做起，二来，可以增加业务员信心，提高他们薪资，增加他们的推广积极性。
但是，在推广见效快的产品的同时，也要推广见效慢的产品，虽然这类型产品，没这么快见效益，但是一旦推广起来，利润是前者的两倍。
所以，必须两者按计划同时进行。现在，我负责的这项目差不多一年了，团队逐渐扩大，业务量也逐渐起来了。
面试是我们职场中很重要的一个环节，如果能把握好，在职场上可以说如虎添翼。
温少爷：3年时间，从职场小白到部门经理，专注于职场与个人成长分享，关注我，我们一起迭代，一起成为职场达人。希望我的回答对您有所帮助和启发。【随手点个赞，对温少爷是个鼓励！】
Kafka，Mq和Redis作为消息队列使用时的差异有哪些
Kafka作为新一代的消息系统，mq是比较成熟消息系统，而redis也可以发布订阅，那么这三者有何异同？
RabbitMQ
是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。
Redis
是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
Kafka
Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。
对比MQ与Kafka
1)在架构模型方面
RabbitMQ遵循AMQP协议，RabbitMQ的broker由Exchange,Binding,queue组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。rabbitMQ以broker为中心；有消息的确认机制。
kafka遵从一般的MQ结构，producer，broker，consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，consumer根据消费的点，从broker上批量pull数据；无消息确认机制。
2)在吞吐量
kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操作，具有O(1)的复杂度，消息处理的效率很高。
rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以采用内存或者硬盘。
3)在可用性方面，
rabbitMQ支持miror的queue，主queue失效，miror queue接管。
