项目性能优化经验--ZY(二)
1. hibernate 级联问题
项目中,用了很多的LAZY级联,在页面用到的时候再去load,这样就使用Open Session In View的功能,在大并发且网络不好的情况下,会导致session迟迟不能释放(session要等页面request请求完全结束之后才close),即connection也没法释放。
之前项目都是使用EAGER,JSON数据传递的方式来处理,整个连接池太小不过100就能顶住1000+的并发下单
建议根据业务详细区分:
1. 如果是前台需要的数据,直接EAGER,然后传递过去,反之LAZY,不要去查了
2.尽量少用Open Session In View 会在大并发情况下,的确会导致很多问题,比如spring的事物管理(Transcational注释)和session的flush_mode之间,会导致频繁的修改session的flush_mode,从auto到commit不停的切换
OSIV的优缺点,见http://blog.jhades.org/open-session-in-view-pattern-pros-and-cons/
2. 关于电商的一些业务建议:
项目中涉及了库存,抢单,促销等操作
库存, 在读写分离的情况下,大并发下库存的读写库同步会有延迟,导致库存超卖
咨询了一下淘宝的人,发现即使淘宝也不能完全避免超卖(只不过人家有钱赔)
淘宝的处理:将下单和库存的扣减分离(不是一个事物),库存异步区扣减,人家机器多,性能好,速度快
本人建议:库存应该异步去减
具体:
1. 根据库存的量,来继续一个几率(每台tomcat),是否允许用户区下单,比如库存就剩10,4台tomcat,那么同一秒内,一台tomcat只允许2个请求的发生(根据一个比率)
2. 然后订单的提交其实分好几步,在提交,确认的任何一步都可以去比库存,然后抛出
3. 超卖既然不能完全制止,就要减少发生概率,对于真的超卖,要么协商处理
抢单:
现在的电商很喜欢搞一些抢单,秒杀
一定要跟真正的下单流程分离,单独机器,单独tomcat,单独数据库(最少也要单独的表),然后直接锁死
挂了就挂了
促销:
现在很多电商,都有相关的促销
一般分几种:
1. 单独商品的促销信息(这些可以绑在商品上)
2. 促销的策略,应该使用策略模式,或者模板模式,单独的把促销的复杂度分离开来
举个例子,促销可以有类似一号店的19,39,59多选三,可以有洗护类满100-50,可以有乐事满100-15,慢多少送什么赠品等
分品牌,分类型,分价格,分总额。。。
简单的说,可以把商品的各个属性都单独拿出来作为策略的主体
应该可以根据属性来定制策略,然后根据不同的策略来组成一次促销,并把商品加入到这次促销中
这些都要求,本身作为商品,相关的属性是多对多的,同时如果简单的多对多,会导致查询商品的时候引出很多的级联查询,所以必要的冗余也是必须的
已有 0 人发表留言,猛击->> 这里<<-参与讨论
ITeye推荐