对Memcached的使用的总结

转载地址:http://hi.baidu.com/zzeric/blog/item/067263fa4362541fa9d31157.html

1. Memcached + Tomcat自定义SessionManager方案，采用分布式缓存+本地缓存的方式，在非Sticky Session模式下，可能会出现本地缓存不一致的情况。
如：

假定用Apache进行非StickySession的负载均衡，用户甲访问服务，第一次请求被分派到Tomcat_Instance_A，并执行session.setAttribute("UPDATE_TIME")，SessionManager负责把这个属性更新到Memcached服务器，并做本地缓存；第二次访问时，请求被分派到Tomcat_Instance_B，并执行session.getAttribute("UPDATE_TIME")，刚开始Tomcat_Instance_B的本地缓存是没有UPDATE_TIME这个属性的，所以会去Memcached服务器取，取到后放到本地缓存。这是没问题的。但在A和B上的本地缓存都有了UPDATE_TIME这个属性的副本后，用户在A上更新UPDATE_TIME的话，A的本地缓存和Memcached服务器都会被更新，但B上的本地缓存则不会被更新，当用户请求再次分派给B时，得到的将是脏数据。

JavaEye上有人提出用OSCache做本地缓存，在本地缓存更新后，通过JGroups广播，更新或删除各服务器本地缓存里的UPDATE_TIME属性。但我觉得因为这样而引入OSCache不值得，JGroups广播与Memcached共存让Memcached的存在变得没有意义，倒不如直接走老路，用OSCache + JGroups的方案。

我觉得还是用StickySession + Memcached的方案解决这个问题是最划算的。Apache把同一用户的每个请求都分派到同一个Tomcat上，当原来的Tomcat宕机后，再分派到另外一个Tomcat上，此时再从Memcached取Session的值。虽然Robbin说Apache的StickySession是在应用层做的分派，不是很稳定，我对此保持怀疑，因为StickySession的实现机制并不复杂，Apache这都会处理得不好?如果在大访问压力的情况下，造成Apache的StickySession不稳定，可以在前端用四层交换机做负载均衡，也是支持StickySession的。

2. Terracotta 和 Memcached的比较

Terracotta的优势：
1)不是通过对象序列化的方式传输，支持Field级别的变更同步。即一个4K的对象里的一个字段变更了，Terracotta只需要同步4bytes的数据，而不需要同步4k数据，大大减少网络流量。
2)无缝整合到应用里，通过自动监控POJO的变更实现JVM的同步，不像Memcached或JGroups等方案需要在程序显式调用某些方法如setAttribute或updateCache时，更新分布缓存。
3）和Memcached一样使用集中的缓存服务器，不像JGroups需要广播带来网络压力。
4）TC本身支持集群，避免单点故障。而Memcached则默认不支持集群，但可以自己实现。
缺点：
1）bytecode级监视，应该是通过AOP的方式实现，服务器性能可能因此而降低。
2）配置烦琐，不像Memcached那么简单。

个人倾向于使用Memcached，首先Memcached使用C开发，在只是维护Cache这么简单的应用里，Memcached的稳健性更强，只要内存够大，出问题的几率不大，集群的需求不是很强烈。其次，Memcached方案会有更大的网络流量，但是服务器的运算压力会更小。最后，配置简单是最吸引我的。