xiaoxi整理

rocketmq的sql92过滤是在哪过滤？msg过滤的顺序？

sql92是一种sql，是在服务端过滤，msg首先根据tag的hash在consumeQueue中第一层过滤，然后从commitLog读出消息根据sql92进行第二层过滤，然后到客户端，根据tag的equal进行第三层过滤。

rocketmq的灰度方案？

producer是怎么识别灰度消息的？
    上游用户一般是double应用，在请求投中指定特定灰度标记，用来标识这个请求是灰度请求，灰度请求下就发送灰度消息，在msg的头部中设置一个灰度标识
灰度消息是怎么控制路由的？
    灰度消息到topic没有路由控制，这个方案是根据properties属性过滤达到灰度需求的。消息还是正常发往topic。
消费者怎么消费灰度消息？
    正常的消费者再消费消息的时候，会识别灰度标识，过滤掉灰度标识的消息，灰度消费者与之相反，过滤正常消息，消费灰度消息。

rocketmq消息追踪怎么实现的？

    在producer发送消息的前后、broker接受消息、消息落盘、consumer拉取消息、consumer消息拉到本都、consumer消费完毕的地方设置勾子函数，将监控信息构建为msg，发送到rocketmq指定的topic。用offsetMsgId做key，这样就可以查到消息的轨迹。

==================================================

数据库同步两边都是master吗？

如果两边都是master如何避免循环复制？如果两边对同一条消息做出修改怎么办？
    数据库打标机房信息，即在表中加一个机房信息，同步数据的时候，只有是对端机房的数据才复制。
    第一点，规避两个master对同一条数据做修改，上端根据主键路由，把sql达到对应master上。第二天，版本号控制，让每一条数据都带版本号，比如updateTime，如果数据库存在版本号比较大的就放弃这条数据。
如果数据库是读写分离的，读的一方部分情况接受不了同步时延怎么办？
    首先从 "从" 读 ，如果没有读到从 "主" 读。用一个参数控制是否需要从主读。这样能达到满足大部分情况下的读写分离，也能满足部分情况的低延迟要求

===================================================

用过什么缓存吗？

自己写的

缓存的淘汰策略？

LRU，其余的不知道

如何设计让缓存命中率更高？

热点统计，用访问次数代表热度

缓存和数据库的一致性？

单点的缓存不存在一致性问题，redis没用过

======================================================

raft选主：

A，B，C，D，E。假设A是leader，在leader可能宕机的情况下，什么情况数据会被写入成功，什么情况下数据丢弃？
    在A宕机之前，只要有一个从回了ack，那么这条数据就会算写入成功，因为下一次选举中，此节点会被选为主，并且会将这条消息继续commit。
A，B，C，D，E。假设A是leader，A，B 和C，D，E 发生了网络分区，这个时候各个分区节点的行为表现?
    首先A收不到大多数发送心跳的回复，这个时候会进入选主状态，B随之也会进入。C D E因为收不到心跳，会有进入选主状态，选出新主。
A，B，C，D，E。假设A是leader，写入两条数据，一条A，B C多数同意了 和A，B，D多数同意了， A,B和C，D，E发生了网络分区，这个时候各个分区节点的行为表现?
    首先这种情况下 C 和D一定有一个节点会同时有这两条数据，因为raft是顺序写，每个事务都有term标识，所以C和D中会有一个被选为主，然后commit两条数据。

如果是你选择配置中心/注册中心，你会有什么考虑？需要考虑到多机房部署