?很多業(yè)務(wù)都需要考慮消息投遞的順序性：

• 單聊消息投遞，保證發(fā)送方發(fā)送順序與接收方展現(xiàn)順序一致；
• 群聊消息投遞，保證所有接收方展現(xiàn)順序一致；
• 充值支付消息，保證同一個(gè)用戶(hù)發(fā)起的請(qǐng)求在服務(wù)端執(zhí)行序列一致；

消息順序性是分布式系統(tǒng)架構(gòu)設(shè)計(jì)中非常難的問(wèn)題，有什么常見(jiàn)優(yōu)化實(shí)踐呢？

折衷一：以客戶(hù)端或者服務(wù)端的時(shí)序?yàn)闇?zhǔn)

不管什么情況，都需要一個(gè)標(biāo)尺來(lái)衡量時(shí)序的先后順序，可以根據(jù)業(yè)務(wù)場(chǎng)景，以客戶(hù)端或者服務(wù)端的時(shí)間為準(zhǔn)，例如：

(1) 郵件展示順序，其實(shí)是以客戶(hù)端發(fā)送時(shí)間為準(zhǔn)的；

畫(huà)外音：發(fā)送方只要將郵件協(xié)議里的時(shí)間調(diào)整為1970年或者2970年，就可以在接收方收到郵件后一直“置頂”或者“置底”。

(2) 秒殺活動(dòng)時(shí)間判斷，肯定得以服務(wù)器的時(shí)間為準(zhǔn)，不可能讓客戶(hù)端修改本地時(shí)間，就能夠提前秒殺；

折衷二：服務(wù)端生成單調(diào)遞增id作為時(shí)序依據(jù)

對(duì)于嚴(yán)格時(shí)序的業(yè)務(wù)場(chǎng)景，可以利用單點(diǎn)寫(xiě)db的seq/auto_inc_id生成單調(diào)遞增的id，來(lái)保證順序性。

畫(huà)外音：這個(gè)生成id的單點(diǎn)容易成為瓶頸。

折衷三：假如業(yè)務(wù)能接受誤差不大的趨勢(shì)遞增id

消息發(fā)送、帖子發(fā)布時(shí)間、甚至秒殺時(shí)間都沒(méi)有這么精準(zhǔn)時(shí)序的要求：

• 同1s內(nèi)發(fā)布的聊天消息時(shí)序亂了，沒(méi)事；
• 同1s內(nèi)發(fā)布的帖子排序不對(duì)，沒(méi)事；
• 用1s內(nèi)發(fā)起的秒殺，由于服務(wù)器多臺(tái)之間時(shí)間有誤差，落到A服務(wù)器的秒殺；成功了，落到B服務(wù)器的秒殺還沒(méi)開(kāi)始，業(yè)務(wù)上也是可以接受的（用戶(hù)感知不到）

所以，大部分業(yè)務(wù)，長(zhǎng)時(shí)間趨勢(shì)遞增的時(shí)序就能夠滿(mǎn)足業(yè)務(wù)需求，非常短時(shí)間的時(shí)序誤差一定程度上能夠接受。

于是，可以使用分布式id生成算法來(lái)生成id，作為時(shí)序依據(jù)。

折衷四：利用單點(diǎn)序列化，可以保證多機(jī)相同時(shí)序

數(shù)據(jù)為了保證高可用，需要做到進(jìn)行數(shù)據(jù)冗余，同一份數(shù)據(jù)存儲(chǔ)在多個(gè)地方，怎么保證這些數(shù)據(jù)的修改消息是一致的呢？

“單點(diǎn)序列化”是可行的：

• 先在一臺(tái)機(jī)器上序列化操作；
• 再將操作序列分發(fā)到所有的機(jī)器，以保證多機(jī)的操作序列是一致的，最終數(shù)據(jù)是一致的；

典型場(chǎng)景一：數(shù)據(jù)庫(kù)主從同步

數(shù)據(jù)庫(kù)的主從架構(gòu)，上游分別發(fā)起了op1,op2,op3三個(gè)操作，主庫(kù)master來(lái)序列化所有的SQL寫(xiě)操作op3,op1,op2，然后把相同的序列發(fā)送給從庫(kù)slave執(zhí)行，以保證所有數(shù)據(jù)庫(kù)數(shù)據(jù)的一致性，就是利用“單點(diǎn)序列化”這個(gè)思路。

典型場(chǎng)景二：GFS中文件的一致性

GFS(Google File System)為了保證文件的可用性，一份文件要存儲(chǔ)多份，在多個(gè)上游對(duì)同一個(gè)文件進(jìn)行寫(xiě)操作時(shí)，也是由一個(gè)主chunk-server先序列化寫(xiě)操作，再將序列化后的操作發(fā)送給其他chunk-server，來(lái)保證冗余文件的數(shù)據(jù)一致性的。

