Category Archives: 高并发

Linux、mysql、tomcat大并发下的配置

Linux, MySQL, Tomcat, 高并发, ,

一、前言
因为之前一直没太接触过项目实现部署的问题，所以中间出现了N多问题，现在有时间了，做了一个整理，已备后用。此处不包括上一层服务器的负载，如使用nginx/apache等。

二、实现
mysql:
1. 最大连接数：
配置项目中的连接池最大连接数 <= mysql的max_connections(如项目有集群，则乘N)
可解决出现：MySQL 提示 Too many connections ( 1040 )

SELECT @@max_connections; -- 查看现有设置数量

临时解决方案：

set global max_connections = 3600; -- 重启后失效

最终解决方案：
1）首先修改/etc/my.cnf(Ubuntu 10下为/etc/mysql/my.cnf)

Linux: vi /etc/my.cnf

2）在[mysqld]最后增加一行

max_connections=5000

3）重新启动mysql

Linux: service mysqld start

2. 序列
非主键的WHERE条件，则可增加序列。

3. 数据类型
相关联的两表中的相同字段长度要一致，mysql取值如果满足可用占用空间小的，如tinyint、smallint等等

tomcat:
catalina.sh  在cygwin=false前面添加

JAVA_OPTS="-server -Xms512M -Xmx512M -Xss256K -Djava.awt.headless=true -Dfile.encoding=utf-8 -XX:PermSize=64M -XX:MaxPermSize=128m"

server.xml

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="1000" minSpareThreads="350" />

 

<Connector port="8080"
        protocol="org.apache.coyote.http11.Http11NioProtocol" // NIO
        executor="tomcatThreadPool" // Executor 线程池
        compression="on"
        compressionMinSize="2048"
        maxThreads="30000" //设定处理客户请求的线程的最大数目，决定了服务器可以同时响应客户请求的数,默认200
        minSpareThreads="512" //初始化线程数，最小空闲线程数，默认为10
        maxSpareThreads="2048"
        enableLookups="false" //关闭DNS反向查询，性能高设false
        redirectPort="8443"
        acceptCount="35000" //当所有可以使用的处理请求的线程数都被使用时，可以被放到处理队列中请求数，请求数超过这个数的请求将不予处理，默认100
        debug="0"
        connectionTimeout="40000"
        disableUploadTimeout="true" URIEncoding="UTF-8" useBodyEncodingForURI="true" />

 

引用

linux:
查询ulimit命令

# 显示当前所有的 limit 信息
Linux: ulimit -a
# Linux操作系统对一个进程可以打开最大文件描述符的数量
Linux: ulimit -n
# 用户最大可用的进程数
Linux: ulimit -u

1. 句柄数：ulimit -n
问题： Can’t open so many files
临时解决方案:

ulimit -SHn 65535

最终解决方案，在/etc/security/limits.conf文件中设置最大打开文件数 添加：

Linux: vi /etc/security/limits.conf

 

# *代表针对所有用户
*      soft    nofile        65535       
*      hard    nofile        65535

最后用重启ulimit -a再次查看，open files的值，如果改过来，则生效。

2. 用户进程数：ulimit -u
比如我们在模拟大规模http并发测试的时候，客户端会报一个无法fork new proc异常，原因是受到了最大进程1024的限制，解除 Linux 系统的最大进程数
解决方案：修改/etc/security/limits.d/90-nproc.conf

Linux: vim /etc/security/limits.d/90-nproc.conf

 

# 添加如下的行
*          soft    nproc     102400
root       soft    nproc     102400

3. 网络参数
修改/etc/sysctl.cnf文件，增加如下内容

Linux: vim /etc/sysctl.cnf

 

net.core.netdev_max_backlog = 32768 
net.core.somaxconn = 32768 
net.core.wmem_default = 8388608 
net.core.rmem_default = 8388608 
net.core.rmem_max = 16777216 
net.core.wmem_max = 16777216 
net.ipv4.ip_local_port_range = 1024 65000 
net.ipv4.route.gc_timeout = 100 
net.ipv4.tcp_fin_timeout = 30 
net.ipv4.tcp_keepalive_time = 1200 
net.ipv4.tcp_timestamps = 0 
net.ipv4.tcp_synack_retries = 2 
net.ipv4.tcp_syn_retries = 2 
net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_mem = 94500000 915000000 927000000 
net.ipv4.tcp_max_orphans = 3276800 
net.ipv4.tcp_max_syn_backlog = 65536

