分布式缓存lru算法

Ⅰ 京东面试官：Redis 这些我必问

缓存好处：高性能 + 高并发

数据库查询耗费了800ms，其他用户对同一个数据再次查询 ，假设该数据在10分钟以内没有变化过，并且 10 分钟之内有 1000 个用户 都查询了同一数据，10 分钟之内，那 1000 每个用户，每个人查询这个数据都感觉很慢 800ms
比如 ：某个商品信息，在 一天之内都不会改变，但是这个商品每次查询一次都要耗费2s，一天之内被浏览 100W次
mysql 单机也就 2000qps,缓存单机轻松几万几十万qps,单机 承载并发量是 mysql 单机的几十倍。

在中午高峰期，有 100W 个用户访问系统 A，每秒有 4000 个请求去查询数据库，数据库承载每秒 4000 个请求会宕机，加上缓存后，可以 3000 个请求走缓存 ，1000 个请求走数据库。
缓存是走内存的，内存天然可以支撑4w/s的请求，数据库（基于磁盘）一般建议并发请求不要超过 2000/s

redis 单线程 ，memcached 多线程
redis 是单线程 nio 异步线程模型

一个线程+一个队列

redis 基于 reactor 模式开发了网络事件处理器，这个处理器叫做文件事件处理器，file event handler，这个文件事件处理器是单线程的，所以redis 是单线程的模型，采用 io多路复用机制同时监听多个 socket,根据socket上的事件来选择对应的事件处理器来处理这个事件。
文件事件处理器包含：多个 socket,io多路复用程序，文件事件分派器，事件处理器（命令请求处理器、命令恢复处理器、连接应答处理器）
文件事件处理器是单线程的，通过 io 多路复用机制监听多个 socket，实现高性能和线程模型简单性
被监听的 socket 准备好执行 accept,read,write,close等操作的时候，会产生对应的文件事件，调用之前关联好的时间处理器处理
多个 socket并发操作，产生不同的文件事件，i/o多路复用会监听多个socket，将这些 socket放入一个队列中排队。事件分派器从队列中取出socket给对应事件处理器。
一个socket时间处理完后，事件分派器才能从队列中拿到下一个socket，给对应事件处理器来处理。

文件事件：
AE_READABLE 对应 socket变得可读（客户端对redis执行 write操作）
AE_WRITABLE 对应 socket 变得可写（客户端对 redis执行 read操作）
I/O 多路复用可以同时监听AE_REABLE和 AE_WRITABLE ，如果同时达到则优先处理 AE_REABLE 时间
文件事件处理器：
连接应答处理器 对应 客户端要连接 redis
命令请求处理器 对应 客户端写数据到 redis
命令回复处理器 对应 客户端从 redis 读数据

流程：

一秒钟可以处理几万个请求

普通的 set,get kv缓存

类型 map结构，比如一个对象（没有嵌套对象）缓存到 redis里面，然后读写缓存的时候，可以直接操作hash的字段（比如把 age 改成 21，其他的不变）
key=150
value = {

}

有序列表 ，元素可以重复
可以通过 list 存储一些列表型数据结构，类似粉丝列表，文章评论列表。
例如：微信大 V的粉丝，可以以 list 的格式放在 redis 里去缓存
key=某大 V value=[zhangsan,lisi,wangwu]
比如 lrange 可以从某个元素开始读取多少个元素，可以基于 list 实现分页查询功能，基于 redis实现高性能分页，类似微博下来不断分页东西。
可以搞个简单的消息队列，从 list头怼进去（lpush），list尾巴出来 (brpop)

无序集合，自动去重
需要对一些数据快速全局去重，（当然也可以基于 HashSet，但是单机）
基于 set 玩差集、并集、交集的操作。比如：2 个人的粉丝列表整一个交集，看看 2 个人的共同好友是谁？
把 2 个大 V 的粉丝都放在 2 个 set中，对 2 个 set做交集（sinter）

排序的 set，去重但是可以排序，写进去的时候给一个分数，自动根据分数排序

排行榜：

zadd board score username

例如：
zadd board 85 zhangsan
zadd board 72 wangwu
zadd board 96 lis
zadd board 62 zhaoliu

自动排序为：
96 lisi
85 zhangsan
72 wangwu
62 zhaoliu

获取排名前 3 的用户 ： zrevrange board 0 3
96 lisi
85 zhangsan
72 wangwu

查看zhaoliu的排行 ：zrank board zhaoliu 返回 4

内存是宝贵的，磁盘是廉价的
给key设置过期时间后，redis对这批key是定期删除+惰性删除
定期删除：
redis 默认每隔 100ms随机抽取一些设置了过期时间的 key，检查其是否过期了，如果过期就删除。
注意：redis是每隔100ms随机抽取一些 key来检查和删除，而不是遍历所有的设置过期时间的key（否则CPU 负载会很高，消耗在检查过期 key 上）
惰性删除：
获取某个key的时候， redis 会检查一下，这个key如果设置了过期时间那么是否过期，如果过期了则删除。
如果定期删除漏掉了许多过期key，然后你也没及时去查，也没走惰性删除，如果大量过期的key堆积在内存里，导致 redis 内存块耗尽，则走内存淘汰机制。

内存淘汰策略：

LRU 算法：

缓存架构（多级缓存架构、热点缓存）
redis 高并发瓶颈在单机，读写分离，一般是支撑读高并发，写请求少，也就 一秒一两千，大量请求读，一秒钟二十万次。

