Java开发面试中间件框架相关知识-持续更新中

/dubbo
       |
/com.bob.dubbo.service.CityDubboService
       |                |                   |                           |
/providers     /consumers     /configurators    / routers
       |                |
/ip port class
所有的method
版本
例如：anyhost=true 
application=dst-operate-service
dubbo=2.6.2
generic=false
interface=com.dst.modules.dataanal.CarRentalRecordService
methods=generatorData,createBatchRecord,deleteAll,selectListByCondition,updateRecordByAccount,queryRecordList,updateByBackcarReasonByCode,queryRentCarListByvinCode,queryRecordListByPickCode,queryRecordListByServiceOrderCode,updateOldServiceCode,createRecord,updateBatchCarRentalRecordById,updateBatchByRenewLease,updateRecord,queryRecordListByDeliveryCode
payload=20971520
pid=41756
side=provider
timestamp=1554781127816

消费者也会注册节点便于管理、监控；
消费者在第一次调用时会获取提供方ip，并缓存到本地，同时消费者会利用zookeeper提供的watcher机制订阅提供者变更信息

zookeeper观察机制;
服务端只存储事件的信息,客户端存储事件的信息和Watcher的执行逻辑.ZooKeeper客户端是线程安全的每一个应用只需要实例化一个ZooKeeper客户端即可，同一个ZooKeeper客户端实例可以在不同的线程中使用。ZooKeeper客户端会将这个Watcher对应Path路径存储在ZKWatchManager中,同时通知ZooKeeper服务器记录该Client对应的Session中的Path下注册的事件类型。当ZooKeeper服务器发生了指定的事件后,ZooKeeper服务器将通知ZooKeeper客户端哪个节点下发生事件类型，ZooKeeper客户端再从ZKWatchManager中找到相应Path，取出相应watcher引用执行其回调函数process。
每个watcher注册一次只会触发一次，需要重新注册才能再触发

服务上线，向zk注册临时节点；
服务下线，zk本身通过发起心跳感知服务端是否存在，心跳长期无响应则删除节点

hession

json

dubbo

java

protobuf

Thrift

所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。 即worker线程接收到事件后，将该事件提交到业务线程池中，自己再去处理其他事。

基于dubbo一致性Hash，相同参数的请求总是发到同一提供者。通过参数计算hash值，以此计算请求哪个提供者

zookeeper

etcd

consul

Eureka

Nacos

固定大小线程池，线程，不关闭，一直持有。(缺省)
coresize：200
maxsize：200
队列：SynchronousQueue
回绝策略：AbortPolicyWithReport - 打印线程信息jstack，之后抛出异常

缓存线程池，无核心线程数，有最大线程数，队列为SynchronousQueue，所以提交任务时，会直接创建线程，空闲一分钟自动删除，需要时重建

可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。

类似tomcat中的线程池，当核心线程都在忙碌时（通过对比已提交未执行任务数量（AtomicInteger）和核心线程数量），优先保障线程数量到达最大线程数，再放队列

一个实例只向注册中心注册一条记录，不同于之前一个接口注册一条，彻底解决服务推送性能瓶颈；
同时由于这样的模型与主流微服务体系如 SpringCloud、K8S 等天然是对等的，因此为 Dubbo 解决和此类异构体系间的互联互通清除了障碍，
dubbo通过对同一接口（服务）发布不同的协议来支持异构服务互联互通

由于注册中心只有 应用-实例 的信息，缺少RPC（如接口等）信息，那么RPC相关的数据Dubbo新版本通过
「服务自省」机制实现：
服务自省在服务消费端和提供端之间建立了一条内置的 RPC 服务信息协商机制，这也是“服务自省”这个名字的由来。服务端实例会暴露一个预定义的 MetadataService RPC 服务，消费端通过调用 MetadataService 获取每个实例 RPC 方法相关的配置信息（如重试、负载均衡策略等等）。
实际上就是提供方和消费方对于RPC数据的同步，目前有两种形式：
    1）内建 MetadataService。
    2）独立的元数据中心，通过中细化的元数据集群协调数据。
消费端可以在调用时查询服务方的MetadataService，或者提供方同步到元数据中心，当注册中心有变动时下发到消费方，消费方再去元数据中心查。
另外还有一个配置中心，保存了 service - app 的映射，调用变成先查配置中心，找到app后查注册中心（缓存的注册中心）找到提供方ip，然后根据提供方的RPC数据然后进行调用。

