最近公司决定做一个面向个人的应用。虽然前期可能并发不会很大但是还是研究了一下支付宝和Ebay的分布式架构，以备用。
首先CAP理论。
我们通常在集中式环境中遇到的事务基本都是遵循ACID原则的。也就是说数据库中的数据有着很强的一致性。
但是在一个分布式环境中由于会遇到读写分离的情况,根据著名的CAP理论,为了更大程度的保证A(availability)和P(partition tolerance),需要在一些情况下对C(consistency)有所妥协。这就是俗称的弱一致性。但是弱贵弱，终归还是要回到一致状态的，于是这个叫最终一致性(Eventually Consistent). 最终一致性的实现是存储系统需要考虑的问题。这个要考虑到Master/Slave的replication的实现方式。
再者就是事务的实现模型。
本地事务不用说了。为了满足分布式事务的需求，业界有一个XA协议下的2 Phase Commit事务模型。
这个模型就是保证了跨数据源的事务或者全部提交或者全部回滚。在一定程度上满足了分布式环境中事务的一致性问题，
但是因为采用的是2阶段提交的方式，效率很低。 于是有了一些解决分布式环境下事务一致性的替代方案。比较著名的一种就是Best Efforts 1 Phase Pattern. 这个方案的原理就是尽量拖延事务提交的顺序。争取在最后把跨多个数据源的多个事务(按照我们需要的顺序)同时提交或者回滚。 这个方案面临的挑战就是当事务没有全部提交系统出现Error的时候怎么办。这个情况下数据就出现了不一致的情况。 但是毕竟这种应用Crash级别的问题比较少见，而且可以在业务里做适当的判断以减少这种情况带来的影响，所以这个方案还是不错的。我看了下阿里巴巴的CobarClient和国内的Guzz，都是用的这种事务模式。
当然，读写分离的实现, 数据库的垂直分割(根据业务功能进行分库), 水平分割(大表的分割),以及应用本身不同系统模块的分割也是需要考虑的。这些对于系统的水平扩展都是非常非常重要的。
同时，为了尽可能的减轻系统压力，有必要采取一些静态化以及缓存技术(对象缓存，静态缓存，页面缓存，局部缓存)以及
对于静态资源进行单独分割（比如:图片服务器,脚本服务器等).
最后从系统设计层面上讲有一个比较重要的原则就是能异步的地方尽量异步。异步对于实现系统的分割以及水平扩展非常有效。
有时间偶去研究一下Guzz然后跟大家做一个比较详细的分享。
最后,以源自Ebay的我很喜欢的一句话来结束这篇小文:
Partition Everything,
Asynchrony Everywhere,
Automate Everything,
Everything Fails,
Embrace Inconsistency,
Expect (R)evolution,
Dependencies Matter,
Respect Authority,
Never Enough Data,
Custom Infrastructure.