Linux环境安装2

最新推荐文章于 2024-04-27 22:16:46 发布

bobshute

最新推荐文章于 2024-04-27 22:16:46 发布

阅读量884

点赞数 15

文章标签： linux 运维服务器

本文链接：https://blog.csdn.net/bobshute/article/details/135320821

版权

1 redis单机版安装

1.1 安装

wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz
tar -xzvf tcl8.6.1-src.tar.gz
cd  /usr/local/tcl8.6.1/unix/
./configure  
make && make install

使用redis-3.2.8.tar.gz（截止2017年4月的最新稳定版）
cd /usr/local/
tar -zxvf redis-3.2.8.tar.gz
cd /usr/local/redis-3.2.8
make && make test && make install

执行最后提醒如下:

 87 seconds - unit/obuf-limits
  83 seconds - unit/geo

\o/ All tests passed without errors!

Cleanup: may take some time... OK
make[1]: Leaving directory `/usr/local/redis-3.2.8/src'
cd src && make install
make[1]: Entering directory `/usr/local/redis-3.2.8/src'

Hint: It's a good idea to run 'make test' ;)

    INSTALL install
    INSTALL install
    INSTALL install
    INSTALL install
    INSTALL install
make[1]: Leaving directory `/usr/local/redis-3.2.8/src'

1.2 启动配置

cp  /usr/local/redis-3.2.8/utils/redis_init_script /etc/init.d/redis_6379

vim /etc/init.d/redis_6379 开头增加如下内容
# chkconfig:   2345 90 10
# description:  Redis is a persistent key-value database

mkdir -p  /etc/redis/

cp  /usr/local/redis-3.2.8/redis.conf  /etc/redis/6379.conf

//修改文件内容
vim /etc/redis/6379.conf
	daemonize	yes							//让redis以daemon进程运行
	dir 		/var/redis/6379				//设置持久化文件的存储位置
	
mkdir -p /var/redis/6379

sh /etc/init.d/redis_6379 start

//执行命令
chkconfig redis_6379 on

3 Redis持久化

3.1 持久化概述

企业级redis集群架构：海量数据、高并发、高可用;

持久化主要是做灾难恢复，数据恢复，实现高可用;

redis如果挂了不可用,此时如果大量请求过来,缓存全部无法命中,就会产生缓存雪崩,后到mysql数据库中查询数据,mysql也可能会挂掉,所以要尽快恢复redis服务,重启(恢复)服务,然后从备份恢复数据;

redis提供的持久化方式包括RDB和AOF

redis总结3-持久化rdb,aof,运维命令,Sentinel监控

3.2 快照RDB (Redis DataBase)

3.2.1 实现方式

//可以查看redis总结1中的conf配置

##snapshot触发的时机，save <seconds> <changes> 
save 900 1      // 900内,有1条写入,则产生快照 
save 300 1000   // 如果300秒内有1000次写入,则产生快照
save 60 10000  // 如果60秒内有10000次写入,则产生快照
(这3个选项都屏蔽,则rdb禁用)

dbfilename dump.rdb  //导出来的rdb文件名
dir ./  //rdb的放置路径
rdbcompression yes    // 导出的rdb文件是否压缩,默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间  

//后台备份进程出错时,主进程停不停止写入;当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等 
stop-writes-on-bgsave-error yes   
Rdbchecksum   yes //  导入rbd恢复时数据时,要不要检验rdb的完整性
————————————————
版权声明：本文为CSDN博主「bobshute」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/bobshute/article/details/78138325

（1）redis根据配置自己尝试去生成rdb快照文件
（2）fork一个子进程出来
（3）子进程尝试将数据dump到临时的rdb快照文件中
（4）完成rdb快照文件的生成之后，就替换之前的旧的快照文件

3.3 日志AOF(Append-only file)

3.3.1 实现方式

##是否打开 aof日志功能;##只有在“yes”下，aof重写/文件同步等特性才会生效 
appendonly no 
##指定aof文件名称  
appendfilename appendonly.aof  

##同步策略-三种
##指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec  
##同步策略1-每1个命令,都立即同步到aof. 安全,速度慢
#每一条aof记录都立即同步到文件，这是最安全的方式，也以为更多的磁盘操作和阻塞延迟，是IO开支较大。
appendfsync always   

##同步策略2-每秒同步一次，性能和安全都比较中庸的方式，也是redis推荐的方式。如果遇到物理服务器故障，有可能导致最近一秒内aof记录丢失(可能为部分丢失)。
# 折衷方案,每秒写1次(每秒将os cache中的数据fsync到磁盘)
appendfsync everysec 

##同步测了3-redis并不直接调用文件同步，而是交给操作系统来处理，操作系统可以根据buffer填充情况/通道空闲时间等择机触发同步；这是一种普通的文件操作方式。性能较好，在物理服务器故障时，数据丢失量会因OS配置有关。
# 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快,
appendfsync no      


##在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no”  
no-appendfsync-on-rewrite  yes: 

##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb”(aof文件,至少超过64M时,重写)
auto-aof-rewrite-min-size 64mb 

##相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。  
#aof文件大小比起上次重写时的大小,增长率100%时,重写
##每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后  
##触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。  
auto-aof-rewrite-percentage 100 
————————————————
版权声明：本文为CSDN博主「bobshute」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/bobshute/article/details/78138325

AOF持久化，默认是关闭的，默认是打开RDB持久化
redis-check-aof --fix命令来修复破损的AOF文件

3.4 RDB vs AOF

3.4.1 RDB

原理: 设置1个或多个周期时间将redis内存中全部数据写为磁盘中1个或多个文件(1个文件代表一个时刻),
写文件效率: 写文件时是fork一个子进程在来执行生成RDB快照文件,如果文件特别大,可能会导致客户端的服务暂停数毫秒甚至数秒,所以不能让RDB的间隔太长否则对redis性能有影响;
文件大小:rdb文件精练小;
数据完整性: 由于是周期性的写入,两个周期之间如果宕机,则丢失的数据为上个周期到当前时刻的数据;
恢复速度: 恢复数据时RDB速度快,是一份数据文件，恢复的时候，直接加载到内存中即可;不过优先级低;
其他: 比aof适合做冷备

3.4.2 AOF

原理将redis写入的命令以append-only的模式写入一个日志文件中,只有一个文件,如果需要多个需要自定义定时任务处理, AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
对reids影响: AOF支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的不过不如RDB,如果一条命令写一次aof,则性能豆浆;
写文件效率: 以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复
文件大小:AOF是命令累记,通常比RDB数据快照文件更大
数据完整性: AOF会每隔1秒，通过一个后台线程执行一次fsync操作保证os cache中的数据写入磁盘中，最多丢失1秒钟的数据,如果宕机最多丢失1秒钟数据;
恢复速度: 恢复数据时速度慢,是命令集合恢复是要回放和执行所有的指令日志;优先级高(因为数据更完整);
其他: AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

3.4.3 总结

如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的久化机制;都需要将持久化的数据备份到其它磁盘或云服务等;
不要仅仅使用RDB，因为那样会导致你丢失很多数据
也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug
综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复
AOF和RDB同时工作
（1）如果RDB在执行snapshotting操作，那么redis不会执行AOF rewrite; 如果redis再执行AOF rewrite，那么就不会执行RDB snapshotting
（2）如果RDB在执行snapshotting，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成之后，才会去执行AOF rewrite
（3）同时有RDB snapshot文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整

3.5 持久化方案示例

（1）rdb和aof在持久化在指定同一目录 /usr/local/redis/snapshotting/yyyyMMdd 在该目录按照日期生成;
（2）写crontab定时调度脚本去做数据备份
（3）每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份
（4）每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份
（5）每次copy备份的时候，都把太旧的备份给删了
（6）每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去

1) 新增linux的sh脚 本1)redis_rdb_copy_hourly.sh (实现:每小时copy一次备份，删除48小时前的数据),脚本内容如下:
#!/bin/sh 
cur_date=`date +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date

