R2M 是京東金融線上大規(guī)模應用的分布式緩存系統(tǒng)，目前管理的機器總內(nèi)存容量超過 60TB，近 600 個 Redis Cluster 集群，9200 多個 Redis 實例。
其主要功能包括：全 web 可視化運維、緩存集群一鍵部署、資源池統(tǒng)籌管理、在線擴容及快速數(shù)據(jù)遷移、多機房切換及容災、完善的監(jiān)控及告警、Redis API 兼容等。
本文將從 R2M 系統(tǒng)架構、資源管理、集群擴容與遷移、數(shù)據(jù)冷熱交換、多機房容災等多方面進行深入剖析，希望讀者能有所收獲。
R2M 接入簡單，以 Java 客戶端為例，只需在業(yè)務程序中引入客戶端 jar 包，配置好 appname 及 ZK 地址，即可使用。
R2M 客戶端提供了諸如連接池、讀寫超時時間、重試次數(shù)等配置，有些情況下，需要對這些配置進行調(diào)優(yōu)，比如 618、雙十一大促來臨時，有些業(yè)務需要減小客戶端讀寫超時時間，避免超時問題引發(fā)的連鎖反應。
為了修改配置，業(yè)務不得不重新上線所有的客戶端，不僅費時費力，還有可能引發(fā)故障。因此，為了避免這個問題，R2M 提供了配置自動下發(fā)功能，業(yè)務客戶端無需重新上線，管理端修改配置后，所有客戶端即時生效。
完全兼容 Redis 各數(shù)據(jù)類型 API 接口，提供包括哈希、集合、有序集合、列表、發(fā)布 / 訂閱等近百個接口。
在保證高性能和數(shù)據(jù)一致性的前提下，實現(xiàn)了基于 LFU 熱度統(tǒng)計的數(shù)據(jù)動態(tài)冷熱交換，使得冷數(shù)據(jù)被交換到 SSD 上，熱數(shù)據(jù)被加載到 Redis 上，取得高性能和低成本的高平衡。
R2M 實現(xiàn)了包括集群部署、擴容、數(shù)據(jù)遷移、監(jiān)控、集群下線、數(shù)據(jù)清理、故障節(jié)點替換及機器下線等在內(nèi)的所有功能的可視化運維，運維效率及可用性大大提升。
通過改造 Redis Cluster 支持多機房災備、防止集群腦裂，以及各系統(tǒng)組件針對多機房切換選舉的支持，實現(xiàn)了在 Web 控制臺的多機房一鍵切換。
R2M 提供了專門的遷移工具組件，支持從原生 Redis 遷移至 R2M，實現(xiàn)了基于 Redis RDB 文件傳輸及增量同步的遷移機制。
同時，還可以指定規(guī)則比如按照前綴匹配或者反向匹配進行部分數(shù)據(jù)遷移。由于內(nèi)部歷史原因，京東金融部分業(yè)務以前用的是京東商城的 Jimdb，R2M 同樣也支持了從 Jimdb 集群進行遷移。
R2M 遷移工具還支持數(shù)據(jù)實時同步的功能，包括 R2M 集群間的數(shù)據(jù)同步和 Jimdb 源集群的數(shù)據(jù)同步。
我們的業(yè)務開發(fā)人員主要用的是 Java，對于非 Java 語言的客戶端，比如 Python、C 等等，則通過 R2M Proxy 組件接入，各種運維操作在 Proxy 層進行，對業(yè)務方屏蔽。同時，Proxy 也提供了高可用保障方案。
是 R2M 緩存系統(tǒng)的可視化運維控制臺。所有運維操作均在 Web console 進行。
整個系統(tǒng)的管理組件。負責所有運維操作的下發(fā)、監(jiān)控數(shù)據(jù)的收集等。運維操作包括集群創(chuàng)建、數(shù)據(jù)遷移、擴容、多機房切換等等。
每臺物理機上部署一個 Agent 組件，Agent 負責本機 Redis 實例的部署和監(jiān)控，并進行數(shù)據(jù)上報。
每個集群的節(jié)點分布在不同機器上，若干個節(jié)點構成一個分布式集群，去中心化，無單點。
客戶端由業(yè)務方引入，如：Java 通過 jar 包方式引入。
對于非 Java 客戶端的業(yè)務，通過 Proxy 提供緩存接入和服務。
分布式集群的部署通常來說是比較麻煩的，涉及到多臺機器、多個節(jié)點及一系列的動作和配置，比如部署 Redis Cluster，就包括節(jié)點安裝與啟動、節(jié)點握手、主從分配、插槽分配、設置復制這些步驟。
雖然官方提供了構建集群的工具腳本，但機器推薦、節(jié)點安裝及配置仍然沒有自動化，對于需要大規(guī)模部署和運維 Redis Cluster 的企業(yè)來說，仍然不夠靈活和便捷。
因此，R2M 基于 Golang 實現(xiàn)了在 Web 控制臺一鍵完成從機器推薦、節(jié)點部署、集群構建、到節(jié)點配置的所有動作，這個過程中每臺機器上的 Agent 組件負責下載并安裝 RPM 包、在指定端口上啟動實例，Manager 組件則負責完成集群構建和節(jié)點配置過程。
自動部署過程中，還有一些必要的驗證條件和優(yōu)先規(guī)則，主要是以下幾點：
檢查主節(jié)點數(shù)量和主備策略，是否滿足分布式選舉及高可用的最低配置條件：三個以上主節(jié)點、一主一從。
避免同一個集群多個節(jié)點部署在相同機器上，防止機器故障，優(yōu)先推薦符合條件的機器。
根據(jù)機器可用內(nèi)存，優(yōu)先推薦剩余可用內(nèi)存多的機器。
根據(jù)主節(jié)點數(shù)量，均衡分配插槽數(shù)量。
由于機房、機器、業(yè)務數(shù)量眾多，要做好平臺化管理，需要對資源進行合理的事先規(guī)劃，事先規(guī)劃包括：申請接入時業(yè)務方對容量進行預估，合理分配緩存實例大小和數(shù)量、機器的預留內(nèi)存，為了方便管理和統(tǒng)計，通常還需要根據(jù)機房對機器進行分組、或者根據(jù)業(yè)務進行機器分組。
做好事先規(guī)劃的同時，還需要對資源使用情況做到一目了然，避免出現(xiàn)超用或嚴重超配的情況。
嚴重超配，就是實際使用量遠小于預估容量的情況，這種情況還是很多的，因為很多時候容量很難準確預估，或者有的業(yè)務開發(fā)為了保險起見或擔心不好擴容，申請的容量往往遠大于實際需要，對于這種情況，我們可以進行一鍵縮容，防止資源浪費。
對于 超用，也就是機器實際資源使用量超過了標準，則是要非常注意的，緩存機器超用比如 Redis 機器超用可能導致非常嚴重的后果，比如 OOM、發(fā)生數(shù)據(jù)淘汰、性能急劇下降，為了避免超用，需要進行合理的資源預留、選擇合適的淘汰策略，同時平臺要有完善的監(jiān)控和實時的報警功能。
R2M 通過對機房、分組、機器、實例的層級管理和監(jiān)控，方便我們更好地對資源進行規(guī)劃，并最大限度的統(tǒng)籌和平衡資源利用，防止資源浪費和機器超用。
業(yè)務在申請緩存時，我們都會要求預估容量，根據(jù)預估值進行分配，但預估值經(jīng)常是不準確的，計劃也永遠趕不上變化，業(yè)務場景拓展、業(yè)務量和數(shù)據(jù)的增長總是無法預測的。
因此，良好的擴容機制顯得尤為重要，擴容做得好不好，決定了系統(tǒng)的擴展性好不好。在 R2M 中，我們將水平擴容解耦為兩個步驟，添加新節(jié)點和數(shù)據(jù)遷移，添加新節(jié)點其實就是一個自動部署的過程，很多步驟與集群創(chuàng)建過程是相同的，那么關鍵就在于如何解決數(shù)據(jù)遷移問題了。
數(shù)據(jù)遷移主要解決以下問題：
如何做到不影響業(yè)務的正常讀寫，即業(yè)務方對遷移是基本無感知的？
如何保證遷移的速度？
當一條數(shù)據(jù)處于遷移中間狀態(tài)時，如果此時客戶端需要對該數(shù)據(jù)進行讀寫，如何處理？
遷移過程中收到讀操作，是讀源節(jié)點還是目標節(jié)點，如何確?？蛻舳瞬粫x到臟數(shù)據(jù)？
遷移過程中是寫源節(jié)點還是寫目標節(jié)點，如果確保不寫錯地方、不會由于遷移使得新值被舊值覆蓋？
遷移完成，如何通知客戶端，將讀寫請求路由到新節(jié)點上？
為了解決這些問題，我們充分吸取了 Redis Cluster 的優(yōu)點，同時也解決了它的一些不足之處和缺點。
上圖就是 Redis Cluster 的數(shù)據(jù)遷移原理圖，遷移過程是通過源節(jié)點、目標節(jié)點、客戶端三者共同配合完成的。
Redis Cluster 將數(shù)據(jù)集分為 16384 個插槽，插槽是數(shù)據(jù)分割的最小單位，所以數(shù)據(jù)遷移時最少要遷移一個插槽，遷移的最小粒度是一個 key，對每個 key 的遷移可以看成是一個原子操作，會短暫阻塞源節(jié)點和目標節(jié)點上對該 key 的讀寫，這樣就使得不會出現(xiàn)遷移“中間狀態(tài)”，即 key 要么在源節(jié)點，要么在目標節(jié)點。
如上圖，假設正在遷移 9 號插槽，首先會在源節(jié)點中將 9 號插槽標記為“正在遷移”狀態(tài)，將目標節(jié)點中 9 號插槽標記為“正在導入”狀態(tài)，然后遍歷遷移該插槽中所有的 key。
此時，如果客戶端要對 9 號插槽的數(shù)據(jù)進行訪問，如果該數(shù)據(jù)還沒被遷移到目標節(jié)點，則直接讀寫并返回，如果該數(shù)據(jù)已經(jīng)被遷移到目標節(jié)點，則返回 Ask 響應并攜帶目標節(jié)點的地址，告訴客戶端到目標節(jié)點上再請求一次。
如果 9 號插槽的數(shù)據(jù)被全部遷移完成，客戶端還繼續(xù)到源節(jié)點進行讀寫的話，則返回 Moved 響應給客戶端，客戶端收到 Moved 響應后可以重新獲取集群狀態(tài)并更新插槽信息，后續(xù)對 9 號插槽的訪問就會到新節(jié)點上進行。這樣，就完成了對一個插槽的遷移。
Redis Cluster 是基于 CRC16 算法做 hash 分片的，在插槽數(shù)量差不多且沒有大 key 存在的情況下，各節(jié)點上數(shù)據(jù)的分布通常非常均衡，而由于數(shù)據(jù)遷移是以 key 為單位的，遷移速度較慢。
當數(shù)據(jù)量暴漲需要緊急擴容時，如果一個接一個地進行主節(jié)點數(shù)據(jù)遷移，有可能部分節(jié)點還沒來得及遷移就已經(jīng)把內(nèi)存“撐爆”了，導致發(fā)生數(shù)據(jù)淘汰或機器 OOM。
因此，R2M 實現(xiàn)了多節(jié)點并行數(shù)據(jù)遷移，防止此類問題發(fā)生，同時也使數(shù)據(jù)遷移耗時大大縮短，另外，結合 Redis 3.0.7 之后的 pipeline 遷移功能，可以進一步減少網(wǎng)絡交互次數(shù)，縮短遷移耗時。
水平擴容添加新節(jié)點后，為了做數(shù)據(jù) / 負載均衡，需要把部分數(shù)據(jù)遷移到新節(jié)點上，通常數(shù)據(jù)遷移過程是比較耗時的，根據(jù)網(wǎng)絡條件、實例大小和機器配置的不同，可能持續(xù)幾十分鐘至幾個小時。
而數(shù)據(jù)遷移時可能對網(wǎng)絡造成較大的壓力，另外，對于正在遷移的 slot 或 keys，Redis Cluster 通過 ASK 或 MOVED 重定向機制告訴客戶端將請求路由至新節(jié)點，使得客戶端與 Redis 多發(fā)生一次請求響應交互。
并且通?？蛻舳说木彺孀x寫超時比較短 (通常在 100~500ms 以內(nèi))，在多重因素的作用下，有可能造成大量讀寫超時情況，對在線業(yè)務造成較大的影響。
基于此，我們實現(xiàn)了遷移任務暫停和遷移任務繼續(xù)，當發(fā)現(xiàn)遷移影響業(yè)務時，隨時可以暫停遷移，待業(yè)務低峰期再繼續(xù)進行剩余的數(shù)據(jù)遷移，做到靈活可控。
R2M 還提供了自動擴容機制，開啟自動擴容后，當機器可用內(nèi)存足夠時，如果實例已使用容量達到或超過了預設的閥值，則自動對容量進行擴大。
對于一些比較重要的業(yè)務，或不能淘汰數(shù)據(jù)的業(yè)務，可以開啟自動擴容。當然，自動擴容也是有條件的，比如不能無限制的自動擴容，實例大小達到一個比較高的值時，則拒絕自動擴容，還要預留出一部分內(nèi)存進行 Fork 操作，避免機器發(fā)生 OOM。
由于我們線上存在很多大容量 (幾百 GB 或幾個 TB) 緩存集群，緩存機器內(nèi)存成本巨大，線上機器總內(nèi)存容量已達到 66TB 左右。
經(jīng)過調(diào)研發(fā)現(xiàn)，主流 DDR3 內(nèi)存和主流 SATA SSD 的單位成本價格差距大概在 20 倍左右，為了優(yōu)化基礎設施 (硬件、機房機柜、耗電等) 綜合成本，因此，我們考慮實現(xiàn)基于熱度統(tǒng)計的數(shù)據(jù)分級存儲及數(shù)據(jù)在 RAM/FLASH 之間的動態(tài)交換，從而大幅度降低基礎設施綜合成本，并達到性能與成本的高平衡。
R2M 的冷熱交換存儲的基本思想是：基于 key 訪問次數(shù) (LFU) 的熱度統(tǒng)計算法識別出熱點數(shù)據(jù)，并將熱點數(shù)據(jù)保留在 Redis 中，對于無訪問 / 訪問次數(shù)少的數(shù)據(jù)則轉存到 SSD 上，如果 SSD 上的 key 再次變熱，則重新將其加載到 Redis 內(nèi)存中。
思想很簡單，但實際上做起來就不那么容易了，由于讀寫 SATA SSD 相對于 Redis 讀寫內(nèi)存的速度還是有很大差距的，設計時為了避免這種性能上的不對等拖累整個系統(tǒng)的性能、導致響應時間和整體吞吐量的急劇下降，我們采用了多進程異步非阻塞模型來保證 Redis 層的高性能，通過精心設計的硬盤數(shù)據(jù)存儲格式、多版本 key 惰性刪除、多線程讀寫 SSD 等機制來最大限度的發(fā)揮 SSD 的讀寫性能。
多進程異步模型，主要是兩個進程，一個是 SSD 讀寫進程，用于訪問 SSD 中的 key，一個是深度改造過的 Redis 進程，用于讀寫內(nèi)存 key，同時如果發(fā)現(xiàn)要讀寫的 key 是在 SSD 上，則會將請求轉發(fā)給 SSD 讀寫進程進行處理。
Redis 進程這一層，最開始我們其實是基于 Redis 3.2 做的，但 Redis 4 出了 RC 版本之后尤其是支持了 LFU、Psync2、內(nèi)存碎片整理等功能，我們就果斷的切到 Redis 4 上進行改造開發(fā)了。
SSD 讀寫進程，起初是基于開源的 SSDB 進行開發(fā)，不過由于 SSDB 的主從復制實現(xiàn)性能很差，數(shù)據(jù)存儲格式設計還不夠好，與 Redis API 有很多的不兼容問題，最終除了基本的網(wǎng)絡框架外，基本重寫了 SSDB。
另外由于 SSDB 默認采用的存儲引擎是 leveldb，結合功能特性、項目活躍度等方面的原因，我們改成了比較流行的 RocksDB，當然，其實它也是發(fā)源于 leveldb 的。
目前我們內(nèi)部已完成了該項目的開發(fā)，并進行了全面的功能、穩(wěn)定性和性能測試，即將上線。由于冷熱交換存儲涉及的內(nèi)容較多，由于篇幅原因，這里不再詳述。該項目已命名為 swapdb，并在 Github 開源
https://github.com/JRHZRD/swapdb
歡迎有興趣的同學關注，歡迎加 star~
多機房切換是一個從上到下各組件協(xié)調(diào)聯(lián)動的過程，要考慮的因素非常多，在 R2M 中，主要包括緩存集群、路由服務 (如：ZooKeeper、etcd) 及各個組件 (Manager、Web console、客戶端) 的多機房切換。
對于多機房支持，關鍵在于如何避免 腦裂 問題。我們先來看看腦裂是如何發(fā)生的。
正常情況下，一個緩存集群的節(jié)點部署在同一個機房，按最低三主、一主一從進行部署，每個主節(jié)點負責一部分數(shù)據(jù)，如果主節(jié)點掛了，剩余主節(jié)點通過選舉將它的從節(jié)點提升為新的主節(jié)點，即自動 failover。
如果要進行機房切換或對重要的業(yè)務進行多機房容災，則需要在另一個機房對每個主節(jié)點再添加一個從節(jié)點，那么每個主節(jié)點將有兩個從，運行過程中，如果集群中有節(jié)點發(fā)生自動 failover，主節(jié)點可能被 failover 到另一個機房，結果，就會出現(xiàn)同一個集群的主節(jié)點分布在不同機房的情況。
這種情況下，如果機房間網(wǎng)絡鏈路出現(xiàn)問題，A 機房的主節(jié)點與 B 機房的主節(jié)點會互相認為對方處于 fail 狀態(tài)，假設多數(shù)主節(jié)點都在 A 機房，那么 A 機房的主節(jié)點會從同機房的從節(jié)點中選出新的主節(jié)點來替代 B 機房的主節(jié)點，導致相同的分片同時被分屬兩個機房的主節(jié)點負責，A 機房的客戶端把這些分片的數(shù)據(jù)寫到了 A 機房新選出的主節(jié)點，B 機房的客戶端仍然把數(shù)據(jù)寫到了 B 機房的主節(jié)點上，從而造成腦裂導致數(shù)據(jù)無法合并。
熟悉 Redis Cluster 的同學可能知道，Redis Cluster 有一個 cluster-require-full-coverage 的參數(shù)，默認是開啟的，該參數(shù)的作用是：只要有節(jié)點宕機導致 16384 個分片沒被全覆蓋，整個集群就拒絕服務，大大降低可用性，所以實際應用中一定要關閉。但帶來的問題就是，如果出現(xiàn)上述問題，就會造成腦裂帶來的后果。
為了解決這個問題，我們在 Redis 的集群通信消息中加入了 datacenter 標識，收到自動 failover 請求時，主節(jié)點會將自己的 datacenter 標識與被提名做 failover 的從節(jié)點的 datacenter 標識進行比較，如果一致，則同意該節(jié)點的自動 failover 請求，否則，拒絕該請求。
保證自動 failover 只會發(fā)生在同機房從節(jié)點上，避免主節(jié)點分布在多個機房的情況。而對于手動 failover 或強制 failover，則不受此限制。針對 Redis 多機房支持的功能，已經(jīng)向 Redis 官方提交了 pull request，作者 antirez 大神在 Redis 4.2 roadmap 中表示會加入這塊功能。
目前，R2M 的機房正常切換及容災切換都已經(jīng)實現(xiàn)了在 Web console 的一鍵切換。當需要做機房正常維護或遷移時，就可以通過手動 failover 將主節(jié)點批量切到跨機房的從節(jié)點上。
值得一提的是，正常切換過程保證切換前后主從節(jié)點的數(shù)據(jù)一致。當機房由于斷電或其它原因出故障時，通過強制 failover 將主節(jié)點批量切到跨機房的從節(jié)點上，由于是突發(fā)事件，少量數(shù)據(jù)可能還未同步給從節(jié)點，但這里的主要目的是容災、及時恢復服務，可用性重要程度要遠大于少量的數(shù)據(jù)不一致或丟失。
業(yè)務客戶端通過路由服務拿到對應的緩存節(jié)點地址，在我們的生產(chǎn)環(huán)境中，每個機房的 ZK 都是獨立部署的，即不同機房的 ZK 實例屬于不同的 ZK 集群，同時每個機房的業(yè)務客戶端直接訪問本機房的 ZK 獲取緩存節(jié)點。
在 R2M 中，每個機房的 ZK 路由節(jié)點存儲的配置全部相同，我們保持 ZK 路由節(jié)點中的信息盡量簡單，所有集群狀態(tài)相關的東西都不在 ZK 上，基本是靜態(tài)配置，只有擴容或下線節(jié)點時才需要更改配置。所以，當機房切換時，不需要對 ZK 做任何變更。
業(yè)務客戶端本身是多機房部署的，不存在多機房問題，但客戶端需要在緩存集群發(fā)生多機房切換后及時把服務路由到切換后的機房，這就需要通知分布于多個機房的各個客戶端，并與每個客戶端維持或建立連接，無疑是一大麻煩事。
在 R2M 中，由于客戶端是 smart client，當感知到異常時，可以從存活的節(jié)點中重新獲取集群狀態(tài)，自動感知節(jié)點角色變更并切換，也就不存在通知的問題了。
Manager 是緩存集群的管理組件，運維操作包括機房切換操作都是通過它來進行，所以必須做到 Manager 本身的多機房才能保證可以隨時進行機房容災切換或正常切換。
需要注意的是，由于不同機房的 ZK 是獨立的，Manager 的多機房切換不能直接依賴于 ZK 來實現(xiàn)，因為有可能剛好被依賴的那個 ZK 所在的機房掛掉了，所以，我們實現(xiàn)了 Manager 的多機房選舉 (類 Raft 機制) 功能，多個 Manager 可以自行選舉 leader、自動 failover。
對于 Web console 的多機房切換，這個就相對簡單了。由于 Web 是無狀態(tài)的，直接通過 Nginx 做負載均衡，只要有任意一個機房的 Web 組件可用就可以了。
業(yè)務出現(xiàn)調(diào)用超時、性能指標出現(xiàn)抖動怎么辦？
一次業(yè)務調(diào)用可能涉及多個服務，比如消息隊列、數(shù)據(jù)庫、緩存、RPC，如何確認不是緩存的問題？
如果是緩存服務的問題，是機器問題、網(wǎng)絡問題、系統(tǒng)問題、還是業(yè)務使用不當問題？
當出現(xiàn)上述問題時，面對大量機器、集群以及無數(shù)的實例，如果沒有一套完善的監(jiān)控與告警系統(tǒng)，沒有一個方便易用的可視化操作界面，那只能茫然無措、一籌莫展，耐心地一個一個實例的看日志、查 info 輸出，查網(wǎng)絡、查機器，所謂人肉運維。
因此，R2M 提供了各種維度的監(jiān)控指標和告警功能，及時對異常情況進行預警，當問題出現(xiàn)時，也能夠快速定位排查方向。
每臺機器的網(wǎng)絡 QoS(丟包率、包重傳次數(shù)、發(fā)送接收錯誤數(shù))、流入流出帶寬、CPU、內(nèi)存使用量、磁盤讀寫速率等。
每個節(jié)點的內(nèi)存使用量、網(wǎng)絡流入流出流量、TPS、查詢命中率、客戶端 TCP 連接數(shù)、key 淘汰數(shù)、慢查詢命令記錄、實例運行日志等。
實時和歷史統(tǒng)計圖表是對各項參數(shù)指標的實時反饋和歷史走勢的直觀展示，不僅能在出問題時快速給出定位的方向，還能夠對運維和業(yè)務開發(fā)提供非常有價值的參考數(shù)據(jù)，這些參考數(shù)據(jù)也反過來促進業(yè)務系統(tǒng)進行優(yōu)化、促進更好地運維。
對于實例的歷史監(jiān)控統(tǒng)計數(shù)據(jù)，由每個機器上部署的 Agent 組件負責收集并上報。由于實例數(shù)及監(jiān)控項非常多，監(jiān)控數(shù)據(jù)量可能會非常大。
為了避免監(jiān)控數(shù)據(jù)占用大量數(shù)據(jù)庫空間，對于歷史統(tǒng)計數(shù)據(jù)，我們會保留展示最近 12 小時以分鐘為維度、最近一個月以小時為維度、以及最近一年以天為維度的數(shù)據(jù)，12 小時以前的分鐘數(shù)據(jù)自動合并為小時維度的數(shù)據(jù)，一個月以前的小時數(shù)據(jù)自動合并為天維度的數(shù)據(jù)，在合并時，保留這個時間段的指標最高值、最低值、以及累加后的平均值。
對于實時監(jiān)控圖表，則是用戶請求查看時才與對應的緩存實例建立連接，直接從實例獲取實時信息。
每個客戶端的 TP50、TP90、TP99、TP999 請求耗時統(tǒng)計，快速定位問題 IP。
容量告警、流入流出流量、TPS、實例阻塞、實例停止服務、客戶端連接數(shù)等。
限于篇幅原因，這里只能對 R2M 緩存系統(tǒng)大致的設計思路和功能做一個簡要的介紹，很多細節(jié)和原理性的東西沒能一一詳述，比如數(shù)據(jù)的冷熱交換，實際上做這個東西的過程中我們遇到了很多的挑戰(zhàn)，也希望以后能對這塊做詳細的介紹。最后，也希望有更多的技術同仁擁抱和參與開源，讓大家有更多更好的輪子用。