通用性

Protobuf 实现了语言中立的服务定义，不依赖于具体的语言，例如java那么只能通过interface来定义服务。

序列化上更高效，更通用

在服务注册阶段提前生成 ServiceDescriptor 和 MethodDescriptor

1. 取字符串的长度的时间复杂度为O(1)：
redis由C语言实现，不存在字符串结构，只能用字符数组和指针实现，buf[]中依然采用了C语言的以\0结尾可以直接使用C语言的部分标准C字符串库函数，redis使用sds其中记录了字符串长度

2. 杜绝缓冲区溢出
由于C 语言不记录字符串长度，如果增加一个字符传的长度，如果没有注意就可能溢出，覆盖了紧挨着这个字符的数据。对于SDS 而言增加字符串长度需要验证 free的长度，如果free 不够就会扩容整个 buf，防止溢出。

3. 减少修改字符串长度时造成的内存再次分配
redis 作为高性能的内存数据库，需要较高的相应速度。字符串也很大概率的频繁修改。 SDS 通过未使用空间这个参数，将字符串的长度和底层buf的长度之间的额关系解除了。buf的长度也不是字符串的长度。基于这个分设计 SDS 实现了空间的预分配和惰性释放。

struct sdshdr {
 int len; //长度
 int free; //剩余空间
 char buf[]; //字符串数组
};

struct listNode {
 struct listNode * prev; //前置节点
 struct listNode * next; //后置节点
 void * value;//节点的值
};

struct dict {
 ... dictht ht[2]; //哈希表 有两个dictht，一个用于扩容复制用
 rehashidx == -1 //rehash使用，没有rehash的时候为-1
}

或者 ziplist

ziplist并没有定义明确的结构体, 根据存储结构我们可以定义ziplist如下
typedef struct ziplist{
     /*ziplist分配的内存大小*/
     uint32_t bytes;
     /*达到尾部的偏移量*/
     uint32_t tail_offset;
     /*存储元素实体个数*/
     uint16_t length;
     /*存储内容实体元素*/
     unsigned char* content[];
     /*尾部标识*/
     unsigned char end;
}ziplist;

ziplist内存布局
|-----------|-----------|----------|---------------------------------------------------|---|
    bytes      offset      length  content         {zlentry, zlentry ... ...}           end

后期版本都使用了quickList，因为zipList对于内存空间耗费过大，所以都使用了quickList，相当于使用双向链表，但是链表项是若干个zipList

每个字典有两个hash表，一个平时使用，一个rehash的时候使用。rehash是渐进式的

过程：dict中ht[2]中有两个hash表, 我们第一次存储数据的数据时, ht[0]会创建一个最小为4的hash表, 一旦ht[0]中的size和used相等, 则dict中会在ht[1]创建一个size*2大小的hash表；
此时并不会直接将ht[0]中的数据copy进ht[0]中, 执行的是渐进式rehash, 即在以后的操作(find, set, get等)中慢慢的迁移进去, 通过 reindexid 记录当前正在迁移的bucketId，迁移时，新增数据会直接写入h[1]，而修改删除查询由于不知道属于h[0]还是[1]，所以会先查找h[0]再找h[1], 因此在ht[1]被占满的时候定能确保ht[0]中所有的数据全部copy到ht[1]中.

触发：1. serveCron定时检测迁移 2. 每次kv变更的时候（新增、更新）的时候顺带rehash。

采用单向链表的方式解决hash冲突，新的冲突元素会被放到链表的表头，头插（依据是时间局部性原理，认为新插入的后续被访问的几率高）

dict 中维护key->score映射，实现 O(1) 查找分数
skiplist 通过分数作为键形成，达到按照分数的（范围）查找

方便范围查找

实现简单

插入元素方便，只需要修改相邻元素的指针

节点层数随机（抛硬币，每个节点每增一个层级就通过随机数决定是否再往上加层级）

struct intset {
 uint32_t encoding;//编码方式
 uint32_t length;//集合包含的元素数量
 int8_t contents[];//保存元素的数组（哈希表实现）
};

save命令

bgsave命令

通过配置文件配置的save规则触发