一主多从，主负责写，将数据同步复制到其他 slave节点，从节点负责读，所有读的请求全部走从节点。主要是解决读高并发。、
主从架构->读写分离->支撑10W+读QPS架构

master->slave 复制，是异步的
核心机制：

master持久化对主从架构的意义：
如果开启了主从架构，一定要开启 master node的持久化，不然 master宕机重启数据是空的，一经复制，slave的数据也丢了

主从复制原理：

第一次启动或者断开重连情况：

正常情况下：
master 来一条数据，就异步给 slave

全年 99.99%的时间，都是出于可用的状态，那么就可以称为高可用性
redis 高可用架构叫故障转移，failover，也可以叫做主备切换，切换的时间不可用，但是整体高可用。
sentinal node(哨兵)

作用：

quorum = 1 （代表哨兵最低个数可以尝试故障转移，选举执行的哨兵）
master 宕机，只有 S2 存活，因为 quorum =1 可以尝试故障转移，但是没达到 majority =2 （最低允许执行故障转移的哨兵存活数）的标准，无法执行故障转移

如果 M1 宕机了，S2,S3 认为 master宕机，选举一个执行故障转移，因为 3 个哨兵的 majority = 2，所以可以执行故障转移

丢数据：

解决方案：

sdown 主观宕机，哨兵觉得一个 master 宕机（ping 超过了 is-master-down-after-milliseconds毫秒数）
odown 客观宕机，quorum数量的哨兵都觉得 master宕机
哨兵互相感知通过 redis的 pub/sub系统，每隔 2 秒往同一个 channel里发消息（自己的 host,ip,runid），其他哨兵可以消费这个消息
以及同步交换master的监控信息。
哨兵确保其他slave修改master信息为新选举的master
当一个 master被认为 odown && marjority哨兵都同意，那么某个哨兵会执行主备切换，选举一个slave成为master（考虑 1. 跟master断开连接的时长 2. slave 优先级 3.复制 offset 4. runid）
选举算法：

quorum 数量哨兵认为odown->选举一个哨兵切换->获得 majority哨兵的授权（quorum majority 需要 majority个哨兵授权，quorum >= majority 需要 quorum 哨兵授权）
第一个选举出来的哨兵切换失败了，其他哨兵等待 failover-time之后，重新拿confiuration epoch做为新的version 切换，保证拿到最新配置，用于 configuration传播（通过 pu/sub消息机制，其他哨兵对比 version 新旧更新 master配置）

高并发：主从架构
高容量：Redis集群，支持每秒几十万的读写并发
高可用：主从+哨兵

持久化的意义在于故障恢复数据备份（到其他服务器）+故障恢复（遇到灾难，机房断电，电缆被切）

AOF 只有一个，Redis 中的数据是有一定限量的，内存大小是一定的,AOF 是存放写命令的，当大到一定的时候，AOF 做 rewrite 操作，就会基于当时 redis 内存中的数据，来重新构造一个更小的 AOF 文件，然后将旧的膨胀很大的文件给删掉，AOF 文件一直会被限制在和Redis内存中一样的数据。AOF同步间隔比 RDB 小，数据更完整

优点：

缺点：

AOF 存放的指令日志，数据恢复的时候，需要回放执行所有指令日志，RDB 就是一份数据文件，直接加载到内存中。

优点：

缺点：

AOF 来保证数据不丢失，RDB 做不同时间的冷备

支持 N 个 Redis master node,每个 master node挂载多个 slave node
多master + 读写分离 + 高可用

数据量很少，高并发 -> replication + sentinal 集群
海量数据 + 高并发 + 高可用 -> redis cluster

hash算法->一致性 hash 算法-> redis cluster->hash slot算法

redis cluster :自动对数据进行分片，每个 master 上放一部分数据，提供内置的高可用支持，部分master不可用时，还是可以继续工作
cluster bus 通过 16379进行通信，故障检测，配置更新，故障转移授权，另外一种二进制协议，主要用于节点间进行高效数据交换，占用更少的网络带宽和处理时间

key进行hash，然后对节点数量取模，最大问题只有任意一个 master 宕机，大量数据就要根据新的节点数取模，会导致大量缓存失效。

key进行hash，对应圆环上一个点，顺时针寻找距离最近的一个点。保证任何一个 master 宕机，只受 master 宕机那台影响，其他节点不受影响，此时会瞬间去查数据库。
缓存热点问题：
可能集中在某个 hash区间内的值特别多，那么会导致大量的数据都涌入同一个 master 内，造成 master的热点问题，性能出现瓶颈。
解决方法：
给每个 master 都做了均匀分布的虚拟节点，这样每个区间内大量数据都会均匀的分布到不同节点内，而不是顺时针全部涌入到同一个节点中。

redis cluster 有固定 16384 个 hash slot,对每个key计算 CRC16 值，然后对16384取模，可以获取 key对应的 hash slot
redis cluster 中每个 master 都会持有部分 slot ,当一台 master 宕机时候，会最快速度迁移 hash slot到可用的机器上（只会短暂的访问不到）
走同一个 hash slot 通过 hash tag实现

集群元数据：包括 hashslot->node之间的映射表关系，master->slave之间的关系，故障的信息
集群元数据集中式存储（storm），底层基于zookeeper（分布式协调中间件）集群所有元数据的维护。好处：元数据的更新和读取，时效性好，一旦变更，其他节点立刻可以感知。缺点：所有元数据的更新压力全部集中在一个地方，可能会导致元数据的存储有压力。
goosip: 好处：元数据的更新比较分散，有一定的延时，降低了压力。缺点：更新有延时，集群的一些操作会滞后。（reshared操作时configuration error）

