有一類(lèi)業(yè)務(wù)場(chǎng)景：

• 超高吞吐量，每秒要處理海量請(qǐng)求;
• 寫(xiě)多讀少，大部分請(qǐng)求是對(duì)數(shù)據(jù)進(jìn)行修改，少部分請(qǐng)求對(duì)數(shù)據(jù)進(jìn)行讀取;

這類(lèi)業(yè)務(wù)，有什么實(shí)現(xiàn)技巧么?

接下來(lái)，一起聽(tīng)我從案例入手，娓娓道來(lái)。

[[358930]]

快狗打車(chē)，場(chǎng)景舉例：

• 司機(jī)地理位置信息會(huì)隨時(shí)變化，可能每幾秒鐘地理位置要修改一次;
• 用戶(hù)打車(chē)的時(shí)候查看某個(gè)司機(jī)的地理位置，查詢(xún)地理位置的頻率相對(duì)較低;

這里要用到兩個(gè)接口：

• 大量修改司機(jī)信息：

void SetDriverInfo(long driver_id, DriverInfo info); 

• 相對(duì)少量查詢(xún)司機(jī)信息：

DriverInfo GetDriverInfo(long driver_id);  

這一類(lèi)業(yè)務(wù)，一般怎么實(shí)現(xiàn)呢?

具體到底層的實(shí)現(xiàn)，往往是一個(gè)Map內(nèi)存緩存：

• 查詢(xún)key定長(zhǎng)，例如：司機(jī)ID;
• 返回value也定長(zhǎng)，例如：司機(jī)實(shí)體序列化后的二進(jìn)制串;

即，類(lèi)似這樣的一個(gè)kv緩存結(jié)構(gòu)：

Map<driver_id, DriverInfo> 

這個(gè)kv內(nèi)存緩存是一個(gè)臨界資源，對(duì)它的并發(fā)訪(fǎng)問(wèn)，有什么注意事項(xiàng)么?臨界資源的訪(fǎng)問(wèn)，需要注意加讀寫(xiě)鎖，實(shí)施互斥。

以下，是加鎖寫(xiě)入的偽代碼：

void SetDriverInfo(long driver_id, DriverInfo info){ 
         WriteLock (m_lock); 
         Map<driver_id>= info; 
         UnWriteLock(m_lock); 
} 

畫(huà)外音：假設(shè)info已經(jīng)序列化。

以下，是加鎖讀取的偽代碼：

DriverInfo GetDriverInfo(long driver_id){ 
         DriverInfo t; 
         ReadLock(m_lock); 
         t= Map<driver_id>; 
         UnReadLock(m_lock); 
         return t; 
} 

當(dāng)吞吐量很高時(shí)，上述流程可能存在什么問(wèn)題?

• 假設(shè)快狗打車(chē)有100w司機(jī)同時(shí)在線(xiàn)，每個(gè)司機(jī)每5秒更新一次經(jīng)緯度狀態(tài)，那么每秒就有20w次寫(xiě)并發(fā)操作。
• 假設(shè)快狗打車(chē)日訂單1000w個(gè)，平均每秒大概也有300個(gè)下單，對(duì)應(yīng)到查詢(xún)并發(fā)量，大概每秒1000級(jí)別的并發(fā)讀操作。

在這樣的吞吐量下(每秒20w寫(xiě)，1k讀)，鎖m_lock會(huì)成為潛在瓶頸，導(dǎo)致Map訪(fǎng)問(wèn)效率極低。

有什么潛在的優(yōu)化方法么?

鎖沖突之所以嚴(yán)重，是因?yàn)檎麄€(gè)Map共用一把鎖，鎖的粒度太粗。

畫(huà)外音：可以認(rèn)為是一個(gè)數(shù)據(jù)庫(kù)的“庫(kù)級(jí)別鎖”。

是否可能進(jìn)行水平拆分，來(lái)降低鎖沖突呢?

答案是肯定的。

畫(huà)外音：類(lèi)似于數(shù)據(jù)庫(kù)里的分庫(kù)，把一個(gè)庫(kù)鎖變成多個(gè)庫(kù)鎖，來(lái)提高并發(fā)，降低鎖沖突。

