3天挣了8000块，私活儿真香！-技术圈

经大佬介绍，接了个技术顾问的私活儿，3天搞定报酬8000，Mark一下，也分享下经验心得。（经大家要求，文末增加了一段接私活儿经验）

背景交代

甲方是广东某国企信息部，美其名曰是邀请技术顾问，其实就是优化下他们开发的一个内部拍卖网站。该网站是面向内部员工，限时竞拍旧的办公笔记本，用户量不大，但有秒杀的性质存在，国企信息部的技术水平，你懂的。过程很简单，3天就完事儿，之前据说是打报告要花几百万买设备升级，优化了几个问题后，原配置搞定！(真不是我厉害，全靠同行衬托)，下面记录2个核心问题和解决办法，抛砖引玉欢迎拍砖。

竞拍报价失败问题

第一个最核心的问题，就是竞拍报价总是失败。内部竞拍设置起拍价格非常低，用了一年的ThinkPad才1000元(福利真好)，所以一上架就很多人开始发起竞拍，短时间内会有多项数据写入，然后问题来了：

之前的设计，每次竞拍需要先比对价格(更高才能写入)，然后再增加报价记录和更新当前价格，整个过程用事务包裹起来，基于SQLServer单机数据库根本扛不住并发，各种的timeout。

重新设计，直接引入了Redis的ZSet有序集合，将商品id作为key，用户报价信息作为value，将价格信息当成score，轻松保存并发报价，而且随时获取当下最高报价，应对不足1000的并发不要太轻松。

数据入库？我设置的是每5分钟/ZSet数据新增过100，就将数据写入一次数据库，一方面避免了数据库的频繁更新，二来最高报价也不需要竞争加锁了，于是还是单机的SQLServer服务器，应付起来毫无压力！

竞拍结束无数请求

再一个核心问题是部分热门拍品在竞拍结束时，经常出现数据库压力过大，有时候还会down机。原因是压轴报价人多，而此时该拍品已经下架了，用户还会不断刷新，然后问题来了：

之前的设计，正在竞拍的商品信息是放在本地缓存的，有效期到竞拍结束为止，竞拍期间都表现的很好，唯一的问题是竞拍结束时，用户还在大量刷新请求该商品信息，然后这一批无效请求都进入数据库了，严重的时候会导致数据库down机。

重新设计，在数据过期时，不是把key-value移除，而是保存了一个key-null的缓存项，用户用这个key来请求时，直接拿到null，提示用户商品不存在或者已下架，这样下来请求都不会影响到数据库了。其实这是一个典型的缓存穿透问题。

一点心得体会：

多会点东西还是很重要的，就这点Redis的基本应用，就轻松挣了8000块。在日常的互联网项目开发中，对Redis要求高多了，单线程模型、epoll多路复用、底层数据结构、跳跃表算法应用、各种数据淘汰策略、集群、高可用等等，都是必备的。给大家推荐一个硬核训练营，3天时间突破Redis实战和原理，由十多年经验的硬核架构师Clay主讲的，我就是从这里学习的。

关于私活