这里需要说明,很多开发者觉得?Memcached?是一种分布式?Cache?,但其实?Memcached?服务端本身是单实例的,只是在客户端实现过程中可以根据存储的主键作分区存储,而这个区就是?Memcached?服务端的一个或者多个实例,如果将客户端也囊括到?Memcached?中,那么可以部分概念上说是集中式的。集中式的构架,无非两种情况:
1.?节点均衡的网状(?**oss Tree Cache?),利用?JGroup?的多播通信机制来同步数据。
2.Master-Slaves?模式(分布式文件系统),由?Master?来管理?Slave?,如何选择?Slave?,如何迁移数据,都是由?Master?来完成,但是?Master?本身也存在单点问题。
内存存储,速度快,对于内存的要求高,所缓存的内容非持久化。对于?CPU?要求很低,所以常常采用将?Memcached?服务端和一些?CPU?高消耗?Memory?低消耗应用部属在一起?。(否则会互相挤占资源)
避开了分布式?Cache?的传播问题,但是需要非单点保证其可靠性,这需要?cluster?的工作,可以将多个?Memcached?作为一个虚拟的?cluster?,同时对于?cluster?的读写和普通的?memcached?的读写性能没有差别。
Memcached?很突出的一个优点,就是采用了可分布式扩展的模式。可以将部属在一台机器上的多个?Memcached?服务端或者部署在多个机器上的?Memcached?服务端组成一个虚拟的服务端,对于调用者来说完全屏蔽和透明。提高的单机器的内存利用率?。
传输内容的大小以及序列化的问题需要注意,虽然?Memcached?通常会被放置到内网作为?Cache,?Socket?传输速率应该比较高(当前支持?Tcp?和?udp?两种模式,同时根据客户端的不同可以选择使用?nio?的同步或者异步调用方式),但是序列化成本和带宽成本还是需要注意。这里也提一下序列化,对于对象序列化的性能往往让大家头痛,但是如果对于同一类的?Class?对象序列化传输,第一次序列化时间比较长,后续就会优化,其实也就是说序列化最大的消耗不是对象序列化,而是类的序列化。如果穿过去的只是字符串,那么是最好的,省去了序列化的操作,因此在?Memcached?中保存的往往是较小的内容?。
首先要说明的是?Memcached?支持最大的存储对象为?1M?(page)。它的内存分配比较特殊,但是这样的分配方式其实也是对于性能考虑的,简单的分配机制可以更容易回收再分配,节省对于?CPU?的使用(前面的文章中有描述)?。
首先它没有什么同步,消息分发,两阶段提交等等,它就是一个很简单的?Cache?,把东西放进去,然后可以取出来,如果发现所提供的?Key?没有命中,那么就很直白的告诉你,你这个?key?没有任何对应的东西在缓存里,去数据库或者其他地方取,当你在外部数据源取到的时候,可以直接将内容置入到?Cache?中,这样下次就可以命中了?。这里会提到怎么去同步这些数据,两种方式,一种就是在你修改了以后立刻更新?Cache内容,这样就会即时生效。另一种是说容许有失效时间,到了失效时间,自然就会将内容删除,此时再去去的时候就会命中不了,然后再次将内容置入?Cache?,用来更新内容。后者用在一些时时性要求不高,写入不频繁的情况。
客户端设计的合理十分重要,同时也给使用者提供了很大的空间去扩展和设计客户端来满足各种场景的需要,包括容错,权重,效率,特殊的功能性需求,嵌入框架等等。
小对象的缓存(用户的?token?,权限信息,资源信息)。小的静态资源缓存。?Sql?结果的缓存(这部分用的好,性能提高相当大。)