作者：快應(yīng)用服務(wù)器研發(fā)團(tuán)隊-Lin Yupan

一、業(yè)務(wù)背景

許多面向用戶的互聯(lián)網(wǎng)業(yè)務(wù)都會在系統(tǒng)后端維護(hù)一份用戶數(shù)據(jù)，快應(yīng)用中心業(yè)務(wù)也同樣做了這件事?？鞈?yīng)用中心允許用戶對快應(yīng)用進(jìn)行收藏，并在服務(wù)端記錄了用戶的收藏列表，通過用戶賬號標(biāo)識OpenID來關(guān)聯(lián)收藏的快應(yīng)用包名。

為了使用戶在快應(yīng)用中心的收藏列表能夠與快應(yīng)用Menubar的收藏狀態(tài)打通，我們同時也記錄了用戶賬號標(biāo)識OpenID與客戶端本地標(biāo)識local_identifier的綁定關(guān)系。因?yàn)榭鞈?yīng)用Manubar由快應(yīng)用引擎持有，獨(dú)立于快應(yīng)用中心外，無法通過賬號體系獲取到用戶賬號標(biāo)識，只能獲取到客戶端本地標(biāo)識local_identifier，所以我們只能通過二者的映射關(guān)系來保持狀態(tài)同步。

在具體實(shí)現(xiàn)上，我們是在用戶啟動快應(yīng)用中心的時候觸發(fā)一次同步操作，由客戶端將OpenID和客戶端本地標(biāo)識提交到服務(wù)端進(jìn)行綁定。服務(wù)端的綁定邏輯是：判斷OpenID是否已經(jīng)存在，如果不存在則插入數(shù)據(jù)庫，否則更新對應(yīng)數(shù)據(jù)行的local_identifier字段（因?yàn)橛脩艨赡芟群笤趦蓚€不同的手機(jī)上登錄同一個vivo賬號）。在后續(xù)的業(yè)務(wù)流程中，我們就可以根據(jù)OpenID查詢對應(yīng)的local_identifier，反之亦可。

但是代碼上線一段時間后，我們發(fā)現(xiàn)t_account數(shù)據(jù)表中居然存在許多重復(fù)的OpenID記錄。根據(jù)如上所述的綁定邏輯，這種情況理論上是不應(yīng)該發(fā)生的。所幸這些重復(fù)數(shù)據(jù)并沒有對更新和查詢的場景造成影響，因?yàn)樵诓樵兊腟QL中我們加入了LIMIT 1的限制，因此針對一個OpenID的更新和查詢操作實(shí)際上都只作用于ID最小的那條記錄。

二、問題分析與定位

雖然冗余數(shù)據(jù)沒有對實(shí)際業(yè)務(wù)造成影響，但是這種明顯的數(shù)據(jù)問題也肯定是不能容忍的。因此我們開始著手排查問題。

首先想到的就是從數(shù)據(jù)本身入手。先通過對t_account表數(shù)據(jù)進(jìn)行粗略觀察，發(fā)現(xiàn)大約有3%的OpenID會存在重復(fù)的情況。也就是說重復(fù)插入的情況是偶現(xiàn)的，大多數(shù)請求的處理都是按照預(yù)期被正確處理了。我們對代碼重新進(jìn)行了走讀，確認(rèn)了代碼在實(shí)現(xiàn)上確實(shí)不存在什么明顯的邏輯錯誤。

我們進(jìn)一步對數(shù)據(jù)進(jìn)行細(xì)致觀察。我們挑選了幾個出現(xiàn)重復(fù)情況的OpenID，將相關(guān)的數(shù)據(jù)記錄查詢出來，發(fā)現(xiàn)這些OpenID重復(fù)的次數(shù)也不盡相同，有的只重復(fù)一次，有的則更多。但是，這時候我們發(fā)現(xiàn)了一個更有價值的信息——這些相同OpenID的數(shù)據(jù)行的創(chuàng)建時間都是完全相同的，而且自增ID是連續(xù)的。

于是，我們猜測問題的產(chǎn)生應(yīng)該是由于并發(fā)請求造成的！我們模擬了客戶端對接口的并發(fā)調(diào)用，確實(shí)出現(xiàn)了重復(fù)插入數(shù)據(jù)的現(xiàn)象，進(jìn)一步證實(shí)了這個猜測的合理性。但是，明明客戶端的邏輯是每個用戶在啟動的時候進(jìn)行一次同步，為什么會出現(xiàn)同一個OpenID并發(fā)請求呢？

