Ignite Partition 笔记

数据复制机制: 客户端根据HASH算出主节点,数据只从客户端发到主节点
GridNearAtomicSingleUpdateFuture.mapOnTopology
GridNearAtomicSingleUpdateFuture.map
GridNearAtomicAbstractUpdateFuture.sendSingleRequest
GridCacheIoManager.send

当数据复制到主节点时,再从主节点复制到其他节点
GridDhtAtomicCache.updateAllAsyncInternal
GridDhtAtomicAbstractUpdateFuture.map
GridDhtAtomicAbstractUpdateFuture.sendDhtRequests
GridCacheIoManager.send

每当集群拓扑改变时候会重新计算主节点
GridCachePartitionExchangeManager.onDiscoveryEvent
GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest/onCacheChangeRequest/onAffinityChangeRequest/
CacheAffinitySharedManager.applyx
GridAffinityAssignmentCache.calculate
AffinityFunction.assignPartitions

IGNITE 采用 Rendezvous hash 算法,计算每个节点的权重, 只要集群视图一致,那么客户端服务端都应用这种算法,找出权重最高的N个节点,
作为主节点和复制节点
RendezvousAffinityFunction:
为每个PARTITION 分配多个集群节点,PARTITION数量为参数传入RendezvousAffinityFunction,默认1024. 分配的结果表示这个PARTITION的数据应该落在哪些节点上
为每个集群节点计算HASH: 值为节点的CONSISTENTHASHID 对 当前的PARTITION取模,
将HASH排序,然后取前N个节点,N为每个PARTITION最终需要复制到的节点,取决于BACKUP的数量,是否EXCLUDE NEIGHBOR等选项
计算 KEY属于哪个PARTITION: 分配的结果存在GridAffinityAssignment中

GridCacheContext.allowFastLocalRead 中有一个方法判断是否可以从本地快速读取:
topology().partitionState(localNodeId(), part) == OWNING

GridCacheContext.toCacheKeyObject 方法将 key 转化为KeyCacheObject, 并分配partition, 参考 IgniteCacheObjectProcessorImpl.partition

读数据:
GridPartitionedSingleGetFuture.mapKeyToNode 方法获取从哪个节点读取数据
内部调用GridCacheAffinityManager.partition 和GridCacheAffinityManager.nodesByPartition
然后默认从获得NODE 列表的第一个读取数据

新的节点加入后会自动重新REBLANCE数据
CacheAffinitySharedManager.onServerJoin
CacheAffinitySharedManager.initAffinityOnNodeJoin

检查rebalance 是否完成 CacheAffinitySharedManager.checkRebalanceState

Partition 的状态 MOVING, OWNING, RENTING, EVICTED, LOST
OWNING 表示分区属于主节点
RENTING 表示拓扑结构改变以后

猜你喜欢

转载自blog.51cto.com/shadowisper/2317737
今日推荐