沈阳免费网站建站模板,1m带宽做网站速度怎么样,公司免费邮箱如何注册,网站地图链接怎么做目录 秒杀活动
一、测压工具jmete的使用
二、java实现秒杀活动
1、myseckillcontroller
2、先启动pos请求添加商品#xff0c;再启动jmeter进行压测 Redis持久化
一 、Redis持久化之RDB
1.RDB是什么
2. 备份是如何执行的
3.Fork
4. RDB持久化流程 5. dump.rdb文件
6…目录 秒杀活动
一、测压工具jmete的使用
二、java实现秒杀活动
1、myseckillcontroller
2、先启动pos请求添加商品再启动jmeter进行压测 Redis持久化
一 、Redis持久化之RDB
1.RDB是什么
2. 备份是如何执行的
3.Fork
4. RDB持久化流程 5. dump.rdb文件
6. 配置位置
7. 如何触发RDB快照保持策略
1 配置文件中默认的快照配置时间间隔
2 命令save bgsave
3flushall命令
4 SNAPSHOTTING快照
5 Save
6 stop-writes-on-bgsave-error
7rdbcompression 压缩文件
8rdbchecksum 检查数据的完整性
9rdb的备份
10优势
11劣势
Redis持久化之AOFAppend Only File
1.AOF是什么
2.AOF持久化流程
3.AOF默认不开启
4.AOF和RDB同时开启redis听谁的
5. AOF启动/修复/恢复
6. AOF同步频率设置
7. Rewrite压缩
2重写原理如何实现重写 秒杀活动
一、测压工具jmete的使用
下载jmeter
https://jmeter.apache.org/download_jmeter.cgi
使用bin目录下的jmeter.bat打开
添加线程
发送对应的请求 二、java实现秒杀活动
1、myseckillcontroller
RestController
RequestMapping(seckill)
public class MySecKillController {private String keypro:1;//添加商品PostMappingpublic void begin(String val){Jedis jedis new Jedis(192.168.195.33,6379);jedis.auth(root);jedis.set(key,val);}GetMappingpublic void seckill(){Jedis jedis new Jedis(192.168.195.33,6379);jedis.auth(root);//.获取对应的商品的数量String s jedis.get(key);//如果数量的值为nutT 为0 秒杀活动还没有开始 已经结束//isBlank判断s是否为nullif(StringUtils.isBlank(s)){System.out.println(活动未开始);}else {//监听事务jedis.watch(key);//将s转换成int类型int i Integer.parseInt(s);if (i0){//组装事务Transaction multi jedis.multi();//减少商品数量multi.decr(key);multi.sadd(userList, UUID.randomUUID().toString());//execListObject exec multi.exec();if (exec.size()0||execnull){System.out.println(秒杀失败);}else {System.out.println(秒杀成功);}}else {System.out.println(秒杀活动结束啦);}}}
}使用multi.sadd(userList, UUID.randomUUID().toString())方法将一个随机生成的用户ID添加到用户列表中。
使用multi.exec()方法执行事务并返回一个包含事务执行结果的列表。
2、先启动pos请求添加商品再启动jmeter进行压测
压测没问题就显示用户购买的集合 Redis持久化
一 、Redis持久化之RDB 1.RDB是什么
在指定的时间间隔内将内存中的数据集快照写入磁盘 也就是行话讲的Snapshot快照它恢复时是将快照文件直接读到内存里
2. 备份是如何执行的
Redis会单独创建fork一个子进程来进行持久化会先将数据写入到 一个临时文件中待持久化过程都结束了再用这个临时文件替换上次持久化好的文件。 整个过程中主进程是不进行任何IO操作的这就确保了极高的性能 如果需要进行大规模数据的恢复且对于数据恢复的完整性不是非常敏感那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。 3.Fork
Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据变量、环境变量、程序计数器等 数值都和原进程一致但是是一个全新的进程并作为原进程的子进程
在Linux程序中fork()会产生一个和父进程完全相同的子进程但子进程在此后多会exec系统调用出于效率考虑Linux中引入了“写时复制技术”
一般情况父进程和子进程会共用同一段物理内存只有进程空间的各段的内容要发生变化时才会将父进程的内容复制一份给子进程。
4. RDB持久化流程 5. dump.rdb文件
redis.conf中配置文件名称默认为dump.rdb 6. 配置位置
rdb文件的保存路径也可以修改。默认为Redis启动时命令行所在的目录下,也就是相对当前
redis.conf
dir /myredis/ 7. 如何触发RDB快照保持策略
1 配置文件中默认的快照配置时间间隔
after 900 sec (15 min) if at least 1 key changed代表15分钟之内如果有一个key方式改变就触发对应的保存策略 after 300 sec (5 min) if at least 10 keys changed
5分钟之内如果有10个key方式改变就触发对应的保存策略如果有15个key当只保存10的情况下出现宕机另外5个key存储在内存里就会遗失 after 60 sec if at least 10000 keys changed 类同上 2 命令save bgsave save save时只管保存其它不管全部阻塞。手动保存。不建议。
bgsaveRedis会在后台异步进行快照操作快照同时还可以响应客户端请求。默认开启 可以通过lastsave 命令获取最后一次成功执行快照的时间
3flushall命令
flushall清空所有的数据库
执行flushall命令也会产生dump.rdb文件但里面是空的无意义
4 SNAPSHOTTING快照
5 Save
格式save 秒 写操作次数
RDB是整个内存的压缩过的SnapshotRDB的数据结构可以配置复合的快照触发条件
默认是1分钟内改了1万次或5分钟内改了10次或15分钟内改了1次。
禁用
不设置save指令或者给save传入空字符串
6 stop-writes-on-bgsave-error 当Redis无法写入磁盘的话(磁盘已满)直接关掉Redis的写操作。推荐yes.
redis出现错误的时候就会停止编写
7rdbcompression 压缩文件 去除一些不必要的命令例如两个set添加就会把两个set转换为mset
对于存储到磁盘中的快照可以设置是否进行压缩存储。如果是的话redis会进行压缩。
如果你不想消耗CPU来进行压缩的话可以设置为关闭此功能。推荐yes.
8rdbchecksum 检查数据的完整性 在存储快照后还可以让redis来进行数据校验如果数据已经损坏就不需要再进行持久化的操作这样做会增加大约10%的性能消耗如果希望获取到最大的性能提升可以关闭此功能
9rdb的备份
先查询rdb文件的目录
将*.rdb的文件拷贝到别的地方
rdb的恢复
关闭Redis
先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
启动Redis, 备份数据会直接加载
10优势
适合大规模的数据恢复
对数据完整性和一致性要求不高更适合使用
节省磁盘空间
恢复速度快 11劣势
Fork的时候内存中的数据被克隆了一份大致2倍的膨胀性需要考虑
虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
在备份周期在一定间隔时间做一次备份所以如果Redis意外down掉的话就会丢失最后一次快照后的所有修改。
Redis持久化之AOFAppend Only File
1.AOF是什么
以日志的形式来记录每个写操作增量保存将Redis执行过的所有写指令记录下来(读操作不记录) 只许追加文件但不可以改写文件redis启动之初会读取该文件重新构建数据换言之redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
2.AOF持久化流程
1客户端的请求写命令会被append追加到AOF缓冲区内
2AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
3AOF文件大小超过重写策略或手动重写时会对AOF文件rewrite重写压缩AOF文件容量
4Redis服务重启时会重新load加载AOF文件中的写操作达到数据恢复的目的 3.AOF默认不开启
需要开启no改成yes 可以在redis.conf中配置文件名称默认为 appendonly.aof
AOF文件的保存路径同RDB的路径一致。
4.AOF和RDB同时开启redis听谁的
AOF和RDB同时开启系统默认取AOF的数据数据不会存在丢失
5. AOF启动/修复/恢复
AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样都是拷贝备份文件需要恢复时再拷贝到Redis工作目录下启动系统即加载。
正常恢复
修改默认的appendonly no改为yes
将有数据的aof文件复制一份保存到对应目录
恢复重启redis然后重新加载
异常恢复
修改默认的appendonly no改为yes
如遇到AOF文件损坏通过
/usr/redis/bin/redis-check-aof --fix 文件的位置/appendonly.aof进行恢复 备份被写坏的AOF文件
恢复重启redis然后重新加载
6. AOF同步频率设置
appendfsync always
始终同步每次Redis的写入都会立刻记入日志性能较差但数据完整性比较好
appendfsync everysec
每秒同步每秒记入日志一次如果宕机本秒的数据可能丢失。
appendfsync no
redis不主动进行同步把同步时机交给操作系统。 7. Rewrite压缩
1Rewrite是什么
AOF采用文件追加方式文件会越来越大为避免出现此种情况新增了重写机制, 当AOF文件的大小超过所设定的阈值时Redis就会启动AOF文件的内容压缩 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
8.重写原理如何实现重写
AOF文件持续增长而过大时会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)redis4.0版本后的重写是指上就是把rdb 的快照以二级制的形式附在新的aof头部作为已有的历史数据替换掉原来的流水账操作。
no-appendfsync-on-rewrite
如果 no-appendfsync-on-rewriteyes ,不写入aof文件只写入缓存用户请求不会阻塞但是在这段时间如果宕机会丢失这段时间的缓存数据。降低数据安全性提高性能
如果 no-appendfsync-on-rewriteno, 还是会把数据往磁盘里刷但是遇到重写操作可能会发生阻塞。数据安全但是性能降低
触发机制何时重写
Redis会记录上次重写时的AOF大小默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
重写虽然可以节约大量磁盘空间减少恢复时间。但是每次重写还是有一定的负担的因此设定Redis要满足一定条件才会进行重写。
auto-aof-rewrite-percentage设置重写的基准值文件达到100%时开始重写文件是原来重写后文件的2倍时触发 -40m 80
auto-aof-rewrite-min-size设置重写的基准值最小文件64MB。达到这个值开始重写。
例如文件达到70MB开始重写降到50MB下次什么时候开始重写100MB
系统载入时或者上次重写完毕时Redis会记录此时AOF大小设为base_size,
如果Redis的AOF当前大小 base_size base_size*100% (默认)且当前大小64mb(默认)的情况下Redis会对AOF进行重写。
9.重写流程背
1bgrewriteaof触发重写判断是否当前有bgsave或bgrewriteaof在运行如果有则等待该命令结束后再继续执行。
2主进程fork出子进程执行重写操作保证主进程不会阻塞。
3子进程遍历redis内存中数据到临时文件客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
41).子进程写完新的AOF文件后向主进程发信号父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
5使用新的AOF文件覆盖旧的AOF文件完成AOF重写。 10. 优势 save 时间 数据量 备份机制更稳健丢失数据概率更低。
可读的日志文本通过操作AOF稳健可以处理误操作。
11. 劣势
比起RDB占用更多的磁盘空间。恢复备份速度要慢。每次读写都同步的话有一定的性能压力。存在个别Bug造成恢复不能。
12 .用哪个好
官方推荐两个都启用。
如果对数据不敏感可以选单独用RDB。
不建议单独用 AOF因为可能会出现Bug。
如果只是做纯内存缓存可以都不用。
13.官方建议
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
只做缓存如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
同时开启两种持久化方式
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.RDB的数据不实时同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢建议不要因为RDB更适合用于备份数据库(AOF在不断变化不好备份) 快速重启而且不会有AOF可能潜在的bug留着作为一个万一的手段。性能建议 因为RDB文件只用作后备用途建议只在Slave上持久化RDB文件而且只要15分钟备份一次就够了只保留save 900 1这条规则。 如果使用AOF好处是在最恶劣情况下也只会丢失不超过两秒数据启动脚本较简单只load自己的AOF文件就可以了。 代价,一是带来了持续的IO二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。 只要硬盘许可应该尽量减少AOF rewrite的频率AOF重写的基础大小默认值64M太小了可以设到5G以上。 默认超过原大小100%大小时重写可以改到适当的数值。
