Memcached memory allocation principles introduced
Memcached master installation, use the command, in fact, for most students, it is sufficient to carry out related development work. But encounter some problems when online, will use Memcached is simply not fast, rational analysis of the problem. So next we will introduce the principle of Memcached memory allocation management.
Under Memcached uses a default allocation mechanism called Slab Allocator, manage memory. Slab Allocator is the basic principle in accordance with a predetermined size, the allocated memory is divided into blocks of a certain length, in order to completely solve the problem of memory fragmentation.
Before introduce memcached memory allocation principle, we need to explain the concept with the following key terms of:
item
A storage element to be calculated according to the size of bytes, can be understood as an article
Chunk
Cache memory space for the item. It can be understood as a storage compartment
Slab Class
chunk the size of a particular group. It can be understood as a storage compartment for classified by size, such as a class 80B, 96B ... as a class.
Page
Slab class assigned to the memory space, the default is 1MB. After Slab into chunk assigned according to the size of the cut slab class. A page can be understood as a fixed-size cabinet, according to the above may be divided slab class, a cabinet can only be divided by a slab class. Grid number in the cabinet is the cabinet size / size of the storage compartment
After a few basic concepts introduced above, we can take a look at mc when allocating memory of how to deal with.
FIG 1 memcached schematic Initialization
1 is a memcached example of some of the parameters at start can be designated as a starting initial size of the slab class size, a growth factor for the next slab class is a multiple of the initial factor. As shown, the initial size is 80B, a growth factor of 1.5. After starting the mc, will press the slab class table map generation.
FIG 2 slab profile
完成初始后，当某一个请求到来的时候——如图中所示由一个123B大小的元素希望找到存储空间，memcached会通过slab class表找到最合适的slab class：比元素大的最少的那个，在图中场景下为180B，即使所需的空间只要123B。
此时Memcached示例并没有分配任何的空间给180B的slab进行管理。所以为了能让请求的元素能存储上，Memcached实例会分配1 个page给180这个slab（在默认情况下为1MB实际内存）。
图 3 page分配图
180B slab class在获取到1MB的空间后，会按照自己的大小对page进行分隔，也即1MB/180=5828个具体的存储空间（chunk）。此时，123B的请求就可以被存储起来了。
随着时间的慢慢推移，memcached的内存空间会逐步被分配完，如下图4所示：
图 4内存slab分配图
我们可以看到，memcached划分给每个slab的page数是不均等的，存在部分的slab是可能一个page都分配不到的。
假设所有的内存都分配完，同时每个slab内部的chunk也都分配完了。此时又来了一个新的元素123B，那么就会触发memcached的淘汰机制了。
memcached首先会查看180B的slab是否存在过期的元素，如果存在，则先清理部分，预留空位。如果180B这个slab的数据都比较热（没有过期），则按LRU进行淘汰。需要注意的是，淘汰是在slab内部进行的，也即在上面的场景中只有180Bslab内部进行淘汰剔除，对于其他的slab，是没有受到影响的。memcached也不会回收比较空余的其他slab的page。也即一个page被分配给某个slab后，他将一直被这个slab所占用，永远无法被mc回收，直到memcached重启。
这个特性被称为Memcached的钙化问题：Memcached在线上跑了一段时间后，内存按原始访问模式分配内存。当访问模式变更后，原有的分配模式可能导致缓存频繁出现数据剔除问题。最典型的场景即为内存尚有空余，但一直有数据被剔除，命中率一直上不去。对于这种情况，解决方法为重启缓存。
主从双层结构
高并发&高可用
主从双层结构
通过数据分片，将mc从单台实例增加到一组缓存后，我们可以解决单端口容量、访问量不足的问题，但是如果出现某一台缓存挂了的情况。请求依然会落到后端的DB上。可以通过一致性hash的方式，来减少损失。
但基于一致性哈希策略的分布式实现在微博业务场景下也存在一些问题：
（1）微博线上业务对缓存命中率要求高。某台缓存挂了，会导致缓存整体命中率下降（即使一致性hash会在一定时间后将数据重新种到另一个节点上），对于命中率要求在99%以上的Feed流核心业务场景来说，命中率的下降是难以接受的
（2）一致性hash存在请求漂移的情况，假设某一段时间服务因网络因素访问某个服务节点失败，则在这时候，会将数据的更新、获取都迁移到下一个节点上。后续网络恢复后，应用服务探测到服务节点可用，则继续从原服务节点中获取数据，这就导致了在故障期间所做的更新操作，对于原服务节点不可见了
目前我们对于这种单点问题主要是通过引入主从缓存结构来解决的。主从结构示意图如下图5所示：
图 5主从双层结构缓存
服务端在上行逻辑中，进行双写操作——由应用服务负责更新master、slave数据。
下行获取数据，先获取master数据，当master返回空，或者无法取到数据的时候，访问slave。
在这种模式下，为了避免两份数据带来的不一致问题，需要以master数据为准。即如果有更新数据操作，需要从master中获取数据，再对master进行cas更新。更新成功后，才更新slave。如果cas多次后都失败，则对master、slave进行delete操作，后续让请求穿透回种即可。
横向线性扩展
在双层结构下，我们可以很好的解决单点问题，即某一个节点如果crash了，请求可以被slave承接住，请求不会直接落在DB上。
但这种架构仍然存在一些问题：
（1）带宽问题。由于存在热点访问的情况，线上经常出现单个服务节点的带宽跑满的情况。
（2）请求量问题。随着业务的不断发展，并发请求数超过了单个节点的机器上限。数据分片、双层结构都不能解决这种问题。
上面的两个问题，其实总结起来是如何快速横向扩展系统的支撑能力。对于这个问题，我们的解决思路为增加数据的副本数。即让数据副本存在于多个节点中，从而平摊原本落在一个节点的请求。
从我们经验来看，对于线性扩展，可以在原来的master上引入一层L1层缓存。整体示意图如6所示：
图6采用L1的缓存架构
上行操作需要对L1进行多写。写缓存的顺序为master-slave-L1(所有)，写失败则进行delete操作，后续由穿透请求进行回种。
L1可以由多组缓存组成，每组缓存相互独立。应用服务在获取数据的时候，先从L1中选取一组资源，然后再进行hash选取特定节点。对于multiget的场景也是先选取一组缓存，然后才对这组缓存进行multiget操作。如果L1获取不到数据，再依次获取master、slave数据。获取成功，则回种到L1中。
在采用L1的模式中，数据也是以master中数据为主的。即如果有更新数据的需要，需要从master中获取数据原本，再进行cas更新。如果cas更新成功，才同时更新slave、L1资源。如果对master的操作失败，则进行delete all操作，让后续请求穿透回种。
当线上流量、请求量达到一个水位的时候，我们会进行L1的扩容——增加一组、或几组L1缓存，从而提升系统整体的承载能力。此时系统的整体响应请求量是可以做到线性扩展的。
Can be seen, the two-layer structure, slave is present as the primary backup. Suppose online master cache hit rate of 99%, on the request of the slave falls only 1%, and that 1% of the requests are very biased, few people to access. Imagine, in this case, if the master problem does occur, the request fell on all the slave, slave is no data available for access. Slave measure as an anti-single-point failure.
After the introduction of L1, slave too cold and has not been resolved, at the same time, because the master is placed below the L1, also encountered problems slave, the risk of cold master data also existed. To solve the above problem, when we configure online, it will send the entire group L1 slave as a set of resources to be configured, so that slave bear the heat request part of the identity of L1. Meanwhile, in order to solve the master too cold, we also make application services in select L1 when there is a certain probability fall, so that the master L1 as a logical grouping, to take part of the heat request. FIG overall configuration shown in Figure 7:
FIG 7 slave, master architecture as both L1