这种高频系统需要考虑的因素很多。
如果在一分钟内会有上百万次请求, 那么1秒钟就要处理1万多次请求。 那么我们分析一下延迟:
网络延迟
系统IO延迟
内存延迟
缓存延迟
数据库延迟
对于网络延迟,没有很好的解决方法,这个跟用户的网络环境有关
对于系统IO, 不太推荐用多线程以及线程池模型。 多线程创建销毁都会有很大的额外开销, 线程池会有等待延迟。 推荐使用libevent这类多路io的框架, 可以在一个线程内完成IO非常轻量
对于内存延迟, 如果我们在短时间内要做大量的业务,建议使用slab这类内存对象方式分配内存,这样可以减少内存分配器带来的开销。 处理完的业务可以放在队列中,可以单独设计一个线程处理队列来给用户response(response延迟并不是那么重要)。另外有大量优化的地方, 例如排除cpu缓存伪共享,集成第三方高性能内存分配器等等手段, 如果有需求可以研究一下。
一般秒杀系统session数据会放在缓存中,例如redis。 如果请求多了, 那么流量会全部压到一个redis的server上,会造成轻微延迟(redis是单线程队列), 这时候可能需要做一个主从系统,不过公司的硬件环境不好有可能会有反效果, 一般情况下1s处理几万次请求还是没有多大问题的。
数据库不要动态写,肯定慢,秒杀结束后一次性把redis的transactions 同步进去。
处理IO建议不要直接用后台服务器, 建议做几个io服务器和客户端连接, 接到客户端请求后用rpc框架投到你的后台。 一个电脑的socket多了后性能下降很快。
1) 对现有网站业务的冲击因为秒杀活动只是网站营销的一个附加活动,这个活动具有时间短,并发访问量大的特点,如果和网站原有应用部署在一起,必然会对现有业务造成冲击,稍有不慎可能导致整个网站瘫痪。
2) 高并发情况以及数据库的负载
用户在秒杀开始前,通过不停的刷新浏览器页面以保证不会错过秒杀,这些请求如果按照一般的网站应用架构,访问应用服务器、连接数据库,会对应用服务器、数据库服务器造成极大的负载压力。
3) 突然增加的网络和服务器带宽
假设商品页面大小200K(主要是商品图片大小),那么需要的网络和服务器带宽是2G(200K×10,000),这些网络带宽是因为秒杀活动新增的,超过网站平时使用的带宽。
4) 直接下单
秒杀的游戏规则是到了秒杀时间才能开始对商品下单购买,在此时间点之前,只能浏览商品信息,不能下单。而下单页面也是一个普通的URL,如果得到这个URL,不用等到秒杀开始就可以下单了。
5) 防止机器秒杀
防止网上的一些“秒杀器”
针对上面的5个问题,对应的策略如下:
1) 秒杀系统独立部署
为了避免因为秒杀活动的高并发访问而拖垮整个网站,使整个网站不必面对蜂拥而来的用户访问,将秒杀系统独立部署,如果需要,还可以使用独立的域名,以和网站完全隔离,即使秒杀系统崩溃了,也不会对网站造成任何影响。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)