Memcached是一个分布式Cache Server，提供了key-value型数据的缓存，支持LRU、数据过期淘汰，基于Slab的方式管理内存块，提供简单的set/get/delete等操作协议，本身具备了稳定、高性能等优点，并在业界已经得到广泛的验证。它的server端本身是一个单机版，而分布式特性是基于client端的实现来满足，通过部署多个Memcached节点，在client端基于一致性hash(或者其他hash策略)进行数据的分散路由，定位到具体的memcached节点再进行数据的交互。当某个节点挂掉后，对该节点进行摘除，并把该节点的请求分散到其他的节点。通过client来实现一定程度的容灾和伸缩的能力。
这种架构经过一段时间的蜜月期后，也逐步遇到了一些问题。
节点挂掉导致的瞬间的峰值问题
比如部署有5个Memcached节点，对key做一致性hash将key散落分布到5个节点上，那么如果其中有1个节点挂掉，那么这个时候会有20%原本Cache hit的请求穿透到后端资源(比如DB)。对于微博而言，多数核心资源的Cache hit的比例是99%，单组资源的QPS可能就达到100W以上的级别，如果这个时候有20%的穿透，那么相当于后端资源需要抗住20W以上的请求，这对于后端资源来说，明显压力过大。
某组资源请求量过大导致需要过多的节点
微博的Feed业务是Cache资源的消耗大户，几十万的QPS，GB(Byte)级别以上的带宽消耗，这个时候，至少需要十几个Memcached节点单元才能够抗住请求，而过多的Memcached节点请求会导致multiget的性能有弱化，因为这个时候keys分散到的Memcached节点会比较多，因此当进行拉取聚合的时候，性能会受影响，同时mutliget的响应时间受最慢的那个节点的影响，从而无法达到服务的SLA要求。
Cache的伸缩容和节点的替换动静太大
对于微博这种会在热点事件、节假日等发生时会有一些变态峰值(往往是数倍或者数十倍)的场景而言，实时的动态伸缩容很是必要，而因为通过client端实例化的Memcached资源节点相对比较固定，因此要进行伸缩容需要：
进行一次代码的线上变更，进行节点配置的变更，而如果依赖该某组资源的应用系统比较多，比如底层的认证资源，那么需要对多个业务系统变更，这一动静不可谓不小，特别是遇到紧急情况，这个会导致操作的执行很缓慢。
需要解决读写导致的一致性问题，假如有一些业务系统在读取Cache，有一些业务系统在写入Cache，而正常的变更是比较难让这些系统在某一刻全部执行节点的配置切换。
需要使用新的节点替换老的节点(比如更换物理机)，面临和上面类似的问题。
过多资源带来的运维问题
Cache资源组是按业务去申请，当业务特别多的时候，Cache资源组也会很多，这个时候要对这些资源进行运维管理如调整，将会变得不容易。而且随着时间的演进，一些比较古老的资源年老失修的情况，要进行运维调整就更为不容易。
Cache架构要用得好的复杂度
会用和用得好是两个不同概念。如果Cache架构需要每个业务开发很熟练才能够用得好，而不会因为Cache的不当使用而导致线上服务出现稳定性问题、以及成本的浪费等各种问题的话，这种对于需要陆续补进新人的团队现状而言，出问题将会是一种常态。 因此要解决这种问题，那么需要提供一种足够简单的Cache使用方式给业务应用方，简单到只有set/get/delete等基本命令的操作，而无需要他们关心底层的任何细节。
