“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取模获取各毗连的概率也是均等的，即负载是平衡的。

【本文为51CTO专栏作者“58沈剑”原创稿件，转载请接洽原作者】

戳这里，看该作者更多好文

【编辑保举】

1. 动静次序性为何这么难？
2. 微博短视频百万级高可用、高并发架构怎样计划？
3. 披荆棘，饿了么数据库高可用架构演进！
4. 毕竟啥才是互联网架构“高可用”
5. 下一代微处事！微博Service Mesh高可用架构拭魅战

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!