經大佬介紹，接了個技術顧問的私活兒，3天搞定報酬8000，Mark一下，也分享下經驗心得。（經大家要求，文末增加了一段接私活兒經驗）

背景交代

甲方是廣東某國企信息部，美其名曰是邀請技術顧問，其實就是優化下他們開發的一個內部拍賣網站。該網站是面向內部員工，限時競拍舊的辦公筆記本，用戶量不大，但有秒殺的性質存在，國企信息部的技術水平，你懂的。過程很簡單，3天就完事兒，之前據說是打報告要花幾百萬買設備升級，優化了幾個問題后，原配置搞定！(真不是我厲害，全靠同行襯托)，下面記錄2個核心問題和解決辦法，拋磚引玉歡迎拍磚。

競拍報價失敗問題

第一個最核心的問題，就是競拍報價總是失敗。內部競拍設置起拍價格非常低，用了一年的ThinkPad才1000元(福利真好)，所以一上架就很多人開始發起競拍，短時間內會有多項數據寫入，然后問題來了：

之前的設計，每次競拍需要先比對價格(更高才能寫入)，然后再增加報價記錄和更新當前價格，整個過程用事務包裹起來，基于SQLServer單機數據庫根本扛不住并發，各種的timeout。

重新設計，直接引入了Redis的ZSet有序集合，將商品id作為key，用戶報價信息作為value，將價格信息當成score，輕松保存并發報價，而且隨時獲取當下最高報價，應對不足1000的并發不要太輕松。

數據入庫？我設置的是每5分鐘/ZSet數據新增過100，就將數據寫入一次數據庫，一方面避免了數據庫的頻繁更新，二來最高報價也不需要競爭加鎖了，于是還是單機的SQLServer服務器，應付起來毫無壓力！

競拍結束無數請求

再一個核心問題是部分熱門拍品在競拍結束時，經常出現數據庫壓力過大，有時候還會down機。原因是壓軸報價人多，而此時該拍品已經下架了，用戶還會不斷刷新，然后問題來了：

之前的設計，正在競拍的商品信息是放在本地緩存的，有效期到競拍結束為止，競拍期間都表現的很好，唯一的問題是競拍結束時，用戶還在大量刷新請求該商品信息，然后這一批無效請求都進入數據庫了，嚴重的時候會導致數據庫down機。

重新設計，在數據過期時，不是把key-value移除，而是保存了一個key-null的緩存項，用戶用這個key來請求時，直接拿到null，提示用戶商品不存在或者已下架，這樣下來請求都不會影響到數據庫了。其實這是一個典型的緩存穿透問題。

一點心得體會：

多會點東西還是很重要的，就這點Redis的基本應用，就輕松掙了8000塊。在日常的互聯網項目開發中，對Redis要求高多了，單線程模型、epoll多路復用、底層數據結構、跳躍表算法應用、各種數據淘汰策略、集群、高可用等等，都是必備的。給大家推薦一個硬核訓練營，3天時間突破Redis實戰和原理，由十多年經驗的硬核架構師Clay主講的，我就是從這里學習的。

關于私活

很多小伙伴兒也想業余接點私活兒，我是走過彎路的，什么豬八戒網都是坑。今年我已經接了2個私活兒，都是找我的在線教育老師，某微軟MVP大佬接的。老師那邊的VIP學員上萬，經常會有各種私活兒，下圖是老師發給我的，又可以小創收一筆了。

關注的小伙伴兒，可以掃描二維碼，來聽聽老師的課程，混個臉熟！然后一起來協作一些大的私活兒，歡迎一起組隊！

掃碼大家一起組隊

人數較多，添加以下號碼也可哦！

微信號：zhaoxihhhhh

最

新

面

試

題

庫

總結

以上是生活随笔為你收集整理的2招解决并发问题，省几百万设备费用！说穿了很简单...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。