平安某金所奇葩的面经－关于幂等和ROA设计的反思

      在公司一直在作跟支付有关的项目，某日接到平安某金所一男子电话，应该是以前某猎头投的，我正好在吃早饭（也不能怪他们上班早，咱们公司弹性工做制，我通常上班比较晚）。 

      由于饭馆信号很差，只能赶忙放下剩下的半碗馄饨（肉痛啊），走了一千米（那片移动信号真是渣）。 

      终于能够正常交流了。对方让我先挑一个项目说说，我一听这套路，牛啊！跟以前的阿里同样（之后找机会再聊聊那次面经），确定是随机在我项目中找点来问了，那我就开始说，说到有个补扣款的场景，一开始设计每次客户端发差额过来，很难保证幂等性，后来设计让客户端发总额过来，幂等问题解决了。这里我重申下幂等定义啊，想必你们都知道了，就是对于一个操做，屡次执行，反作用是同样的，而不是叠加的。好比我扣款，若是我没法分清客户端过来的差额是补扣仍是重试，那么极可能多扣客人钱。 

      那么问题来了，总额模式为何能解决问题？某金所面试官逮到机会发问，并且我注意到他的发问仿佛是循循善诱，告诉我，年轻人，你是否是不懂幂等啊，跟我这里乱讲，我知道的解决幂等的方案是不同的喔！我当时没反应过来，以为大牛应该不用我解释幂等吧，应该是在考校我，那么我就描述了一下场景，若是保险费原来是10元，客户端增长了10元，加一加，20元给我，那么即便这个20元给了屡次，保险费仍是20元不会变，是否是这个理？ 

      而后奇葩的事情发生了，面试官开启教育模式，后面就一直是他在说，说我这个只是业务上的变更而已，并无真正的解决幂等啊（我心想这怎么没解决幂等呢，从定义上来讲解决了啊），而后又说，差额也能解决幂等问题啊，我就能够解决！我赶忙说，我也能够，就是用惟一的UUID策略，重发的话使用上次一样的UUID，那么我这边服务就不作处理落。他说，你知道为何不说呢，这个才是技术上的正解啊，你跟我说业务上的东西干吗啊，你说的根本解决不了问题，仍是要用这方案才行。我说，这个是基础的东西，相似接口实现都会那么作啊，可是因为是老的协议，这个临时方案改动最小，也最经济。而后面试官沉默了一下子，问我，你说说你在Java方面的心得吧，我说了一点，可是明显感受他在敷衍了。后来就没有后来了。 

      说真的，此次面经真是让我深受打击，面试官究竟是大牛呢，仍是只知道背书的奇葩呢？可是，正是由于人家是平安某金所的总监（也许吧），我只是渣渣程序员一枚，这种地位差距致使了我对本身知识和经验的怀疑。 

      可是最近看到了大神Jim Webber的大做REST in Practice，我从新找回了自信心，其中介绍到HTTP的PUT方法是幂等的，为何呢，解释是这样的（我直接打中文了），“因为PUT请求是幂等的（由于服务端状态被客户端状态整个地替代了），消费者能够安全地按照本身的须要屡次重复该操做......”。 

      这里大神提到的实际上是一种面向资源的设计理念（ROA），PUT方法实现对资源的更新，就像保险费，若是你把它当作是资源，那么每次就应该直接用新值替换（总额替代总额），而若是你把修改保险费自己当作一种操做，每次须要扣多少钱（总额减差额），那么就会破坏幂等，而咱们如今大多WebService的设计都是基于操做的思惟，为了实现幂等又引入一套复杂的机制，人为添加了复杂性。