项目性能优化经验--ZY(二)

标签: 项目 性能优化 经验 | 发表时间:2014-11-21 21:10 | 作者:patrick002
出处:http://www.iteye.com

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推荐



相关 [项目 性能优化 经验] 推荐:

项目性能优化经验--ZY(三)

- - 行业应用 - ITeye博客
读写分离,不是想做就做的,说分就分的,随便找个中间件把请求一转发就OK的. 比如,在项目中有个模块是购物车(现在的电子商务一般都需要存储购物车内容,因为存在PC,MOBILE等不同的终端),客户先点击添加购物车,然后结算(这时候会做个判断购物车是否有商品),在大并发情况下,mysql的读库和写库的同步(beanlog)严重的delay,导致购物车一直判断为空,订单无法下.

项目性能优化经验--ZY(二)

- - 行业应用 - ITeye博客
项目中,用了很多的LAZY级联,在页面用到的时候再去load,这样就使用Open Session In View的功能,在大并发且网络不好的情况下,会导致session迟迟不能释放(session要等页面request请求完全结束之后才close),即connection也没法释放. 之前项目都是使用EAGER,JSON数据传递的方式来处理,整个连接池太小不过100就能顶住1000+的并发下单.

项目性能优化经验--ZY项目

- - 行业应用 - ITeye博客
最近负责给公司某个ZY项目进行性能优化的一些经验分析. 压力测试到100并发,任何一个场景CPU暴高,接近100%. 查询jstack日志,发现大部分的线程block在tomcat 的 http11.connect 的poll方法上 或者是c3p0连接池的获取上. 同时发现该项目数据库连接池配置了2000+,仍然不够用,100并发.

PHP项目性能优化

- - SegmentFault 最新的文章
PHP项目性能优化的三个层次. PHP周边(服务器,数据库,webserver). 尽量使用PHP原生函数和常量,类. 如果要实现的功能有原生PHP函数,则不要自己用PHP实现. 尽量使用性能更高的内置函数. 比如isset和array_key_exists都可以使用,则使用isset. 尽量不要使用错误抑制符@.

SQL性能优化十条经验

- - CSDN博客推荐文章
尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用,最好不要用.. 其实只需要对该脚本略做改进,查询速度便会提高近百倍. a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表,用户模糊输入供应商名称时,直接在前台就帮忙定位到具体的供应商,这样在调用后台程序时,这列就可以直接用等于来关联了.

MySQL性能优化的最佳20+套经验

- - CSDN博客推荐文章
今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显. 关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我 们程序员需要去关注的事情. 当我们去设计数据库表结构,对操作数据库时(尤其是查表时的SQL语句),我们都需要注意数据操作的性能. 这里,我们不会讲过 多的SQL语句的优化,而只是针对MySQL这一Web应用最多的数据库.

高手详解SQL性能优化十条经验

- - SQL - 编程语言 - ITeye博客
尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用,最好不要用. 其实只需要对该脚本略做改进,查询速度便会提高近百倍. a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表,用户模糊输入供应商名称时,直接在前台就帮忙定位到具体的供应商,这样在调用后台程序时,这列就可以直接用等于来关联了.

一些项目管理经验(1)

- - 曉生
要尽早的参与到产品的需求当中,在讨论过程中给出自己的专业建议. 设计是整个团队的一部分,考虑的不只限于我应该做什么,而是可以为整个产品做什么. 设计与产品不可避免会有意见上的冲突,设计抱怨产品策略没有想清楚,强调流程上产品给出明确的文档之后设计再开始参与. 如前期能帮助制定产品策略,会扩大设计的影响力.

MySQL性能优化

- sun - IT程序员面试网
在笔试面试中,尤其是像百度,淘宝这些数据量非常大,而且用LAMP架构的公司,数据库优化方面就显得特别重要了. 此外,除了数据库索引之外,在LAMP结果如此流行的今天,数据库(尤其是MySQL)性能优化也是海量数据处理的一个热点. 下面就结合自己的经验,聊一聊MySQL数据库优化的几个方面. 首先,在数据库设计的时候,要能够充分的利用索引带来的性能提升,至于如何建立索引,建立什么样的索引,在哪些字段上建立索引,上面已经讲的很清楚了,这里不在赘述.

Hebernate 性能优化

- - 企业架构 - ITeye博客
文章分为十三个小块儿对Hibernate性能优化技巧进行总结性分析,分析如下:. 一、在处理大数据量时,会有大量的数据缓冲保存在Session的一级缓存中,这缓存大太时会严重显示性能,所以在使用Hibernate处理大数 据量的,可以使用session. clear()或者session. evict(Object) 在处理过程中,清除全部的缓存或者清除某个对象.