單對(duì)單聊天，怎么保證發(fā)送順序與接收順序一致呢？

單人聊天的需求，發(fā)送方A依次發(fā)出了msg1，msg2，msg3三個(gè)消息給接收方B，這三條消息能否保證顯示時(shí)序的一致性（發(fā)送與顯示的順序一致）？

方案設(shè)計(jì)思路如下：

• 如果利用服務(wù)器單點(diǎn)序列化時(shí)序，可能出現(xiàn)服務(wù)端收到消息的時(shí)序?yàn)閙sg3，msg1，msg2，就會(huì)與發(fā)出序列不一致。
• 業(yè)務(wù)上不需要全局消息一致，只需要對(duì)于同一個(gè)發(fā)送方A，ta發(fā)給B的消息時(shí)序一致，常見(jiàn)優(yōu)化方案，在A往B發(fā)出的消息中，加上發(fā)送方A本地的一個(gè)絕對(duì)時(shí)序，來(lái)表示接收方B的展現(xiàn)時(shí)序。

msg1{sender:A, seq:10, receiver:B, msg:content1}
msg2{sender:A, seq:20, receiver:B, msg:content2}
msg3{sender:A, seq:30, receiver:B, msg:content3}

可能存在問(wèn)題是：如果接收方B先收到msg3，msg3會(huì)先展現(xiàn)，后收到msg1和msg2后，會(huì)展現(xiàn)在msg3的前面。

群聊消息，怎么保證各接收方收到順序一致？

群聊消息的需求，N個(gè)群友在一個(gè)群里聊，怎么保證所有群友收到的消息顯示時(shí)序一致？

方案設(shè)計(jì)思路如下：

• 假設(shè)和單聊消息一樣，利用發(fā)送方的seq來(lái)保證時(shí)序，因?yàn)榘l(fā)送方不單點(diǎn)，seq無(wú)法統(tǒng)一生成，可能存在不一致。
• 于是，可以利用服務(wù)器的單點(diǎn)做序列化。

如上圖，此時(shí)群聊的發(fā)送流程為：

• sender1發(fā)出msg1，sender2發(fā)出msg2；
• msg1和msg2經(jīng)過(guò)接入集群，服務(wù)集群；
• service層到底層拿一個(gè)唯一seq，來(lái)確定接收方展示時(shí)序；
• service拿到msg2的seq是20，msg1的seq是30；
• 通過(guò)投遞服務(wù)將消息給多個(gè)群友，群友即使接收到msg1和msg2的時(shí)間不同，但可以統(tǒng)一按照seq來(lái)展現(xiàn)；

這個(gè)方法能實(shí)現(xiàn)，所有群友的消息展示時(shí)序相同。

缺點(diǎn)是，生成全局遞增序列號(hào)的服務(wù)很容易成為系統(tǒng)瓶頸。

還有沒(méi)有進(jìn)一步的優(yōu)化方法呢？

群消息其實(shí)也不用保證全局消息序列有序，而只要保證一個(gè)群內(nèi)的消息有序即可，這樣的話(huà)，“id串行化”就成了一個(gè)很好的思路。

這個(gè)方案中，service層不再需要去一個(gè)統(tǒng)一的后端拿全局seq，而是在service連接池層面做細(xì)小的改造，保證一個(gè)群的消息落在同一個(gè)service上，這個(gè)service就可以用本地seq來(lái)序列化同一個(gè)群的所有消息，保證所有群友看到消息的時(shí)序是相同的。

此時(shí)利用本地時(shí)鐘來(lái)生成seq就湊效了，是不是很巧妙？

總結(jié)

• 要“有序”，先得有衡量“有序”的標(biāo)尺，可以是客戶(hù)端標(biāo)尺，可以是服務(wù)端標(biāo)尺；
• 大部分業(yè)務(wù)能夠接受大范圍趨勢(shì)有序，小范圍誤差；絕對(duì)有序的業(yè)務(wù)，可以借助服務(wù)器絕對(duì)時(shí)序的能力；
• 單點(diǎn)序列化，是一種常見(jiàn)的保證多機(jī)時(shí)序統(tǒng)一的方法，典型場(chǎng)景有db主從一致，gfs多文件一致；
• 單對(duì)單聊天，只需保證發(fā)出的時(shí)序與接收的時(shí)序一致，可以利用客戶(hù)端seq；
• 群聊，只需保證所有接收方消息時(shí)序一致，需要利用服務(wù)端seq，方法有兩種，一種單點(diǎn)絕對(duì)時(shí)序，另一種id串行化；

思路比結(jié)論更重要，希望大家有收獲。