自己提供服务的端口号+ 10000 ，每隔一段时间就会往另外几个节点发送ping消息，同时其他几点接收到ping之后返回pong

故障信息，节点的增加和移除， hash slot 信息

meet:某个节点发送 meet给新加入的节点，让新节点加入集群中，然后新节点就会开始于其他节点进行通信
ping:每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据
ping:返回ping和meet，包含自己的状态和其他信息
fail:某个节点判断另一个节点fail之后，就发送 fail 给其他节点，通知其他节点，指定的节点宕机了

ping 很频繁，且携带元数据，会加重网络负担
每个节点每秒会执行 10 次 ping，每次选择 5 个最久没有通信的其他节点
当如果发现某个节点通信延迟达到了 cluster_node_timeout /2 ，那么立即发送 ping， 避免数据交换延迟过长，落后时间太长（2 个节点之间 10 分钟没有交换数据，整个集群处于严重的元数据不一致的情况）。
每次ping，一个是带上自己的节点信息，还有就是带上1/10其他节点的信息，发送出去，进行数据交换
至少包含 3 个其他节点信息，最多包含总节点-2 个其他节点的信息

客户端发送到任意一个redis实例发送命令，每个redis实例接受到命令后，都会计算key对应的hash slot，如果在本地就本地处理，否则返回moved给客户端，让客户端进行重定向 （redis-cli -c）

通过tag指定key对应的slot,同一个 tag 下的 key，都会在一个 hash slot中，比如 set key1:{100} 和 set key2:{100}

本地维护一份hashslot->node的映射表。
JedisCluster 初始化的时候，随机选择一个 node，初始化 hashslot->node 映射表，同时为每个节点创建一个JedisPool连接池，每次基于JedisCluster执行操作，首先JedisCluster都会在本地计算key的hashslot，然后再本地映射表中找到对应的节点，如果发现对应的节点返回moved，那么利用该节点的元数据，更新 hashslot->node映射表（重试超过 5 次报错）

hash slot正在迁移，那么会返回ask 重定向给jedis,jedis 接受到ask重定向之后，，会重定向到目标节点去执行

判断节点宕机：
如果一个节点认为另外一个节点宕机了， 就是pfail,主观宕机
如果多个节点都认为另外一个节点宕机了，那么就是fail，客观宕机（跟哨兵原理一样）
在cluster-node-timeout内，某个节点一直没有返回 pong,那么就被认为是 pfail
如果一个节点认为某个节点pfail了，那么会在gossip消息中，ping给其他节点，如果超过半数的节点认为pfail了，那么就会变成fail。
从节点过滤：
对宕机的 mster node ，从其所有的 slave node中，选择一个切换成 master node
检查每个 slave node与master node断开连接的时间，如果超过了cluster-node-timeout * cluster-slave-validity-factor，那么就没资格切换成 master（和哨兵一致）
从节点选举：
每个从节点，根据自己对 master 复制数据的 offset，设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，所有的 master node 开始投票，给要进行选举的 slave进行投票，如果大部分 master node(N/2 +1) 都投票给某个从节点，那么选举通过，从节点执行主备切换，从节点切换成主节点
总结：和哨兵很像，直接集成了 replication 和 sentinal

方案：
事前：保证 redis 集群高可用性 （主从+哨兵或 redis cluster），避免全盘崩溃
事中：本地 ehcache 缓存 + hystrix 限流（保护数据库） & 降级，避免 MySQL被打死
事后： redis持久化，快速恢复缓存数据，继续分流高并发请求

限制组件每秒就 2000 个请求通过限流组件进入数据库，剩余的 3000 个请求走降级，返回一些默认 的值，或者友情提示
好处 ：

4000 个请求黑客攻击请求数据库里没有的数据
解决方案：把黑客查数据库中不存在的数据的值，写到缓存中，比如： set -999 UNKNOWN

读的时候，先读缓存，缓存没有，就读数据库，然后取出数据后放入缓存，同时返回响应
更新的时候，删除缓存，更新数据库
为什么不更新缓存：
更新缓存代价太高（更新 20 次，只读 1 次），lazy思想，需要的时候再计算，不需要的时候不计算

方案：先删除缓存，再修改数据库

方案：写，读路由到相同的一个内存队列（唯一标识，hash，取模）里，更新和读操作进行串行化（后台线程异步执行队列串行化操作），（队列里只放一个更新查询操作即可，多余的过滤掉，内存队列里没有该数据更新操作，直接返回 ）有该数据更新操作则轮询取缓存值，超时取不到缓存值，直接取一次数据库的旧值

TP 99 意思是99%的请求可以在200ms内返回
注意点：多个商品的更新操作都积压在一个队列里面（太多操作积压只能增加机器），导致读请求发生大量的超时，导致大量的读请求走数据库
一秒 500 写操作，每200ms，100 个写操作，20 个内存队列，每个队列积压 5 个写操作，一般在20ms完成

方案：分布式锁 + 时间戳比较

10台机器，5 主 5 从，每个节点QPS 5W ，一共 25W QPS（Redis cluster 32G + 8 核 ，Redis 进程不超过 10G）总内存 50g，每条数据10kb，10W 条数据1g，200W 条数据 20G，占用总内存不到50%，目前高峰期 3500 QPS

