|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-10-02
cenwenchu 写道 sdh5724 写道 我很喜欢MEMCACHED。 MEMCACHED非常的稳定， 我有一群机器， MEMCACHED进程已经运行运行了大约1年半了。 表现的算是比较稳定了。
cenwenchu 你说的情况， 我很明白， 就是利用一个不存在KEY去查询数据库， 很容易导致数据库搞跨。 我也在试图解决这个问题。 在理论上， 有很多技术能消除这个问题。 目前， 最流行的技术就 BloomFilter. 这东西能解决不存在的key造成性能的损耗的问题。 不过， 目前， 好像我们的应用没有遭受这样的攻击。 ..... 是的，这也是我封装它第一个目的，接口化，后端实现随时动态替换，只需要在自己实现的jar里面配置一个文件即可。因为我现在的产品比较特殊，是集成第三方服务的平台，自由开发者只需要注册一个开发应用即可使用淘宝，支付宝等API，所以不仅仅是自身安全问题，同时一旦被攻击，后端的服务也将会不能使用，因此才需要这样的考虑，第三方的我没有太多地去找，因为还是觉得有些东西简单化即可，搞太多的依赖反而维护成本会增加。 最近也想花点时间学习一下 memcache，这个帖子很有助益啊。 关于无效key的攻击，我不太了解 memcache 是否对此有办法处理；根据我项目中使用其他缓存方案的经验，如果没有，我想楼主反正也在封装，可以自己进行简单封装，对频繁访问的 但未命中的 key 进行特殊处理，（其实其他缓存像Ehcache据我目前用到的层次，还没有发现此功能） 例如：某段时间 T1 内连续访问次数达到N， miss 率达到 100%， 就为此 key设置一个虚值,比如：#NULL#, 并维持一段有效时间 T2。 举例： 30秒内， key： topicid=999999, 访问100次，miss率达到 100%，那么为此key， cache.put("topicid=999999","#NULL#") 该cache策略为 存活 10分钟。 那么，之后10分钟，因为无效key攻击而产生的后台数据库的压力应该可以避免了；如果在 web转发层的 http请求处也加上此策略控制，也可以避免web服务器的压力，具体看项目情况的选择了。 不过既然 sdh5724 同学说 BloomFilter 可以处理这个问题，那楼主不妨可以试试。 |
| 返回顶楼 | |
|
发表时间：2008-11-02
如果说 memcached 本身不支持集群，那么应该算是一大缺憾吧。
又看了一次主贴，结合对集群式cache方案的了解， 楼主做的实际上不但是 优化 那么简单了，算是个全新项目了，譬如叫： Memcached Cluster。 不过，个人观点， applicationA， B 应该只面对CacheManager了，而不再面对 Client了，而由 CacheManager 来管理整个集群。 这些可以参考一下Jboss cache， Coherence 等的设计思想。 |
| 返回顶楼 | |
|
发表时间：2008-11-05
robbin 写道 ehcache, jboss cache不适合互联网那种大规模分布式缓存应用场景。jboss cache你部署两台，四台还行，到八台，16台就已经非常勉强了，缓存同步的开销已经极端恐怖了。但是memcached的话，有些大型网站，例如facebook，是3000多台的规模在用。
jboss cache3将推出buddy replication。不过就算再加上partition，只要它死抱着事务和锁定这种重量级功能不放，性能肯定还是比不过memcached |
| 返回顶楼 | |
|
发表时间：2008-11-21
你的这个客户端在并发大的时候会出现java.io.IOException: ++++ socket or its streams already null in trueClose call
at com.alisoft.xplatform.asf.cache.memcached.client.SockIOPool$SockIO.trueClose(SockIOPool.java:2186) at com.alisoft.xplatform.asf.cache.memcached.client.SockIOPool.selfMaint(SockIOPool.java:1335) at com.alisoft.xplatform.asf.cache.memcached.client.SockIOPool$MaintThread.run(SockIOPool.java:1905) |
| 返回顶楼 | |
|
发表时间：2009-09-16
xianglei 写道 你的这个客户端在并发大的时候会出现java.io.IOException: ++++ socket or its streams already null in trueClose call
at com.alisoft.xplatform.asf.cache.memcached.client.SockIOPool$SockIO.trueClose(SockIOPool.java:2186) at com.alisoft.xplatform.asf.cache.memcached.client.SockIOPool.selfMaint(SockIOPool.java:1335) at com.alisoft.xplatform.asf.cache.memcached.client.SockIOPool$MaintThread.run(SockIOPool.java:1905) 这个问题可能是maintSleep设置太小了。 |
| 返回顶楼 | |
