3天挣了8000块,私活儿真香!

DotNetCore实战

共 1490字,需浏览 3分钟

 · 2020-09-16

经大佬介绍,接了个技术顾问的私活儿,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主讲的,我就是从这里学习的。



关于私活



很多小伙伴儿也想业余接点私活儿,我是走过弯路的,什么猪八戒网都是坑。今年我已经接了2个私活儿,都是找我的在线教育老师,某微软MVP大佬接的。老师那边的VIP学员上万,经常会有各种私活儿,下图是老师发给我的,又可以小创收一笔了。

关注的小伙伴儿,可以扫描二维码,来听听老师的课程,混个脸熟!然后一起来协作一些大的私活儿,欢迎一起组队!

扫码大家一起组队

人数较多,添加以下号码也可哦!

微信号:zhaoxiPenny







浏览 37
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

举报