作者： mousycoder

Ⅱ 谈谈redis，memcache，mongodb的区别和具体应用场景

从以下几个维度，对 redis、memcache、mongoDB 做了对比。
1、性能
都比较高，性能对我们来说应该都不是瓶颈。
总体来讲，TPS 方面 redis 和 memcache 差不多，要大于 mongodb。
2、操作的便利性
memcache 数据结构单一。（key-value）
redis 丰富一些，数据操作方面，redis 更好一些，较少的网络 IO 次数，同时还提供 list，set，
hash 等数据结构的存储。
mongodb 支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富。
3、内存空间的大小和数据量的大小
redis 在 2.0 版本后增加了自己的 VM 特性，突破物理内存的限制；可以对 key value 设置过
期时间（类似 memcache）
memcache 可以修改最大可用内存,采用 LRU 算法。Memcached 代理软件 magent，比如建立
10 台 4G 的 Memcache 集群，就相当于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b
10.1.2.3:14000 mongoDB 适合大数据量的存储，依赖操作系统 VM 做内存管理，吃内存也比较厉害，服务
不要和别的服务在一起。
4、可用性（单点问题）
对于单点问题，
redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整
个快照,无增量复制，因性能和效率问题，
所以单点问题比较复杂；不支持自动 sharding,需要依赖程序设定一致 hash 机制。
一种替代方案是，不用 redis 本身的复制机制，采用自己做主动复制（多份存储），或者改成
增量复制的方式（需要自己实现），一致性问题和性能的权衡
Memcache 本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的 hash 或者环
状的算法，解决单点故障引起的抖动问题。
mongoDB 支持 master-slave,replicaset（内部采用 paxos 选举算法，自动故障恢复）,auto sharding 机制，对客户端屏蔽了故障转移和切分机制。
5、可靠性（持久化）
对于数据持久化和数据恢复，
redis 支持（快照、AOF）：依赖快照进行持久化，aof 增强了可靠性的同时，对性能有所影
响
memcache 不支持，通常用在做缓存,提升性能；
MongoDB 从 1.8 版本开始采用 binlog 方式支持持久化的可靠性
6、数据一致性（事务支持）
Memcache 在并发场景下，用 cas 保证一致性redis 事务支持比较弱，只能保证事务中的每个操作连续执行
mongoDB 不支持事务
7、数据分析
mongoDB 内置了数据分析的功能(maprece),其他不支持
8、应用场景
redis：数据量较小的更性能操作和运算上
memcache：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写
少，对于数据量比较大，可以采用 sharding）
MongoDB:主要解决海量数据的访问效率问题。
表格比较：
memcache redis 类型 内存数据库 内存数据库
数据类型 在定义 value 时就要固定数据类型 不需要
有字符串，链表，集 合和有序集合
虚拟内存 不支持 支持
过期策略 支持 支持
分布式 magent master-slave，一主一从或一主多从
存储数据安全 不支持 使用 save 存储到 mp.rdb 中
灾难恢复 不支持 append only file(aof)用于数据恢复
性能
1、类型——memcache 和 redis 都是将数据存放在内存，所以是内存数据库。当然，memcache 也可用于缓存其他东西，例如图片等等。
2、 数据类型——Memcache 在添加数据时就要指定数据的字节长度,而 redis 不需要。
3、 虚拟内存——当物理内存用完时，可以将一些很久没用到的 value 交换到磁盘。
4、 过期策略——memcache 在 set 时就指定，例如 set key1 0 0 8,即永不过期。Redis 可以通
过例如 expire 设定，例如 expire name 10。
5、 分布式——设定 memcache 集群，利用 magent 做一主多从;redis 可以做一主多从。都可
以一主一从。
6、 存储数据安全——memcache 断电就断了，数据没了；redis 可以定期 save 到磁盘。
7、 灾难恢复——memcache 同上，redis 丢了后可以通过 aof 恢复。
Memecache 端口 11211
yum -y install memcached
yum -y install php-pecl-memcache
/etc/init.d/memcached start memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/memcached.pid
-d 启动一个守护进程
-p 端口
-m 分配的内存是 M
-c 最大运行并发数-P memcache 的 pid
//0 压缩（是否 MEMCACHE_COMPRESSED） 30 秒失效时间
//delete 5 是 timeout <?php
$memcache = new Memcache; $memcache -> connect('127.0.0.1', 11211); $memcache -> set('name','yang',0,30);
if(!$memcache->add('name','susan',0, 30)) {
//echo 'susan is exist'; }$memcache -> replace('name', 'lion', 0, 300); echo $memcache -> get('name');
//$memcache -> delete('name', 5);
printf "stats\r\n" | nc 127.0.0.1 11211
telnet localhost 11211 stats quit 退出
Redis 的配置文件 端口 6379
/etc/redis.conf 启动 Redis
redis-server /etc/redis.conf 插入一个值
redis-cli set test "phper.yang" 获取键值
redis-cli get test 关闭 Redis
redis-cli shutdown 关闭所有
redis-cli -p 6379 shutdown <?php
$redis=new
Redis(); $redis->connect('127.0.0.1',6379); $redis->set('test',
'Hello World'); echo $redis->get('test'); Mongodb
apt-get install mongo mongo 可以进入 shell 命令行
pecl install mongo Mongodb 类似 phpmyadmin 操作平台 RockMongo

Ⅲ 游戏服务端并发的问题是什么情况

Ⅳ memcached gui 工具有哪些

1.什么是memcached

缓存是一种常驻与内存的内存数据库，内存的读取速度远远快于程序在磁盘读取数据的速度。我们在设计程序的时候常常会考虑使用缓存，将经常访问的数据放到内存上面这样可以提高访问数据的速度，同时可以降低磁盘或数据库的压力。
memcached就是一款可以方便实现缓存的工具软件，memcached的优势在于以下几点：
1.实现分布式缓存（支持热部署），通过hashcode根据缓存服务器ip智能分配将数据缓存到的服务器上。
2.实现最近最少访问的数据优先被移除缓存。
3.快速找到适配的存储空间，避免内存的浪费。
4.使用键值对存储数据，方便读取修改等缓存的管理。
5.socket通信，缓存服务器和应用服务器分离。
等等，memcached还含有很多自身的优势。
使用缓存中我们面临的缓存数据无法同步的问题：比如一台缓存服务器突然崩溃那么这台服务器上面的缓存数据就会全部丢失，而且需要在配置中及时去除这台崩溃的服务器IP，这个需要我们编写更多的代码进行相应的控制。

2.memcached内部机制

memcached为了提高数据的存储速度，在安装启动memcached服务的时候，他会自动将分配给memcached的内存分隔为大小不一致的很多块。每当任意一个大小的需要缓存的数据提交过来的时候memcached将会自动找到符合这个数据大小最适合的内存块，然后把数据放到这个块里面。这种方式不仅可以降低内存的浪费同时可以减少了内存分配的时间了。
如果memcached里面的内存已经被使用完了，还需要向里面添加数据的时候，memcached将会把存入缓存中最长时间没有用的数据清除掉。
每次向缓存中添加数据的时候都会带上该数据的有效时间，如果超过了这个有效时间那么缓存的数据自动失效了。
memcached安装到计算机上是一款服务默认端口11211，我们可以通过socket与他建立通信。建立起通信之后就可以通过执行memcached的指令向缓存里面添加取出或修改或删除缓存数据的工作了。

3.C#如何操作memcached

C#建立memcached连接，首先通过socket建立于11211的通信，建立socketpool，然后通过socket发起远程命令的执行语句，在这里使用socket建立连接就需要设定每一次连接建立的最大时间，如果不设定最大时间，那么在建立某一个连接的时候发生了异常，那么机器就会长时间处于等待知道连接超时异常抛出。
使用了线程池和进行Socket的链接。然后通过Socket进行相应的链接操作。
其实memcached作为一种服务，他可以被不同语言不同平台建立连接并执行命令。

4.memcached内部操作指令和名词解释

所有语言建立连接到memcached服务之后，要管理memcached都执行的是同一套的指令集合。

在Windows系统中我们可以使用telnet命令来查看Memcached的相关运行情况如：
stats telnet xxx.xxx.xxx.xxx 11211
输入stats命令：在这里屏幕是空白，看不到输入的内容，回车之后可以看到Memcached的运行相关信息。
set key
get key
memcached客户机命令
set
Add
replace
get
delete
输入stats命令：在这里屏幕是空白，看不到输入的内容，回车之后可以看到Memcached的运行相关信息。
查看出来的结果名词的意思：Pid: Memcached服务器中的进程编号
Uptime：Memcached服务器启动之后所经历的时间，单位秒
Time：当前系统时间，单位秒
Version: Memcached的版本号
pointer_size：服务器所在主机操作系统的指针大小，一般为32或64
curr_items：表示当前缓存中存放的所有缓存对象的数量
total_items：表示从memcached服务启动到当前时间，系统存储过的所有对象的数量，包括已经删除的对象
bytes：表示系统存储缓存对象所使用的存储空间，单位为字节
curr_connections：表示当前系统打开的连接数
total_connections：表示从memcached服务启动到当前时间，系统打开过的连接的总数
cmd_get：查询缓存的次数，即使不成功也算一次
cmd_set：保存数据的次数，当然这里只保存成功的次数
get_hits：表示获取数据成功的次数。
get_misses：表示获取数据失败的次数。
evictions：为了给新的数据项目释放空间，从缓存移除的缓存对象的数目。比如超过缓存大小时根据LRU算法移除的对象，以及过期的对象
bytes_read：memcached服务器从网络读取的总的字节数
bytes_written：memcached服务器发送到网络的总的字节数
limit_maxbytes：memcached服务缓存允许使用的最大字节数
threads：被请求的工作线程的总数量
缓存命中率 = get_hits / cmd_get * 100% ;

Ⅳ ElasticSearch查询流程详解

前面已经介绍了ElasticSearch的写入流程，了解了ElasticSearch写入时的分布式特性的相关原理。ElasticSearch作为一款具有强大搜索功能的存储引擎，它的读取是什么样的呢？读取相比写入简单的多，但是在使用过程中有哪些需要我们注意的呢？本篇文章会进行详细的分析。

在前面的文章我们已经知道ElasticSearch的读取分为两种GET和SEARCH。这两种操作是有一定的差异的，下面我们先对这两种核心的数据读取方式进行一一分析。

（图片来自官网）

以下是从主分片或者副本分片检索文档的步骤顺序：

注意：

在协调节点有个http_server_worker线程池。收到读请求后它的具体过程为：

数据节点上有一个get线程池。收到了请求后，处理过程为：

注意：

get过程会加读锁。处理realtime选项，如果为true，则先判断是否有数据可以刷盘，然后调用Searcher进行读取。Searcher是对IndexSearcher的封装在早期realtime为true则会从tranlog中读取，后面只会从index的lucene读取了。即实时的数据只在lucene之中。

对于Search类请求，ElasticSearch请求是查询lucene的Segment，前面的写入详情流程也分析了，新增的文档会定时的refresh到磁盘中，所以搜索是属于近实时的。而且因为没有文档id，你不知道你要检索的文档在哪个分配上，需要将索引的所有的分片都去搜索下，然后汇总。ElasticSearch的search一般有两个搜索类型

所有的搜索系统一般都是两阶段查询：

第一阶段查询到匹配的docID，第二阶段再查询DocID对应的完整文档。这种在ElasticSearch中称为query_then_fetch，另一种就是一阶段查询的时候就返回完整Doc，在ElasticSearch中叫query_and_fetch，一般第二种适用于只需要查询一个Shard的请求。因为这种一次请求就能将数据请求到，减少交互次数，二阶段的原因是需要多个分片聚合汇总，如果数据量太大那么会影响网络传输效率，所以第一阶段会先返回id。

除了上述的这两种查询外，还有一种三阶段查询的情况。

搜索里面有一种算分逻辑是根据TF和DF来计算score的，而在普通的查询中，第一阶段去每个Shard中独立查询时携带条件算分都是独立的，即Shard中的TF和DF也是独立的。虽然从统计学的基础上数据量多的情况下，每一个分片的TF和DF在整体上会趋向于准确。但是总会有情况导致局部的TF和DF不准的情况出现。

ElasticSearch为了解决这个问题引入了DFS查询。

比如DFS_query_then_fetch，它在每次查询时会先收集所有Shard中的TF和DF值，然后将这些值带入请求中，再次执行query_then_fetch，这样算分的时候TF和DF就是准确的，类似的有DFS_query_and_fetch。这种查询的优势是算分更加精准，但是效率会变差。

另一种选择是用BM25代替TF/DF模型。

在ElasticSearch7.x，用户没法指定以下两种方式： DFS_query_and_fetch 和 query_and_fetch 。

注：这两种算分的算法模型在《ElasticSearch实战篇》有介绍：

这里query_then_fetch具体的搜索的流程图如下：

（图片来自官网）

查询阶段包含以下四个步骤:

以上就是ElasticSearch的search的详细流程，下面会对每一步进行进一步的说明。

协调节点处理query请求的线程池为：

http_server_work

负责该解析功能的类为：

org.elasticsearch.rest.action.search.RestSearchAction

主要将restquest的参数封装成SearchRequest

这样SearchRequest请求发送给TransportSearchAction处理

将索引涉及到的shard列表或者有跨集群访问相关的shard列表合并

如果有多个分片位于同一个节点，仍然会发送多次请求

shardsIts为搜索涉及的所有分片，而shardRoutings.nextOrNull()会从分片的所有副本分片选出一个分片来请求。

onShardSuccess对收集到的结果进行合并，这里需要检查所有的请求是否都已经有了回复。

然后才会判断要不要进行executeNextPhase

当返回结果的分片数等于预期的总分片数时，协调节点会进入当前Phase的结束处理，启动下一个阶段Fetch Phase的执行。onPhaseDone()会executeNextPhase来执行下一个阶段。

当触发了executeNextPhase方法将触发fetch阶段

上一步的executeNextPhase方法触发Fetch阶段，Fetch阶段的起点为FetchSearchPhase#innerRun函数，从查询阶段的shard列表中遍历，跳过查询结果为空的 shard。其中也会封装一些分页信息的数据。

使用了countDown多线程工具，fetchResults存储某个分片的结果，每收到一个shard的数据就countDoun一下，当都完毕后，触发finishPhase。接着会进行下一步：

CountedCollector:

finishPhase:

执行字段折叠功能，有兴趣可以研究下。即ExpandSearchPhase模块。ES 5.3版本以后支持的Field Collapsing查询。通过该类查询可以轻松实现按Field值进行分类，每个分类获取排名前N的文档。如在菜单行为日志中按菜单名称（用户管理、角色管理等）分类，获取每个菜单排名点击数前十的员工。用户也可以按Field进行Aggregation实现类似功能，但Field Collapsing会更易用、高效。

ExpandSearchPhase执行完了，就返回给客户端结果了。

处理数据节点请求的线程池为：search

根据前面的两个阶段，数据节点主要处理协调节点的两类请求：query和fetch

这里响应的请求就是第一阶段的query请求

executeQueryPhase:

executeQueryPhase会执行loadOrExecuteQueryPhase方法

这里判断是否从缓存查询，默认启用缓存，缓存的算法默认为LRU，即删除最近最少使用的数据。如果不启用缓存则会执行queryPhase.execute(context);底层调用lucene进行检索，并且进行聚合。

关键点：

ElasticSearch查询分为两类，一类为GET，另一类为SEARCH。它们使用场景不同。

本文主要分析了ElasticSearch分布式查询主体流程，并未对lucene部分进行分析，有兴趣的可以自行查找相关资料。

Ⅵ 分布式存储最佳缓存比

作者：深入细节的 SmartX 一线技术团队

近日，VMware 发布了 vSAN 8，对存储架构进行了重大更新。其中最主要的变化，即引入了新的 Express Storage Architecture（ESA）架构：用“存储池”替代了原存储架构（OSA）中的“磁盘组”，并不再需要专用 SSD 承担缓存加速功能，一定程度上避免了 8.0 之前版本中的专用缓存盘利用率低、易发生缓存击穿等问题。
而值得一提的是，在 vSAN 大版本更新之前，SmartX 即通过统一缓存空间和智能冷热数据管理优化了分布式存储缓存机制，有效规避了上述问题。本文将通过重点解读 vSAN（以 vSAN 7 为例）和 SmartX 分布式块存储组件 ZBS* 缓存机制的原理，并测试对比两种缓存机制下虚拟机性能表现，让读者更好地了解两种技术实现机制的区别对业务可能带来的实际影响。

* ZBS 内置于 SmartX 超融合软件 SMTX OS，可与 SmartX 原生虚拟化 ELF 搭配提供服务。

本文重点
vSAN 7 采用划分读写缓存空间的机制，将缓存磁盘按照容量占比划分为写缓冲区（30%）和读缓存区（70%）。这种方式可能出现缓存利用率低、在访问数据量过大时导致缓存击穿，进而引起性能下降等问题。
ZBS 采用统一缓存空间的机制，并通过 2 级 LRU 算法对冷热数据进行管理，在充分利用缓存容量的同时避免了因访问量激增导致虚拟机性能下降的情况。
本文基于相同的硬件配置和 I/O 读写场景，分别测试 VMware 超融合（vSphere 虚拟化 + vSAN 分布式存储）写入 300 GB 数据、SMTX OS（ELF + ZBS）写入 500 GB 数据时虚拟机的性能表现。结果显示，vSAN 7 难以充分利用缓存介质，发生缓存击穿，导致存储性能下降；而 SMTX OS 即便在写入更多数据的情况下也未发生缓存击穿，虚拟机性能保持稳定。
场景问题
混闪配置是超融合或分布式存储现阶段的主流落地模式。混闪配置是指机器中的磁盘使用 SSD + HDD 混合组成，其中 SSD 磁盘作为数据缓存层，而 HDD 磁盘作为数据容量层。以该模式构建的分布式存储池通过软件算法进行冷热数据自动判断，在提供高性能的同时，还可获得较大的存储容量，进而提升资源利用率，获得相对全闪存储更高的性价比。

在将 SSD 磁盘用作数据缓存层时，部分超融合产品会将缓存容量（Cache）划分为读和写各自独立的两部分。例如，vSAN 7 及更早版本会将每个磁盘组（Disk Group）中的缓存磁盘，按照容量占比划分为写缓冲区（30%）和读缓存区（70%），当读取数据未命中缓存或者写缓存已满，将会直接从容量层进行读写。

Ⅶ 在linux中启动memcached出问题！

MemCache是高性能分布式内存对象缓存系统（将数据调用到内存中，然后在内存中读取，从而大大提高读取速度）
Memcached安装与启动：
安装memcached需要先安装libevent
Shell>tar zxvf libevent-1.4.14b-stable.tar.gz
Shell>cd libevent-1.4.14b-stable
Shell>./configure
Shell>make && make install
安装memcached
Shell>tar zxvf memcached-1.2.5.tar.tar
Shell>cd memcached-1.2.5
Shell>./configure –prefix=/usr/local/memcached
Shell>make && make install
启动memcached
Shell>/usr/local/memcached/bin/memcached –p 11211 –d –u root –P /tmp/memcached.pid
-P是表示使用TCP，默认端口为11211
-d表示后台启动一个守护进程(daemon)
-u表示指定root用户启动，默认不能用root用户启动
-P表示进程的pid存放地点，此处“p”为大写“P”
-l，后面跟IP地址，手工指定监听IP地址，默认所有IP都在监听
-m后面跟分配内存大小，以MB为单位，默认为64M
-c最大运行并发连接数，默认为1024
-f 块大小增长因子，默认是1.25
-M 内存耗尽时返回错误，而不是删除项，即不用LRU算法

Ⅷ Spring本地缓存的使用方法

我们现在在用的Spring Cache，可以直接看Spring Boot提供的缓存枚举类，有如下这些：

EhCache：一个纯Java的进程内缓存框架，所以也是基于本地缓存的。(注意EhCache2.x和EhCache3.x相互不兼容)。
Redis：分布式缓存，只有Client-Server(CS)模式，Java一般使用Jedis/Luttuce来操纵。
Hazelcast：基于内存的数据网格。虽然它基于内存，但是分布式应用程序可以使用Hazelcast进行分布式缓存、同步、集群、处理、发布/订阅消息等。
Guava：它是Google Guava工具包中的一个非常方便易用的本地化缓存实现，基于LRU（最近最少使用）算法实现，支持多种缓存过期策略。在Spring5.X以后的版本已经将他标记为过期了。
Caffeine：是使用Java8对Guava缓存的重写版本，在Spring5中将取代了Guava，支持多种缓存过期策略。
SIMPLE：使用ConcurrentMapCacheManager，因为不支持缓存过期时间，所以做本地缓存基本不考虑该方式。

关于分布式缓存，我们需要后面会专门讨论Redis的用法，这里只看本地缓存。性能从高到低，依次是Caffeine，Guava，ConcurrentMapCacheManager，其中Caffeine在读写上都快了Guava近一倍。

这里我们只讨论在Spring Boot里面怎么整合使用Caffeine和EhCache。

主要有以下几个步骤：

1)加依赖包：

