1.背景描述

應用框架:Spring + SpringMVC + Hibernate 
資料庫：Oracle11g

一家文學網站向我係統推多執行緒低併發推送資料，我這邊觀察日誌和資料庫，發現有一個作者被儲存了2次到資料庫中。按照程式的編寫邏輯，重複的資料是會被判斷出來不被儲存的。

2.原因分析

由於網路原因，客戶可能連續推送了兩條重複的資料，兩條資料時間間隔非常小，因此導致了我們的

if(使用者不存在)
{
    xxxxx
    儲存使用者到資料庫
}
else
{
    重複推送，不採取任何措施
}

這個操作還沒有執行完畢，第二條擁有相同資料的執行緒已經進入並通過了if的檢驗，導致資料庫儲存了兩條相同的資料。後來我自己寫了個100併發的多執行緒測試程式，發現100條相同資料中有40條被插入到了資料庫裡！天啦嚕！！！因此確定了是多執行緒的併發導致了程式的判斷邏輯失效。
 

3.解決思路：

    1) 在Author主表中對 身份證號 添加了唯一索引，現在Author主表不會出現重複資料了，如果連續推送客戶會收到一條推送失敗的提示資訊。

    2) 但是AuthorOrg表(Author與AuthorOrg是一對多關係)依然會出現重複資料，想過新增siteId + userUniqueId的 聯合唯一索引來解決，但是想到work表也會出現同樣的問題，新增過多索引會導致DB佔用空間無限增大，因此不採用。

    3) 考慮使用synchronized對方法新增同步鎖，但是這樣會導致其他正常資料的推送執行緒也被阻塞，影響效率。因此不採用。

    4) 使用對資料庫新增行鎖，實驗發現還是會出現2條重複資料
        分析：
            理論上的結果應該是1條成功，149條失敗。
            對資料庫的select語句新增行鎖必須作用於某條記錄，但是第一次報送時，資料庫中並沒有這條資料，因此行鎖根本沒有加上，導致第二條資料成功非同步使用select語句。
            第一次報送成功以後，資料庫中有了這條資料，select語句成功的對這條記錄添加了行鎖，所以後邊不會出現重複資料。因此此法不可用。
 

    5) 即想提高效率不對方法新增synchronized，又想保證資料準確性，最後使用synchronized(siteId + uid) 在Controller層加鎖(保證了只有重複資料被加鎖,在Controller使用的原因是因為事務會在Service呼叫完畢才被提交，我實驗過在Service同步，150併發會出現2條重複資料，因為事務還沒來得及提交)
    測試結果：測試了3次150併發  不到一秒的時間全部返回，結果1條登記成功，149條返回該作者已登記。

下一步：
    針對所有可能出現高併發問的介面進行調整。

4.提示

    這種加同步鎖的方法在負載均衡下的多臺應用伺服器會失效
 
！因為就算Spring保證了物件是單例的，但是多臺伺服器肯定是多個物件！因此synchronized將無效。解決方法是在資料庫層對該對接公司的唯一記錄加select鎖，這樣就能保證資料的不重複性，但是會降低該公司推送資料的效率(相當於逐條推送)，但是公司與公司之間還是並行推送的。還有一個方法就是將業務邏輯寫入儲存過程，然後對儲存過程加鎖，這種方法太麻煩了，需求有變動就必須去修改儲存過程，但是效率要比前者高得多。