Memcached的定位

关于Memcached，主要说两点：
1，为什么会出现Memcached。
2，Memcached的定位。
让我们一一来分析。

1，为什么会出现Memcached。
据史料记载(http://en.wikipedia.org/wiki/Memcached)，第一代Memcached诞生于公元2003年5月，服务端由Danga Interactive
使用C语言开发，客户端可以使用任何语言来编写，它们之间通过socket通讯。
该软件用于提升LiveJournal.com访问速度。LJ每秒动态页面访问量几千次，用户700万。Memcached将数据库负载大幅度降低，更好的分配资源，更快速访问。
那么，在03年，当时的互联网是一个什么状态？当时的互联网技术又是一个怎样的状态？
俺不知道。谁能给点历史？
要想知道为什么要开发或使用Memcached，得从IO密集型说起。

IO密集型是指读写非常频繁，在短时间内呈现高并发的状态，使得性能下降。
IO密集型操作涉及客户端，中间层，服务端，因此可以从这三个点进行缓解：
a，减少客户端的请求。比如像秒杀这样的活动，是一个高并发的场景，可以在前面设一个临界值，超过临界值则给一个返回提示。
b，减少中间层的消耗，提升中间层的性能。比如使用mysql的handlersocket插件，它省去了很多多余的mysql操作，使得其查询性能比memcached快2倍，比mysql快7.5倍。
c，分离服务端的数据。将服务端的数据分离，则可以直接把IO给分离(即读写分离)，使得数据库的负载大大降低。

而从memcached的实际效果来看，它显然是分化了IO的读取请求，注意，是读取请求，而不是写。因为每次朝memcached写一次之后，还得朝数据库写一次以保持数据的一致，数据库的写入压力并未减少。
也就是说，memcached缓解的，是数据库的读取压力，这才是为什么要使用memcached的原因。


2，Memcached的定位是什么。
IT行业的本体是数据，而IT系统，不过是数据的载体。
这就好比我们人类社会，有着各自各样的楼房，但这些楼房主要是人居住的容器，人们在不同的建筑之间穿梭，就好比数据在不同的系统中出入一样。
因此考察一个系统的定位，总是以与其关联的数据为依据。
即首先考察该系统中数据的定位，然后才是系统本身的定位。

Memcached是处在传统关系数据库与应用服务之间的一个中间层。
从宏观层面看，它就像数据长河中的一个分支，与数据库这种大型“数据湖泊”相比，它就是一个小型湖泊。
由于其处于数据库层之上，因此其稳定性要低一些，数据的变动性更大，数据的生命周期也就更短了。
若排除Memcached与其它系统的关系，直接观察它，可以发现它只是一个数据容器。
数据按hash的方式放在这个容器里面，而且对数据的类型、大小、容量、生命周期都有所限定。
Memcached数据特点：
体积：Memcached的内存结构采用Slab Allocator机制，据说能避免内存碎片，而这也导致其只能存储小型数据(最大不能超过1M)。这个限制可以改。
周期：数据最多只能存活30天。当然这个限制也能改。
容量：由于其LRU也是建立在这个Slab Allocator机制上，导致了其容量过大时会有一个问题：命中率问题。即如果要存储达千万级的数据量，那么LRU时就可能出现问题，导致后面的数据覆盖前面已经添加的数据。当然可以通过某些调整基本解决这个问题。
分布：理论上是可以无限扩展。但Facebook在2008年已经有超过800台memcached服务器，他们已经发现了memcached存在的一些问题，他们称为Multiget Hole，即增加memcached服务器并不能增加处理容量。这个据说也有办法解决。
故可以得出Memcached中数据的一个定位(相对于数据库而言)：小型短命的活跃对象。
因此Memcached系统的定位也可以设定：小型大容量数据的分布式缓存系统。