事實(shí)上，代碼的實(shí)際運(yùn)行并不如我們想象中的那么理想，計算機(jī)的運(yùn)行過程中往往存在一些不穩(wěn)定的因素，比如網(wǎng)絡(luò)環(huán)境、服務(wù)器的負(fù)載情況。而這些不穩(wěn)定因素就可能導(dǎo)致客戶端發(fā)送請求失敗，這里的“失敗”可能并不意味著真正的失敗，而是可能整個請求時間過長，超過了客戶端設(shè)定的超時時間，從而被人為地判定為失敗，于是通過重試機(jī)制再次發(fā)送請求。那么最終就可能導(dǎo)致同樣的請求被提交了多次，而且這些請求也許在中間某個環(huán)節(jié)被阻塞了（比如當(dāng)服務(wù)器的處理線程負(fù)載過大，來不及處理請求，請求進(jìn)入了緩沖隊列），當(dāng)阻塞緩解后這幾個請求就可能在很短的時間內(nèi)被并發(fā)處理了。

這其實(shí)是一個典型的并發(fā)沖突問題，可以把這個問題簡單抽象為：如何避免并發(fā)情況下寫入重復(fù)數(shù)據(jù)。事實(shí)上，有很多常見的業(yè)務(wù)場景都可能面臨這個問題，比如用戶注冊時不允許使用相同的用戶名。

一般來說，我們在處理這類問題時，最直觀的方式就是先進(jìn)行一次查詢，當(dāng)判斷數(shù)據(jù)庫中不存在當(dāng)前數(shù)據(jù)時才允許插入。

顯然，這個流程從單個請求的角度來看是沒有問題的。但是當(dāng)多個請求并發(fā)時，請求A和請求B都先發(fā)起一次查詢，并且都得到結(jié)果是不存在，于是兩者都又執(zhí)行了數(shù)據(jù)插入，最終導(dǎo)致并發(fā)沖突。

三、探索可行的方案

既然問題定位到了，接下來就要開始尋求解決方案了。面對這種情況，我們通常有兩種選擇，一種是讓數(shù)據(jù)庫來解決，另一種是由應(yīng)用程序來解決。

3.1 數(shù)據(jù)庫層面處理——唯一索引

當(dāng)使用MySQL數(shù)據(jù)庫及InnoDB存儲引擎時，我們可以利用唯一索引來保障同一個列的值具有唯一性。顯然，在t_account這張表中，我們最開始是沒有為open_id列創(chuàng)建唯一索引的。如果我們想要此時加上唯一索引的話，可以利用下列的ALTER TABLE語句。

ALTER TABLE t_account ADD UNIQUE uk_open_id( open_id );

一旦為open_id列加上唯一索引后，當(dāng)上述并發(fā)情況發(fā)生時，請求A和請求B中必然有一者會優(yōu)先完成數(shù)據(jù)的插入操作，而另一者則會得到類似錯誤。因此，最終保證t_account表中只有一條openid=xxx的記錄存在。

Error Code: 1062. Duplicate entry 'xxx' for key 'uk_open_id'

3.2 應(yīng)用程序?qū)用嫣幚怼?a href="/tags/分布式" target="_blank">分布式鎖

另一種解決的思路是我們不依賴底層的數(shù)據(jù)庫來為我們提供唯一性的保障，而是靠應(yīng)用程序自身的代碼邏輯來避免并發(fā)沖突。應(yīng)用層的保障其實(shí)是一種更具通用性的方案，畢竟我們不能假設(shè)所有系統(tǒng)使用的數(shù)據(jù)持久化組件都具備數(shù)據(jù)唯一性檢測的能力。

那具體怎么做呢？簡單來說，就是化并行為串行。之所以我們會遇到重復(fù)插入數(shù)據(jù)的問題，是因?yàn)椤皺z測數(shù)據(jù)是否已經(jīng)存在”和“插入數(shù)據(jù)”兩個動作被分割開來。由于這兩個步驟不具備原子性，才導(dǎo)致兩個不同的請求可以同時通過第一步的檢測。如果我們能夠把這兩個動作合并為一個原子操作，就可以避免數(shù)據(jù)沖突了。這時候我們就需要通過加鎖，來實(shí)現(xiàn)這個代碼塊的原子性。

對于Java語言，大家最熟悉的鎖機(jī)制就是synchronized關(guān)鍵字了。