保存退出，执行sysctl命令，重新加载内核参数立刻生效

Linux: sysctl -p

 

引用
from:http://itindex.net/detail/54557-linux-mysql-tomcat

扛住100亿次请求？我们来试一试

架构, 高并发

作者：ppmsn2005#gmail.com
项目: https://github.com/xiaojiaqi/10billionhongbaos
wiki: https://github.com/xiaojiaqi/10billionhongbaos/wiki/扛住100亿次请求？我们来试一试

1. 前言

前几天，偶然看到了 《扛住100亿次请求——如何做一个“有把握”的春晚红包系统”》（url）一文，看完以后，感慨良多，收益很多。正所谓他山之石，可以攻玉，虽然此文发表于2015年,我看到时已经是2016年末，但是其中的思想仍然是可以为很多后端设计借鉴，。同时作为一个工程师，看完以后又会思考，学习了这样的文章以后，是否能给自己的工作带来一些实际的经验呢？所谓纸上得来终觉浅，绝知此事要躬行，能否自己实践一下100亿次红包请求呢？否则读完以后脑子里能剩下的东西 不过就是100亿 1400万QPS整流 这样的字眼，剩下的文章将展示作者是如何以此过程为目标，在本地环境的模拟了此过程。

实现的目标: 单机支持100万连接，模拟了摇红包和发红包过程，单机峰值QPS 6万，平稳支持了业务。

注：本文以及作者所有内容，仅代表个人理解和实践，过程和微信团队没有任何关系，真正的线上系统也不同，只是从一些技术点进行了实践，请读者进行区分。因作者水平有限，有任何问题都是作者的责任，有问题请联系 ppmsn2005#gmail.com. 全文内容 扛住100亿次请求？我们来试一试

2. 背景知识

QPS: Queries per second 每秒的请求数目

PPS：Packets per second 每秒数据包数目

摇红包：客户端发出一个摇红包的请求，如果系统有红包就会返回，用户获得红包

发红包：产生一个红包里面含有一定金额，红包指定数个用户，每个用户会收到红包信息，用户可以发送拆红包的请求，获取其中的部分金额。

3. 确定目标

在一切系统开始以前，我们应该搞清楚我们的系统在完成以后，应该有一个什么样的负载能力。

3.1 用户总数:

通过文章我们可以了解到接入服务器638台, 服务上限大概是14.3亿用户， 所以单机负载的用户上限大概是14.3亿/638台=228万用户/台。但是目前中国肯定不会有14亿用户同时在线，参考 http://qiye.qianzhan.com/show/detail/160818-b8d1c700.html 的说法，2016年Q2 微信用户大概是8亿，月活在5.4 亿左右。所以在2015年春节期间，虽然使用的用户会很多，但是同时在线肯定不到5.4亿。

3.2. 服务器数量：

一共有638台服务器，按照正常运维设计，我相信所有服务器不会完全上线，会有一定的硬件冗余，来防止突发硬件故障。假设一共有600台接入服务器。

3.3 单机需要支持的负载数：

每台服务器支持的用户数：5.4亿/600 = 90万。也就是平均单机支持90万用户。如果真实情况比90万更多，则模拟的情况可能会有偏差，但是我认为QPS在这个实验中更重要。

3.4. 单机峰值QPS：

文章中明确表示为1400万QPS.这个数值是非常高的，但是因为有600台服务器存在，所以单机的QPS为 1400万/600= 约为2.3万QPS, 文章曾经提及系统可以支持4000万QPS，那么系统的QPS 至少要到4000万/600 = 约为 6.6万, 这个数值大约是目前的3倍，短期来看并不会被触及。但是我相信应该做过相应的压力测试。

3.5. 发放红包：

文中提到系统以5万个每秒的下发速度，那么单机每秒下发速度50000/600 ＝83个/秒,也就是单机系统应该保证每秒以83个的速度下发即可。
最后考虑到系统的真实性，还至少有用户登录的动作，拿红包这样的业务。真实的系统还会包括聊天这样的服务业务。

最后整体的看一下 100亿次摇红包这个需求，假设它是均匀地发生在春节联欢晚会的4个小时里，那么服务器的QPS 应该是10000000000/600/3600/4.0=1157. 也就是单机每秒1000多次，这个数值其实并不高。如果完全由峰值速度1400万消化 10000000000/(1400*10000) = 714秒，也就是说只需要峰值坚持11分钟，就可以完成所有的请求。可见互联网产品的一个特点就是峰值非常高，持续时间并不会很长。