我們可以把1個(gè)Map水平切分成N個(gè)Map：

void SetDriverInfo(long driver_id, DriverInfo info){ 
         i = driver_id % N; // 水平拆分成N份，N個(gè)Map，N個(gè)鎖 
         WriteLock (m_lock[i]);  //鎖第i把鎖 
         Map[i]<driver_id>= info;  // 操作第i個(gè)Map 
         UnWriteLock (m_lock[i]); // 解鎖第i把鎖 
} 

如此優(yōu)化，能否提高性能?

• 一個(gè)Map變成了N個(gè)Map，每個(gè)Map的并發(fā)量，變成了1/N;
• 同時(shí)，每個(gè)Map的數(shù)據(jù)量，變成了1/N;

所以理論上，鎖沖突會(huì)成平方指數(shù)降低，性能會(huì)提升。

有沒(méi)有可能，進(jìn)一步細(xì)化鎖粒度，一個(gè)元素一把鎖呢?

答案也是肯定的。

畫(huà)外音：可以認(rèn)為是一個(gè)數(shù)據(jù)庫(kù)的“庫(kù)級(jí)別鎖”，優(yōu)化為“行級(jí)別鎖”。

不妨設(shè)driver_id是遞增生成的，并且假設(shè)內(nèi)存比較大，此時(shí)可以把Map優(yōu)化成Array，并把鎖的粒度細(xì)化到最細(xì)的，每個(gè)司機(jī)信息一個(gè)鎖：

void SetDriverInfo(long driver_id, DriverInfo info){ 
         index = driver_id; 
         WriteLock (m_lock[index]);  //超級(jí)大內(nèi)存，一條記錄一個(gè)鎖，鎖行鎖 
         Array[index]= info; //driver_id就是Array下標(biāo) 
         UnWriteLock (m_lock[index]); // 解鎖行鎖 
} 

這個(gè)方案使得鎖沖突降到了最低，但鎖資源大增，在數(shù)據(jù)量非常大的情況下，內(nèi)存往往是裝不下的。畫(huà)外音：數(shù)據(jù)量比較小的時(shí)候，可以一個(gè)元素一把鎖，典型的是連接池，每個(gè)連接用一把鎖表示連接是否可用。

還沒(méi)有方法進(jìn)一步降低鎖沖突，提升并發(fā)量呢?

寫(xiě)多讀少的業(yè)務(wù)，有一種優(yōu)化方案：無(wú)鎖緩存，將鎖沖突降低到。

無(wú)鎖緩存，可能存在什么問(wèn)題?

如果緩存不加鎖，讀寫(xiě)吞吐量可以達(dá)到極限，但是多線(xiàn)程對(duì)緩存中同一塊定長(zhǎng)數(shù)據(jù)進(jìn)行寫(xiě)操作時(shí)，有可能出現(xiàn)不一致的臟數(shù)據(jù)。

這個(gè)方案為了提高性能，犧牲了一致性。

讀取時(shí)，獲取到了錯(cuò)誤的數(shù)據(jù)，是不能接受的。

畫(huà)外音：作為緩存，允許cache miss，卻不允許讀臟數(shù)據(jù)。

臟數(shù)據(jù)是如何產(chǎn)生的?

不加鎖，在多線(xiàn)程并發(fā)寫(xiě)時(shí)，可能出現(xiàn)以下情況：

• 線(xiàn)程1對(duì)緩存進(jìn)行操作，對(duì)key想要寫(xiě)入value1;
• 線(xiàn)程2對(duì)緩存進(jìn)行操作，對(duì)key想要寫(xiě)入value2;
• 不加鎖，線(xiàn)程1和線(xiàn)程2對(duì)同一個(gè)定長(zhǎng)區(qū)域進(jìn)行一個(gè)并發(fā)的寫(xiě)操作，可能每個(gè)線(xiàn)程寫(xiě)成功一半，導(dǎo)致出現(xiàn)臟數(shù)據(jù)產(chǎn)生，最終的結(jié)果即不是value1也不是value2，而是一個(gè)亂七八糟的不符合預(yù)期的值value-unexpected;