public synchronized void submit(String openId, String localIdentifier){ Account account = accountDao.find(openId); if (account == null) { // insert } else { // update }}

但是，事情可沒這么簡單。要知道，我們的程序可不是只部署在一臺服務(wù)器上，而是部署了多個節(jié)點(diǎn)。也就是說這里的并發(fā)不僅僅是線程間的并發(fā)，而是進(jìn)程間的并發(fā)。因此，我們無法通過java語言層面的鎖機(jī)制來解決這個同步問題，我們這里需要的應(yīng)該是分布式鎖。

3.3 兩種解決方案的權(quán)衡

基于以上的分析，看上去兩種方案都是可行的，但最終我們選擇了分布式鎖的方案。為什么明明第一種方案只需要簡單地加個索引，我們卻不采用呢？

因?yàn)楝F(xiàn)有的線上數(shù)據(jù)已然在open_id列上存在重復(fù)數(shù)據(jù)，如果此時直接去加唯一索引是無法成功的。為了加上唯一索引，我們必須首先將已有的重復(fù)數(shù)據(jù)先進(jìn)行清理。但是問題又來了，線上的程序一直持續(xù)運(yùn)行著，重復(fù)數(shù)據(jù)可能會源源不斷地產(chǎn)生。那我們能不能找一個用戶請求不活躍的時間段去進(jìn)行清理，并在新的重復(fù)數(shù)據(jù)插入之前完成唯一索引的建立？答案當(dāng)然是肯定的，只不過這種方案需要運(yùn)維、DBA、開發(fā)多方協(xié)同處理，而且由于業(yè)務(wù)特性，最合適的處理時間段應(yīng)該是凌晨這種夜深人靜的時候。即便是采取這么苛刻的修復(fù)措施，也不能百分之百完全保證數(shù)據(jù)清理完成到索引建立之間不會有新的重復(fù)數(shù)據(jù)插入。因此，基于唯一索引的修復(fù)方案乍看之下非常合適，但是具體操作起來還是略為麻煩。

事實(shí)上，建立唯一索引最合適的契機(jī)應(yīng)該是在系統(tǒng)最初的設(shè)計階段，這樣就能有效避免重復(fù)數(shù)據(jù)的問題。然而木已成舟，在當(dāng)前這個情景下，我們還是選擇了可操作性更強(qiáng)的分布式鎖方案。因?yàn)檫x擇這個方案的話，我們可以先上線加入了分布式鎖修復(fù)的新代碼，阻斷新的重復(fù)數(shù)據(jù)插入，然后再對原有的重復(fù)數(shù)據(jù)執(zhí)行清理操作，這樣一來只需要修改代碼并一次上線即可。當(dāng)然，待問題徹底解決之后，我們可以重新再考慮為數(shù)據(jù)表加上唯一索引。

那么接下來，我們就來看看基于分布式鎖的方案如何實(shí)現(xiàn)。首先我們先來回顧一下分布式鎖的相關(guān)知識。

四、分布式鎖概述

4.1 分布式鎖需要具備哪些特性？

• 在分布式系統(tǒng)環(huán)境下，同一時間只有一臺機(jī)器的一個線程可以獲取到鎖；

• 高可用的獲取鎖與釋放鎖；

• 高性能的獲取鎖與釋放鎖；

• 具備可重入特性；

• 具備鎖失效機(jī)制，防止死鎖；

• 具備阻塞/非阻塞鎖特性。

4.2 分布式鎖有哪些實(shí)現(xiàn)方式？

分布式鎖實(shí)現(xiàn)主要有如下三種：

• 基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖；

• 基于Zookeeper實(shí)現(xiàn)分布式鎖；

• 基于Redis實(shí)現(xiàn)分布式鎖；

4.2.1 基于數(shù)據(jù)庫的實(shí)現(xiàn)方式

基于數(shù)據(jù)庫的實(shí)現(xiàn)方式就是直接創(chuàng)建一張鎖表，通過操作表數(shù)據(jù)來實(shí)現(xiàn)加鎖、解鎖。以MySQL數(shù)據(jù)庫為例，我們可以創(chuàng)建這樣一張表，并且對method_name進(jìn)行加上唯一索引的約束：

CREATE TABLE `myLock` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵', `method_name` varchar(100) NOT NULL DEFAULT '' COMMENT '鎖定的方法名', `value` varchar(1024) NOT NULL DEFAULT '鎖信息', PRIMARY KEY (`id`), UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='鎖定中的方法';

然后，我們就可以通過插入數(shù)據(jù)和刪除數(shù)據(jù)的方式來實(shí)現(xiàn)加鎖和解鎖：

#加鎖insert into myLock(method_name, value) values ('m1', '1'); #解鎖delete from myLock where method_name ='m1';

基于數(shù)據(jù)庫實(shí)現(xiàn)的方式雖然簡單，但是存在一些明顯的問題：

