Memcached有两个核心组件组成：服务端（ms）和客户端（mc），在一个memcached的查询中，mc先通过计算key的hash值来 确定kv对所处在的ms位置。当ms确定后，客户端就会发送一个查询请求给对应的ms，让它来查找确切的数据。因为这之间没有交互以及多播协议，所以 memcached交互带给网络的影响是最小化的。
举例说明：考虑以下这个场景，有三个mc分别是X，Y，Z，还有三个ms分别是A，B，C：
设置kv对
X想设置key=”foo”,value=”seattle”
X拿到ms列表，并对key做hash转化，根据hash值确定kv对所存的ms位置
B被选中了
X连接上B，B收到请求，把（key=”foo”,value=”seattle”）存了起来
获取kv对
Z想得到key=”foo”的value
Z用相同的hash算法算出hash值，并确定key=”foo”的值存在B上
Z连接上B，并从B那边得到value=”seattle”
其他任何从X，Y，Z的想得到key=”foo”的值的请求都会发向B
Memcached服务器(ms)
内存分配
默认情况下，ms是用一个内置的叫“块分配器”的组件来分配内存的。舍弃c++标准的malloc/free的内存分配，而采用块分配器的主要目的 是为了避免内存碎片，否则操作系统要花费更多时间来查找这些逻辑上连续的内存块（实际上是断开的）。用了块分配器，ms会轮流的对内存进行大块的分配，并 不断重用。当然由于块的大小各不相同，当数据大小和块大小不太相符的情况下，还是有可能导致内存的浪费。
同时，ms对key和data都有相应的限制，key的长度不能超过250字节，data也不能超过块大小的限制 --- 1MB。
因为 mc所使用的hash算法，并不会考虑到每个ms的内存大小。理论上mc会分配概率上等量的kv对给每个ms，这样如果每个ms的内存都不太一样，那可能 会导致内存使用率的降低。所以一种替代的解决方案是，根据每个ms的内存大小，找出他们的最大公约数，然后在每个ms上开n个容量=最大公约数的 instance，这样就等于拥有了多个容量大小一样的子ms，从而提供整体的内存使用率。
缓存策略
当ms的hash表满了之后，新的插入数据会替代老的数据，更新的策略是LRU（最近最少使用），以及每个kv对的有效时限。Kv对存储有效时限是在mc端由app设置并作为参数传给ms的。
同时ms采用是偷懒替代法，ms不会开额外的进程来实时监测过时的kv对并删除，而是当且仅当，新来一个插入的数据，而此时又没有多余的空间放了，才会进行清除动作。
Memcached客户端（mc）
Memcached客户端有各种语言的版本供大家使用，包括java，c，php，.net等等。
大家可以根据自己项目的需要，选择合适的客户端来集成。
缓存式的Web应用程序架构
有了缓存的支持，我们可以在传统的app层和db层之间加入cache层， 每个app服务器都可以绑定一个mc，每次数据的读取都可以从ms中取得，如果没有，再从db层读取。而当数据要进行更新时，除了要发送update的 sql给db层，同时也要将更新的数据发给mc，让mc去更新ms中的数据。