2)配置缓存：
这里有两种方法，通过文件配置或者在配置类里面配置，先看一下文件配置，我们可以写一个properties文件，内容像这样：

然后还要在主类中加上@EnableCaching注解：

另外一种更灵活的方法是在配置类中配置：

应用类：

测试类：

导入依赖包，分为2.x版本和3.x版本。
其中2.x版本做如下导入：

3.x版本做如下导入：

导包完成后，我们使用JCacheManagerFactoryBean + ehcache.xml的方式配置：

参考资料：

https://blog.csdn.net/f641385712/article/details/94982916

http://www.360doc.com/content/17/1017/20/16915_695800687.shtml

Ⅸ 缓存系统中的主要使用的数据结构是什么

缓存系统中的主要使用的数据结构是memcached。

memcached是一套分布式的高速缓存系统，由LiveJournal的Brad Fitzpatrick开发，但被许多网站使用。这是一套开放源代码软件，以BSD license授权发布。

memcached的API使用三十二比特的循环冗余校验（CRC-32）计算键值后，将数据分散在不同的机器上。当表格满了以后，接下来新增的数据会以LRU机制替换掉。

由于memcached通常只是当作缓存系统使用，所以使用memcached的应用程序在写回较慢的系统时（像是后端的数据库）需要额外的代码更新memcached内的数据。