总结：

从单台服务器看.它需要满足下面一些条件
1. 支持至少100万连接用户
2. 每秒至少能处理2.3万的QPS，这里我们把目标定得更高一些 分别设定到了3万和6万。
3. 摇红包：支持每秒83个的速度下发放红包，也就是说每秒有2.3万次摇红包的请求，其中83个请求能摇到红包，其余的2.29万次请求会知道自己没摇到。当然客户端在收到红包以后，也需要确保客户端和服务器两边的红包数目和红包内的金额要一致。因为没有支付模块，所以我们也把要求提高一倍，达到200个红包每秒的分发速度
4. 支持用户之间发红包业务，确保收发两边的红包数目和红包内金额要一致。同样也设定200个红包每秒的分发速度为我们的目标。

想完整模拟整个系统实在太难了，首先需要海量的服务器，其次需要上亿的模拟客户端。这对我来说是办不到，但是有一点可以确定，整个系统是可以水平扩展的，所以我们可以模拟100万客户端，在模拟一台服务器 那么就完成了1/600的模拟。

和现有系统区别：
和大部分高QPS测试的不同，本系统的侧重点有所不同。我对2者做了一些对比。

常见高QPS系统压力测试 本系统压力测试
连接数 一般<1000 （几百以内） 1000000 (1百万)
单连接吞吐量 非常大 每个连接几十M字节吞吐 非常小 每个连接每次几十个字节
需要的IO次数 不多 非常多

4. 基础软件和硬件

4.1软件：

Golang 1.8r3 , shell, python (开发没有使用c++ 而是使用了golang, 是因为使用golang 的最初原型达到了系统要求。虽然golang 还存在一定的问题，但是和开发效率比，这点损失可以接受)
服务器操作系统:
Ubuntu 12.04
客户端操作系统:
debian 5.0

4.2硬件环境

服务端： dell R2950。 8核物理机，非独占有其他业务在工作，16G内存。这台硬件大概是7年前的产品，性能应该不是很高要求。
服务器硬件版本：
machine
服务器CPU信息：
cpu

客户端： esxi 5.0 虚拟机,配置为4核 5G内存。一共17台，每台和服务器建立6万个连接。完成100万客户端模拟

5. 技术分析和实现

5.1) 单机实现100万用户连接

这一点来说相对简单，笔者在几年前就早完成了单机百万用户的开发以及操作。现代的服务器都可以支持百万用户。相关内容可以查看   github代码以及相关文档。
https://github.com/xiaojiaqi/C1000kPracticeGuide
系统配置以及优化文档：
https://github.com/xiaojiaqi/C1000kPracticeGuide/tree/master/docs/cn

5.2) 3万QPS

这个问题需要分2个部分来看客户端方面和服务器方面。

客户端QPS

因为有100万连接连在服务器上，QPS为3万。这就意味着每个连接每33秒，就需要向服务器发一个摇红包的请求。因为单IP可以建立的连接数为6万左右， 有17台服务器同时模拟客户端行为。我们要做的就保证在每一秒都有这么多的请求发往服务器即可。
其中技术要点就是客户端协同。但是各个客户端的启动时间，建立连接的时间都不一致，还存在网络断开重连这样的情况，各个客户端如何判断何时自己需要发送请求，各自该发送多少请求呢？

我是这样解决的：利用NTP服务，同步所有的服务器时间，客户端利用时间戳来判断自己的此时需要发送多少请求。
算法很容易实现：
假设有100万用户，则用户id 为0-999999.要求的QPS为5万， 客户端得知QPS为5万，总用户数为100万，它计算 100万/5万=20，所有的用户应该分为20组，如果 time() % 20 == 用户id % 20，那么这个id的用户就该在这一秒发出请求，如此实现了多客户端协同工作。每个客户端只需要知道 总用户数和QPS 就能自行准确发出请求了。
（扩展思考：如果QPS是3万 这样不能被整除的数目，该如何办？如何保证每台客户端发出的请求数目尽量的均衡呢？）

服务器QPS

服务器端的QPS相对简单，它只需要处理客户端的请求即可。但是为了客观了解处理情况，我们还需要做2件事情。
第一: 需要记录每秒处理的请求数目，这需要在代码里埋入计数器。
第二: 我们需要监控网络，因为网络的吞吐情况，可以客观的反映出QPS的真实数据。为此，我利用python脚本 结合ethtool 工具编写了一个简单的工具，通过它我们可以直观的监视到网络的数据包通过情况如何。它可以客观的显示出我们的网络有如此多的数据传输在发生。
工具截图： 工具截图

