diff --git a/net/src/main/java/com/zfoo/net/handler/GatewayRouteHandler.java b/net/src/main/java/com/zfoo/net/handler/GatewayRouteHandler.java index b215bec1e..0d57f755d 100644 --- a/net/src/main/java/com/zfoo/net/handler/GatewayRouteHandler.java +++ b/net/src/main/java/com/zfoo/net/handler/GatewayRouteHandler.java @@ -78,7 +78,7 @@ public void channelRead(ChannelHandlerContext ctx, Object msg) { } - // 把客户端信息包装为一个GatewayAttachment,因此通过这个网关附加包可以得到玩家的uid、sid之类的信息 + // 把客户端信息包装为一个GatewayAttachment,因此通过这个网关附加包可以得到用户或玩家的uid、sid之类的信息 var gatewayAttachment = new GatewayAttachment(session); var signalAttachment = (SignalAttachment) decodedPacketInfo.getAttachment(); if (signalAttachment != null) { @@ -87,7 +87,7 @@ public void channelRead(ChannelHandlerContext ctx, Object msg) { } // 网关优先使用IGatewayLoadBalancer作为一致性hash的计算参数,然后才会使用客户端的session做参数 - // 例子:以聊天服务来说,玩家知道自己在哪个群组groupId中,那往这个群发送消息时,会在Packet中带上这个groupId做为一致性hash就可以了。 + // 例子:以聊天服务来说,用户或玩家知道自己在哪个群组groupId中,那往这个群发送消息时,会在Packet中带上这个groupId做为一致性hash就可以了。 if (packet instanceof IGatewayLoadBalancer) { var loadBalancerConsistentHashObject = ((IGatewayLoadBalancer) packet).loadBalancerConsistentHashObject(); gatewayAttachment.setTaskExecutorHash(loadBalancerConsistentHashObject.hashCode()); @@ -103,7 +103,7 @@ public void channelRead(ChannelHandlerContext ctx, Object msg) { } // 再使用session的sid做一致性hash,因为每次客户端连接过来sid都会改变,所以客户端重新建立连接的话可能会被路由到其它的服务器 // 如果有特殊需求的话,可以考虑去重写网关的转发策略 - // 拿着玩家的sid做一致性hash,那肯定是:一旦重连sid就会一直变化。所以:一般情况下除非自己创建TcpClient,否则逻辑不应该走到这里。 而是走上面的通过UID做一致性hash + // 拿着用户或玩家的sid做一致性hash,那肯定是:一旦重连sid就会一直变化。所以:一般情况下除非自己创建TcpClient,否则逻辑不应该走到这里。 而是走上面的通过UID做一致性hash var sid = session.getSid(); forwardingPacket(packet, gatewayAttachment, sid); } diff --git a/net/src/main/java/com/zfoo/net/router/Router.java b/net/src/main/java/com/zfoo/net/router/Router.java index 057b77638..1b4699fb2 100644 --- a/net/src/main/java/com/zfoo/net/router/Router.java +++ b/net/src/main/java/com/zfoo/net/router/Router.java @@ -125,7 +125,7 @@ public void receive(Session session, Object packet, @Nullable Object attachment) gatewayAttachment.setClient(false); dispatchByTaskExecutorHash(gatewayAttachment.taskExecutorHash(), task); } else { - // 这里是:别的服务提供者提供授权给网关,比如:在玩家登录后,home服查到了玩家uid,然后发给Gateway服 + // 这里是:别的服务提供者提供授权给网关,比如:在用户或玩家登录后,home服查到了玩家uid,然后发给Gateway服 var gatewaySession = NetContext.getSessionManager().getServerSession(gatewayAttachment.getSid()); if (gatewaySession == null) { logger.error("gateway receives packet:[{}] and attachment:[{}] from server" + ", but serverSessionMap has no session[id:{}], perhaps client disconnected from gateway.", JsonUtils.object2String(packet), JsonUtils.object2String(attachment), gatewayAttachment.getSid()); @@ -159,7 +159,7 @@ public void receive(Session session, Object packet, @Nullable Object attachment) * 在zfoo这套线程模型中,保证了服务器所接收到的Packet(最终被包装成PacketReceiverTask任务),永远只会在同一条线程处理, * TaskBus通过AbstractTaskDispatch去派发PacketReceiverTask任务,具体在哪个线程处理通过IAttachment的taskExecutorHash计算。 *

- * 这种流水线做法对cpu缓存非常友好,java线程能大部分时间跑在一个cpu核心,而玩家又和线程一一对应,这样就可以最大限度提高cpu缓存命中率。 + * 这种流水线做法对cpu缓存非常友好,java线程能大部分时间跑在一个cpu核心,而用户逻辑又和线程一一对应,这样就可以最大限度提高cpu缓存命中率。 * cpu的cache越大命中率就越高,性能提高就越明显。 *

* 单线程热点问题,在负载足够大的情况下,比如5000人同时在线的8核服务器,因为样本足够大每个核心分配的人数差距并不会太大。 diff --git a/orm/src/main/java/com/zfoo/orm/model/IEntity.java b/orm/src/main/java/com/zfoo/orm/model/IEntity.java index 9d0e750b3..d2ea4532b 100644 --- a/orm/src/main/java/com/zfoo/orm/model/IEntity.java +++ b/orm/src/main/java/com/zfoo/orm/model/IEntity.java @@ -30,7 +30,7 @@ public interface IEntity> { *

* 写入一条数据到数据库的时候会对比当前entity的vs和数据库的vs是不是一样,不是一样的话无法写入,一致的话就写入数据并且让vs自增+1. * 主要是为了防止多个服务器去操作同一条数据,保证在分布式环境的数据一致性;简单的说就是一个数据版本号的简单实现,版本号一致才能写入数据。 - * 在分布式环境中,会存在有状态服务器,比如网关路由一个玩家的数据到a服务器,这个时候你加了一个b服务器,有可能下一条数据就被路由到b。 + * 在分布式环境中,会存在有状态服务器,比如网关路由一个用户或玩家的数据到a服务器,这个时候你加了一个b服务器,有可能下一条数据就被路由到b。 * 虽然用了一致性hash的负载均衡算法,但是一样有概率会让某些消息路由到不同服务器。 * 这个时候版本号就可以保证只有一台服务器可以对数据库做操作,不用担心多个服务器去操作数据。 * 这是一个容错的操作,真实环境下很少发生。为了高性能必须要把服务器做成有状态的,这个容错操作就是最后一道保证数据一致的方案。