互聯網應用特點三高：高並發、高可用、高性能，要達到這幾個目標，好的方法方式是建立相應指標，
來進行准確描述，有了准確指標進行監控，方能易於實現我們設定目標。
先將指標介紹下，方便下面相關術語使用，qps即每秒處理請求數，是一個機器性能重要描述指標，通
過它我們知道單個容器能處理最大請求數。目前JD所有線上服務均在Docker容器中運行。
tp99、tp999性能監控指標，TP=Top Percentile，Top百分數，是一個統計學里的術語，與平均數、中
位數都是一類。TP50、TP90和TP99等指標常用於系統性能監控場景，指高於50%、90%、99%等百分線
的情況。
可用率（Availability）指一個網絡或設備在一個給定的時間間隔內可操作的總時間與時間間隔的比。例如，
99.99%, 指一個網絡或網站系統（或其它設備）一個給定的時期內處於可操作狀態的時間總量，可用性用比率
來衡量。
有了指標要達到高並發、高可用、高性能，需要我們增加服務處理請求能力，即提升qps，降低每個請求
處理時間，我們線上服務處理tp99、999一般要求在50ms以下，線上服務依賴於存儲處理能力。
互聯網服務處理高並發最早是提升數據庫db tps，來達到處理高並發、保證服務高可用、高性能核心。核
心是提升文件系統IO，將數據庫緩存、磁盤IO用到極致，提升db tps達到提升線上服務qps目的，在硬盤介質限
定下提升tps是極難的。
后來雅虎通過緩存、分布式內存緩存方式將存儲tps提升了多個數量級。存儲不在成為應用處理請求瓶頸，
帶來互聯網應用快速發展，提供了基礎保證。早期時使用memcache，目前互聯網公司使用更多的是redis。
redis是一種極其高效分布式內存緩存系統，由c語言開發，支持String、Hash、Map等多種數據結構，極
高qps讀寫處理能力，支持磁盤持久化，並且極其穩定，不會出現集群當機情況，因其上邊這些出色表現，是目
前互聯網公司首選存儲引擎。
JD目前基本基於redis研發自己解決方案，目前除了核心交易流程，據我了解大部分業務數據甚至只存儲在
redis中。
redis性能，平時查詢用的多的，get處理在1ms甚至以下，mGet處理一般在5-10ms之間，性能表現極其優秀。
redis雖然有很出色表現，但也有很多使用方法上需要注意的地方，線上微服務突然性能差，半夜2點被人找
服務性能差時候，一定要有快速定位問題能力，能力主要來自於平時多思考、以及以前處理問題經驗記錄。
微服務突然性能差，有多個可能原因。分類的話大概三類一是硬件問題：微服務節點性能差導致服務性能差，
下掉服務節點，解決問題。
二是服務本身問題：服務本身有邏輯bug，有部分用戶觸發到邏輯bug導致又死循環，或多線程用hashmap
使用不對，例如：記一次雙11大促壓測線上服務cpu100%。
三線上服務和redis相關問題導致性能差：redis遇到過單節點tcp包重傳過多，導致單點差，最終導致集群性
能差；再有redis單個節點容器壞了導致性能差，下掉單點問題解決；redis寫有大value數據並且在持續更新，遇到
空pin寫redis導致節點性能差，因為空pin即為登陸用戶很多，最終集群性能差，停止空pin寫問題解決；再有就是
讀熱點，但個key被全網獨取，這種數據解決方式是起定時線程拉取，而不要通過用戶觸發，避免這些問題redis用
起來得心應手。
總結一下：為了實現應用三高受限於硬件IO很難提升tps以及qps，換個思路通過分布式緩存一下將應用性能
提升多個數量級，思路升級一下解決很多問題，我們解決其他問題也可換個角度看問題，再有就是當下互聯網公司
比如JD已經拿緩存當db用，電商都可以用，大家大部分業務都可以放心使用，但要注意集群維護，也了解到redis
官方開源分布式集群方案在線上服務用沒有任何問題，有團隊在這么用。
分享一下redis應用場景，希望大家能方便實現線上高並發、高可用、高性能目標。
掃碼關注公眾號