在《消息順序性為何這麼難？》中，介紹了一種為了保證“所有群友展示的群消息時序都是一緻的”所使用的“id串行化”的方法：讓同一個群gid的所有消息落在同一台伺服器上處理。
id串行化是如何實作的呢？
用戶端，反向代理層，接入層，服務層，存儲層，這是網際網路常見的高可用分層架構。
畫外音：這個圖用過好多次。
這裡的“服務層”至關重要，id串行化保證的是，同一個群gid的消息落在同一個服務上。
畫外音：服務叢集有很多節點，如果能落在同一個服務節點上，就可以利用這個服務節點做消息串行化。
服務一般由rpc架構實作，上遊調用方是多線程程式，通過rpc-client通路服務，而rpc-client内部又通過連接配接池connection-pool來通路的。
畫外音：為了保證高可用，連接配接池會對叢集中的每個服務都建立連接配接。
如上圖：
（1）上遊是業務應用；
（2）下遊是服務叢集；
（3）業務應用，它又分為了這麼幾個部分：
上層是任務隊列(粉色)；
中間是工作線程(藍色)，每個工作線程完成實際的業務任務，典型的工作任務是通過服務連接配接池進行rpc調用；
下層是服務連接配接池(綠色)，所有的rpc調用都是通過服務連接配接池往下遊服務發請求執行；
畫外音：橙色是連接配接池中的一條連接配接。
工作線程的典型工作流是這樣的：
對連接配接池進行少量改動，擷取連接配接時：
cpool.getconnection()
畫外音：傳回任何一個可用服務連接配接。
更新為
cpool.getconnection(long id)
畫外音：傳回id取模相關聯的服務連接配接。
隻要傳入群gid，就能夠保證同一個群的請求擷取到同一個連接配接，進而使請求落到同一個服務上。
需要注意的是，連接配接池不關心傳入的long id是什麼業務含義：
（1）傳入群gid，同gid的請求落在同一個服務上；
（2）傳入使用者uid，同uid的請求落在同一個服務上；
（3）傳入任何業務xid，同業務xid的請求落在同一個服務上；
不會，當有下遊服務挂掉的時候，連接配接池能夠檢測到連接配接的可用性，取模時要把不可用的服務連接配接排除掉。
不會，隻要資料通路id是均衡的，從全局來看，由id取模擷取各連接配接的機率也是均等的，即負載是均衡的。
擷取連接配接，id取模，希望大家有收獲。
架構師之路-分享可落地的技術文章
相關推薦：
《離不開的微服務架構，脫不開的rpc細節（值得收藏）》
《究竟啥才是網際網路架構“高可用”》