• 沒有鎖失效時間，如果解鎖失敗，就會導(dǎo)致鎖記錄永遠(yuǎn)留在數(shù)據(jù)庫中，造成死鎖。

• 該鎖不可重入，因?yàn)樗徽J(rèn)識請求方是不是當(dāng)前占用鎖的線程。

• 當(dāng)前數(shù)據(jù)庫是單點(diǎn)，一旦宕機(jī)，鎖機(jī)制就會完全崩壞。

4.2.2 基于Zookeeper的實(shí)現(xiàn)方式

ZooKeeper是一個為分布式應(yīng)用提供一致性服務(wù)的開源組件，它內(nèi)部是一個分層的文件系統(tǒng)目錄樹結(jié)構(gòu)，規(guī)定同一個目錄下的節(jié)點(diǎn)名稱都是唯一的。

ZooKeeper的節(jié)點(diǎn)（Znode）有4種類型：

• 持久化節(jié)點(diǎn)（會話斷開后節(jié)點(diǎn)還存在）

• 持久化順序節(jié)點(diǎn)

• 臨時節(jié)點(diǎn)（會話斷開后節(jié)點(diǎn)就刪除了）

• 臨時順序節(jié)點(diǎn)

當(dāng)一個新的Znode被創(chuàng)建為一個順序節(jié)點(diǎn)時，ZooKeeper通過將10位的序列號附加到原始名稱來設(shè)置Znode的路徑。例如，如果將具有路徑/mynode的Znode創(chuàng)建為順序節(jié)點(diǎn)，則ZooKeeper會將路徑更改為/mynode0000000001，并將下一個序列號設(shè)置為0000000002，這個序列號由父節(jié)點(diǎn)維護(hù)。如果兩個順序節(jié)點(diǎn)是同時創(chuàng)建的，那么ZooKeeper不會對每個Znode使用相同的數(shù)字。

基于ZooKeeper的特性，可以按照如下方式來實(shí)現(xiàn)分布式鎖：

• 創(chuàng)建一個目錄mylock；

• 線程A想獲取鎖就在mylock目錄下創(chuàng)建臨時順序節(jié)點(diǎn)；

• 獲取mylock目錄下所有的子節(jié)點(diǎn)，然后獲取比自己小的兄弟節(jié)點(diǎn)，如果不存在，則說明當(dāng)前線程順序號最小，獲得鎖；

• 線程B獲取所有節(jié)點(diǎn)，判斷自己不是最小節(jié)點(diǎn)，設(shè)置監(jiān)聽比自己次小的節(jié)點(diǎn)；

• 線程A處理完，刪除自己的節(jié)點(diǎn)，線程B監(jiān)聽到變更事件，判斷自己是不是最小的節(jié)點(diǎn)，如果是則獲得鎖。

由于創(chuàng)建的是臨時節(jié)點(diǎn)，當(dāng)持有鎖的線程意外宕機(jī)時，鎖依然可以得到釋放，因此可以避免死鎖的問題。另外，我們也可以通過節(jié)點(diǎn)排隊監(jiān)聽機(jī)制實(shí)現(xiàn)阻塞特性，也可以通過在Znode中攜帶線程標(biāo)識來實(shí)現(xiàn)可重入鎖。同時，由于ZooKeeper集群的高可用特性，分布式鎖的可用性也能夠得到保障。不過，因?yàn)樾枰l繁的創(chuàng)建和刪除節(jié)點(diǎn)，Zookeeper方式在性能上不如Redis方式。

4.2.3 基于Redis的實(shí)現(xiàn)方式

Redis是一個開源的鍵值對(Key-Value)存儲數(shù)據(jù)庫，其基于內(nèi)存實(shí)現(xiàn)，性能非常高，常常被用作緩存。

基于Redis實(shí)現(xiàn)分布式鎖的核心原理是：嘗試對特定key進(jìn)行set操作，如果設(shè)置成功（key之前不存在）了，則相當(dāng)于獲取到鎖，同時對該key設(shè)置一個過期時間，避免線程在釋放鎖之前退出造成死鎖。線程執(zhí)行完同步任務(wù)后主動釋放鎖則通過delete命令來完成。

這里需要特別注意的一點(diǎn)是如何加鎖并設(shè)置過期時間。有的人會使用setnx expire這兩個命令來實(shí)現(xiàn)，但這是有問題的。假設(shè)當(dāng)前線程執(zhí)行setnx獲得了鎖，但是在執(zhí)行expire之前宕機(jī)了，就會造成鎖無法被釋放。當(dāng)然，我們可以將兩個命令合并在一段lua腳本里，實(shí)現(xiàn)兩條命令的原子提交。

