分布式緩存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