摘要:這是一個關于的故事前奏記錄移動設備在移動開發中應該是很常見的操作,一般的流程是移動設備在應用商店中下載后打開,這時客戶端程序會將獲取設備信息并提交到服務器端接口入庫。
這是一個關于mysql的故事
前奏:
記錄移動設備id在移動開發中應該是很常見的操作,一般的流程是:移動設備在應用商店中下載app后打開,這時客戶端程序會將獲取設備信息并提交到服務器端接口入庫。但是由于XX原因我們需要在這之前再加一個同樣的請求,也就是在這之前有可能已經寫入數據庫了,但是還要再走一遍相同的邏輯。
癥狀:
當我寫好程序交由客戶端同學去測試的時候,不可思議的事情發生了:有大概20%的概率會報錯“Duplicate entry XXX”(此處省去30字),然后客戶端同學還反映說如果兩個請求間隔1秒鐘就沒問題。
分析
我看完代碼后發現邏輯是這樣的:model文件里首先判斷設備id是否存在,不存在則寫入。結合之前的反饋我斷定:第一次寫入成功且第二次判斷時為空的時候,再寫入的時候數據庫里已經有數據了。運維同學說服務器mysql是讀寫分離的,也就是說出現這種問題的原因是:第一次訪問服務器時如果設備id不存在(slave)則寫入master,這時master開始向slave同步,第二次訪問服務器時如果之前的同步完成了則不會二次寫入,如果同步沒有完成則會第二次寫入master,這時就報錯了。
解決
1.既然客戶端同學說延遲1秒就ok了淡然可以這樣干,但是這個時間其實和同步時間相關的,不一定是這個數字,有一定的風險,所以不建議采納,但是救急是可以的。
2.我的方案是:第一次寫入的時候將當前的設備id保存在memcache中,第二次訪問的時候直接判定memcache中是否存在,保存時間的話,設置個10秒鐘基本就夠了。
結語:
其實這種連續寫入同一數據到同一表中的需求不是很多,但是業務需求千奇百怪,熟悉業務的同時也要熟悉生產環境,這樣才能快速定位問題,解決問題。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/30250.html
摘要:只有當超時故障扇區等明確故障項出現后,兩者關聯才確診硬盤故障,否則只是隔離觀察,不報修。如果存在進程住時間超過分鐘,我們認為這個硬盤故障的影響面已擴大到了整機,需要進行重啟消除影響。 隨著阿里大數據產品業務的增長,服務器數量不斷增多,IT運維壓力也成比例增大。各種軟、硬件故障而造成的業務中斷,成為穩定性影響的重要因素之一。本文詳細解讀阿里如何實現硬件故障預測、服務器自動下線、服務自愈以...
摘要:虛擬網卡與虛擬機的生命周期一致,無法進行分離,虛擬機被銷毀時,虛擬網卡即被銷毀。每塊虛擬網卡支持綁定一個安全組,提供網卡級別安全控制。平臺默認提供塊虛擬網卡,若業務有塊以上網卡需求可通過綁定彈性網卡,為虛擬機提供多網絡服務。虛擬機是 UCloudStack 云平臺的核心服務,提供可隨時擴展的計算能力服務,包括 CPU 、內存、操作系統等最基礎的計算組件,并與網絡、磁盤等服務結合提供完整的計算...
摘要:事實上,這種快捷的發布周期需要配合一系列流程工具甚至是管理文化,從而共同支撐起一套安全且可靠的云原生應用程序運作機制。云原生框架云原生應用程序的一大關鍵性特質在于,其需要遵循一套設計契約以較大程度實現行為的可預測性。 擺脫臨時性自動化方案之定位,發揮優勢以實現可預測功能。您能否以每周為單位向客戶發布各類新功能?甚至進一步達到以每天乃至每小時為單位?新晉開發人員能否在上班的第一天即進行代碼部署...
摘要:云原生路徑谷歌花了十幾年時間開發應用和提煉云原生計算的原則。和云原生模式將通過滾動更新版本控制和新組件新功能的金絲雀部署來提高生命周期管理。此外,用戶將受益于可自我恢復的基礎設施,使更易于管理,對核心服務和單個計算節點的故障恢復更具有彈性。 Mirantis是OpenStack的主要貢獻者,今天他宣布將使用Kubernetes作為底層編排引擎重寫其私有云平臺。我們認為這是推進OpenS...
閱讀 2337·2021-11-16 11:52
閱讀 2323·2021-11-11 16:55
閱讀 750·2021-09-02 15:41
閱讀 2981·2019-08-30 15:54
閱讀 3142·2019-08-30 15:54
閱讀 2252·2019-08-29 15:39
閱讀 1508·2019-08-29 15:18
閱讀 968·2019-08-29 13:00