(9)分布式缓存lru算法扩展阅读：

一、存储方式

为了提高性能，memcached中保存的数据都存储在memcached内置的内存存储空间中。由于数据仅存在于内存中，因此重启memcached、重启操作系统会导致全部数据消失。

另外，内容容量达到指定值之后，就基于LRU(Least Recently Used)算法自动删除不使用的缓存。memcached本身是为缓存而设计的服务器，因此并没有过多考虑数据的永久性问题。

二、通信分布式

memcached尽管是“分布式”缓存服务器，但服务器端并没有分布式功能。各个memcached不会互相通信以共享信息。那么，怎样进行分布式呢？这完全取决于客户端的实现。本文也将介绍memcached的分布式。

Ⅹ 分布式session的几个问题

高并发下分布式Session需解决的问题：

• 透明处理存储介质的故障转移

• 动态增删节点，减小“缓存颠簸”问题

• 保证数据在各个节点的分布均衡

• Session序列化和反序列化

三.保证“基本可用 Basically Available”的分布式Session方案：

Eric A. Brewer 在 1988 年提出的BASE 策略，即Basically Available、Soft state、和Eventually consistent。

互联网大多数应用更强调可用性，即牺牲高一致性，获得可用性或可靠性。

基本可用Basically Available的定义：

在分布式系统部分损坏的时候，允许部分内容不可用，但是其他部分仍旧可用。因此称这种系统为“基本可用”。比如，一个数据存储系统由五个节点构成。其中一个发生了损坏，这时只有20%的数据不能访问，其他80%数据仍然可用。那么就可以称这种系统为基本可用的。

