软件开发中关于集群(cluster)的问题

看到有文章说，JMS,XA和Cluster是98%开发人员眼中的鸡肋，似乎有一定的道理，JMS可以找到替代品，XA一般来说不建议使用，或者说使用起来成本很高，很少有需要多个数据库，或者事务源之间的事务，而Cluster，开发者基本也不太考虑。 不过在我所做的产品中， 这三个恰好都用上了，而且一般来说，用了JMS，很有可能就会用XA，也很有可能需要部署到cluster环境中。从我看到的，cluster在客户实际环境中，还是经常使用的，毕竟为了保证7x24的服务， 提高服务性能，Cluster还是不二法门，但是对于程序员来说，的确还是经常忽略了一些问题。

Cluster环境下，开发人员最容易出现的一个问题就是ID生成问题。在一些应用中，时钟是一个常用的生成ID的方式，但是在cluster环境，显然是不行的，而且也是常见问题之一。解决的方法很简单，用数据库的sequence就可以了。但是对于大量的sequence生成，sequence显然代价很高， 可以用另一种方式，就是给集群里的机器编号，用编号加上时间戳的方式作为ID,既可以解决全局唯一性，同时又不会有性能方面的问题，编号同样可以从sequence获取。

程序员容易忽略的另一个问题就是对象的序列化，在cluster环境下，由于Session Copy的原因， 对象需要可序列化，这看上去是个很简单的事情， 只要加上一个serialiable 接口，只是这个简单的步骤常常被人忽略，而且，不到cluster环境，还真发现不了。最近产品发布后，多个客户报出cluster环境的问题，才发现平时设计时考虑得不周全。另外， Serializable也不是万能的，比如有的第三方的类，如果放在session中， 可能它本来就没有实现序列化，怎么办了？一种当然只能构造自己的类，装载必要的信息， 另一种就是tansient,不将该对象纳入session copy中。

最后，cluster 部署架构也是多种多样的。在有的cluster环境中， 上面的问题就没有出现， 为什么了？因为没有Session copy发生，每个请求都会forward到之前的机器中，通常说请求是sticky的。这里也有一个有趣的问题，有不同的配置可以决定sticky table的内容。例如session id,url,或者application data，决定新来的请求到集群中的哪个机器。不过sticky table由于大小受限，出现过session time out问题，因为容纳不了那么多数据， 导致请求不一定发送到原来的机器上， 可能出现需要重新登录的问题。

从上面可以看出来，cluster和部署关系很大，不同的策略会导致不同的结果，例如stiky策略，session copy的策略，还有这次没有涉及的分布式缓存等等，都需要我们在程序设计的时候就考虑到。所有，作为程序员，即使没有真正在cluster环境下开发，还是需要考虑相关的问题的。