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

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

在南明等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站建设、网站设计网站设计制作按需求定制网站,公司网站建设,企业网站建设,高端网站设计,营销型网站,外贸网站建设,南明网站建设费用合理。

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

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

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

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

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

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

2. 服务层上下游细节

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

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

如上图：

(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是什么业务含义：

传入群gid，同gid的请求落在同一个服务上;
传入用户uid，同uid的请求落在同一个服务上;
传入任何业务xid，同业务xid的请求落在同一个服务上;

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

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

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

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

【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】

攀枝花网站建设、攀枝花网站运维推广公司-贝锐智能，是专注品牌与效果的网络营销公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：贝锐智能

贝锐智能技术为您推荐以下文章