__group__	ticket	summary	component	version	type	owner	status	created	_changetime	_description	_reporter
Milestone 汽车报价v5.5	8	关于MongoDB的全局锁	汽车报价库前台	5.5	需求		new	2012-01-05T15:32:20+08:00	2012-01-05T15:32:20+08:00	"对MongoDB有所了解的人都知道，MongoDB有一个让人头疼的全局锁（读写锁，允许并发读，而写会阻塞所有的读写），要命的是这个锁不是表级的，不是库级的，而是整个Server级别的，这让人听起来是不是非常的蛋疼。

在2.0版本以前，这一问题一直没有得到解决，于是有人提出，在可预见某个update操作的记录可能在磁盘上时，为了减少写锁占用的时间，可以采用先读后写的方式，通过先读一次，将要操作的记录加载到内存中，再进行内存中的update，这样写锁就不包括将数据从磁盘加载到内存的时间了。

在可预见数据冷热的情况下，这种操作能够有一定的效果，但是很明显，这种变态的方法不应该是一个终极解决方案。

值得庆幸的是，在2.0版本中，MongoDB宣称有很大程度的并发性能提升，而这一提升的基础正是解决了这个全局锁的问题。

解决的方法并不是通过减少锁粒度来解决，虽然collection级别的锁机制也正在开发中。（SERVER-1240）

解决方法是通过对一些可能造成长时间锁占用的操作进行锁抑制。比如和我们上面的方法类似，在进行update操作时，如果发现需要更新的记录在磁盘上，那么这个锁就不会一直占用，而是等到将数据从磁盘加载到内存后再添加写锁进行update。

而同理，对于其它一些可能耗时比较长的操作也可以采用类似的方法，通过将长时间占用的全局锁拆分成多个细粒度的小锁来使需要获取锁来进行的操作能够交错的执行，从而避免一夫当关万夫莫开的情况，主要包括下面一些操作：

•查询操作
•批量更新操作
•批量删除操作
•批量insert写入操作
如果你还在使用2.0以前的版本，并且在并发性能上出现问题，可以考虑在2.0.x版本上进行一些性能测试并对你的MongoDB进行升级
"	liangqinsheng
Milestone 汽车报价v5.5	9	关于Repository模式	汽车报价库前台	5.5	需求		new	2012-01-09T09:52:12+08:00	2012-01-09T09:52:12+08:00	"近期读了电脑网产品库的源码 里面使用到一种设计模式
Repository模式

个人理解：Repository是一个独立的层，介于领域层与数据映射层（数据访问层）之间。它的存在让领域层感觉不到数据访问层的存在，它提供一个类似集合的接口提供给领域层进行领域对象的访问。Repository是仓库管理员，领域层需要什么东西只需告诉仓库管理员，由仓库管理员把东西拿给它，并不需要知道东西实际放在哪。

tabbycat的理解（来源）：

1. Repository模式是架构模式，在设计架构时，才有参考价值；

2. Repository模式主要是封装数据查询和存储逻辑；

3. Repository模式实际用途：更换、升级ORM引擎，不影响业务逻辑；

4. Repository模式能提高测试效率，单元测试时，用Mock对象代替实际的数据库存取，可以成倍地提高测试用例运行速度。

评估：应用Repository模式所带来的好处，远高于实现这个模式所增加的代码。只要项目分层，都应当使用这个模式。

关于泛型Repository接口（来源）：

仅使用泛型Repository接口并不太合适，因为Repository接口是提供给Domain层的操作契约，不同的entity对于Domain来说可能有不同的操作约束。因此Repository接口还是应该单独针对每个Eneity类来定义。

泛型的Repository<T>类仍然用来减少重复代码，只是不能被UserRepository类直接继承，因为这样Delete方法将侵入User类，所以改为在UserRepository中组合一个Repository<T>，将开放给domain可见且又能使用泛型重用的功能委托给这个Repository<T>

Repository与Dal的区别（来源）：

Repository是DDD中的概念，强调Repository是受Domain驱动的，Repository中定义的功能要体现Domain的意图和约束，而Dal更纯粹的就是提供数据访问的功能,并不严格受限于Business层。

使用Repository，隐含着一种意图倾向，就是 Domain需要什么我才提供什么，不该提供的功能就不要提供，一切都是以Domain的需求为核心；而使用Dal，其意图倾向在于我Dal层能使用的数据库访问操作提供给Business层，你Business要用哪个自己选。换一个Business也可以用我这个Dal，一切是以我Dal能提供什么操作为核心。

对比汽车网simple框架，里面设计的DomainObject也用到了类似的思想。但是DomainEvent与DomainObject的耦合度太高，设计也不够抽象，不适合灵活的需求。其实可以使用Ioc的思想来做改进。

下篇再做讨论。


"	liangqinsheng