其實(shí)，我們簡單利用set命令可以直接在一條命令中實(shí)現(xiàn)setnx和設(shè)置過期時間，從而完成加鎖操作：

SET key value [EX seconds] [PX milliseconds] NX

解鎖操作只需要：

DEL key

五、基于Redis分布式鎖的解決方案

在本案例中，我們采用了基于Redis實(shí)現(xiàn)分布式鎖的方式。

5.1 分布式鎖的Java實(shí)現(xiàn)

由于項(xiàng)目采用了Jedis框架，而且線上Redis部署為集群模式，因此我們基于redis.clients.jedis.JedisCluster封裝了一個RedisLock類，提供加鎖與解鎖接口。

public?class?RedisLock?{ private static final String LOCK_SUCCESS = "OK"; private static final String LOCK_VALUE = "lock"; private static final int EXPIRE_SECONDS = 3; @Autowired protected JedisCluster jedisCluster; public boolean lock(String openId) { String redisKey = this.formatRedisKey(openId); String ok = jedisCluster.set(redisKey, LOCK_VALUE, "NX", "EX", EXPIRE_SECONDS); return LOCK_SUCCESS.equals(ok); } public void unlock(String openId) { String redisKey = this.formatRedisKey(openId); jedisCluster.del(redisKey); } private String formatRedisKey(String openId){ return "keyPrefix:" openId; }}

在具體實(shí)現(xiàn)上，我們設(shè)置了3秒鐘的過期時間，因?yàn)楸患渔i的任務(wù)是簡單的數(shù)據(jù)庫查詢和插入，而且服務(wù)器與數(shù)據(jù)庫部署在同個機(jī)房，正常情況下3秒鐘已經(jīng)完全能夠足夠滿足代碼的執(zhí)行。

事實(shí)上，以上的實(shí)現(xiàn)是一個簡陋版本的Redis分布式鎖，我們在實(shí)現(xiàn)中并沒有考慮線程的可重入性，也沒有考慮鎖被其他進(jìn)程誤釋放的問題，但是它在這個業(yè)務(wù)場景下已經(jīng)能夠滿足我們的需求了。假設(shè)推廣到更為通用的業(yè)務(wù)場景，我們可以考慮在value中加入當(dāng)前進(jìn)程的特定標(biāo)識，并在上鎖和釋放鎖的階段做相對應(yīng)的匹配檢測，就可以得到一個更為安全可靠的Redis分布式鎖的實(shí)現(xiàn)了。

當(dāng)然，像Redission之類的框架也提供了相當(dāng)完備的Redis分布式鎖的封裝實(shí)現(xiàn)，在一些要求相對嚴(yán)苛的業(yè)務(wù)場景下，我建議直接使用這類框架。由于本文側(cè)重于介紹排查及解決問題的思路，因此沒有對Redisson分布式的具體實(shí)現(xiàn)原理做更多介紹，感興趣的小伙伴可以在網(wǎng)上找到非常豐富的資料。

5.2 改進(jìn)后的代碼邏輯

現(xiàn)在，我們可以利用封裝好的RedisLock來改進(jìn)原來的代碼了。

public?class?AccountService?{ @Autowired private RedisLock redisLock; public void submit(String openId, String localIdentifier) { if (!redisLock.lock(openId)) { // 如果相同openId并發(fā)情況下，線程沒有搶到鎖，則直接丟棄請求 return; } // 獲取到鎖，開始執(zhí)行用戶數(shù)據(jù)同步邏輯 try { Account account = accountDao.find(openId); if (account == null) { // insert } else { // update } } finally { // 釋放鎖 redisLock.unlock(openId); } }}

5.3 數(shù)據(jù)清理

最后再簡單說一下收尾工作。由于重復(fù)數(shù)據(jù)的數(shù)據(jù)量較大，不太可能手工去慢慢處理。于是我們編寫了一個定時任務(wù)類，每隔一分鐘執(zhí)行一次清理操作，每次清理1000個重復(fù)的OpenID，避免短時間內(nèi)大量查詢和刪除操作對數(shù)據(jù)庫性能造成影響。當(dāng)確認(rèn)重復(fù)數(shù)據(jù)已經(jīng)完全清理完畢后就停掉定時任務(wù)的調(diào)度，并在下一次版本迭代中將此代碼移除。

六、總結(jié)

在日常開發(fā)過程中難免會各種各樣的問題，我們要學(xué)會順藤摸瓜逐步分析，找到問題的根因；然后在自己的認(rèn)知范圍內(nèi)盡量去尋找可行的解決方案，并且仔細(xì)權(quán)衡各種方案的利弊，才能最終高效地解決問題。