fork 子进程来进行数据持久化，保证 Redis 在此期间可以继续对外提供服务，但是fork一瞬间会阻塞父进程；
因为fork采用操作系统写时复制机制（COW），fork不会拷贝父进程的内存数据，但是会拷贝进程的必要的数据结构，例如拷贝内存页表（虚拟内存和物理内存的映射索引表），这个过程会消耗CPU且阻塞，内存数据越多则阻塞时间越长；
fork后父子进程实际上是指向同一个地址空间，父子进程各自有虚拟内存空间，但是对应的物理内存地址空间是同一个。此时把内存页的权限设置为read-only，如果两个进程中的一个尝试对写操作时，触发page-fault，触发kernel中断，kernel把触发异常的页复制一份，申请独立的内存地址，此后读写至此，逐渐各自独立。
在rdb场景中即父进程对已存在的key进行写操作时，会复制对应的内存页到新申请的内存地址，子进程则还是会读到fork时的内存地址数据，互不影响。

redis 没有专门的用户导入的命令，redis 在启动的时候会检测是否有 RDB 文件，有的话，就自动导入。

恢复大数据集时较快，缺点是备份时间较长的话，发生宕机，容易丢失部分数据

描述：aof由于是类似日志追加的形式保存，其数据会越来越大，所以进行压缩存储，如多条命令合并为一条，这样存储就节省了很多。重写也不是分析现有 aof，重写就是从数据库读取现有的 key，然后尽量用一条命令替代；
另外重写是通过fork子进程重写，重写时机由文件大小来控制

删缓存方案

存在的问题

采用删缓存而不是更新缓存还体现了懒加载，需要的时候才更新缓存

和方案3. 更新数据库+删缓存区别在于
数据库数据要加版本号信息
缓存组件要判断版本号较新的进行更新，旧的忽略
避免缓存穿透

存在的问题

redisson

唯一键

问题

业务名：表名：id 例子 o2o:order:1

拒绝big key

打散过期时间（加上随机数）

所谓热key问题就是，突然有几十万的请求去访问redis上的某个特定key。那么，这样会造成流量过于集中，达到物理网卡上限，从而导致这台redis的服务器宕机。那接下来这个key的请求，就会直接怼到你的数据库上，导致你的服务不可用

1. 凭借业务经验，进行预估哪些是热key其实这个方法还是挺有可行性的。比如某商品在做秒杀，那这个商品的key就可以判断出是热key。缺点很明显，并非所有业务都能预估出哪些key是热key。

2. 在客户端进行收集这个方式就是在操作redis之前，加入一行代码进行数据统计。那么这个数据统计的方式有很多种，也可以是给外部的通讯系统发送一个通知信息。缺点就是对客户端代码造成入侵。

3. 在Proxy层做收集有些集群架构是下面这样的，Proxy可以是Twemproxy，是统一的入口。可以在Proxy层做收集上报，但是缺点很明显，并非所有的redis集群架构都有proxy。 client -> proxy ->redis cluster

4. 用redis自带命令(1)monitor命令，该命令可以实时抓取出redis服务器接收到的命令，然后写代码统计出热key是啥。当然，也有现成的分析工具可以给你使用，比如redis-faina。但是该命令在高并发的条件下，有内存增暴增的隐患，还会降低redis的性能。(2)hotkeys参数，redis 4.0.3提供了redis-cli的热点key发现功能，执行redis-cli时加上–hotkeys选项即可。但是该参数在执行的时候，如果key比较多，执行起来比较慢。

5. 自己抓包评估Redis客户端使用TCP协议与服务端进行交互，通信协议采用的是RESP。自己写程序监听端口，按照RESP协议规则解析数据，进行分析。缺点就是开发成本高，维护困难，有丢包可能性。

1. 预热，首先热 key 肯定是要缓存的，提前把热数据加载到缓存中，一上线就直接读取缓存。

2. 备份，缓存至少集群架构，保证多个从，这样就算一个从挂了，还有备份。

3. 二级缓存（热点发现，本地缓存），使用机器的内存再做一道拦截。比如像秒杀的商品基本信息可以直接使用机器的内存，可以通过增加proxy层，topK统计高频访问key，达到阈值后自动通过集中式配置中心例如zookeeper下发客户端，客户端本地缓存对应kv。

4. 限流，预估支持的 qps，拦截多余的请求。

