无法挽回的大错

        这是我职业生涯以来所犯下的最大错误，我为了这个错误悔恨自责。这个错误给客户公司造成了巨额的经济损失。虽然客户已不再追究，但是我内心非常不好受。想想昨天还在自夸自己同步设计的不错，今天就直接被同步狠狠地打了一巴掌。

        事情的起因是这样的，客户公司要求给平台做一次活动，活动的内容是在315这个节日给客户回馈些东西。然后就叫我开发一个抢礼品的小模块，一共有3150份礼品供用户抢，先到先得。我起初的构思是使用数据库同步，也就是select语句后面加上for update给表加锁，但是这个项目没有使用任何框架，我感觉这样写数据库锁很麻烦就转而想要不用java的同步锁就可以了。在这个思想的影响下我写了一个同步的方法，用户进来抢礼品之后判断是否有线程持有锁，有则等待，没有就立刻获得锁。这个方法里面封装的是查询剩余的礼品数量，如果大于0则给礼品数减一返回给客户他抢到了礼品。开发完成之后提给测试在测试环境上也测的没有问题。我当然就高枕无忧的等着今天的到来。今天中午过去加班的时候客户跟我说，系统有十台服务器。我当时只是感觉到一点不太对劲但是没有仔细多想。等到后来用户开抢的时候，灾难发生了。

        我在监控生产数据库剩余礼品的时候发现剩余礼品改变的不规则，本来是按照减一减一的顺序递减的，但是我看见礼品数一会多一会少，完全就是一个不规则的情况。我突然想到有十台服务器，顿时有如被雷劈中，不同的服务器那样的加锁方法根本就控制不了同步，当时我的第一个想法就是关掉所有的服务器，我强行把生产的剩余礼品改成0再重启服务。可是客户不同意这种做法。没办法，我只能自己手动的去改，但是这个时候有很多客户持有数据库的锁，我改完立马又被客户改回去，这时候我想起来用户表有一个状态字段，于是我又强行把客户在抢礼品这个状态字段里的状态全部改成没抢到的状态。最后才遏制住了客户抢礼品。但是，事后我立马统计已经被抢出去的礼品。比预计的多了将近3000份，要知道一共客户就提供了3000多份的礼品，我一下就把这个基数翻了一倍。我粗略的估计了一下每份礼品大约要50元左右，一算15W。就这么活生生坑了客户15W。虽然客户最后给我的解决方案是说，报告里不要提是我们没有控制住，是因为抢的人太多而导致的。可是我还是走不出这个圈，我是做客户现场的，在自己引以为豪的行业出现这样致命的错误。本来已经有换部门的打算，这下更加是不得不走。我都想要引咎辞职。下周一我要怎么去面对我的客户？