互联网应用特点三高：高并发、高可用、高性能，要达到这几个目标，好的方法方式是建立相应指标，
来进行准确描述，有了准确指标进行监控，方能易于实现我们设定目标。
先将指标介绍下，方便下面相关术语使用，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应用场景，希望大家能方便实现线上高并发、高可用、高性能目标。
扫码关注公众号