rocketmq的sql92过滤？消息过滤的顺序？sql92是sql的一种，在server端进行过滤。首先msg在consumeQueue中根据tag的hash进行第一层过滤，然后从commitLog中读取message按照sql92进行第二层过滤，然后发给client，根据equalof标签。第三层过滤。Rocketmq的灰度方案？生产者如何识别灰度消息？上游用户一般是双应用，在请求中指定特定的灰度标记，标识该请求是灰度请求。灰度请求下发送灰度消息，在msg的头部设置灰度标志，消息如何控制路由？没有灰度消息到主题的路由控制。该解决方案基于属性过滤来满足灰度要求。消息仍然正常发送到主题。消费者如何消费灰度新闻？正常消费者再次消费新闻时，会识别灰度标识，过滤掉灰度标识。相反，灰度消费者会过滤正常的消息，消费灰度消息。rocketmq消息追踪是如何实现的？producer发送消息前后，broker接受消息，drop消息，consumer拉消息，consumer消息拉到capital，consumer完成消费。设置钩子函数，将监控信息构建成msg，发送到rocketmq指定的topic。使用offsetMsgId作为key，这样就可以找到消息的轨迹。==================================================双方都是数据库同步高手吗？如果双方都是主人，如何避免循环复制？如果双方都对同一条消息进行更改怎么办？数据库标记机房信息，即在表中添加一条机房信息。同步数据时，只复制对端机房的数据。第一点是防止两个master修改同一条数据，上端根据主键路由将SQL路由到对应的master。第二天控制版本号，让每条数据都有一个版本号，比如updateTime。如果数据库的版本号比较大，这条数据就会被丢弃。数据库读写分离，读方不能接受同步延迟怎么办？如果不从“主”读取，则先从“从”读取。使用参数来控制是否需要从master读取。这样可以满足大部分情况的读写分离，也可以满足部分情况的低延迟需求=============================================================你用过缓存吗？自写缓存淘汰策略？LRU，剩下的不知道怎么设计才能让缓存命中率更高？热点统计，用访问次数来表示热点缓存和数据库的一致性？单点缓存没有一致性问题，没用过redis==================================================================================================================================================================================================================================================================================Raft选择themaster：A，B，C，D，E。假设A是leader，当leader可能宕机时，什么情况下数据会写入成功，什么情况下数据会被丢弃？在A宕机前，只要有一个slave返回ack，就认为数据成功，因为在下次选举中，这个节点会被选为主，这条消息会继续提交。A、B、C、D、E。假设A是leader，A、B、C、D、E有一个网络分区。此时各个分区节点的行为是怎样的？首先，A无法收到大部分的心跳回复。这时候会进入master选举状态，B跟着也会进入。因为CDE收不到心跳，会进入master选择状态，选举新的master。A、B、C、D、E。假设A是leader，写入两份数据，一份A，BC多数同意，A，B，D多数同意，A，B和C，D，E有一个网络分区，此时各个分区节点的行为?首先，在这种情况下，C和D中肯定有一个节点会同时拥有这两个数据，因为raft是顺序写入的，每个事务都有一个termidentifier，所以C和D中的一个会是选为master，然后commit两条数据。如果选择配置中心/注册中心，你会考虑什么？需要考虑多机房部署
