由于短網址業務量的逐漸增大，原有的服務器系統負載已經接近極限。為了更好的滿足用戶的需求，FT12短網址有新增了兩臺服務器，和原有的一臺服務器組成負載均衡系統。前段任何一條短網址的訪問，都會先經過負載均衡服務器，然后再隨機轉發給后臺的任意一臺服務器處理。這樣就能有效的提升短網址的穩定性和快速訪問。但經過一段時間的使用，發現了有些致命的缺陷。

用戶A生成一條短網址，這個請求被隨機轉發到后臺的任意一臺服務器。然后這臺服務器再鏈接數據庫，獲取短鏈接代碼，最后進行插入操作。這個邏輯看似沒有什么漏洞，但是每次在網站訪問高峰期，就會發生一個邏輯上的bug。那就是用戶B也在這個時候生成一條短網址，這個請求被轉發到了另一臺后端服務器B，那么這個時候服務器B也會連接數據，獲取短網址代碼，然后再插入數據庫。那么，問題來了。這個時候，用戶A和用戶B很有可能再鏈接數據庫時，獲取了相同的短網址代碼，而短網址代碼（CODE）在數據庫中是唯一的，其中必然會有一個用戶的數據庫插入操作會以失敗告終。這大大影響了用戶的正常使用體驗。為了解決這個問題，我們闡釋了很多種方法。

上圖是我們最終的解決方案。對服務器的數據庫操作使用了try函數，如果插入數據庫不成功，則重新獲取短網址代碼，然后再次進行插入。這樣的邏輯設計很好的解決了負載均衡下，短網址的生成成功率極大的提升了。