标签：思路 远程 日志 name 函数返回 通信 roc oop off
最近面试聚美优品以及睿沿科技都挂在一些开放性问题上，简单分享一下：
（毕业面百度也是最后一面开放性问题挂了，感觉都喜欢问技术选型，大数据量储存检索解决方案）
MQ 选型：
ROCKETMQ整体架构：
负责消息储存的broker（包含topic，一个topic有多个队列）, 负责消息投递的客户端，负责消息消费的消费端，负责协调broker的name-server组成。
各个模块间的通信由基于Netty封装的协议完成，具体可看源码rocketmq-remoting
消息投送： 询问name-server当前TOPIC有哪些broker可以投递消息，按照一定的策略选择broker投递消息。
消息消费： 消费提供两种模式，集群消费、广播消费模式。
集群消费模式同一个消费组下不同消费者实例消费的消息肯定不会重复（集群模式实例消费的位置记录在远程服务端，下一次启动会从远程询问消费位置，从指定位置消费）
广播模式topic下面所有消息都会被消费一次。（每次都会从本地OFFET STORE查询消费，如果清空本地存储直接从头消费）
提供的功能特性：
1，顺序消费。
支持顺序消费，需要保证当前topic下面的队列唯一性。
2，支持消息事务
由于其设计了一种了消息状态PREPARE，消息发送成功后消费者不可见，只有发送成功回调函数返回COMMIT才认为成功，此时消费者可正常消费。可以看到这里的事务保证的是消息投递与本地业务的事务一致性。
kafaka 架构上 与ROCKETMQ一致，只不过他把队列叫成分区并且每个分区只能被同已消费组的某一个实例持有。KAFAKA与ROCKETMQ类似也支持顺序消费，同样需要保证单个topic单个分区（因为分区上的消息是有序的，可以根据时间SORT不知道他怎么实现的）。
选型的问题：
1，JAVA业务场景下建议ROCKETMQ
因为JAVA业务体系下抛开KAFAKA的吞吐量优势其他和ROCKETMQ比没有适合优势（本身的缓存还有可能导致JAVA 频繁GC）。因为业务场景下面TOPIC数量可能较大，KAFAKA单机超过16个分区就有性能问题。
ROCKETMQ 提供对消息的检索，这是KAFAKA不具备的
ROCKETMQ 消费已经集成了线程池什么的，手动可配，KAFKA还需要手动自己写。
但是ROCKETMQ与SPRING-STREAM整合不是很友好
2， 日志收集首选KAFAKA，因为他吞吐量大，我们认为日志收集就是大数据量。
海量上亿小文件的存储检索方案：
检索一般涉及到一些检索算法（向量搜索引擎，存储涉及到一些分布式储存的概念，这个坑跌倒两次了）
有了上面的消息BROKER,TOPIC这种思路引导，显然我们把消息变成文件，把BROKER变成专攻文件存储(hdfs)，把NAME-SERVER追加文件检索的功能(Map-REDUCE)，你可能就会发现这恰恰有点契合HADOOP大数量的分布式文件储存检索方案
标签：思路 远程 日志 name 函数返回 通信 roc oop off
原文地址：https://www.cnblogs.com/enjoyall/p/13060457.html