5. 冗余到多个节点，首先生成hotKey_l, hotKey_2, hotKey_3…, hotKey100，换句话说，热键被人为复制了100次。它们会映射到多个哈希槽，并存储在许多不同的 Redis 实例上。然后在查询时，每当这个热键hotKey由客户端请求，我们在热键后添加一个 [1, 100] 范围内的随机数

1. 字符串类型 超过10KB 2. 集合类型 元素数量超过5000？

1. redis阻塞 redis单线程，bigkey删除耗时长，也消耗cpu，bigkey序列化反序列也消耗应用的cpu

2. 网络阻塞 假设我们的交换机，千兆网络（小b），那么 实际带宽 1024 / 8 = 128M . 假设你的这个key的大小 500KB， 客户端并发 1000获取这个key， 那么就意味着 1000 * 500KB = 500M ,那就是每秒产生500M的流量。先不说你的Redis能不能处理的过来这个并发下的bigKey，单说你的这个千兆网络， 你说你这个网络I/O能扛得住吗？ 一般服务器会采用单机多实例的方式来部署，也就是说一个bigkey可能会对其他实例也造成影响，其后果不堪设想

--bigkeys 命令

离线方式 对rdb文件进行分析，不够实时

分片：big list变为 list_1、list_2、…list_N
比如一个大的key，假设存了1百万的用户数据，可以拆分成 200个key，根据用户id分片，newHashKey = hashKey + (哈希(字段) % 200);

查少量：若大key不可避免 那么不要一下子全查出来，例如有时候仅仅需要hmget，而不是hgetall

过期时间设置为非业务高峰期，否则过期触发del，造成阻塞，或者用redis 4.0的lazy free特性，但是默认不开启

* Redis 4.0提供了过期异步删除(lazyfree-lazyexpire yes)lazy free 惰性删除或延迟释放: 当删除键的时候,redis提供异步延时释放key内存的功能，把key释放操作放在Background I/O单独的子线程处理中，减少删除big key对redis主线程的阻塞，有效地避免删除big key带来的性能和可用性问题。

现象：访问一个非法的数据（数据库和缓存中都不存在）出现这种情况，每次必然是要去数据库请求一次不存在的数据，这时候因为没有数据，所以也不会写入缓存，下一次同样的请求还是会重蹈覆辙。

解决方案

现象：热点数据在某一时刻缓存过期，然后突然大量请求打到 db 中，这时如果 db 扛不住，可能就挂了，引起线上连锁反应。

解决方案

现象：缓存不可用或者大量缓存由于超时时间相同在同一时间段失效，所有的请求都打到了 db，与缓存击穿不同的是，雪崩是大量的 key，击穿是一个 key，这时 db 的压力也不言而喻。

解决方案

在主从的架构下，解决人工将从节点晋升为主节点，但是没有解决数据分片，每台节点数据都一样

1. Codis Proxy (codis-proxy)
    - 实现了Redis协议，表现的和原生Redis差不多，集群部署，无状态，分布式逻辑写在proxy上，逻辑上将key分成1024个slot（hash算法是crc32(key)%1024），会从zk同步节点的槽位分布路由信息
2. Codis Manager (codis-config)
    - 管理工具，节点的增删改查
3. Codis Redis (codis-server)
4. ZooKeeper
    - 存放数据路由表，proxy元数据，config通过zookeeper下发配置到每个proxy

1. 中心化，codis强依赖zookeeper，proxy通过zookeeper来监听的redis集群变化等，会出现zk死机或选举阶段服务不可用或者通信问题，zk没有及时摘除故障proxy，导致请求按比例丢失的风险
2. codis本身并不负责主从切换，主从复制依赖redis本身的replication，手动切换；另外也提供一个codis-ha在master挂掉后，提升slave为master
3. 部署结构复杂，缩扩容需要手动干预

为什么slot大小为16384而不是65536（CRC16产生的 Hash 值有 16bit，即65536个值）？

答：三个方面 心跳包大小、节点数量、心跳包压缩比
1. 节点间交换信息中包含一个bitmap用于表示当前节点负责的槽信息，大小为16384/8/1024 = 2KB，当slot为65536时，大小相应变为8KB
unsigned char myslots[CLUSTER_SLOT/8];
2. 另外也会携带其他节点的信息，比例约为集群总结点数的1/10，至少为3个节点，导致节点越多，心跳包消息头越大，所以作者建议节点数不大于1000，
这样slot为16384时，每个节点的slot分配不会过少。
3. bitmap传输中会进行压缩，bitmap填充率（slot/N N为节点数）很高的情况下，压缩率变低。
综上作者的16384是一个权衡下的最合适的选择。

