TerraCotta  通过将POJO对象在群集内下的共享,让POJO不再局限于SNA(Share Nothing Architect)的架构,比较透明的支持了集群模式,可谓POJO开发模型的最后一块拼图。

      实它的原理很简单,本身是一个中央式的Cache服务器。在应用启动命令中添加Terracotta参数,Classloader就会根据配置文件在JVM级以AOP方式修改ByteCode,用户透明地将对象存储于中央服务器。

      为了性能,它以对象属性而不是整个对象为存储单位;为了可用性,它本身也支持主备集群。

  
     研究院和项目组的同事们早就在他们的地盘上用上了,这几天自己也跟风了一把。

     很喜欢这种"前商业项目",一般都会有不错的工具。 
  • Sessions Configurator 。以Debug模式将tc-confg.xml运行在一个预配置的双机集群下,让你观察共享对象的数值变化,出现运行时错误时,提示配置文件缺漏错误的修正。
  • Eclipse插件。通过对着任意的类、属性、函数点右键来设定tc-config.xml。

     说是用户透明,其实只是最美好的愿望,可能还是有些代码修改:

  • 同步问题。原本单机运行的程序,改成集群运行,跑不掉的是先要将自己共享对象类的代码改为线程安全的,如使用线程安全的ConcurrentHashMap 、AtomicInteger属性,或在访问属性的代码中加入synchronized控制。然后在xml中配置Terracotta的autolock将锁其扩展到群集范围,设定以锁为边界的批量更新属性的事务。
    反向理解TC的CTO同志关于调优的讲话,锁没搞好的话对性能影响挺大。
  • 本地资源属性。有些很local的属性如文件句柄是没办法共享的,这时候就需要配置为Transients 属性。这种属性在另一个JVM里就会被强制设为Null。怎么办呢?推荐的做法是另写一个初始化这些属性的init函数,在tc-config.xml中配置调用。更少侵入的做法是直接在tc-config.xml中写beanshell脚本,不过这脚本不好写。

     最后TC承担了实现POJO集群的功能,但TC Server本身就存在单点故障的危险,需要配成Cluster模式。在TC的Persistent HA Cluster模式中,所有数据会Persist到磁盘,Cluster中永远只有一个Active Node,其他节点就作为Passive Nodee。Active Node的失效切换与Client的重连都是透明的。 Passive 与Active Node使可以用同一块支持文件锁的磁盘空间,也可以让Active Node将所有变化通过网络同步到Passive Node上。一般采用后者。


       另外,已经可以买国内的技术支持服务了。唯一遗憾要到12月份的TC2.7版,才会支持Glassfish 2。