del_date=`date -d -48hour +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$del_date



2 新增redis_rdb_copy_daily.sh(每天copy一次备份)
#!/bin/sh 

cur_date=`date +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date

del_date=`date -d -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date



添加linux定时任务
crontab -e

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh

3.6 数据恢复方案

3.6.1 redis进程挂掉

如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据,fsync everysec，最多就丢一秒的数

3.6.2 redis进程所在服务器挂掉

重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复,如果AOF文件破损，那么用redis-check-aof fix,
如果最新的AOF和RDB文件出现了丢失，则尝试某个最新的RDB数据副本进行数据恢复;注意先关闭aof，拷贝rdb备份，重启redis，确认数据恢复，直接在命令行热修改redis配置(redis config set热修改配置参数)，打开aof，这个redis就会将内存中的数据对应的日志，写入aof文件中,此时aof和rdb两份数据文件的数据就同步了

redis-cli
//查询配置值
config get appendonly
//设置配置值
config set appendonly yes

4.redis高并发

4.1 概述

redis不能支撑高并发的瓶颈为单机,单机不好高并发,单机在几万QPS
redis主要用在读多写少的场景, 写请求一秒钟几千，一两千,读一秒钟可达二十万次读
redis高并发支撑读通过写分离;主从架构 -> 读写分离 -> 支撑10万+读QPS的架构 ;
redis replication ,redis主从架构 -> 读写分离架构 -> 可支持水平扩展的读高并发架构;

4.2 redis replication(复制)

4.2.1 复制的完整流程

1). slave node启动，会记录master node信息,包括master node的host和ip(redis.conf中slaveof),
2). slave node内部有定时任务,每秒检查是否有新的master node要连接和复制，如发现就跟master node建立socket网络连接
3). slave node发送ping命令给master node
4). 口令认证，如果master设置了requirepass，那么salve node必须发送masterauth的口令过去进行认证
5). master node第一次执行全量复制，将所有数据发给slave node
6). master node后续持续将写命令，异步复制给slave node

4.2.1.1 全量复制过程

1). master执行bgsave，在本地生成一份rdb快照文件
2). master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节这个参数,对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s
3). master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve,node保存了rdb之后，再将新的写命令复制给salve node,client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败
4). slave node接收到rdb之后，清空自己的旧数据，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务
5). 如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF,
6). rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave aof rewrite，很耗费时间,
如果复制的数据量在4G~6G之间，那么很可能全量复制时间消耗到1分半到2分钟

4.2.1.2 增量复制

1). 如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制
2). master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB
3). msater就是根据slave发送的psync中的offset来从backlog中获取数据的

4.2.2、复制要点

A).resynchronization

当启动一个slave node的时候，它会发送一个PSYNC命令给master node
2.1) 如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据;
2.2) 否则如果是slave node第一次连接master node，那么会触发一次full resynchronization,
开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。
RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。

slave node如果跟master node有网络故障，断开了连接，会自动重连。

master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

B).offset

master和slave都会维护一个offset,
master会在自身不断累加offset，slave也会在自身不断累加offset,
slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset

C). backlog
master node有一个backlog，默认是1MB大小,
master node给slave node复制数据时，也会将数据在backlog中同步写一份;
backlog主要是用来做全量复制中断候的增量复制的
D). master run id
通过host+ip定位master node是不精准的(单机多服),通过info server可查看master run id,
如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制
如果需要不更改run id重启redis，可以使用redis-cli debug reload命令
E). psync
从节点使用psync从master node进行复制，psync runid offset,master node会根据自身的情况返回响应信息:
可能是FULLRESYNC runid offset触发全量复制，也可能是CONTINUE触发增量复制
F). heartbeat
主从节点互相都会发送heartbeat信息,master默认每隔10秒发送一次heartbeat，salve node每隔1秒发送一个heartbeat
G). 异步复制
master每次接收到写命令之后，现在内部写入数据，然后异步发送给slave node
H). 主从复制的断点续传
从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份,
master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。
如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制,
但是如果没有找到对应的offset，那么就会执行一次resynchronization;
I). 无磁盘化复制
master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了

repl-diskless-sync
repl-diskless-sync-delay，等待一定时长再开始复制，因为要等更多slave重新连接过来

J). 过期key处理
slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

4.2.3 replication使用注意点

1). redis采用异步方式复制数据到slave节点，不过redis 2.8开始，slave node会周期性地确认自己每次复制的数据量 - 2). 一个master node是可以配置多个slave node的,slave node也可以连接其他的slave node
3). slave node做复制的时候，是不会block master,node的正常工作的，也不会block对自己的查询操作，它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了
4). slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量
5). 主从架构，master节点，必须要使用持久化机制
6). 即使采用了高可用机制，slave node可以自动接管master node，但是也可能sentinal还没有检测到master failure，master node就自动重启了，还是可能导致上面的所有slave node数据清空故障

4.3 实战

4.3.1、启用复制，部署slave node

wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz
tar -xzvf tcl8.6.1-src.tar.gz
cd  /usr/local/tcl8.6.1/unix/
./configure  
make && make install

使用redis-3.2.8.tar.gz（截止2017年4月的最新稳定版）
tar -zxvf redis-3.2.8.tar.gz
cd redis-3.2.8
make && make test && make install

（1）redis utils目录下，有个redis_init_script脚本
（2）将redis_init_script脚本拷贝到linux的/etc/init.d目录中，将redis_init_script重命名为redis_6379，6379是我们希望这个redis实例监听的端口号
（3）修改redis_6379脚本的第6行的REDISPORT，设置为相同的端口号（默认就是6379）
（4）创建两个目录：/etc/redis（存放redis的配置文件），/var/redis/6379（存放redis的持久化文件）
（5）修改redis配置文件（默认在根目录下，redis.conf），拷贝到/etc/redis目录中，修改名称为6379.conf

（6）修改redis.conf中的部分配置为生产环境

daemonize	yes							让redis以daemon进程运行
pidfile		/var/run/redis_6379.pid 	设置redis的pid文件位置
port		6379						设置redis的监听端口号
dir 		/var/redis/6379				设置持久化文件的存储位置

（7）让redis跟随系统启动自动启动

在redis_6379脚本中，最上面，加入两行注释

# chkconfig:   2345 90 10

# description:  Redis is a persistent key-value database

chkconfig redis_6379 on

在slave node上配置：slaveof 192.168.1.1 6379，即可

也可以使用slaveof命令

4.3.2、强制读写分离

基于主从复制架构，实现读写分离

redis slave node只读，默认开启，slave-read-only

开启了只读的redis slave node，会拒绝所有的写操作，这样可以强制搭建成读写分离的架构

4.3.3、集群安全认证

master上启用安全认证，requirepass
master连接口令，masterauth

4.3.4、读写分离架构的测试

先启动主节点，eshop-cache01上的redis实例
再启动从节点，eshop-cache02上的redis实例

Redis slave node一直说没法连接到主节点的6379的端口

在搭建生产环境的集群的时候，不要忘记修改一个配置，bind

bind 127.0.0.1 -> 本地的开发调试的模式，就只能127.0.0.1本地才能访问到6379的端口

每个redis.conf中的bind 127.0.0.1 -> bind自己的ip地址
在每个节点上都: iptables -A INPUT -ptcp --dport 6379 -j ACCEPT

redis-cli -h ipaddr
info replication

在主上写，在从上读

4.4 压力测试

你如果要对自己刚刚搭建好的redis做一个基准的压测，测一下你的redis的性能和QPS（query per second）

redis自己提供的redis-benchmark压测工具，是最快捷最方便的，当然啦，这个工具比较简单，用一些简单的操作和场景去压测

4.4.1、对redis读写分离架构进行压测，单实例写QPS+单实例读QPS

redis-3.2.8/src

./redis-benchmark -h 192.168.31.187

-c <clients>       Number of parallel connections (default 50)
-n <requests>      Total number of requests (default 100000)
-d <size>          Data size of SET/GET value in bytes (default 2)

根据你自己的高峰期的访问量，在高峰期，瞬时最大用户量会达到10万+，-c 100000，-n 10000000，-d 50

各种基准测试，直接出来

1核1G，虚拟机

====== PING_INLINE ======
  100000 requests completed in 1.28 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.78% <= 1 milliseconds
99.93% <= 2 milliseconds
99.97% <= 3 milliseconds
100.00% <= 3 milliseconds
78308.54 requests per second

====== PING_BULK ======
  100000 requests completed in 1.30 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.87% <= 1 milliseconds
100.00% <= 1 milliseconds
76804.91 requests per second

====== SET ======
  100000 requests completed in 2.50 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

5.95% <= 1 milliseconds
99.63% <= 2 milliseconds
99.93% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
40032.03 requests per second

====== GET ======
  100000 requests completed in 1.30 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.73% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
76628.35 requests per second

====== INCR ======
  100000 requests completed in 1.90 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

80.92% <= 1 milliseconds
99.81% <= 2 milliseconds
99.95% <= 3 milliseconds
99.96% <= 4 milliseconds
99.97% <= 5 milliseconds
100.00% <= 6 milliseconds
52548.61 requests per second

====== LPUSH ======
  100000 requests completed in 2.58 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

3.76% <= 1 milliseconds
99.61% <= 2 milliseconds
99.93% <= 3 milliseconds
100.00% <= 3 milliseconds
38684.72 requests per second

====== RPUSH ======
  100000 requests completed in 2.47 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

6.87% <= 1 milliseconds
99.69% <= 2 milliseconds
99.87% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
40469.45 requests per second

====== LPOP ======
  100000 requests completed in 2.26 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

28.39% <= 1 milliseconds
99.83% <= 2 milliseconds
100.00% <= 2 milliseconds
44306.60 requests per second

====== RPOP ======
  100000 requests completed in 2.18 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

36.08% <= 1 milliseconds
99.75% <= 2 milliseconds
100.00% <= 2 milliseconds
45871.56 requests per second

====== SADD ======
  100000 requests completed in 1.23 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.94% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
81168.83 requests per second

====== SPOP ======
  100000 requests completed in 1.28 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.80% <= 1 milliseconds
99.96% <= 2 milliseconds
99.96% <= 3 milliseconds
99.97% <= 5 milliseconds
100.00% <= 5 milliseconds
78369.91 requests per second

====== LPUSH (needed to benchmark LRANGE) ======
  100000 requests completed in 2.47 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

15.29% <= 1 milliseconds
99.64% <= 2 milliseconds
99.94% <= 3 milliseconds
100.00% <= 3 milliseconds
40420.37 requests per second

====== LRANGE_100 (first 100 elements) ======
  100000 requests completed in 3.69 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

30.86% <= 1 milliseconds
96.99% <= 2 milliseconds
99.94% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
27085.59 requests per second

====== LRANGE_300 (first 300 elements) ======
  100000 requests completed in 10.22 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.03% <= 1 milliseconds
5.90% <= 2 milliseconds
90.68% <= 3 milliseconds
95.46% <= 4 milliseconds
97.67% <= 5 milliseconds
99.12% <= 6 milliseconds
99.98% <= 7 milliseconds
100.00% <= 7 milliseconds
9784.74 requests per second

====== LRANGE_500 (first 450 elements) ======
  100000 requests completed in 14.71 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.00% <= 1 milliseconds
0.07% <= 2 milliseconds
1.59% <= 3 milliseconds
89.26% <= 4 milliseconds
97.90% <= 5 milliseconds
99.24% <= 6 milliseconds
99.73% <= 7 milliseconds
99.89% <= 8 milliseconds
99.96% <= 9 milliseconds
99.99% <= 10 milliseconds
100.00% <= 10 milliseconds
6799.48 requests per second

====== LRANGE_600 (first 600 elements) ======
  100000 requests completed in 18.56 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.00% <= 2 milliseconds
0.23% <= 3 milliseconds
1.75% <= 4 milliseconds
91.17% <= 5 milliseconds
98.16% <= 6 milliseconds
99.04% <= 7 milliseconds
99.83% <= 8 milliseconds
99.95% <= 9 milliseconds
99.98% <= 10 milliseconds
100.00% <= 10 milliseconds
5387.35 requests per second

====== MSET (10 keys) ======
  100000 requests completed in 4.02 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.01% <= 1 milliseconds
53.22% <= 2 milliseconds
99.12% <= 3 milliseconds
99.55% <= 4 milliseconds
99.70% <= 5 milliseconds
99.90% <= 6 milliseconds
99.95% <= 7 milliseconds
100.00% <= 8 milliseconds
24869.44 requests per second

搭建一些集群，专门为某个项目，搭建的专用集群，4核4G内存，比较复杂的操作，数据比较大

几万，单机做到，差不多了

redis提供的高并发，至少到上万，没问题

几万~十几万/二十万不等

QPS，自己不同公司，不同服务器，自己去测试，跟生产环境还有区别

生产环境，大量的网络请求的调用，网络本身就有开销，你的redis的吞吐量就不一定那么高了

QPS的两个杀手：一个是复杂操作，lrange，挺多的; value很大，2 byte，我之前用redis做大规模的缓存

做商品详情页的cache，可能是需要把大串数据，拼接在一起，作为一个json串，大小可能都几k，几个byte

2、水平扩容redis读节点，提升度吞吐量

就按照上一节课讲解的，再在其他服务器上搭建redis从节点，单个从节点读请QPS在5万左右，两个redis从节点，所有的读请求打到两台机器上去，承载整个集群读QPS在10万+

5.Redis高可用

9.参考文章

redis总结1-Redis简介、安装、集群

=================================
Hystrix原理与实战

https://blog.csdn.net/loushuiyifan/article/details/82702522

ssh-keygen -t rsa
cp /root/.ssh/id_rsa.pub authorized_keys

bobshute

关注

15
点赞
踩
17

收藏

觉得还不错? 一键收藏
0
评论
Linux环境安装2

企业级redis集群架构：海量数据、高并发、高可用;持久化主要是做灾难恢复，数据恢复，实现高可用;redis如果挂了不可用,此时如果大量请求过来,缓存全部无法命中,就会产生缓存雪崩,后到mysql数据库中查询数据,mysql也可能会挂掉,所以要尽快恢复redis服务,重启(恢复)服务,然后从备份恢复数据;redis提供的持久化方式包括RDB和AOFredis总结3-持久化rdb,aof,运维命令,Sentinel监控。
复制链接

扫一扫