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，慢多少送什么赠品等

分品牌，分类型，分价格，分总额。。。

简单的说，可以把商品的各个属性都单独拿出来作为策略的主体

应该可以根据属性来定制策略，然后根据不同的策略来组成一次促销，并把商品加入到这次促销中

这些都要求，本身作为商品，相关的属性是多对多的，同时如果简单的多对多，会导致查询商品的时候引出很多的级联查询，所以必要的冗余也是必须的