基于 memcache 的Hash取模算法（hash() mod n，hash() 取用户ID，n为节点数） 实现的分布式 Session 方案，就属于基本可用：

第一，如果节点发生故障，该节点上的所有用户 Session 丢失，系统无法自恢复。

第二，如果系统压力突然增大，需要临时增加机器节点。按照 Hash取模的算法，在增加机器节点的这一时刻，大量缓存无法命中（其实还都存在之前的节点上），导致大范围的缓存穿透，压力会直接打到数据库上。

第三，根据 LRU 缓存失效算法，memcache 里存储的 key/value 有可能被踢出，用户 Session 容易丢失。

针对 Hash取模 的改进办法是：

四.基于一致性哈希算法的 memcache 解决方案

1）一致性哈希帮我们解决的是，当机器节点减少时，缓存数据能进行最少重建。

2）还能解决 Session 数据的分布均衡问题。

3）当机器节点宕机，这部分数据必然丢失。由于节点数目变化，有可能对部分没有丢失的数据也要重建。

但上面的方案都解决不了“一个节点失败后，它所存储的 Session 如何由其他节点获取以便接替失效节点，实现集群的容错（Failover）”。

郑昀先介绍下面几个概念：

五.Sticky Session、Non-sticky Session和Replicated Sessions

• Sticky Sessions：粘性会话。即同一个会话中的请求必须被转发到同一个节点上，除非该节点宕机才转发到故障转移节点。一个节点宕机，所存储的 Sessions 完全丢失。通俗的话就是，将用户“粘”在某一个服务器节点上。

• Non-Sticky Sessions：非粘性会话。每一次请求都可能转发到不同节点。

• Replicated Sessions：把一个节点上的 Sessions 复制到集群的其他节点上，防止数据丢失，允许失效无缝转移。如node 0复制到node 5，node 1复制到node 6，以此类推。多数应用服务器（如 Tomcat ）都支持会话复制机制。

当用户数量和集群数量达到一定规模后，Session 复制就可能成为性能瓶颈。于是人们提出了从第三方缓存恢复失效节点数据的方案，开源产品Memcached-Session-Manager（下面简称MSM）就是基于这个思想。

六.MSM的工作原理

MSM 支持 Tomcat 6 和 7，即它主要解决的是 Tomcat 的高可用性。

它的特性为：

• 支持 sticky sessions 和 non-ticky sessions 模式。

• 没有单点故障。

• 能处理 tomcat 故障转移

• 能处理 memcache 故障转移

• pluggable session serialization

• 允许异步存储 session，提高响应速度

• sessions 只有真正被修改时，才会发给 memcache