前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >“ID串行化”是如何保证消息顺序性的?

“ID串行化”是如何保证消息顺序性的?

作者头像
Java架构师必看
发布2021-10-20 16:14:54
8170
发布2021-10-20 16:14:54
举报
文章被收录于专栏:Java架构师必看Java架构师必看

在《消息顺序性为何这么难?》中,介绍了一种为了保证“所有群友展示的群消息时序都是一致的”所使用的“ID串行化”的方法:让同一个群gid的所有消息落在同一台服务器上处理。

ID串行化是如何实现的呢?

互联网高可用常见分层架构

“ID串行化”是如何保证消息顺序性的?
“ID串行化”是如何保证消息顺序性的?

客户端,反向代理层,接入层,服务层,存储层,这是互联网常见的高可用分层架构。

画外音:这个图用过好多次。

这里的“服务层”至关重要,ID串行化保证的是,同一个群gid的消息落在同一个服务上。

画外音:服务集群有很多节点,如果能落在同一个服务节点上,就可以利用这个服务节点做消息串行化。

服务层上下游细节

服务一般由RPC框架实现,上游调用方是多线程程序,通过RPC-client访问服务,而RPC-client内部又通过连接池connection-pool来访问的。

画外音:为了保证高可用,连接池会对集群中的每个服务都建立连接。

“ID串行化”是如何保证消息顺序性的?
“ID串行化”是如何保证消息顺序性的?

如上图:

(1)上游是业务应用;

(2)下游是服务集群;

(3)业务应用,它又分为了这么几个部分:

 - 上层是任务队列(粉色)

 - 中间是工作线程(蓝色),每个工作线程完成实际的业务任务,典型的工作任务是通过服务连接池进行RPC调用;

 - 下层是服务连接池(绿色),所有的RPC调用都是通过服务连接池往下游服务发请求执行;

画外音:橙色是连接池中的一条连接。

工作线程的典型工作流是这样的:

void work_thread_routine(){

// 获取任务

Task t = TaskQueue.pop(); 

// 任务逻辑处理,组成一个网络包packet

Packet p = MakePacket(t);

// 从Service连接池获取一个Service连接

ServiceConnection c = CPool.GetConnection();

// 通过Service连接发送报文执行RPC请求

c.Send(p); 

// 将Service连接放回Service连接池

CPool.PutConnection(c); 

}

如何保证同一个群gid的消息落在同一个服务上呢?

对连接池进行少量改动,获取连接时:

CPool.GetConnection()

画外音:返回任何一个可用服务连接。

升级为

CPool.GetConnection(long id)

画外音:返回id取模相关联的服务连接。

只要传入群gid,就能够保证同一个群的请求获取到同一个连接,从而使请求落到同一个服务上。

需要注意的是,连接池不关心传入的long id是什么业务含义:

(1)传入群gid,同gid的请求落在同一个服务上;

(2)传入用户uid,同uid的请求落在同一个服务上;

(3)传入任何业务xid,同业务xid的请求落在同一个服务上;

ID串行化访问服务,同一个id访问同一个服务,当服务挂掉时,会不会受影响服务可用性?

不会,当有下游服务挂掉的时候,连接池能够检测到连接的可用性,取模时要把不可用的服务连接排除掉。

取模访问服务,是否会影响各连接上请求的负载均衡?

不会,只要数据访问id是均衡的,从全局来看,由id取模获取各连接的概率也是均等的,即负载是均衡的。

获取连接,ID取模,希望大家有收获。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
负载均衡
负载均衡(Cloud Load Balancer,CLB)提供安全快捷的流量分发服务,访问流量经由 CLB 可以自动分配到云中的多台后端服务器上,扩展系统的服务能力并消除单点故障。负载均衡支持亿级连接和千万级并发,可轻松应对大流量访问,满足业务需求。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档