如何解決上述問(wèn)題呢?

本質(zhì)上，這是一個(gè)數(shù)據(jù)完整性問(wèn)題。

并發(fā)寫(xiě)入的數(shù)據(jù)分別是value1和value2，讀出的數(shù)據(jù)是value-unexpected，數(shù)據(jù)被篡改，這本質(zhì)上是一個(gè)數(shù)據(jù)完整性的問(wèn)題。

通常如何保證數(shù)據(jù)的完整性呢?

例如：運(yùn)維如何保證，從中控機(jī)分發(fā)到上線(xiàn)機(jī)上的二進(jìn)制沒(méi)有被篡改?md5。

又例如：即時(shí)通訊系統(tǒng)中，如何保證接受方收到的消息，就是發(fā)送方發(fā)送的消息?發(fā)送方除了發(fā)送消息本身，還要發(fā)送消息的簽名，接收方收到消息后要校驗(yàn)簽名，以確保消息是完整的，未被篡改。

“簽名”是一種常見(jiàn)的保證數(shù)據(jù)完整性的方案。

加入“簽名”保證數(shù)據(jù)的完整性之后，讀寫(xiě)流程需要如何升級(jí)?

加上簽名之后，不但緩存要寫(xiě)入定長(zhǎng)value本身，還要寫(xiě)入定長(zhǎng)簽名(例如16bitCRC校驗(yàn))：

(1)線(xiàn)程1對(duì)緩存進(jìn)行操作，對(duì)key想要寫(xiě)入value1，寫(xiě)入簽名v1-sign;

(2)線(xiàn)程2對(duì)緩存進(jìn)行操作，對(duì)key想要寫(xiě)入value2，寫(xiě)入簽名v2-sign;

(3)如果不加鎖，線(xiàn)程1和線(xiàn)程2對(duì)同一個(gè)定長(zhǎng)區(qū)域進(jìn)行一個(gè)并發(fā)的寫(xiě)操作，可能每個(gè)線(xiàn)程寫(xiě)成功一半，導(dǎo)致出現(xiàn)臟數(shù)據(jù)產(chǎn)生，最終的結(jié)果即不是value1也不是value2，而是一個(gè)亂七八糟的不符合預(yù)期的值value-unexpected，但簽名，一定是v1-sign或者v2-sign中的任意一個(gè);

畫(huà)外音：16bit/32bit的寫(xiě)可以保證原子性。

(4)數(shù)據(jù)讀取的時(shí)候，不但要取出value，還要像消息接收方收到消息一樣，校驗(yàn)一下簽名，如果發(fā)現(xiàn)簽名不一致，緩存則返回NULL，即cache miss;

當(dāng)然，對(duì)應(yīng)到司機(jī)地理位置，除了內(nèi)存緩存之前，肯定需要timer對(duì)緩存中的數(shù)據(jù)定期落盤(pán)，寫(xiě)入數(shù)據(jù)庫(kù)，如果cache miss，可以從數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)。

巧不巧秒?

總結(jié)

當(dāng)業(yè)務(wù)滿(mǎn)足：

• 超高并發(fā);
• 寫(xiě)多讀少;
• 定長(zhǎng)value;

時(shí)，可以用以下方法來(lái)提升吞吐量：

(1)水平拆分來(lái)降低鎖沖突;

思路：?jiǎn)螏?kù)變多庫(kù)。

(2)Map轉(zhuǎn)Array的方式來(lái)最小化鎖沖突，一條記錄一個(gè)鎖;

思路：庫(kù)鎖變行鎖。

(3)無(wú)鎖，最大化并發(fā);

思路：行鎖變無(wú)鎖，完整性與性能的折衷。

(4)通過(guò)簽名的方式保證數(shù)據(jù)的完整性，實(shí)現(xiàn)無(wú)鎖緩存;

思路：寫(xiě)時(shí)寫(xiě)簽名，讀時(shí)校驗(yàn)簽名。

【本文為51CTO專(zhuān)欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文