收藏并探讨电商的贴子中的技术(不断学习更新)

最近学习这个，开个帖子专门总结一下：

一、一号店的架构演化。http://geek.csdn.net/news/detail/62985

其中提到了：架构层面的规划有业务逻辑层的拆分-SOA服务化，另一个是DB层的水平拆库。

SOA化感悟：订单是电商中的核心业务，还关联着其它很多模块，必然要拆分。其实soa的思想与我们业务中的分层差不多，我指的不只是J2EE项目中的dao,service,controller，这个是非常基本的分层，当然最初设计的人是这个思想，后面的人已经不要考虑了，所以不代表就掌握了这个思想。其实重要的是service层的再分层，这就体现出设计水平的高低了，怎么拆，拆几层，相互调用关系，参数传递，边界等都是要考虑的要素。拆分后一方面可以共用公共的部分，另一方面结构清晰，还有就是分离出异步操作。
我见过别人写的超长的方法，别人看很累，不知道自己回头看有没有这样的感觉，至少分成几个调用关系。学会了拆分，甚至一些设计模式自然就用上了，比如模板模式，比如回调模式。可以说学不会拆分就用不好模式。

DB水平拆库：数据库会成为高并发的瓶颈，虽然我们的小业务中没有分库，但偶尔的大的共享对象用一下copyOnWriteArrayList也是一个道理。读多写少的时候用。而且在之前分析阿里的druid的源码时，我们看到数据源对象的filters用的就是这个，很多很多filterchain对象引用到它，如果不分离，还要加锁，那性能肯定差了远了。水平拆库一般ID是取余的方式，你按买家定单拆分了库，那卖家的数据必然分散多库了，所以最好卖家复制一份按卖家放从库方便卖家读取，但写的时候还是写主库。

二、59store技术架构http://geek.csdn.net/news/detail/74177
经过半年的不断抽象、剥离、重构，现在59已经形成了一整套基础服务体系，以及构建在其之上的众多业务。

SOA化感悟：同样也是基础服务体系的soa化，很难想象不分层，不分模块，如何开发复杂庞大的系统。如何应对变化，如何应对分工，如何应对排错，如何查找瓶颈...

秒杀商品信息全部缓存在Redis集群中，以减缓高并发场景下的系统压力和数据库负载。假设一个商品秒杀库存有5件，库存的信息会被存储在一个Redis集群中，并且留有一定冗余，比如记录秒杀商品库存为8件。

秒杀技术：已经看过一些秒杀技术，比如阻止大量的请求最终到达后台，还考虑数据库锁定等。所以把数据都拿缓存中，甚至也可以用一些锁定对象策略，我试过一个数组对应一类商品，数组里是空对象，得到一个锁才能得到一个商品，最后再写入库中结果。

    还有就是用队列方式，想起14年抢上海马拉松名额，网站崩溃了，后来人家用的消息队列。其实钞杀可以用生活场景设想，可能你没设计过系统，但你肯定可以设计好生活中的抢购，至少参与过生活中的抢购吧：
    比如想象生活中很多人拥过来抢东西，可以每人领到一张有号码的票，拿到票的人到一排固定的桌子上有位置可以填表买商品。保安大叔不时检查有没有空桌子，有的话正好安排下一个去空桌子。有时候可以随机排几个队，那就安排几个保安负责把本队的人放进空桌子，但会产生共享冲突，要锁定。排队买火车票时，你发现正好有1张票，真正买时没了，没准边上一队伍的人正好也看到1张，先下手了。
    还有生活中抢头香吧，一群人冲进来多危险啊，我看只要冲进来3个人就关头道山门，之后看谁先跑到香跟前。
    还有新娘抛花，很多人抢，只能一个人抢到，那就干脆随机数。
    还有一些品牌店促销，每个店有10个货，但热门的地方一下就没了，远的地方可能还有。那要么就这样了，要么调配货品。可能你听说远的地方有，但过去一看，已经排了15个人了，几乎没机会了，就放弃吧。
    生活中的场景多，有时候有先后顺序，有时候简化处理，所以各家的秒杀系统可能也有不同之处，不过商品放缓存中总是比数据库中快。也可以设想东西摆到桌子上比从后面仓库中取快，生活中买鞋子一般店员从后面取，摆的只是样品，促销的嘛直接摆在小车上也是一样道理。这样感觉好理解多了！