最近需要做一个拍卖程序,请有相关经验的朋友进来看看

迷路的游侠 发布于 2011/05/27 16:36
阅读 368
收藏 3

最近公司要我做一个网上拍卖的程序,无奈实在没有相关方面的经验。

所以想OSC上问问有相关经验的朋友,做这个东西的时候应该注意些什么。

 

我现在的设想是把出价记录存到memcached上,

然后有人出价的时候就先从memcached上取出记录集合,在集合里插入新的记录后再存回memcached.同时将这条记录存到数据库中,以作备份(万一memcached里过期了可以去数据库取)。

这个是我初步的设想,大家觉得怎么样呢~。~!

 

还有其他想法,希望朋友们能畅所欲言呀

加载中
0
RickHuang
RickHuang

应该先从场景/流程入手,假设:

1、商品底价100元

2、A B  C三个用户同时出价,B的出价先到达系统,A C的出价被驳回(因为商品当前价格已经变更,A C的出价无效)

从这个流程商品价格需要有个锁,当前只能有一个事务拥有这个锁,其它事务发现锁已经被获取了就自己回滚。

另外,此类需求不适合用缓存设计,因为都是关键数据资源,必须每次操作都固化到数据库中。

0
老盖
老盖

没做过,不过我记得《测试驱动的面向对象软件开发》这本书就是以一个拍卖程序作为例子

0
迷路的游侠
迷路的游侠

引用来自#2楼“RickHuang”的帖子

应该先从场景/流程入手,假设:

1、商品底价100元

2、A B  C三个用户同时出价,B的出价先到达系统,A C的出价被驳回(因为商品当前价格已经变更,A C的出价无效)

从这个流程商品价格需要有个锁,当前只能有一个事务拥有这个锁,其它事务发现锁已经被获取了就自己回滚。

另外,此类需求不适合用缓存设计,因为都是关键数据资源,必须每次操作都固化到数据库中。

嗯,谢谢你的建议。

我使用缓存的初衷是为了缓解数据库的压力。你这么一说我发现确实有道理。

还有关于“从这个流程商品价格需要有个锁,当前只能有一个事务拥有这个锁,其它事务发现锁已经被获取了就自己回滚。”

你能描述的再清晰一点吗?

0
沈义扬
沈义扬

如果只是单应用服务器的话,缓存对象也是可以做版本控制的

AtomicStampedReference,版本相符才更新,过期的请求被驳回。

0
沈义扬
沈义扬

另外你要减少压力的话,可以考虑这个方式,所有的写操作都会把这条记录的缓存废弃,但是读操作不会。

这样数据没有修改的话,你的读就没有压力了。当然这也是取决于你的写操作是不是会很频繁,实际场景中会不会缓存没有命中率

0
迷路的游侠
迷路的游侠

引用来自#5楼“沈义扬”的帖子

如果只是单应用服务器的话,缓存对象也是可以做版本控制的

AtomicStampedReference,版本相符才更新,过期的请求被驳回。

现在是两台服务器的集群,每台2个tomcat....

但是都是共用一个memcached。

0
mrvoce
mrvoce
竞拍网站我之前做过那种最低唯一模式的,不是现在用钱去顶时间,那时候特别郁闷的是最低唯一要保证最低价格由是不被覆盖的,那么加锁在数据库上进行操作服务器好可以顶1000-2000人同时出价(2Tomcat和1Apache)没考虑缓存,但是发现读的时候压力特别的大,写操作如果缓存可靠可以全部放缓存中然后每轮完成后持久化到数据库。关键是要有一个锁,每次进入就要排队经过这个锁。考虑下吧。
0
ouotu
ouotu

这个可能看访问量是多大。

一般情况,读的次数比较多,而写的次数比较少。你的缓存估计是用来给读操作的。

竞价流程:从持久层加载商品,业务逻辑处理(竞价的价格是不是比现在的商品价格高,高就继续),写日志,更新缓存。

一般情况需要在业务逻辑处理进行排队或加锁处理,和事务处理。

查价流程:直接从缓存读取,没有就到持久层拿,再放入缓存中。

当然,也可以有好多台web服务器,多台缓存服务器,多台业务处理队列服务器。数据量大,也可以对缓存和业务处理服务器进行水平或垂直划分。

 

0
JPer
JPer
建议楼主去拍卖现场走一趟,亲自体验下,看看拍卖人员怎么处理多个竞价;实际上就是对出价一个队列排序,依次回显到客户端,用户按照最高金额再次给出价格,缓存只记录最高价格即可,队列依次将金额入库或者其他处理;
返回顶部
顶部