1.what这个技术是什么
官方文档定义
Read and write streams of data like a messaging system.
Write scalable stream processing applications that react to events in real-time.
Store streams of data safely in a distributed, replicated, fault-tolerant cluster.
不只是消息系统，还是实时流处理应用和保存流数据。
对比同类技术的优缺点，适用场景（上网抄袭，还需仔细研究）
- RabbitMQ(待研究)
本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。
- Redis(一个缓存做起mq的事情，需要看内部实现，可能停留在可以做，场景未找到，待研究)
Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
- ZeroMQ（嵌套在应用程序里，ZeroMQ不是传统意义上的MQ。它比较适用于节点之间和节点与Master之间的通信。https://blog.csdn.net/gobravery/article/details/71123425）
ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中默认使用ZeroMQ作为数据流的传输。
- ActiveMQ（好似比较常用，之前用于本地调试。待研究）
ActiveMQ是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。
- Kafka(批量发送，顺序读写持久化，所以很适合高吞吐日志流)
快速持久化，可以在O(1)的系统开销下进行消息持久化；因为顺序读写
高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；Kafka的TPS跑到单机百万，主要是由于Producer端将多个小消息合并，批量发向Broker。
完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；
- RocketMQ（和kafka一样海量消息堆积。比kafka消息传递可靠，为什么，需要再研究）
淘宝中间件团队在对Kafka做过充分Review之后，Kafka无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满足，为此我们重新用Java语言编写了RocketMQ，定位于非日志的可靠消息传输（日志场景也OK），目前RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。
https://blog.csdn.net/paincupid/article/details/79721817
ActiveMQ 以及旗下的各个子项目，主要面向企业级市场，吞吐不是其强项，主要和企业已有基础设施集成起来比较方便，如 EAI，ESB 这种早期企业基础架构。
国内一些中大型规模的公司普遍部署了两套消息引擎，一套选择 Apache RocketMQ 用在交易，数据分发等核心链路上，一套选择 Apache Kafka 用在大数据等在线、离线分析链路上。毫无疑问，Kafka 目前在大数据生态建设这块，确实具备一定的先发优势。
http://www.ijiandao.com/2b/baijia/97775.html
此技术的架构组成
每个分区至多只能绑定到一个消费者上，即一个消费者可以消费多个分区，一个分区只能给一个消费者消费
2.why为什么有这个技术
此技术解决什么问题
消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。
https://blog.csdn.net/xiang__liu/article/details/80347516
kafka对比其他消息队列的好处就是批量发送加压缩来高吞吐，顺序读写加快持久化，但是批量发送也带来一定可靠消息传输问题，所以他适合在日志通道的场景，其他场景未必适合。
Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：
- 顺序读写。以时间复杂度为O(1)的方式提供消息持久化能力，并保证即使对TB级以上数据也能保证常数时间的访问性能
- 批量发送和fetch, broken zero copy加压缩，高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输
Kafka采用解耦的设计思想，并非原始的发布订阅（生产者负责产生消息，直接推送给消费者push）。而是在中间加入持久化层——broker,生产者把数据存放在broker中，消费者从broker中pull取数据。这样就带来了几个好处:
- 1 生产者的负载与消费者的负载解耦
- 2 消费者按照自己的能力fetch数据
- 3 消费者可以自定义消费的数量
如果是我，怎么解决这个问题
如果能答到https://www.jianshu.com/p/a7f7d9973fea最后的问题，那就是掌握了。
- 为什么使用消息队列？消息队列的作用是什么？
异步处理，应用解耦，流量削锋和消息通讯
https://blog.csdn.net/xiang__liu/article/details/80347516
- Kafka的topic和分区内部是如何存储的，有什么特点？
kafka为每个主题维护了分布式的分区(partition)日志文件，每个partition在kafka存储层面是append log。任何发布到此partition的消息都会被追加到log文件的尾部，在分区中的每条消息都会按照时间顺序分配到一个单调递增的顺序编号，也就是我们的offset,offset是一个long型的数字，我们通过这个offset可以确定一条在该partition下的唯一消息。在partition下面是保证了有序性，但是在topic下面没有保证有序性。
在上图中在我们的生产者会决定发送到哪个Partition。
1.如果没有Key值则进行轮询发送。
2.如果有Key值，对Key值进行Hash，然后对分区数量取余，保证了同一个Key值的会被路由到同一个分区，如果想队列的强顺序一致性，可以让所有的消息都设置为同一个Key。
- 与传统的消息系统相比,Kafka的消费模型有什么优点
Kafka采取拉取模型(poll)，由自己控制消费速度，以及消费的进度，消费者可以按照任意的偏移量进行消费。比如消费者可以消费已经消费过的消息进行重新处理，或者消费最近的消息等等。
- Kafka如何实现分布式的数据存储与数据读取
kafka一个topic下面的所有消息都是以partition的方式分布式的存储在多个节点上。同时在kafka的机器上，每个Partition其实都会对应一个日志目录，在目录下面会对应多个日志分段(LogSegment)。LogSegment文件由两部分组成，分别为“.index”文件和“.log”文件，分别表示为segment索引文件和数据文件。这两个文件的命令规则为：partition全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值，数值大小为64位，20位数字字符长度，没有数字用0填充，如下，假设有1000条消息，每个LogSegment大小为100，下面展现了900-1000的索引和Log：
由于kafka消息数据太大，如果全部建立索引，即占了空间又增加了耗时，所以kafka选择了稀疏索引的方式，这样的话索引可以直接进入内存，加快偏查询速度。
如何读取数据，如果我们要读取第911条数据首先第一步，找到他是属于哪一段的，根据二分法查找到他属于的文件，找到0000900.index和00000900.log之后，然后去index中去查找 (911-900) =11这个索引或者小于11最近的索引,在这里通过二分法我们找到了索引是[10,1367]然后我们通过这条索引的物理位置1367，开始往后找，直到找到911条数据。
上面讲的是如果要找某个offset的流程，但是我们大多数时候并不需要查找某个offset,只需要按照顺序读即可，而在顺序读中，操作系统会对内存和磁盘之间添加page cahe，也就是我们平常见到的预读操作，所以我们的顺序读操作时速度很快。但是kafka有个问题，如果分区过多，那么日志分段也会很多，写的时候由于是批量写，其实就会变成随机写了，随机I/O这个时候对性能影响很大。所以一般来说Kafka不能有太多的partition。针对这一点，RocketMQ把所有的日志都写在一个文件里面，就能变成顺序写，通过一定优化，读也能接近于顺序读。
- kafka为什么比rocketmq支持的单机partion要少
Kafka的每个Topic、每个分区都会对应一个物理文件。当Topic数量增加时，消息分散的落盘策略会导致磁盘IO竞争激烈成为瓶颈。而RocketMQ所有的消息是保存在同一个物理文件中的，Topic和分区数对RocketMQ也只是逻辑概念上的划分，所以Topic数的增加对RocketMQ的性能不会造成太大的影响。
https://yq.aliyun.com/articles/25379
- 为什么需要分区，也就是说主题只有一个分区，难道不行吗？
利用好可以水平拓展，无论是并发，吞吐量还是存储量。
- 日志为什么需要分段？
增加性能，日志无限增长，查询速度会减慢。
- kafka是依靠什么机制保持高可靠，高可用？
分布式系统中，实现数据高可靠往往通过多副本加Paxos等分布式一致性算法，实现高可用一般是实现快速的故障迁移机制，实现热升级和动态的扩缩容。
高可靠：三份数据副本，任意一份副本丢失不会影响读写和数据完整性。在写入时，保证至少两份写成功后返回，并在后台修复可能存在的一份副本写入失败的情况。读取时，大部分情况只需要读取一份副本即可。
高可用：zookeeper的管理和协调，分片在不同broker里可以使得zookeeper，
https://yq.aliyun.com/articles/236371#3
- 消息队列如何保证消息幂等？
幂等需要通过唯一的业务单号来保证。也就是说相同的业务单号，认为是同一笔业务。使用这个唯一的业务单号来确保，后面多次的相同的业务单号的处理逻辑和执行效果是一致的。
每个producer在初始化的时候都会被分配一个唯一的PID，对于每个唯一的PID，Producer向指定的Topic中某个特定的Partition发送的消息都会携带一个从0单调递增的sequence number。在我们的Broker端也会维护一个维度为<PID,Topic,Partition>，每次提交一次消息的时候都会对齐进行校验: 1）如果消息序号比Broker维护的序号大一以上，说明中间有数据尚未写入，也即乱序，此时Broker拒绝该消息，Producer抛出InvalidSequenceNumber。2）如果消息序号小于等于Broker维护的序号，说明该消息已被保存，即为重复消息，Broker直接丢弃该消息，Producer抛出DuplicateSequenceNumber。3）如果消息序号刚好大一，就证明是合法的。
上面所说的解决了两个问题:1）当Prouducer发送了一条消息之后失败，broker并没有保存，但是第二条消息却发送成功，造成了数据的乱序。2）当Producer发送了一条消息之后，broker保存成功，ack回传失败，producer再次投递重复的消息。上面所说的都是在同一个PID下面，意味着必须保证在单个Producer中的同一个seesion内，如果Producer挂了，被分配了新的PID，这样就无法保证了，所以Kafka中又有事务机制去保证。在kafka的事务中，应用程序必须提供一个唯一的事务ID，即Transaction ID，并且宕机重启之后，也不会发生改变。
- 让你自己设计个消息队列，你会怎么设计，会考虑哪些方面？
吞吐？exactly-onceat-least-onceat-most-once不丢失？
3.how怎么学这个技术
quickstart
https://blog.csdn.net/abcd1101/article/details/85872057
demo
源码
项目实践
如何分享