发表于： 2017-11-06 18:39:10
1 793
今日完成：
这个是把返回数据减少后的响应速度，确实是快了很多，我认为限制吞吐量的可能是网速，1m小水管传输速度有限，而服务器cpu和内存占用都不高。
查阅网上关于memcache的资料，大概了解其作用和概念，但还不能实现。
MemCache虽然被称为”分布式缓存”，但是MemCache本身完全不具备分布式的功能，MemCache集群之间不会相互通信（与之形成对比的，比如JBoss Cache，某台服务器有缓存数据更新时，会通知集群中其他机器更新缓存或清除缓存数据），所谓的”分布式”，完全依赖于客户端程序的实现。
其中有两种hash算法：
1.余数Hash
分配服务的方式是通过hashcode和服务器数目相除余数分配的，由于HashCode随机性比较强，所以使用余数Hash路由算法就可以保证缓存数据在整个MemCache服务器集群中有比较均衡的分布。在不修改服务器配置的前提下，余数hash算法可以满足打多数缓存路由需求，但如果要增加减少服务器时会出现可以无法命中的情况，因为整个序列会改变很多，而余数分配就是根据序列分配，所以会存在内存重新分配的情况，而在旧内存没被更新完之前他就一直占着位置，假设这个服务已经运行了很久，那要更换内存内的内容需要的时间可能比开机到现在的时间长，在内存信息更换前都是处于没有配置mencache的状态甚至更慢，毕竟分配服务也是需要时间的。
2.一致性Hash算法
一致性Hash算法通过一个叫做一致性Hash环的数据结构实现Key到缓存服务器的Hash映射。
具体算法过程为：先构造一个长度为232的整数环（这个环被称为一致性Hash环），根据节点名称的Hash值（其分布为[0, 232-1]）将缓存服务器节点放置在这个Hash环上，然后根据需要缓存的数据的Key值计算得到其Hash值（其分布也为[0, 232-1]），然后在Hash环上顺时针查找距离这个Key值的Hash值最近的服务器节点，完成Key到服务器的映射查找。
采用一致性Hash算法，虽然更改服务器的确也会影响到整个集群，但是影响的只是加粗的那一段而已，相比余数Hash算法影响了远超一半的影响率，这种影响要小得多。更重要的是，集群中缓存服务器节点越多，增加节点带来的影响越小，很好理解。换句话说，随着集群规模的增大，继续命中原有缓存数据的概率会越来越大，虽然仍然有小部分数据缓存在服务器中不能被读到，但是这个比例足够小，即使访问数据库，也不会对数据库造成太大的负载压力。
关于memcache工作原理
首先要说明一点，MemCache的数据存放在内存中，所以其访问数据的速度比传统的关系型数据库要快，因为Oracle、MySQL这些传统的关系型数据库为了保持数据的持久性，数据存放在硬盘中，IO操作速度慢。因为数据存放在内存中，所以只要memcache重启了数据就会刷新。
emCache采用的内存分配方式是固定空间分配，以下图为底说明：
这张图片里面涉及了slab_class、slab、page、chunk四个概念，它们之间的关系是：
1、MemCache将内存空间分为一组slab
2、每个slab下又有若干个page，每个page默认是1M，如果一个slab占用100M内存的话，那么这个slab下应该有100个page
3、每个page里面包含一组chunk，chunk是真正存放数据的地方，同一个slab里面的chunk的大小是固定的
4、有相同大小chunk的slab被组织在一起，称为slab_class
MemCache内存分配的方式称为allocator，slab的数量是有限的，几个、十几个或者几十个，这个和启动参数的配置相关。
MemCache中的value过来存放的地方是由value的大小决定的，value总是会被存放到与chunk大小最接近的一个slab中，比如slab[1]的chunk大小为80字节、slab[2]的chunk大小为100字节、slab[3]的chunk大小为128字节（相邻slab内的chunk基本以1.25为比例进行增长，MemCache启动时可以用-f指定这个比例），那么过来一个88字节的value，这个value将被放到2号slab中。放slab的时候，首先slab要申请内存，申请内存是以page为单位的，所以在放入第一个数据的时候，无论大小为多少，都会有1M大小的page被分配给该slab。申请到page后，slab会将这个page的内存按chunk的大小进行切分，这样就变成了一个chunk数组，最后从这个chunk数组中选择一个用于存储数据。
明日计划：
讲小课堂，继续学习memcache。
进度：
任务六
预计demo：
11.10
是否有延期风险：
不知
返回列表
评论