“id串行化”到底是怎么實現的？
一、需求緣起
在上一篇文章《消息“時序”與“一致性”為何這么難?》中，介紹了一種為了保證“所有群友展示的群消息時序都是一致的”所使用的“id串行化”的方法：讓同一個群gid的所有消息落在同一臺服務器上處理。
有朋友就要問了，如何保證一個群gid的消息落到同一個服務器處理呢，“id串行化”具體是怎么實現的呢，這個問題在年初的一篇文章中描述過，這里再給有疑問的同學解答一下。
二、互聯網高可用常見分層架構
客戶端，反向代理層，接入層(此圖是http短鏈接接入，群聊消息的話是tcp長連接接入)，服務層(處理群消息業務邏輯)，存儲層(緩存cache存儲，固化db存儲)，這是互聯網常見的高可用分層架構。
服務層的引入至關重要，群消息的投遞不能保證落在同一個接入層，但可以保證落在同一個服務層。
三、服務層上下游細節
服務化的service一般由RPC-server框架實現，上游應用是多線程程序(站點層http接入應用，或者長連接tcp接入應用)一般通過RPC-client訪問service，而RPC-client內部又通過連接池connection-pool訪問下游的service(為了保證高可用，是一個service集群)。
如上圖：
(1)上游是業務應用(站點層http接入應用，或者長連接tcp接入應用)
(2)下游是service集群
(3)業務應用，它又分為了這么幾個部分
(3.1)最上層是任務隊列【或許web-server例如tomcat幫你干了這個事情了】
(3.2)中間是工作線程【或許web-server的工作線程或者cgi工作線程幫你干了線程分派這個事情了】，每個工作線程完成實際的業務任務，典型的工作任務是通過服務連接池進行RPC調用
(3.3)最下層是服務連接池，所有的RPC調用都是通過服務連接池往下游服務去發包執行的
工作線程的典型工作流偽代碼是這樣的：
- void work_thread_routine(){
- Task t = TaskQueue.pop(); // 獲取任務
- // 任務邏輯處理，組成一個網絡包packet，調用下游RPC接口
- ServiceConnection c = CPool.GetServiceConnection();
- // 從Service連接池獲取一個Service連接
- c.Send(packet); // 通過Service連接發送報文執行RPC請求
- CPool.PutServiceConnection(c); // 將Service連接放回Service連接池
- }
如何保證同一個群gid的消息落在同一個service上呢?
只要對服務連接池進行少量改動：
獲取Service連接的CPool.GetServiceConnection()【返回任何一個可用Service連接】改為
CPool.GetServiceConnection(long id)【返回id取模相關聯的Service連接】
只要傳入群gid，就能夠保證同一個群的請求獲取到同一個連接，從而使請求落到同一個服務Service上。
需要注意的是，連接池不關心傳入的long id是什么業務含義：
(1)傳入群gid，同gid的請求落在同一個service上
(2)傳入用戶uid，同uid的請求落在同一個service上
(3)傳入任何業務xid，同業務xid的請求落在同一個service上
四、其他問題
提問：id串行化訪問service，同一個id訪問同一個service，當service掛掉時，是否會影響service的可用性?
答：不會，當有下游service掛掉的時候，service連接池能夠檢測到連接的可用性，取模時要把不可用的服務連接排除掉。
提問：取模訪問service，是否會影響各連接上請求的負載均衡?
答：不會，只要數據訪問id是均衡的，從全局來看，由id取模獲取各連接的概率也是均等的，即負載是均衡的。
五、總結
升級RPC-client內部的連接池，在service連接選取上做微小改動，就能夠實現“id串行化”，實現不同類型的業務gid/uid等的串行化、序列號需求(這下查找日志就方便了，一個群gid/用戶uid的日志只需去一臺機器grep啦)。
文章來源微信號：gh_10a6b96351a9