5.3) 摇红包业务

摇红包的业务非常简单，首先服务器按照一定的速度生产红包。红包没有被取走的话，就堆积在里面。服务器接收一个客户端的请求，如果服务器里现在有红包就会告诉客户端有，否则就提示没有红包。
因为单机每秒有3万的请求，所以大部分的请求会失败。只需要处理好锁的问题即可。
我为了减少竞争，将所有的用户分在了不同的桶里。这样可以减少对锁的竞争。如果以后还有更高的性能要求，还可以使用 高性能队列——Disruptor来进一步提高性能。

注意，在我的测试环境里是缺少支付这个核心服务的，所以实现的难度是大大的减轻了。另外提供一组数字：2016年淘宝的双11的交易峰值仅仅为12万/秒，微信红包分发速度是5万/秒，要做到这点是非常困难的。（http://mt.sohu.com/20161111/n472951708.shtml）

5.4) 发红包业务

发红包的业务很简单，系统随机产生一些红包，并且随机选择一些用户，系统向这些用户提示有红包。这些用户只需要发出拆红包的请求，系统就可以随机从红包中拆分出部分金额，分给用户，完成这个业务。同样这里也没有支付这个核心服务。

5.5）监控

最后 我们需要一套监控系统来了解系统的状况，我借用了我另一个项目(https://github.com/xiaojiaqi/fakewechat) 里的部分代码完成了这个监控模块，利用这个监控，服务器和客户端会把当前的计数器内容发往监控，监控需要把各个客户端的数据做一个整合和展示。同时还会把日志记录下来，给以后的分析提供原始数据。 线上系统更多使用opentsdb这样的时序数据库，这里资源有限,所以用了一个原始的方案

监控显示日志大概这样
监控日志

6. 代码实现及分析

在代码方面，使用到的技巧实在不多，主要是设计思想和golang本身的一些问题需要考虑。
首先golang的goroutine 的数目控制，因为至少有100万以上的连接，所以按照普通的设计方案，至少需要200万或者300万的goroutine在工作。这会造成系统本身的负担很重。
其次就是100万个连接的管理，无论是连接还是业务都会造成一些心智的负担。
我的设计是这样的：

架构图

首先将100万连接分成多个不同的SET，每个SET是一个独立，平行的对象。每个SET 只管理几千个连接，如果单个SET 工作正常，我只需要添加SET就能提高系统处理能力。
其次谨慎的设计了每个SET里数据结构的大小，保证每个SET的压力不会太大，不会出现消息的堆积。
再次减少了gcroutine的数目，每个连接只使用一个goroutine,发送消息在一个SET里只有一个gcroutine负责，这样节省了100万个goroutine。这样整个系统只需要保留 100万零几百个gcroutine就能完成业务。大量的节省了cpu 和内存
系统的工作流程大概如下：
每个客户端连接成功后，系统会分配一个goroutine读取客户端的消息，当消息读取完成，将它转化为消息对象放至在SET的接收消息队列，然后返回获取下一个消息
在SET内部，有一个工作goroutine，它只做非常简单而高效的事情，它做的事情如下，检查SET的接受消息，它会收到3类消息

1， 客户端的摇红包请求消息

2， 客户端的其他消息 比如聊天 好友这一类

3， 服务器端对客户端消息的回应

对于 第1种消息 客户端的摇红包请求消息 是这样处理的，从客户端拿到摇红包请求消息，试图从SET的红包队列里 获取一个红包，如果拿到了就把红包信息 返回给客户端，否则构造一个没有摇到的消息，返回给对应的客户端。
对于第2种消息 客户端的其他消息 比如聊天 好友这一类，只需简单地从队列里拿走消息，转发给后端的聊天服务队列即可，其他服务会把消息转发出去。
对于第3种消息 服务器端对客户端消息的回应。SET 只需要根据消息里的用户id，找到SET里保留的用户连接对象，发回去就可以了。

对于红包产生服务，它的工作很简单，只需要按照顺序在轮流在每个SET的红包产生对列里放至红包对象就可以了。这样可以保证每个SET里都是公平的，其次它的工作强度很低，可以保证业务稳定。

见代码
https://github.com/xiaojiaqi/10billionhongbaos

7实践

实践的过程分为3个阶段

阶段1：

分别启动服务器端和监控端，然后逐一启动17台客户端，让它们建立起100万的链接。在服务器端，利用ss 命令 统计出每个客户端和服务器建立了多少连接。
命令如下：
Alias ss2=Ss –ant | grep 1025 | grep EST | awk –F: “{print \$8}” | sort | uniq –c’

结果如下： 100万连接建立

阶段2：

利用客户端的http接口，将所有的客户端QPS 调整到3万，让客户端发出3W QPS强度的请求。
运行如下命令：
启动脚本

观察网络监控和监控端反馈，发现QPS 达到预期数据
网络监控截图
3万qps

在服务器端启动一个产生红包的服务，这个服务会以200个每秒的速度下发红包，总共4万个。此时观察客户端在监控上的日志，会发现基本上以200个每秒的速度获取到红包。

摇红包

等到所有红包下发完成后，再启动一个发红包的服务，这个服务系统会生成2万个红包，每秒也是200个，每个红包随机指定3位用户，并向这3个用户发出消息，客户端会自动来拿红包，最后所有的红包都被拿走。

发红包

阶段3

利用客户端的http接口，将所有的客户端QPS 调整到6万，让客户端发出6W QPS强度的请求。

6wqps

如法炮制，在服务器端，启动一个产生红包的服务，这个服务会以200个每秒的速度下发红包。总共4万个。此时观察客户端在监控上的日志，会发现基本上以200个每秒的速度获取到红包。
等到所有红包下发完成后，再启动一个发红包的服务，这个服务系统会生成2万个红包，每秒也是200个，每个红包随机指定3位用户，并向这3个用户发出消息，客户端会自动来拿红包，最后所有的红包都被拿走。

最后，实践完成。

8 分析数据

在实践过程中，服务器和客户端都将自己内部的计数器记录发往监控端，成为了日志。我们利用简单python 脚本和gnuplt 绘图工具，将实践的过程可视化，由此来验证运行过程。

第一张是 客户端的QPS发送数据
客户端qps
这张图的横坐标是时间，单位是秒，纵坐标是QPS，表示这时刻所有客户端发送的请求的QPS。
图的第一区间，几个小的峰值，是100万客户端建立连接的， 图的第二区间是3万QPS 区间，我们可以看到数据 比较稳定的保持在3万这个区间。最后是6万QPS区间。但是从整张图可以看到QPS不是完美地保持在我们希望的直线上。这主要是以下几个原因造成的

  1. 当非常多goroutine 同时运行的时候，依靠sleep 定时并不准确，发生了偏移。我觉得这是golang本身调度导致的。当然如果cpu比较强劲，这个现象会消失。
  2. 因为网络的影响，客户端在发起连接时，可能发生延迟，导致在前1秒没有完成连接。
  3. 服务器负载较大时，1000M网络已经出现了丢包现象，可以通过ifconfig 命令观察到这个现象，所以会有QPS的波动。

第二张是 服务器处理的QPS图
服务器qps

和客户端的向对应的，服务器也存在3个区间，和客户端的情况很接近。但是我们看到了在大概22：57分，系统的处理能力就有一个明显的下降，随后又提高的尖状。这说明代码还需要优化。

整体观察在3万QPS区间，服务器的QPS比较稳定，在6万QSP时候，服务器的处理就不稳定了。我相信这和我的代码有关，如果继续优化的话，还应该能有更好的效果。

将2张图合并起来 qps

基本是吻合的，这也证明系统是符合预期设计的。

这是红包生成数量的状态变化图
生成红包

非常的稳定。

这是客户端每秒获取的摇红包状态
获取红包

可以发现3万QPS区间，客户端每秒获取的红包数基本在200左右，在6万QPS的时候，以及出现剧烈的抖动，不能保证在200这个数值了。我觉得主要是6万QPS时候，网络的抖动加剧了，造成了红包数目也在抖动。

最后是golang 自带的pprof 信息，其中有gc 时间超过了10ms, 考虑到这是一个7年前的硬件，而且非独占模式，所以还是可以接受。
pprof

总结：

按照设计目标，我们模拟和设计了一个支持100万用户，并且每秒至少可以支持3万QPS，最多6万QPS的系统，简单模拟了微信的摇红包和发红包的过程。可以说达到了预期的目的。
如果600台主机每台主机可以支持6万QPS，只需要7分钟就可以完成 100亿次摇红包请求。

虽然这个原型简单地完成了预设的业务，但是它和真正的服务会有哪些差别呢？我罗列了一下

区别 真正服务 本次模拟
业务复杂 更复杂 非常简单
协议 Protobuf 以及加密 简单的协议
支付 复杂 无
日志 复杂 无
性能 更高 无
用户分布 用户id分散在不同服务器，需要hash以后统一， 复杂。 用户id 连续，很多优化使代码简单 非常高效
安全控制 复杂 无
热更新及版本控制 复杂 无
监控 细致 简单

Refers：

瞬时高并发（秒杀/活动）Redis方案

架构, 高并发,
1，Redis
  • 丰富的数据结构（Data Structures）
    • 字符串（String）
      • Redis字符串能包含 任意类型的数据
      • 一个字符串类型的值最多能存储 512M字节的内容
      • 利用 INCR命令簇（ INCR, DECR, INCRBY）来把字符串当作 原子计数器使用
      • 使用 APPEND命令在字符串后添加内容
    • 列表（List）
      • Redis列表是简单的字符串列表，按照插入顺序排序
      • 你可以添加一个元素到列表的 头部（左边：LPUSH）或者 尾部（右边：RPUSH）
      • 一个列表最多可以包含232-1个元素（4294967295，每个表超过 40亿个元素）
      • 在社交网络中建立一个时间线模型，使用 LPUSH去添加 新的元素到 用户时间线中，使用 LRANGE去检索一些 最近插入的条目
      • 你可以同时使用 LPUSH和 LTRIM去创建一个 永远不会超过指定元素数目的 列表并同时记住 最后的N个元素
      • 列表可以用来当作 消息传递的 基元（primitive），例如，众所周知的用来创建后台任务的Resque Ruby库
    • 集合（Set）
      • Redis集合是一个 无序的， 不允许相同成员存在的字符串合集（ Uniq操作，获取某段时间所有数据 排重值）
      • 支持一些服务端的命令从现有的集合出发去进行 集合运算，如合并（ 并集：union）,求交( 交集：intersection)， 差集, 找出不同元素的操作（共同好友、二度好友）
      • 用集合跟踪一个独特的事。想要知道所有访问某个博客文章的独立IP？只要每次都用SADD来处理一个页面访问。那么你可以肯定重复的IP是不会插入的（ 利用 唯一性，可以 统计访问网站的所有独立IP）
      • Redis集合能很好的表示 关系。你可以创建一个tagging系统，然后用集合来代表单个tag。接下来你可以用SADD命令把所有拥有tag的对象的所有ID添加进集合，这样来表示这个特定的tag。如果你想要同时有3个不同tag的所有对象的所有ID，那么你需要使用 SINTER
      • 使用 SPOP或者 SRANDMEMBER命令 随机地获取元素
    • 哈希（Hashes）
      • Redis Hashes是字符串字段和字符串值之间的映射
      • 尽管Hashes主要用来表示对象，但它们也能够 存储许多元素
    • 有序集合（Sorted Sets）
      • Redis有序集合和Redis集合类似，是 不包含相同字符串的合集
      • 每个有序集合的成员都 关联着一个评分，这个评分用于把有序集合中的成员按最低分到最高分排列（ 排行榜应用，取TOP N操作）
      • 使用有序集合，你可以非常快地（O(log(N))）完成添加，删除和更新元素的操作
      • 元素是在插入时就排好序的，所以很快地通过 评分(score)或者 位次(position)获得一个 范围的元素（需要 精准设定过期时间的应用）
      • 轻易地访问任何你需要的东西:  有序的元素， 快速的存在性测试， 快速访问集合中间元素
      • 在一个 巨型在线游戏中建立一个 排行榜，每当有新的记录产生时，使用 ZADD 来更新它。你可以用 ZRANGE轻松地获取 排名靠前的用户， 你也可以提供一个用户名，然后用 ZRANK获取他在 排行榜中的名次。 同时使用 ZRANK和 ZRANGE你可以获得与指定用户有相同分数的用户名单。 所有这些操作都非常迅速
      • 有序集合通常用来 索引存储在Redis中的数据。 例如：如果你有很多的hash来表示用户，那么你可以使用一个有序集合，这个集合的年龄字段用来当作评分，用户ID当作值。用 ZRANGEBYSCORE可以简单快速地检索到 给定年龄段的所有用户
  • 复制（Replication, Redis复制很简单易用，它通过配置允许slave Redis Servers或者Master Servers的复制品）
    • 一个Master可以有 多个Slaves
    • Slaves能 通过接口其他slave的链接，除了可以接受同一个master下面slaves的链接以外，还可以接受同一个结构图中的其他slaves的链接
    • redis 复制是在 master段是 非阻塞的，这就意味着master在同一个或多个slave端 执行同步的时候还可以 接受查询
    • 复制在 slave端也是非阻塞的，假设你在redis.conf中配置redis这个功能，当slave在执行的新的同步时，它仍可以用旧的数据信息来提供查询，否则，你可以配置当redis slaves去master失去联系是，slave会给发送一个客户端错误
    • 为了有多个slaves可以做只读查询， 复制可以重复2次，甚至多次，具有 可扩展性（例如：slaves对话与重复的排序操作，有多份数据冗余就相对简单了）
    • 他可以利用 复制去避免在master端保存数据，只要对master端redis.conf进行配置，就可以避免保存（所有的保存操作），然后通过slave的链接，来实时的保存在slave端
  • LRU过期处理（Eviction）
    • EVAL 和 EVALSHA 命令是从 Redis 2.6.0 版本开始的，使用内置的 Lua 解释器，可以对 Lua 脚本进行求值
    • Redis 使用 单个 Lua 解释器去运行所有脚本，并且， Redis 也保证脚本会以 原子性(atomic)的方式执行：  当某个脚本正在运行的时候，不会有其他脚本或 Redis 命令被执行。 这和使用 MULTI / EXEC  包围的事务很类似。 在其他别的客户端看来，脚本的效果(effect)要么是不可见的(not visible)，要么就是已完成的(already completed)
    • LRU过期处理（Eviction）
      • Redis允许为每一个key设置不同的 过期时间，当它们到期时将自动从服务器上删除（EXPIRE）
  • 事务
    • MULTI 、 EXEC 、 DISCARD 和  WATCH 是 Redis  事务的基础
    • 事务是一个 单独的隔离操作：事务中的所有 命令都会 序列化、按顺序地执行。事务在 执行的过程中， 不会被其他客户端发送来的命令请求所打断
    • 事务中的命令要么全部被执行，要么全部都不执行， EXEC 命令负责触发并执行事务中的所有命令
    • Redis 的 Transactions 提供的并 不是严格的 ACID 的事务
    • Transactions 还是提供了基本的 命令打包执行的功能： 可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行
    • Redis 还提供了一个  Watch 功能，你可以 对一个 key 进行 Watch，然后再 执行 Transactions，在这过程中，如果这个  Watched 的值进行了修改，那么这个  Transactions 会发现并拒绝执行
  • 数据持久化
    • RDB
      • 特点
        • RDB持久化方式能够在 指定的时间间隔能对你的 数据进行快照存储
      • 优点
        • RDB是一个非常 紧凑的文件,它保存了 某个时间点得数据集,非常 适用于数据集的备份
        • RDB是一个紧凑的单一文件, 非常 适用于灾难恢复
        • RDB在保存RDB文件时父进程唯一需要做的就是 fork出一个子进程,接下来的 工作全部由 子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以 最大化redis的性能
        • 与AOF相比,在 恢复大的数据集的时候， RDB方式会更快一些
      • 缺点
        • 如果你希望在 redis意外停止工作（例如电源中断）的情况下 丢失的数据最少的话，那么 RDB不适合，Redis要完整的 保存整个数据集是一个比较 繁重的工作
        • RDB 需要经常fork子进程来保存数据集到硬盘上,当 数据集比较大的时候, fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒, AOF也需要fork,但是你可以 调节重写日志文件的频率来提高数据集的耐久度
    • AOF
      • 特点
        • AOF持久化方式记录 每次对服务器写的操作
        • redis重启的时候会 优先载入AOF文件来 恢复原始的数据,因为在通常情况下 AOF文件保存的数据集要比 RDB文件保存的 数据集要完整
      • 优点
        • 使用AOF 会让你的Redis 更加耐久: 你可以使用不同的 fsync策略： 无fsync,每秒fsync,每次写的时候fsync
        • AOF文件是一个只 进行追加的日志文件,所以不需要写入seek
        • Redis 可以在 AOF 文件体积 变得过大时， 自动地在后台对  AOF 进行重写
        • AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此  AOF 文件的内容非常 容易被人读懂， 对文件进行 分析（parse）也很轻松。  导出（export） AOF 文件也非常简单
      • 缺点
        • 对于 相同的数据集来说， AOF 文件的体积通常要 大于 RDB 文件的体积
        • 根据所使用的  fsync 策略， AOF 的速度可能会 慢于 RDB
    • 选择
      • 同时使用 两种持久化功能
  • 分布式
    • Redis Cluster （Redis 3版本）
    • Keepalived
      • 当 Master挂了后， VIP漂移到Slave； Slave 上 keepalived 通知redis 执行：slaveof no one ,开始提供业务
      • 当 Master起来后， VIP 地址不变， Master的 keepalived 通知redis 执行slaveof slave IP host ，开始 作为从同步数据
      • 依次类推
    • Twemproxy
      • 快、轻量级、减少后端Cache Server连接数、易配置、支持ketama、modula、random、常用hash 分片算法
      • 对于客户端而言，r edis集群是透明的，客户端简单，遍于动态扩容
      • Proxy为 单点、处理一致性hash时，集群节点 可用性检测不存在脑裂问题
      • 高性能，CPU密集型，而 redis节点集群多CPU资源冗余，可部署在redis节点集群上，不需要额外设备
  • 高可用（HA）
    • Redis Sentinel（redis自带的集群管理工具 ）
      • 监控（Monitoring）： Redis Sentinel实时监控主服务器和从服务器运行状态
      • 提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Redis Sentinel 可以向系统管理员发送通知， 也可以通过 API 向其他程序发送通知
      • 自动故障转移（Automatic failover）： 当一个主服务器不能正常工作时，Redis Sentinel 可以将一个从服务器升级为主服务器， 并对其他从服务器进行配置，让它们使用新的主服务器。当应用程序连接到 Redis 服务器时， Redis Sentinel会告之新的主服务器地址和端口
    • 单M-S结构
      • 单M-S结构特点是在Master服务器中配置 Master Redis（Redis-1M）和 Master Sentinel（Sentinel-1M）
      • Slave服务器中配置 Slave Redis（Redis-1S）和 Slave Sentinel（Sentinel-1S）
      • 其中  Master Redis可以提供 读写服务，但是 Slave Redis只能提供 只读服务。因此，在业务压力比较大的情况下，可以选择将只读业务放在Slave Redis中进行
    • 双M-S结构
      • 双M-S结构的特点是在 每台服务器上配置一个 Master Redis，同时部署一个 Slave Redis。由两个 Redis Sentinel同时对 4个Redis进行监控。 两个Master Redis可以同时对应用程序提供 读写服务，即便其中一个服务器出现故障，另一个服务器也可以同时运行两个Master Redis提供读写服务
      • 缺点是 两个Master redis之间无法实现数据共享，不适合存在大量用户数据关联的应用使用
    • 单M-S结构和双M-S结构比较
      • 单M-S结构适用于 不同用户数据存在关联，但 应用可以实现读写分离的业务模式。 Master主要提供写操作，Slave主要提供读操作，充分利用硬件资源
      • 双（多）M-S结构适用于 用户间不存在或者存在较少的数据关联的业务模式， 读写效率是单M-S的两（多）倍，但 要求故障时单台服务器能够承担两个Mater Redis的资源需求
  • 发布/订阅（Pub/Sub）
  • 监控：Redis-Monitor
    • 历史redis运行查询： CPU、内存、命中率、请求量、主从切换等
    • 实时监控曲线
2，数据类型Redis使用场景
  • String
    •   计数器应用
  • List
    • 取 最新N个数据的操作
    • 消息队列
    • 删除与 过滤
    • 实时分析正在发生的情况，用于 数据统计与 防止垃圾邮件（结合Set）
  • Set
    • Uniqe操作，获取某段时间所有数据 排重值
    • 实时系统，反垃圾系统
    • 共同好友、二度好友
    • 利用 唯一性，可以 统计访问网站的所有 独立 IP
    • 好友推荐的时候，根据 tag  求交集，大于某个 threshold 就可以推荐
  • Hashes
    • 存储、读取、修改用户属性
  • Sorted Set
    • 排行榜应用，取 TOP N操作
    • 需要 精准设定过期时间的应用（时间戳作为Score）
    • 带有 权重的元素，比如一个游戏的用户得分排行榜
    • 过期项目处理，按照时间排序
3，Redis解决秒杀/抢红包等高并发事务活动
  • 秒杀开始前30分钟把秒杀库存从数据库同步到Redis Sorted Set
  • 用户秒杀 库存放入秒杀限制数长度的 Sorted Set
  • 秒杀到 指定秒杀数后， Sorted Set不在接受秒杀请求，并显示返回标识
  • 秒杀活动完全结束后， 同步Redis数据到数据库，秒杀正式结束