短網址程序在多服務器組負載均衡系統中遇到的問題
由于短網址業務量的逐漸增大,原有的服務器系統負載已經接近極限。為了更好的滿足用戶的需求,FT12短網址有新增了兩臺服務器,和原有的一臺服務器組成負載均衡系統。前段任何一條短網址的訪問,都會先經過負載均衡服務器,然后再隨機轉發給后臺的任意一臺服務器處理。這樣就能有效的提升短網址的穩定性和快速訪問。但經過一段時間的使用,發現了有些致命的缺陷。
用戶A生成一條短網址,這個請求被隨機轉發到后臺的任意一臺服務器。然后這臺服務器再鏈接數據庫,獲取短鏈接代碼,最后進行插入操作。這個邏輯看似沒有什么漏洞,但是每次在網站訪問高峰期,就會發生一個邏輯上的bug。那就是用戶B也在這個時候生成一條短網址,這個請求被轉發到了另一臺后端服務器B,那么這個時候服務器B也會連接數據,獲取短網址代碼,然后再插入數據庫。那么,問題來了。這個時候,用戶A和用戶B很有可能再鏈接數據庫時,獲取了相同的短網址代碼,而短網址代碼(CODE)在數據庫中是唯一的,其中必然會有一個用戶的數據庫插入操作會以失敗告終。這大大影響了用戶的正常使用體驗。為了解決這個問題,我們闡釋了很多種方法。
上圖是我們最終的解決方案。對服務器的數據庫操作使用了try函數,如果插入數據庫不成功,則重新獲取短網址代碼,然后再次進行插入。這樣的邏輯設計很好的解決了負載均衡下,短網址的生成成功率極大的提升了。
掃描二維碼推送至手機訪問。
版權聲明:本文由短鏈接發布,如需轉載請注明出處。
本文鏈接:http://www.virginiabusinesslawupdate.com/article_544.html