IgnitePartition笔记

数据复制机制： 客户端根据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 表示拓扑结构改变以后

网站栏目：IgnitePartition笔记
标题来源：http://6mz.cn/article/phojhg.html