为什么不用一致性hash，而采用虚拟槽？

答：首先一致性hash是将节点分布在hash环上，请求计算hash值对应节点位置后，顺时针寻找环上的最近节点，
那么相对于一致性hash的key的分布是自动的，而hash槽的 key-node 映射是确定的，方便运维介入控制，比如节点的增删、热点key迁移等等

每个节点维护一份自己视角下整个集群的状态，主要包含：
1. 当前集群状态
2. 集群中各节点所负责的slot及migrate状态
3. 各节点master-slave状态
4. 各节点存活及怀疑Fail状态

节点之间会发送多种消息，最主要的是节点间会通过发送PING/PONG互相探活和交换信息。

1. 集群半数master宕机

2. 某一个节点主从全部宕机

扩容：
1. CLUSTER MEET命令或使用redis-trib.rb工具让新节点加入集群
2. rehash指定节点的数据（目的是迁移到新节点）
3. 添加从节点

缩容类似：
1. 迁移数据
2. 下线节点

Redis Cluster通过ping/pong消息实现故障发现：不需要sentinel
ping/pong不仅能传递节点与槽的对应消息，也能传递其他状态，比如：节点主从状态，节点故障等
故障发现就是通过这种模式来实现，分为主观下线和客观下线：

1. 主观下线（偏见）
某个节点认为另一个节点不可用，'偏见'，只代表一个节点对另一个节点的判断，不代表所有节点的认知
流程：
1.节点1定期发送ping消息给节点2
2.如果发送成功，代表节点2正常运行，节点2会响应PONG消息给节点1，节点1更新与节点2的最后通信时间
3.如果发送失败，则节点1与节点2之间的通信异常判断连接，在下一个定时任务周期时，仍然会与节点2发送ping消息
4.如果节点1发现与节点2最后通信时间超过node-timeout，则把节点2标识为pfail状态

2. 客观下线（半数存在偏见则客观下线）
当半数以上持有槽的主节点都标记某节点主观下线时，可以保证判断的公平性，
集群模式下，只有主节点(master)才有读写权限和集群槽的维护权限，从节点(slave)只有复制的权限
1.某个节点接收到其他节点发送的ping消息，如果接收到的ping消息中包含了其他pfail节点，这个节点会将主观下线的消息内容添加到自身的故障列表中，故障列表中包含了当前节点接收到的每一个节点对其他节点的状态信息
2.当前节点把主观下线的消息内容添加到自身的故障列表之后，会尝试对故障节点进行客观下线操作

1. 资格检查
对从节点的资格进行检查，只有经过过检查的从节点才可以开始进行故障恢复
每个从节点检查与故障主节点的断线时间
超过cluster-node-timeout * cluster-slave-validity-factor数字，则取消资格
cluster-node-timeout默认为15秒，cluster-slave-validity-factor默认值为10
如果这两个参数都使用默认值，则每个节点都检查与故障主节点的断线时间，如果超过150秒，则这个节点就没有成为替换主节点的可能性

2. 投票、替换故障的主
由正常的master节点进行投票，slave复制的offset大的权重大，获得的投票多，超过半数成为master

当一个从节点发现自己正在复制的主节点进入了已下线状态时，从节点将开始对下线主节点进行故障转移，以下是故障转移执行的步骤：

1. 从节点会执行SLAVEOF no one命令，成为新的主节点；
2. 新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽全部指派给自己；
3.新的主节点向集群广播一条PONG消息，这条PONG消息可以让集群中的其他节点立即知道这个节点已经由从节点变成了主节点，并且这个主节点已经接管了原本由已下线节点负责处理的槽。
4. 新的主节点开始接收和自己负责处理的槽有关的命令请求，故障转移完成。

queue数量=consumer数量时，queue与consumer一对一指定。queue数量>consumer数量时，其中一些消费者会消费多个队列。queue数量<consumer数量，queue与consumer一对一指定，多出来的消费者空闲。

发送重试

单机的同步、异步刷盘机制

主从之间的数据复制

ACK机制

每个状态单独分出一个或多个独立的字段。消息来时只更新其中一个字段，会有短暂的不一致，但是最终会一致。

Kafka

RocketMQ

Kafka

RocketMQ

Kafka

RocketMQ