平安某金所奇葩的面經－關於冪等和ROA設計的反思

      在公司一直在作跟支付有關的項目，某日接到平安某金所一男子電話，應該是以前某獵頭投的，我正好在吃早飯（也不能怪他們上班早，咱們公司彈性工做制，我通常上班比較晚）。 

      由於飯館信號很差，只能趕忙放下剩下的半碗餛飩（肉痛啊），走了一千米（那片移動信號真是渣）。 

      終於能夠正常交流了。對方讓我先挑一個項目說說，我一聽這套路，牛啊！跟以前的阿里同樣（之後找機會再聊聊那次面經），確定是隨機在我項目中找點來問了，那我就開始說，說到有個補釦款的場景，一開始設計每次客戶端發差額過來，很難保證冪等性，後來設計讓客戶端發總額過來，冪等問題解決了。這裏我重申下冪等定義啊，想必你們都知道了，就是對於一個操做，屢次執行，反作用是同樣的，而不是疊加的。好比我扣款，若是我沒法分清客戶端過來的差額是補釦仍是重試，那麼極可能多扣客人錢。 

      那麼問題來了，總額模式爲何能解決問題？某金所面試官逮到機會發問，並且我注意到他的發問彷彿是循循善誘，告訴我，年輕人，你是否是不懂冪等啊，跟我這裏亂講，我知道的解決冪等的方案是不同的喔！我當時沒反應過來，以爲大牛應該不用我解釋冪等吧，應該是在考校我，那麼我就描述了一下場景，若是保險費原來是10元，客戶端增長了10元，加一加，20元給我，那麼即便這個20元給了屢次，保險費仍是20元不會變，是否是這個理？ 

      而後奇葩的事情發生了，面試官開啓教育模式，後面就一直是他在說，說我這個只是業務上的變更而已，並無真正的解決冪等啊（我心想這怎麼沒解決冪等呢，從定義上來講解決了啊），而後又說，差額也能解決冪等問題啊，我就能夠解決！我趕忙說，我也能夠，就是用惟一的UUID策略，重發的話使用上次一樣的UUID，那麼我這邊服務就不作處理落。他說，你知道爲何不說呢，這個纔是技術上的正解啊，你跟我說業務上的東西幹嗎啊，你說的根本解決不了問題，仍是要用這方案才行。我說，這個是基礎的東西，相似接口實現都會那麼作啊，可是因爲是老的協議，這個臨時方案改動最小，也最經濟。而後面試官沉默了一下子，問我，你說說你在Java方面的心得吧，我說了一點，可是明顯感受他在敷衍了。後來就沒有後來了。 

      說真的，此次面經真是讓我深受打擊，面試官究竟是大牛呢，仍是隻知道背書的奇葩呢？可是，正是由於人家是平安某金所的總監（也許吧），我只是渣渣程序員一枚，這種地位差距致使了我對本身知識和經驗的懷疑。 

      可是最近看到了大神Jim Webber的大做REST in Practice，我從新找回了自信心，其中介紹到HTTP的PUT方法是冪等的，爲何呢，解釋是這樣的（我直接打中文了），「因爲PUT請求是冪等的（由於服務端狀態被客戶端狀態整個地替代了），消費者能夠安全地按照本身的須要屢次重複該操做......」。 

      這裏大神提到的實際上是一種面向資源的設計理念（ROA），PUT方法實現對資源的更新，就像保險費，若是你把它當作是資源，那麼每次就應該直接用新值替換（總額替代總額），而若是你把修改保險費自己當作一種操做，每次須要扣多少錢（總額減差額），那麼就會破壞冪等，而咱們如今大多WebService的設計都是基於操做的思惟，爲了實現冪等又引入一套複雜的機制，人爲添加了複雜性。