从铁道部12306.cn网站漫谈电子商务网站的“海量事务高速处理”系统》
今天你买到票了吗？——从铁道部12306.cn网站漫谈电子商务网站的“海量事务高速处理”系统》
首发地址： http://bbs.hpx-party.org/thread-8488-1-1.html
文章比较长，成文仓促，结构的确不晴晰，向各位读者致歉，写一个本文导读吧。整篇文章论述的就是“海量事务高速处理”的经验和误区。
第一部分论述“海量事务高速处理”现阶段没有通用解决方案，尝试通用解决方案就是误区。
第二部分讲解算法问题、安全问题经验，以及一些误区。
第三部分讲解电子商务网站的核心交易系统如何随着网站的发展而演进，分成了三个发展阶段，发展过程中的一些经验和误区。
另外，具体的需求的确不在本文讨论之列，望各位读者海涵。
“海量事务高速处理”期核心交易系统分析探讨
当系统演讲到海量事务高速处理阶段，如前面所述，整个交易系统是完全按照需求定制的，下面仅就一些共性的问题做简要的探讨。主要涉及三方面的问题，系统的可用性，锁的粒度，以及事务的划分。
首先看系统的可用性，任何系统随着规模的增长，设备故障的频率也将越来越高，此时就需要有相应的容灾策略。需要消除单点、甚至于单集群故障。在前面提到的锁服务也就不能采用通用的数据库来设计。目前流行的做法是采用基于Paxos算法的锁服务，通过五台计算机（最少是三台，一般是奇数个，考虑容灾的需要一般用五台，更多的计算机会造成之间通讯量的快速增长）组成一个针对某类资源的锁服务集群。在操作某一项资源时，先在锁服务上对这一项加锁，操作之后解锁。这和悲观离线锁机制相同，当然在实际操作中，因为还要消除保存资源数据的计算机的单点故障，加锁和解锁的过程要和所有数据的一致性保持同步。
既然锁是以锁服务的形式存在，那么如何划分锁的粒度就成为效率的关键，锁的粒度太细的话，一个事务中操作锁的次数就太多了，锁的粒度太粗的话，碰撞的可能性就大得多。另外，既然锁已经独立于数据，因此一组锁服务可以为几类数据量不大的数据服务，对于数据量很大的数据可以分成几组锁服务。
锁的粒度划分又和事务紧密联系在一起，一般来说，一个事务中持有的锁越多，碰撞的机会就越多，而碰撞的结果就是回滚。从定性的分析来看，可以用N^2来评价，比如说一个事务中持有两个锁，那么碰撞的机会就是4，持有三个锁的话，碰撞的机会就是9。也就是说，如果把一个需要持有三个锁的事务划分成两个持有两个锁的阶段的话，碰撞的机会就是2*4=8<9。从这个简单的定性分析可以看出，事务应以2个锁为主，不超过3个锁。4个锁以上的事务一定要分解成多个小事务。当然经过分解之后，复杂程度也随之提升，但是因为减少了碰撞，系统的总体性能获得了提升。也就在另外的一些环节中减少了系统的复杂度。
系统的可用性、锁的粒度以及事务的划分这三个问题既相互独立，又相互联系。对于核心交易系统来说，合理的事务划分可以提升性能，从而减少计算机的数量，间接提升了可用性。
另外一些误区
在前面提到了采用类似于EJB的中间件容器或者将事务交给数据库处理是两个主要的误区，下面谈一谈其他一些认识上的误区。
加强CDN建设能提升核心交易系统性能。答案是没有直接联系，对于电子商务网站来说，CDN的价植更多体现在CMS产品上，也就是货架陈列产品上，对于涉及到事务的MIS、OA、ERP来说，不可能使用CDN的缓存，最多使用CDN的路由加速功能。这些对于核心交易系统没有直接联系。
将核心交易系统建设成开放平台有助于简化核心交易系统，提升交易性能。答案正好相反。内部系统纵然有种种弊端，但是对于任何一个细节都是可控的，而对于开放平台来说，难以控制外部的操作，为了应外可能出现的负荷变化可能要做更多的准备。换句说话，在内部系统还没有完善的时候，开放平台不仅没有帮助，反而可能放大现在的缺陷引发连锁崩溃。
对于其他的误区欢迎各位联系，我将继续补充。
?
