首页新闻招聘找找看知识库
  • 回复:17 浏览:7871 2010-06-17 11:06 来自 gaobanana

    现在出现了很多网站都有这类的限时,限量的购物机会出现,大量人短期内频繁操作。

    作为程序员,也应该想想其对数据库,性能等方面的一些要求。

    最近稍微思考了一下,提出几点不成熟的思考,希望可以抛砖引玉,大家也一起探讨一下!

     

    1. 数据库可以分库,分表,在晚上执行任务进行汇总统计

     

    2.  限定多长时间内只能操作几次来减低服务器压力和并发数

     

    3.  在用户登陆时显示其前面已经登陆的用户数(或者是已经在他之前抢购了的人数),以此来减轻服务器负担。

     

    肯定还会有很多可以考虑的方面,希望大家一起讨论讨论。

  • Kevan
    2010-06-17 11:30 Kevan
    UPDATE 锁表SUM(成功下单人数) +1
    第1楼 回到顶楼
  • 邢少
    2010-06-17 11:30 邢少
    没有看到楼主的想法,列举的三个方面并没有对性能有什么提升。
    1、数据库分库、分表、并且在晚上可以解决你的问题“短时间频繁操作”的并发性能问题吗?.只能在数据统计的时候清晰一点、数量级小点,这都是在“频繁操作后”要作的统计工作,与主题无关。
    2、既然限量购物,登录人肯定很多。限定1个人只能登录几次可以减少并发吗?并且失去了公平性。是牺牲了功能。限量购物就是吸引人气的。把客户限制了,还吸引什么人气?!不理解楼主的思路。
    3、显示登录用户数可能是增强了客户体验。但是性能有什么优化吗?.反而保证数字的准确性还要牺牲部分的性能
    第2楼 回到顶楼
  • gaobanana
    2010-06-17 11:39 gaobanana
    @邢少
    1. 用户做了购买操作,信息是需要记录的啊!

    2. 是限定比如几秒钟内不能重复点击购买,分配到单位时间内的并发会减少啊! 也需要考虑客户端用程序模拟点击的问题。

    3. 显示这个东西可以减少一部分人继续点击购买的可能性啊,只能感叹自己下手晚了!就像我们去银行排队办理业务一样。

    以上是我的想法,你也可以对你的观点进行说明啊,也讨论讨论,别只提出疑问啊??
    也给出解决的办法才好啊!
    第3楼 回到顶楼
  • 菩提树下的杨过
    2010-06-17 11:41 菩提树下的杨过
    秒杀的高峰压力主要来自于密集型的登录与下单,对于登录,暂时没想到啥好的办法(毕竟人家要来上你的网站,这是好事,不太可能从技术上限制,技术手段用尽以后,这块主要还是依赖硬件的提升来处理);对于下单,可以参考下petshop的异步操作思路,异步提交到消息队列,即:先把所有的下单请求全部照单全收至msmq(这样可避免堵塞),然后跑一个windows服务在后台一条条订单入库,直到把整个队列全处理完。通常秒杀时间一过,压力即将慢慢解除。但异步操作有一个潜在问题,用户已经提交下单请求了,此时可能尚未入库(保存在消息队列中),如果用户这时就查看“我的订单”,可能查不到数据,暂时能想到的解决方案:秒杀时段,订单查询的界面上,提示用户一些信息,比如“秒杀成绩将在5分钟后公布显示”之类.
    第4楼 回到顶楼
  • gaobanana
    2010-06-17 11:54 gaobanana
    @菩提树下的杨过
    这个也考虑过,不过这类的项目没有涉及过,不知道真用起来结果如何,呵呵,就是曾经面试时被问到的问题,和大家谈谈。
    第5楼 回到顶楼
  • MyCoolDog
    2010-06-17 11:58 MyCoolDog
    这个 ,很想了解拍拍和淘宝是怎么做的,
    有大牛来说说吗~?
    第6楼 回到顶楼
  • Birdshover
    2010-06-17 14:44 Birdshover
    采用高并发的消息服务器即可。一般用Redis就够用了。
    第7楼 回到顶楼
  • iIMax
    2010-06-17 15:05 iIMax
    我现在最想研究的就是一个秒杀的外挂来帮助我秒杀,最近太忙 还没时间研究呢
    第8楼 回到顶楼
  • Jeffrey Zhao
    2010-06-18 09:38 Jeffrey Zhao
    实在不行就不用关系型数据库嘛,其实自己随便写一个简单的存储结构都可以支撑的,而且应对现在这个场景还是很容易的,hmmm……
    第9楼 回到顶楼
  • Ivony...
    2010-06-18 09:47 Ivony...
    最关键的一点没说。

    就是程序挂了别让用户知道。

    事实上我们就是这样干的,因为没有什么办法可以保证程序不被用户玩死,但有办法可以让用户不知道这回事儿。事实上程序被弄挂的时候,秒杀早完成了。
    第10楼 回到顶楼
  • Capricornus
    2010-06-18 09:49 Capricornus
    嗯. 肯定用队列会比较好. 减少很多压力.
    而且限时秒杀的物品可以单分到一个库或表里.
    第11楼 回到顶楼
  • 黑羽飘舞
    2010-06-18 11:14 黑羽飘舞
    一般处理这种情况我们都是把秒杀作为一个模块独立出来,订单采用缓存保存,再通过异步方式隔一段时间持久化保存一次,尽量减少io和数据库的读写操作.用户在订单中心查看的时候也是直接读取缓存的数据.比较难处理的就是对库存数的并发访问,如果处理不好往往会照成读入脏数据
    第12楼 回到顶楼
  • kiler
    2010-06-18 11:30 kiler
    数据库倒不是主要瓶颈,主要是webserver接受请求会出问题。
    第13楼 回到顶楼
  • www.mangago.com
    2010-06-18 14:34 www.mangago.com
    you can read free manga online (http://www.mangago.com)
    第14楼 回到顶楼
  • 風語者·疾風
    2010-06-19 09:29 風語者·疾風
    其实未必有那么复杂:
    首先抢购页面一般都是静态页面,WebServer的压力不会太大。
    其次,可以对所有抢购商品的库存,时间点等数据进行缓存,缓存策略如下:
    1、用户的请求和响应都从缓存中计算并反馈,这样减少对数据库的压力和提高响应速度;
    2、在每次对缓存改写的同时,通过异步方式(例如消息队列)提交到数据库,以确保订单的持久性和可靠性。同时也保证了响应速度和对数据库服务器的峰值压力。

    还有吗?貌似基本已经解决了
    第15楼 回到顶楼
  • 苏飞
    2010-06-19 11:36 苏飞
    可以考虑把一个东西记录在客户端
    第16楼 回到顶楼
  • 布衣人老白
    2015-10-27 19:15 布衣人老白
    @菩提树下的杨过
    这样用户可能会觉得后台作弊,加版本号处理如何?
    第17楼 回到顶楼
登录后才能评论,请先登录注册