ddd之ehcache和no ddd 之memcached扩展性的比较

10-12-03 niyunjiu
         

我对此有些疑问,大家讨论一下

在banq看来,基于ddd设计的软件,其扩展性依赖于ehcache等分布式缓存的扩展性。

而ehcache节点间的同步是比较低效的,只要是通过网络改变状态的同步方法,扩展性肯定不如memcached,因为memcached节点间是不用通讯的。比如100个节点,memcached的效率比echcache高得多。

实例也是如此。facebook有世界上最大的memcached集,facebook主要是php写成的,php当然不会用ddd了。php和memcached结合的应用很多。

实例中有大规模的echcache集群吗?如果有,请大家告知一下。

memcached本质不是对象缓存,需要经过序列化和反序列化处理。

ehcache是对象缓存,不需要经过序列化处理。

单机性能肯定是ehcache好,分布后我就有些担心了。

         

banq
2010-12-04 08:42

现在ehcache其实就是兵马俑 terracotta

见这个帖子比较:

缓存: Memcached和terracotta

总得来说,正如你说,ehcache/terracotta属于集群性质的分布式,强调稳定性和可靠性,拓展性不好,而MemCached则可靠性不太好。

对于企业应用比较侧重可靠性;对于社区应用,比较侧重拓展性,这里就涉及分布式架构设计原则CAP原理,根据不同项目进行选择。

[该贴被banq于2010-12-04 08:44修改过]

niyunjiu
2010-12-04 13:19

回复得很清晰,谢谢。

另外,你主张把域对象放到缓存中,这样的话就失去了数据库的一个特性: 事务,尤其是持久性,机器突然坏了,内存的数据就丢失了,而数据库就不会。

当然不是所有的应用都有事务的要求。

对事务要求很严的应用,数据库的作用还是不可忽略的,因为通过应用层和缓存实现ACID是比较困难的.

缓存的最初目的是缓解数据库的压力,缓存要取代数据库的地位,就要很好的持久化设计。就像linux的虚拟内存和文件系统的关系,linux的虚拟内存的设计很精妙,也很复杂。缓存要取代数据库,那最终的解决方案还是基于内存的对象数据库。

这里的根本点在于内存和文件系统的关系,内存快,文件系统慢,缓存基于内存,数据库基于文件系统。

所以我认为ddd真正需要的是基于内存的对象数据库,而不是缓存,缓存还是太简单了。

基于缓存的ddd只能适用于部分对事务要求不严的应用。

基于orm的ddd则适用于对事务有严格要求的应用,其扩展性最终还是得依赖于数据库。

以上拙见,请道友们指教

[该贴被niyunjiu于2010-12-04 13:31修改过]

banq
2010-12-04 18:00

你说得有道理,通过缓存的引入,可以让我们重新思考过去缺省都是事务的习惯,使用缓存,你就必须考虑哪些不需要事务,从而对你的业务进行事务精确化,这样是提供可伸缩性最好的办法,因为事务是可伸缩性的敌人。

当我们很小心处理事务之后,这部分事务还是可以使用Java内存锁机制或者Scala的内存事务等来完成,相信随着技术进步,摆脱数据库事务的内存事务是一个趋势。