乙個關於客戶端和服務端時間同步問題引出的小猜想。特記錄如下：
由於每天都在使用摩拜，每次預約之後不得不想那個倒計時。摩拜猿們是如何同步客戶端和伺服器端的時間的。
基於每次的體驗，我猜想應該沒有做任何同步處理。因為，每次我預約單車的時候，總想不足1min的時候，取消預約再次預約。然而真實情況是，當我取消預約再次預約的時候，竟然提示已被別人預約。心中一萬隻cnm從腦海中飄過。。。
現在我們梳理一下整個流程。
當使用者點選預約的時候，預約的請求傳送到服務端，此刻服務端不免也在處理著數以萬計其他使用者的請求，處理到你這個請求也許已經過去數秒。等服務端處理完請求，響應資料返回給客戶端。如果再把網路延遲等因素算上，這一來一回時間誤差也不會太小。
所以不論是點選預約的時候就開啟倒計時（樂觀模式，期望每次都能預約上，好像不太現實，使用者體驗極差，倒計時了以為預約成功了，誰成想伺服器返回的資料告訴客戶端不好意思已經被其他人搶先了，把倒計時取消了。這種模式我個人還是挺喜歡的，誰也不知道結果是什麼。），還是等伺服器返回資料的時候再進行倒計時（悲觀模式，總是要等伺服器返回資料在進行下一步操作），都會存在一定的倒計時誤差。
對於樂觀模式和悲觀模式大部分應用都是採取折中的辦法，使用者點選之後，立馬響應，出現乙個轉的圈圈。等服務端響應結果再給相應的頁面展示
但是有一點是值得肯定得，為了使用者體驗好，不能出現客戶端倒計時到了，服務端的時間還沒結束。導致使用者再次預約的時候提示已被預約了（其實還是那個使用者預約的，只是服務端時間沒到而已）。這種情況也有可能會出現，誰知道呢。
所以我猜想服務端倒計時絕對不可能和客戶端一樣，一般都會少一點。可能有的人就會想了，竟然服務端時間有可能比客戶端時間先到了，那不是別人就可以預約了。實際真會發生這樣的事情。今天早上還和討論這個事情。他預約的時間不足1min了，我讓他重新預約一下，他說沒事，那個秒數足夠走到車那，尷尬的事情出現了，車子並沒有亮藍燈（這裡有人可能會說是不是燈壞了，好吧，這個我服。）。也就是說服務端的時間已經到了，客戶端還沒到。如果這個時間段正好有人預約，就是真的打臉了。其實這種體驗也是不太好，明明客戶端還有時間，你就可以讓別人預約了。
再次宣告以上僅是個人猜想。關於這個客戶端和服務端時間同步問題，還有待解決。。。
摩拜單車開鎖原理
摩拜的開鎖原理，需要通過整體架構來梳理，分為幾個部分 業務層 使用者掃碼，讀取乙個匹配裝置序列號，使用者資料在後台訂單系統做一次裝置使用授權校驗 比如押金餘額 沒有問題的話，下一步 裝置層 通知伺服器下發乙個開鎖訊號到車鎖控制系統。簡單的說就是業務層解決完了，處理開關問題。在以上最難的部分在於處理通...
筆試刷題 摩拜
題目描述 小摩手裡有乙個字串a，小拜的手裡有乙個字串b，b的長度大於等於a，所以小摩想把a串變得和b串一樣長，這樣小拜就願意和小摩一起玩了。而且a的長度增加到和b串一樣長的時候，對應的每一位相等的越多，小拜就越喜歡。比如 abc 和 abd 對應相等的位數為2，為前兩位。小摩可以在a的開頭或者結尾新...
摩拜單車 說走就走的旅程
聽 azure 背後的故事 不知從何時起，我們每天生活的城市裡，開始被霧霾籠罩，沒有一點點防備，就會開始漫長的限行時光。漸漸地，我們開始懷念單車出行的日子，那時候的天很藍，空氣良好，日子也簡單而自由。有這樣乙個女孩兒，她說 我希望我像乙個機器貓一樣，當我想要一輛自行車的時候，我就能從口袋裡掏出一輛自...