|
精华帖 (5) :: 良好帖 (9) :: 新手帖 (0) :: 隐藏帖 (13)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-11-08
yangguo 写道 每修改一次服务端数据，都会对所有客户端发出失效命令，有点像观察者模式。
服务器累得不行。 通知失效，不如直接更新缓存？ 不是对所有的客户端通知失效，只对对该数据感兴趣的客户端通知。local cache适合读比写多的情况。比如读写比率是3：1，在没有local cache的情况下server需要处理4X的请求，在有local cache的情况下只需要处理2X的请求。这意味着同样的server可以处理更多的请求。和原先比起来只会轻松很多^_^ 通知失效，一般情况更好。有以下考虑: 1. 通知失效更快，因为只需要很少的数据放送。数据本身可能很大，通知就需要很多时间。这样一致性的缺口就更大，而且不好预测。 2. 通知失效现在只发生CacheID,可以进行批量发送。即把当前所有通知信息在一个请求中发送给客户端。 3. 客户端可能已经对这个数据不感兴趣了，以后也不会访问了。这时候更新缓存就浪费了。 |
| 返回顶楼 | |
|
发表时间：2011-11-08
wl95421 写道 如果是通知机制，肯定只适合写少读多的场景，比如说1:10000这样级别，否则的话，光一致性保持的开销，就足够吐血的了。
是的，local cache适合写少读多的场景。事实上大多数cache系统都是适合写少读多。比如我们在db 之前放一个memcached，肯定是认为读比写多。要不还不如直接写db。 1:10000不需要这么夸张^_^。即使是1:2使用local cache就能提高很大的性能了。local cache维护的开销是不大的。 |
| 返回顶楼 | |
|
发表时间：2011-11-08
agapple 写道 local cache的实现有点类似于zookeeper的watcher，即使1ms的延迟，对于一些并发高或者读写分离的应用来说可能也会是一个致命的问题。
LZ可以考虑一下支持paxos一致性算法，让客户自己选用。强一致性选择有成本，选用需谨慎，呵呵 不过LZ的方案不失为一个cache的好方案，像以前使用kv/cache缺少一个主动推送的功能，所以经常自己做一层内存cache，设置过期时间，两者不一致性问题比较麻烦 paxos慢啊^_^而且zookeeper在某种情况下也不能保证强一致性。强一致性有些时候是非常重要，Xixibase以后会增强local cache的一致性和整个系统的高可用性。希望有比paxos更好的算法，否则。。。 |
| 返回顶楼 | |
|
发表时间：2011-11-09
yeaya 写道 yangguo 写道 每修改一次服务端数据，都会对所有客户端发出失效命令，有点像观察者模式。
服务器累得不行。 通知失效，不如直接更新缓存？ 不是对所有的客户端通知失效，只对对该数据感兴趣的客户端通知。local cache适合读比写多的情况。比如读写比率是3：1，在没有local cache的情况下server需要处理4X的请求，在有local cache的情况下只需要处理2X的请求。这意味着同样的server可以处理更多的请求。和原先比起来只会轻松很多^_^ 通知失效，一般情况更好。有以下考虑: 1. 通知失效更快，因为只需要很少的数据放送。数据本身可能很大，通知就需要很多时间。这样一致性的缺口就更大，而且不好预测。 2. 通知失效现在只发生CacheID,可以进行批量发送。即把当前所有通知信息在一个请求中发送给客户端。 3. 客户端可能已经对这个数据不感兴趣了，以后也不会访问了。这时候更新缓存就浪费了。 相对于这种实现，用消息中间件更好。例如 ActiveMQ |
| 返回顶楼 | |
|
发表时间：2011-11-09
楼主想法不错，而且开发出了我一直想实现的东西，非常好。
之前一直没有使用memcache就是因为远端集中cache需要消耗网络时间，最快的还是localcache |
| 返回顶楼 | |
|
发表时间：2011-11-09
CurrentJ 写道 楼主想法不错，而且开发出了我一直想实现的东西，非常好。
之前一直没有使用memcache就是因为远端集中cache需要消耗网络时间，最快的还是localcache 你也可以将memcached放在本地啊 |
| 返回顶楼 | |
|
发表时间：2011-11-09
yangguo 写道 yeaya 写道 yangguo 写道 每修改一次服务端数据，都会对所有客户端发出失效命令，有点像观察者模式。
服务器累得不行。 通知失效，不如直接更新缓存？ 不是对所有的客户端通知失效，只对对该数据感兴趣的客户端通知。local cache适合读比写多的情况。比如读写比率是3：1，在没有local cache的情况下server需要处理4X的请求，在有local cache的情况下只需要处理2X的请求。这意味着同样的server可以处理更多的请求。和原先比起来只会轻松很多^_^ 通知失效，一般情况更好。有以下考虑: 1. 通知失效更快，因为只需要很少的数据放送。数据本身可能很大，通知就需要很多时间。这样一致性的缺口就更大，而且不好预测。 2. 通知失效现在只发生CacheID,可以进行批量发送。即把当前所有通知信息在一个请求中发送给客户端。 3. 客户端可能已经对这个数据不感兴趣了，以后也不会访问了。这时候更新缓存就浪费了。 相对于这种实现，用消息中间件更好。例如 ActiveMQ 同感。 |
| 返回顶楼 | |
|
发表时间：2011-11-09
yeaya 写道 evanzzy 写道 用Memcache这种集中式的cache，就是要避免数据一致性问题，LocalCache是不能满足要求的。最简单的LocalCache就是弄个map自己在那儿查，有什么意义么？有点标题党的味道了
local cache的数据和server端和其他客户端的local cache的数据是一致的。在某一数据被修改、删除或者过期之后，Xixibase server会立即通知对应的客户端删除local cache中对应的数据。这个时间是非常快的，局域网内是毫秒级。还有local cache是封装在Xixibase Client中的，外部调用只要使用简单的API就可以。 用Server作为通知服务器，那Server的集群怎么做？如果单点的Server失败，会造成全局的缓存错误 |
| 返回顶楼 | |
|
发表时间：2011-11-09
萝卜白菜各有所需啊 对读的数据多的且对一致性没有百分之百要求的 我觉得楼主的这个东西是很好的解决方案 有些情况下确实是不合适的
|
| 返回顶楼 | |
|
发表时间：2011-11-09
yangguo 写道 yeaya 写道 yangguo 写道 每修改一次服务端数据，都会对所有客户端发出失效命令，有点像观察者模式。
服务器累得不行。 通知失效，不如直接更新缓存？ 不是对所有的客户端通知失效，只对对该数据感兴趣的客户端通知。local cache适合读比写多的情况。比如读写比率是3：1，在没有local cache的情况下server需要处理4X的请求，在有local cache的情况下只需要处理2X的请求。这意味着同样的server可以处理更多的请求。和原先比起来只会轻松很多^_^ 通知失效，一般情况更好。有以下考虑: 1. 通知失效更快，因为只需要很少的数据放送。数据本身可能很大，通知就需要很多时间。这样一致性的缺口就更大，而且不好预测。 2. 通知失效现在只发生CacheID,可以进行批量发送。即把当前所有通知信息在一个请求中发送给客户端。 3. 客户端可能已经对这个数据不感兴趣了，以后也不会访问了。这时候更新缓存就浪费了。 相对于这种实现，用消息中间件更好。例如 ActiveMQ 太慢了 |
| 返回顶楼 | |
