题外话:技术的分类
1、解决功能性的问题:Java、Jsp、RDBMS、Tomcat、HTML、Linux、JDBC、SVN
项目的本质无非是增删改查功能,通过这些技术就可以实现CRUD 会产生的问题:需求的变化不断地升级,不断的扩展
2、解决扩展性的问题:Struts、Spring、SpringMVC、Hibernate、Mybatis
用框架就可以解决扩展型的问题。
3、解决性能的问题:NoSQL、Java线程、Hadoop、Nginx、MQ、ElasticSearch
用一些中间件的工具和数据库可以解决项目的性能问题,高并发和多线程
Web1.0的时代,数据访问量很有限,用一夫当关的高性能的单点服务器可以解决大部分问题。
随着Web2.0的时代的到来,用户访问量大幅度提升,同时产生了大量的用户数据。加上后来的智能移动设备的普及,所有的互联网平台都面临了巨大的性能挑战。
缓解Cpu内存的压力,一般采用服务集群的方式来分担服务的请求,Nignx负载均衡,分布式架构
问题就是session该怎么进行存储呢?
解决方案:
1.将session信息存储到客户端,或者是放到cookie中,每次请求都是带着cookie的,但是cookie存储有一个致命缺点,由于cookie存储在客户端,安全性很难有保证
2.session的复制,session复制多个到各个服务器中,缺点是浪费空间,造成冗余。
3.NoSQL数据库存储用户信息,NoSQL不需要进行IO操作,他的数据可以直接存储到内存中,存到内存中读的速度更快。同时NoSQL还可以减少io的读操作,将一些频繁进行查询处理的数据放到缓存数据库中。
NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,泛指非关系型的数据库。
NoSQL 不依赖业务逻辑方式存储,而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。
特点:
不遵循SQL标准。
不支持ACID。事务的四个特性,NOSQL是支持事务的
远超于SQL的性能。
对数据高并发的读写
海量数据的读写
对数据高可扩展性的(秒杀功能)
需要事务支持
基于sql的结构化查询存储,处理复杂的关系,需要即席查询。
总结:用不着sql的和用了sql也不行的情况,请考虑用NoSql
按行存储
按列存储
Redis是一个开源的key-value存储系统。
和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash(哈希类型)。
这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。
在此基础上,Redis支持各种不同方式的排序。
与memcached一样,为了保证效率,数据都是缓存在内存中。
区别的是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件。
并且在此基础上实现了master-slave(主从)同步。
高频次,热门访问的数据,降低数据库IO
分布式架构,做session共享
6.2.4 for Linux(redis-6.2.4.tar.gz)
不用考虑在windows环境下对Redis的支持
1.下载安装linux环境下的redis安装包
下载链接:Redishttps://redis.io/ 2.将安装移动到home的opt文件下进行解压,注意权限不够记得用sudo命令(我的是ubuntu16.04版本)
3.基本环境安装
yum install gcc-c++
# 然后进入redis目录下执行
gcc -v
#查看gcc版本
make
# 然后执行
make install
4.make执行完后执行make install
5.去到usr/local/bin目录下看看是否有启动文件
6.将redis配置文件复制到我们当前目录下
7.Redis默认不是后台启动的,所以需要修改配置文件
8.启动Redis服务
sudo redis-server myconfig/redis.conf
9.查看redis服务是否启动
ps -ef|grep redis
10.关闭redis服务
shutdown
在关闭服务时遇到bug,需要将log文件进行配置和权限修改
具体解决文章:
Redis第一次启动,SHUTDOWN时提示: (error) ERR Errors trying to SHUTDOWN. Check logs._松林羊的博客-CSDN博客
redis默认有16个数据库,下标从0-15,使用select i 表示切换到第i个数据库
dbsize可以查看
memcached和redis的 区别 memcached是串行执行+多线程+锁机制的形式
而Redis是单线程 + 多路IO复用的形式实现的。
Redis命令中心(Redis commands) -- Redis中国用户组(CRUG) : Redis常见数据类型操作命令
keys *查看当前库所有key (匹配:keys *1)
exists key判断某个key是否存在
type key 查看你的key是什么类型
del key 删除指定的key数据
unlink key 根据value选择非阻塞删除 非阻塞:仅将keys从keyspace元数据中删除,真正的删除的会在后续异步操作
expire key 10 :设置key的过期时间为10s,10s后key-v将不复存在
ttl key :查看key多久过期, -1 为永不过期,-2为已过期
select命令切换数据库
dbsize查看当前数据库的key的数量
flushdb清空当前库
flushall通杀全部库
String是Redis最基本的类型,你可以理解成与Memcached一模一样的类型,一个key对应一个value。
String类型是二进制安全的。意味着Redis的string可以包含任何数据。比如jpg图片或者序列化的对象。
String类型是Redis最基本的数据类型,一个Redis中字符串value最多可以是512M
set
*NX:当数据库中key不存在时,可以将key-value添加数据库
*XX:当数据库中key存在时,可以将key-value添加数据库,与NX参数互斥
*EX:key的超时秒数
*PX:key的超时毫秒数,与EX互斥
get
append
strlen
setnx
incr
decr
incrby / decrby
在用incr key的时候有一个特点是原子性操作,所谓原子性操作是指不会被线程调度机制所打断的操作,这种操作点开始就会一直运行到结束,中间不会有任何的context switch (切换线程)
(1)在单线程中, 能够在单条指令中完成的操作都可以认为是"原子操作",因为中断只能发生于指令之间。
(2)在多线程中,不能被其它进程(线程)打断的操作就叫原子操作。
Redis单命令的原子性主要得益于Redis的单线程。
mset
同时设置一个或多个 key-value对
mget
同时获取一个或多个 value
msetnx
getrange
获得值的范围,类似java中的substring,前包,后包
setrange
用
setex <过期时间>
设置键值的同时,设置过期时间,单位秒。
getset
以新换旧,设置了新值同时获得旧值。
String的数据结构为简单动态字符串(Simple Dynamic String,缩写SDS)。是可以修改的字符串,内部结构实现上类似于Java的ArrayList,采用预分配冗余空间的方式来减少内存的频繁分配.
如图中所示,内部为当前字符串实际分配的空间capacity一般要高于实际字符串长度len。当字符串长度小于1M时,扩容都是加倍现有的空间,如果超过1M,扩容时一次只会多扩1M的空间。需要注意的是字符串最大长度为512M。
list为单键多值
Redis 列表是简单的字符串列表,按照插入顺序排序。你可以添加一个元素到列表的头部(左边)或者尾部(右边)。
它的底层实际是个双向链表,对两端的操作性能很高,通过索引下标的操作中间的节点性能会较差。
lpush/rpush
lpop/rpop
rpoplpush
lrange
按照索引下标获得元素(从左到右)
lrange mylist 0 -1 0左边第一个,-1右边第一个,(0-1表示获取所有)
lindex
llen
linsert
lrem
lset
List的数据结构为快速链表quickList。
首先在列表元素较少的情况下会使用一块连续的内存存储,这个结构是ziplist,也即是压缩列表。
它将所有的元素紧挨着一起存储,分配的是一块连续的内存。
当数据量比较多的时候才会改成quicklist。
因为普通的链表需要的附加指针空间太大,会比较浪费空间。比如这个列表里存的只是int类型的数据,结构上还需要两个额外的指针prev和next。
Redis将链表和ziplist结合起来组成了quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除性能,又不会出现太大的空间冗余。
无重复,无序
set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的。
Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表,所以添加,删除,查找的复杂度都是O(1)。
一个算法,随着数据的增加,执行时间的长短,如果是O(1),数据增加,查找数据的时间不变
sadd
将一个或多个 member 元素加入到集合 key 中,已经存在的 member 元素将被忽略
smembers
sismember
scard
srem
spop
srandmember
smove
sinter
sunion
sdiff
Set数据结构是dict字典,字典是用哈希表实现的。
Java中HashSet的内部实现使用的是HashMap,只不过所有的value都指向同一个对象。Redis的set结构也是一样,它的内部也使用hash结构,所有的value都指向同一个内部值。
Redis hash 是一个键值对集合。
Redis hash是一个string类型的field和value的映射表,hash特别适合用于存储对象。
类似Java里面的Map 存储对象实例: 第一种存储方式, k-v实现存储 第二种存储方式:k-v实现 第三种:hash的存储方式 通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了,既不需要重复存储数据,也不会带来序列化和并发修改控制的问题。 hset hget hmset hexists hkeys hvals hincrby hsetnx Hash类型对应的数据结构是两种:ziplist(压缩列表),hashtable(哈希表)。当field-value长度较短且个数较少时,使用ziplist,否则使用hashtable。 zipList(压缩列表): Redis源码分析-压缩列表ziplist_weixin_33800463的博客-CSDN博客 Redis有序集合zset与普通集合set非常相似,是一个没有重复元素的字符串集合。 不同之处是有序集合的每个成员都关联了一个评分(score),这个评分(score)被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的,但是评分可以是重复了 。 因为元素是有序的, 所以你也可以很快的根据评分(score)或者次序(position)来获取一个范围的元素。 访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。 zadd 将一个或多个 member 元素及其 score 值加入到有序集 key 当中。 zrange [WITHSCORES] 返回有序集 key 中,下标在 带WITHSCORES,可以让分数一起和值返回到结果集。 zrangebyscore key minmax [withscores] [limit offset count] 返回有序集 key 中,所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。有序集成员按 score 值递增(从小到大)次序排列。 zrevrangebyscore key maxmin [withscores] [limit offset count] 同上,改为从大到小排列。 zincrby zrem zcount zrank Zset是Redis提供的一个特别的数据结构,一方面它等价于Java的数据结构MAp zset底层使用了两个数据结构 ①hash,hash的作用是关联元素的value值和权重score,保障元素value的唯一性,可以通过value找到相关的score值 ②跳跃表(跳表),跳跃表的目的在于给元素value排序,根据score的范围获取元素列表。 1.简介 有序集合在生活中比较常见,例如根据成绩对学生排名,根据得分对玩家排名等。对于有序集合的底层实现,可以用数组、平衡树、链表等。数组不便元素的插入、删除;平衡树或红黑树虽然效率高但结构复杂;链表查询需要遍历所有效率低。Redis采用的是跳跃表。跳跃表效率堪比红黑树,实现远比红黑树简单。 2.例子:对比普通的有序链表和跳表,查找出指定元素51 有序链表: 要查找值为51的元素,需要从第一个元素开始依次查找、比较才能找到。共需要6次比较。 跳跃表: 从第2层开始,1节点比51节点小,向后比较。 21节点比51节点小,继续向后比较,后面就是NULL了,所以从21节点向下到第1层 在第1层,41节点比51节点小,继续向后,61节点比51节点大,所以从41向下 在第0层,51节点为要查找的节点,节点被找到,共查找4次 通过增加索引层数和个数来减少搜索的时间复杂度,加快查询的效率。用空间来交换时间。 由于跳表除了原链表之后的各层级索引,只保存了前后指针和关键值,不会存在大对象的存储,所以在具体研发中基本不必特别在意空间带来的影响。 配置大小单位,开头定义了一些基本的度量单位,只支持bytes(字节类型),不支持bit 大小写不敏感 类似jsp中的include,多实例的情况可以把公用的配置文件提取出来 在文件中的bind 127.0.0.1 - : :1 这个就是限制了只能在本身主机上进行访问 默认情况bind=127.0.0.1只能接受本机的访问请求 不写的情况下,无限制接受任何ip地址的访问 如果开启了protected-mode,那么在没有设定bind ip且没有设密码的情况下,Redis只允许接受本机的响应 protected-mode no之后,就没有了保护模式,其他ip地址主机就可以访问到该redis环境了 设置tcp的backlog,backlog其实是一个连接队列,backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。 在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。 注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值(128),所以需要确认增大/proc/sys/net/core/somaxconn和/proc/sys/net/ipv4/tcp_max_syn_backlog(128)两个值来达到想要的效果 一个空闲的客户端维持多少秒会关闭,0表示关闭该功能。即永不关闭。 对访问客户端的一种心跳检测,每个n秒检测一次。 单位为秒,如果设置为0,则不会进行Keepalive检测,建议设置成60 是否为后台进程,设置为yes 守护进程,后台启动 设置数据库的大小 访问密码的查看、设置和取消 在命令中设置密码,只是临时的。重启redis服务器,密码就还原了。 永久设置,需要再配置文件中进行设置。 设置redis同时可以与多少个客户端进行连接。默认情况下的最大连接数为10000个客户端 如果超过了设置的限制,redis将会拒绝新的连接请求,并且向这些请求发送"max number of clients reached"作为回应 4.6.2maxmemory 建议必须设置,否则将内存占满会造成服务器宕机 设置redis可以使用的内存量。一旦到达内存使用上限,redis将会试图移除内部数据,移除规则可以通过maxmemory-policy来指定 如果redis无法根据移除规则来移除内存中的数据,或者设置了“不允许移除”,那么redis则会针对那些需要申请内存的指令返回错误信息,比如SET、LPUSH等 Redis 发布订阅 (pub/sub) 是一种消息通信模式:发送者 (pub) 发送消息,订阅者 (sub) 接收消息。 Redis 客户端可以订阅任意数量的频道。 1.客户端可以订阅频道如下图: 2.当这个频道发布消息之后,消息就会发送给订阅频道的客户端。 1.打开一个客户端订阅channel1 2.向channel1中发布消息 3.打开第一个客户端就可以看到发送的消息 注:发布的消息没有持久化,如果在订阅的客户端收不到hello,只能收到订阅后发布的消息。 bit有位的意思,所以该数据结构主要就是进行位操作 简介: 现代计算机用二进制(位) 作为信息的基础单位, 1个字节等于8位, 例如“abc”字符串是由3个字节组成, 但实际在计算机存储时将其用二进制表示, “abc”分别对应的ASCII码分别是97、 98、 99, 对应的二进制分别是01100001、 01100010和01100011,如下图 如果可以合理的使用操作位就可以有效的提高内存的使用率和开发效率 Redis提供了Bitmaps这个数据类型可以实现对位的操作: ① Bitmaps本身不是一种数据类型, 实际上它就是字符串(key-value) , 它是专门进行位操作的字符串 ②Bitmaps单独提供了一套命令, 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组, 数组的每个单元只能存储0和1, 数组的下标在Bitmaps中叫做偏移量。 如下图所示 1.setbit 格式: 实例: 每个独立用户是否访问过网站存放在Bitmaps中, 将访问的用户记做1, 没有访问的用户记做0, 用偏移量作为用户的id。 设置键的第offset个位的值(从0算起) , 假设现在有20个用户,userid=1, 6, 11, 15, 19的用户对网站进行了访问, 那么当前Bitmaps初始化结果如图 unique:users:20211106代表2020-11-06这天的独立访问用户的Bitmaps 很多应用的用户id以一个指定数字(例如10000) 开头, 直接将用户id和Bitmaps的偏移量对应势必会造成一定的浪费, 通常的做法是每次做setbit操作时将用户id减去这个指定数字。 在第一次初始化Bitmaps时, 假如偏移量非常大, 那么整个初始化过程执行会比较慢, 可能会造成Redis的阻塞。 2.getbit 3.bitcount 统计字符串被设置为1的bit数。一般情况下,给定的整个字符串都会被进行计数,通过指定额外的 start 或 end 参数,可以让计数只在特定的位上进行。start 和 end 参数的设置,都可以使用负数值:比如 -1 表示最后一个位,而 -2 表示倒数第二个位,start、end 是指bit组的字节的下标数,二者皆包含。 4.bitop 1.bitmaps比set更加的节省空间 2.bitmaps也不是万金油,假如该网站每日的活跃度很低,例如只有10万,那么bitmaps的优势就体现不出了。 在工作当中,我们经常会遇到与统计相关的功能需求,比如统计网站PV(PageView页面访问量),可以使用Redis的incr、incrby轻松实现。 但像UV(UniqueVisitor,独立访客)、独立IP数、搜索记录数等需要去重和计数的问题如何解决?这种求集合中不重复元素个数的问题称为基数问题。例如同一个用户多次访问网站只需要记录一次,同一个IP访问也是只需要记录一次。 基数问题:比如数据集{1,3,5,7,5,7,8},这个数据的基数为{1,3,5,7,8},基数是统计不重复的元素 解决基数问题的办法: ①MySQL表中,使用distinct count 计算出不重复的个数 ②使用Redis提供的hash,set,bitmaps等数据结构处理。 但是通过以上方法解决后,随着数据的不断增加,将会导致占用的内存空间越来越大,对于非常大的数据集是不可行的。所以Redis提出了HyperLogLog来做基数统计的算法。可以通过更少的空间存储更多的值。 1.pfadd 实例: 将所有元素添加到指定HyperLogLog数据结构中。如果执行命令后HLL估计的近似基数发生变化,则返回1,否则返回0。 2.pfcount 3.pfmerge Redis 3.2 中增加了对GEO类型的支持。GEO,Geographic,地理信息的缩写。该类型,就是元素的2维坐标,在地图上就是经纬度。redis基于该类型,提供了经纬度设置,查询,范围查询,距离查询,经纬度Hash等常见操作。 1.geoadd 2.geopos 3.geodist 4.georadius maven文件,导入所需要的jar包 禁用Linux的防火墙:Linux(CentOS7)里执行命令 systemctl stop/disable firewalld.service redis.conf中注释掉bind 127.0.0.1 ,然后 protected-mode no Jedis-API Key String List Set hash Zset 要求 ①输入手机号,点击发送后随机生成6位数字码,2分钟内有效 ②输入验证码,点击验证,返回成功或失败 ③每个手机号每天只能输入三次 对应的基本步骤: 1.生成随机的6位数字 Random函数 2.验证码在2分钟内有效,将验证码存储到redis中设置一下过期时间即可。并且设置验证码的发送次数 : redis 用incr操作当 数量大于2的时候不能再发送。 3.判断输入的数字和验证码是否一致 : 从redis中获取验证码进行校对 。 Spring Boot整合Redis非常简单,只需要按如下步骤整合即可 1、 在pom.xml文件中引入redis相关依赖 2、 application.properties配置redis配置 3、 添加redis配置类 Redis事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。 Redis事务的主要作用就是串联多个命令防止别的命令插队。 从输入Multi命令开始,输入的命令都会依次进入命令队列中,但不会执行,直到输入Exec后,Redis会将之前的命令队列中的命令依次执行。组队的过程中可以通过discard来放弃组队。 案例演示 代码顺序 在接下来的操作都会作为一个事务来等待执行知道执行了exec命令事务里的代码才会执行 dicard就会放弃组队,让当前事务里的全部不执行 组队中某个命令出现了报告错误,执行时整个的所有队列都会被取消。 如果执行阶段某个命令报出了错误,则只有报错的命令不会被执行,而其他的命令都会执行,不会回滚。 例子: 你有一个账号,三个人使用你的账号对你的金额进行操作 一个请求要-8000,第二个请求-5000,第三个请求是-1000 这个过程的先后顺序执行之后可能导致最终的余额为-4000 在多个操作之间并没有添加事务,对数据都同时产生影响 Redis中主要通过锁的机制来解决事务冲突的问题,锁则一般分成为悲观锁和乐观锁两种 悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。 乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。通过添加版本号实现乐观锁。 当一个任务执行完之后,会对版本号进行更改,下一次操作的时候会对版本号先进行判断是否相同,相同的情况下才会进行后面的操作。 相当于监听器 在执行multi之前,先执行watch key1 [key2],可以监视一个(或多个) key ,如果在事务执行之前这个(或这些) key被其他命令所改动,那么事务将被打断。 实例 打开两个终端,对同一个key值进行修改 终端一: 终端二: unwatch 取消 WATCH 命令对所有 key 的监视。 如果在执行 WATCH 命令之后,EXEC 命令或DISCARD 命令先被执行了的话,那么就不需要再执行UNWATCH 了。 1.单独的隔离操作 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。 2.没有隔离级别的概念 队列中的命令没有提交之前都不会实际被执行,因为事务提交前任何指令都不会被实际执行 3.不保证原子性 事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚 。 如果在组队过程中有一个失败那么就都不会成功,但是如果组队完成后在执行阶段出现错误,有那个失败就失败不影响后续的操作。 事务里秒杀成功的操作其实就是库存数量-1和购买者数量+1 前端页面代码 后端servlet代码: redis代码 测试就是打开网页进行测试即可 模拟多请求并发的效果 使用ab工具模拟并发情况下的测试 CentOS6默认已安装 CentOS7需要手动安装 有网络状态下:yum install httpd-tools 无网络状态下: (1) 进入cd /run/media/root/CentOS 7 x86_64/Packages(路径跟centos6不同) (2) 顺序安装 apr-1.4.8-3.el7.x86_64.rpm apr-util-1.5.2-6.el7.x86_64.rpm httpd-tools-2.4.6-67.el7.centos.x86_64.rpm 并发测试过程 vim postfile 模拟表单提交参数,以&符号结尾;存放当前目录。 测试结果: 出现了负数库存和在秒杀结束后再次秒杀成功的问题。 由于并发的操作,使得数据在一个操作内更改另一个还没有改变使得出现问题。 解决办法是利用乐观锁来解决超卖问题,在jedis中调用watch方法监视库存key值的变化,之后将最终秒杀的过程放到一个事务中去 11.4.2连接超时问题 在继续增加并发的大小之后,发现连接有限了,我们采用数据库连接池解决这个问题 节省每次连接redis服务带来的消耗,把连接好的实例反复利用。 通过参数管理连接的行为 代码见项目中 在增加库存和并发数量之后,我们发现有的时库存还是有的却秒杀失败,这是因为乐观锁的缺点,乐观锁只负责了安全,没有管你商品会不会卖完,所以可能在更改了版本号之后导致一些列操作无法成功,需要改进。 而redis并没有提供悲观锁的方法,而且悲观锁的并发度太低,任务可能会一直等待。 LUA(露阿)脚本语言 Lua 是一个小巧的脚本语言,Lua脚本可以很容易的被C/C++ 代码调用,也可以反过来调用C/C++的函数,Lua并没有提供强大的库,一个完整的Lua解释器不过200k,所以Lua不适合作为开发独立应用程序的语言,而是作为嵌入式脚本语言。 很多应用程序、游戏使用LUA作为自己的嵌入式脚本语言,以此来实现可配置性、可扩展性。 这其中包括魔兽争霸地图、魔兽世界、博德之门、愤怒的小鸟等众多游戏插件或外挂。 小结: 普通的redis代码可以实现秒杀功能但是都会存在问题 什么是持久化? Redis是存储在内存中的,将内存的数据存储到硬盘当中称之为持久化过程。 Redis提供了两种不同的持久化方式 RDB(Redis DataBase) AOF(Append Of File) 本章先介绍RDB 时间间隔,固定的时间点 数据集快照,当前时间点内存中的瞬间数据。 Redis在RDB备份过程中,会单独创建一个(fork)子进程来进行持久化的操作,会先将数据写入到一个临时文件中,持久化过程结束后,再用这个临时文件替换上一次持久化的文件。而这整个过程主线程不会进行IO操作,如果需要进行大规模数据的恢复且对数据恢复的完整性要求不高,RDB要由于AOF。但RDB的缺点是最后一次持久化会有数据丢失问题。 Fork(创建子进程的过程): Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等) 数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程 在Linux程序中,fork()会产生一个和父进程完全相同的子进程,但子进程在此后多会exec系统调用,出于效率考虑,Linux中引入了写时复制技术 写时赋值技术:redis不会将所有的数据直接封存到rdb文件中,而是会通过fork产生一个临时区域和临时文件,当这个进程的任务完成后才将rdb的持久化文件替换,保证了数据的完整性和安全性。 式一般情况父进程和子进程会共用同一段物理内存,只有进程空间的各段的内容要发生变化时,才会将父进程的内容复制一份给子进程。 1.在redis.conf中配置文件名称,默认为dump.rdb 2.rdb文件的保存路径,也可以修改。默认为Redis启动时命令行所在的目录下,dir "/myredis/" 3.stop-writes-on-bgsave-error 当Redis无法写入磁盘的话,直接关掉Redis的写操作。推荐yes. 4.rdbcompression 压缩文件 对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。 如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能。推荐yes. 5.rdbchecksum 检查完整性 在存储快照后,还可以让redis使用CRC64算法来进行数据校验, 但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能,推荐yes. 开启之后会在持久化之前检查数据是否完整是否有损坏,如果有损坏就终止持久化。 6.Save 格式:save 秒钟 写操作次数,持久化操作之后时间和监视key改变的数量都会刷新重新开始。 RDB是整个内存的压缩过的Snapshot,RDB的数据结构,可以配置复合的快照触发条件, 默认是1分钟内改了10000次,或5分钟内改了10次,或15分钟内改了1次。就会触发持久化过程。 一般是禁用的,不设置save指令,或者给save传入空字符串 save 指令:save时只管保存,其它不管,全部阻塞。手动保存。不建议。 bgsave指令:Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。 可以通过lastsave 命令获取最后一次成功执行快照的时间 在redis操作过程中数据出现了问题,希望可以恢复到之前的状态,就要用到rdb的备份。 优势: 适合大规模的数据恢复和保存 对数据完整性和一致性要求不高时使用 节省磁盘空间 恢复速度快 缺点: fork的操作过程中,内存中的数据被克隆,会导致内存膨胀 虽然Redis在fork过程用到了写时拷贝技术,但是如果数据量过大还是比较消耗性能。 RDB在最后一次数据持久化的时候可能会造成数据的丢失 解释为什么最后一次丢失,例如现在的要求是在20s内有10个key发生改变那么就进行持久化操作,但是还未达到持久化条件的过程中改变了key,同时服务器宕机就会导致数据丢失。 动态停止 以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来(读操作不记录), 只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。 AOF默认是不开启的,所以需要去配置文件中设置一下,默认为appendonly.aof 将appendonly no 改为 yes AOF文件的保存路径,同RDB的路径一致。 问题:如果AOF和RDB同时开启,redis到底服从哪个? AOF和RDB同时开启,系统默认取AOF的数据(数据不会存在丢失) AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样,都是拷贝备份文件,需要恢复时再拷贝到Redis工作目录下,启动系统即加载 正常恢复: 修改默认的appendonly no,改为yes 将有数据的aof文件复制一份保存到对应目录(查看目录:config get dir) 恢复:重启redis然后重新加载 异常恢复:在aof文件追加过程中aof文件出现了损坏,redis可以对其进行恢复 修改默认的appendonly no,改为yes 如遇到AOF文件损坏,通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复 返回的结果是之前和现在有哪些不同 的备份被写坏的AOF文件 恢复:重启redis,然后重新加载 在配置文件中设置 AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制, 当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩, 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof Rewrite的重写原理 AOF文件持续增长而过大时,会fork出一条新进程来将文件进行重写(也是先临时文件最后再rename),redis4.0之后是指把rdb的快照以2进制的形式附着在aof头部,作为已有的历史数据,替换掉原来的流水操作。 重写流程和之前的RDB是类似的,通过fork生成子进程将数据写入到aof临时文件,之后用新的aof文件替换之前的文件。 客户端在请求写命令时候会被append追加到AOF缓冲区中 AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF中 AOF文件大小超过重写策略或手动重写时,会对AOF文件进行rewrite重写,以压缩AOF的文件容量。 当redis服务重启的时候,会重新load加载AOF文件中的写操作达到恢复的目的。 优点: 备份机制更加稳健,丢失数据概率更低 生成的文件是可读性较强的日志文件,通过操作AOF,处理错误操作 缺点: 比起RDB占用更多的空间,因为他它记录了不仅仅是数据还有操作 由于记录的东西比较多,恢复备份速度更慢 每次读写同步的话,性能较差。 存在个别bug导致恢复有问题 RDB是在指定时间内的快照存储,AOF是对你的操作进行日志追加 官方推荐两个都用 如果对数据的安全和完整性不敏感,选用RDB 同时不建议单独使用AOF,可能会出现BUG 如果只是做纯内存存储加快读写速度,可以两者都不用。 主机数据更新后根据配置和策略,自动同步到备机的master/slaver的机制,Master以写为主,Slaver以读为主。 因为数据库主要的目的是读写,而读取数据更是更多的情况,所以考虑将应用对数据的写直接修改到主库,而将主库的数据进行复制生成多个分库,让应用读取时候可以从多个库进行读取,减少数据库的压力 可以实现读写分离:如果读写放在一个服务器会导致该服务器压力过大 数据容灾时的快速恢复:当一台服务器宕机,快速的切换从服务器 必须为一主多从的效果,但是如果主服务器挂掉怎么办? 考虑使用集群的方法,集群将多个主从机制进行关联达到服务的保证。 拷贝多个redis.conf文件include(写绝对路径) 开启daemonize yes Pid文件名字pidfile 指定端口port Log文件名字 dump.rdb名字dbfilename Appendonly 关掉或者换名字 1.创建/myredis文件夹 2.复制配置文件 3.配置一主两从的效果,创建三个配置文件 *redis6379.conf *redis6380.conf *redis6381.conf 4.在三个配置文件中写入内容 打开redis6379.conf文件进行内容引入和配置 复制一份6379的文件作为6380 同理复制一份6380到6381 5.根据三个配置文件启动三个redis服务 6.查看三台主机运行的情况 默认没启动就都是没有主机没有从机 7.配置从库 在6380和6381的服务器上执行 之后在主机上新建和更改的数据,在从机上都可以读取到了。 如果主机挂掉,重启主机,一切都会恢复正常 从机重启需要再次设置主机目标 切入点问题?slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来,那之前的k1,k2,k3是否也可以复制? 从机是否可以进行写操作?set可否? 主机shutdown后情况如何,从机是上位成为主机还是原地待命? 主机在宕机重新启动后,主机新增记录,是否会同步到从机? 其中一台从机宕机后情况如何,恢复时是否可以跟上主库。 上一个Slave可以是下一个slave的Master,Slave同样可以接收其他 slaves的连接和同步请求,那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。从服务器的身份既是从机也是下一层的主机。 当一个master宕机后,后面的slave可以立刻升为master,其后面的slave不用做任何修改。 Slave启动成功连接到master后会发送一个sync(同步)命令 主服务器接到服务器发送来的同步消息后,会把主服务器数据先进性持久化,放入rdb文件,将rdb发送给从服务器,从服务器拿到rdb进行读取。 反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库。 1.调整为一主二仆模式,6379带着6380,6381 2.在myredis目录下创建sentinel.conf文件,文件名字必须是这个,绝不能错 3.配置文件进行填写 4.启动哨兵 5.当主机挂掉,从机将会被选举出一台作为主机 (大概10秒左右可以看到哨兵窗口日志,切换了新的主机) 哪个从机会被选举为主机呢?根据优先级别:slave-priority 原主机重启后会变为从机。 同时也是可以从日志中看到替换的过程的 7.复制延时 由于所有操作都是现在主机上进行操作,然后再同步更新到从机的,所以master同步到slave机器是一定会有延时的,当系统繁忙或者slave过多时,这个问题会加重。 优先级在redis.conf中默认:slave-priority 100,值越小优先级越高 在新版本的redis中属性名为 replica-priority 100 偏移量优先是指从机中和主机的重复度最高的,即数据和主机最为接近的服务器。 每个redis实例启动后都会随机生成一个40位的runid。 问题背景: 当redis容量不够时,如何进行扩容? 并发写操作,redis如何分摊? 另外,主从模式,薪火相传模式,主机宕机,导致ip地址发生变化,应用程序中配置需要修改对应的主机地址、端口等信息。 之前通过代理主机来解决,但是redis3.0中提供了解决方案。就是无中心化集群配置。 代理主机:客户端的请求先发送到代理主机然后进行任务的分配。 无中心化集群配置:客户的请求可以进行任何一台服务器的入口,服务器之间可以相互进行访问。 Redis 集群实现了对Redis的水平扩容,即启动N个redis节点,将整个数据库分布存储在这N个节点中,每个节点存储总数据的1/N。 Redis 集群通过分区(partition)来提供一定程度的可用性(availability): 即使集群中有一部分节点失效或者无法进行通讯, 集群也可以继续处理命令请求。 1.首先要将之前的rdb和aof文件全都删除,防止对后续有干扰 2.制作6个redis服务端口:6379,80,81,89,90,91; 其中呢79是主,89是从机,以此类推,79,80,81都是主机后面都是对应的从机 3.在对应的.conf文件下配置基本信息 内容如下 接下来将6379的conf文件进行复制五份 将这些内容都进行一下指定的修改 4.启动这6个redis服务 5.将这6个结点合成为1个集群 组合之前,请确保所有redis实例启动后,nodes-xxxx.conf文件都生成正常。 合体命令 之后会返回一个值,这个我们先记下 普通方式登录 可能直接进入读主存,存储数据时候会出现MOVED重定向操作,所以应该以集群的方式登录。 因此考虑使用集群策略连接,设置连接数据会自动切换到 6.Redis cluster如何分配这6个结点? 分配的原则,尽量保证每个主数据库运行在不同的IP地址,每个从库和主库不在同一个IP地址上 在搭建成功后会返回一个slots值 slots的意思是插槽 一个 Redis 集群包含 16384 个插槽(hash slot), 数据库中的每个键都属于这 16384 个插槽的其中一个。 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽, 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。 集群中的每个节点负责处理一部分插槽。 举个例子, 如果一个集群可以有主节点, 其中: 节点 A 负责处理 0 号至 5460 号插槽。 节点 B 负责处理 5461 号至 10922 号插槽。 节点 C 负责处理 10923 号至 16383 号插槽。 插槽的目的就是把数据尽可能三列的分布在集群的每一个服务器上 在redis-cli每次录入、查询键值,redis都会计算出该key应该送往的插槽,如果不是该客户端对应服务器的插槽,redis会报错,并告知应前往的redis实例地址和端口。 redis-cli客户端提供了 –c 参数实现自动重定向。 如 redis-cli -c –p 6379 登入后,再录入、查询键值对可以自动重定向。 不在一个slot下的键值,是不能使用mget,mset等多键操作。 可以通过{}来定义组的概念,从而使key中{}内相同内容的键值对放到一个slot中去。 例如现在一台服务器宕机了 首先看一下目前的服务器结点状况 可以看到当前的6379显示为fail,但是79之前的从机将会作为新的主机来提供服务 此时如果6379恢复之后,将会成为当前主机的从机 如果主机和从机都挂掉了,那么整个集群还是否会继续提供服务呢? 不一定,看配置了 主要的接口: JedisCluster(HostAndPort); 问题描述: 缓存穿透的原因 redis查不到数据 在操作中出现了很多的不正常的url访问 黑客的目的并不是得到你的数据而是让你的服务器瘫痪。 解决方案: 1.对空值进行缓存:当一个查询结果为空时,将这个k-v(null)存储到缓存中,设置很短的过期时间,定时让空缓存删除。 2.设置可访问的名单(白名单):使用bitmaps(位操作,通过偏移量进行判断)类型定义一个可访问的名单,名单的id作为bitmaps的偏移量,每次访问和bitmaps里的id进行校对,如果不存在则拦截。 3.采用布隆过滤器:底层也是bitmaps。 4.进行实时监控:当发现Redis的命中率开始降低时,需要排查访问对象和访问的数据,设置黑名单。 问题描述:key对应的数据存在,但是在redis中过期,此时如果有大量的并发请求申请,这些请求会大并发的压向数据库,导致后端数据库崩溃。 现象: ①数据库的访问压力瞬时间增大了 ②redis里面并没有出现大量的key过期 ③redis正常运行但是数据库崩溃 原因 ①redis中某个key过期了,恰巧有大量的访问这个key 解决方案: 1.预先设置热门数据:在redis高峰访问之前,把一些热门数据提前存入redis并加长有效时间 2.实时调整:现场监控热门数据,实时调整key的有效时间 3.使用锁:①在缓存失效的时候先等待而不是立即去load db ②先试用缓存工具中某些带成功的返回结果 缓存雪崩与缓存击穿的区别在于这里针对很多key缓存,前者则是某一个key 正常访问: 缓存失效瞬间: 雪崩原因: 在极少的时间段内,查询大量的key集中过期情况,访问key时都跑去了db。 解决方案: 1.构建多级缓存架构: nginx缓存 + redis缓存 +其他缓存(ehcache) 2.使用锁或者队列(对数据库访问的时候尽量单线程,不被打扰,效率低):用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写,从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况 3.设置过期标志更新缓存(尽量让key不要过期而是更新):记录缓存数据是否过期(设置提前量),如果过期会触发通知另外的线程在后台去更新实际key的缓存。 4.将缓存失效时间分撒开(避免大量的key集体过期):比如我们可以在原有的失效时间基础上增加一个随机值,比如1-5分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。 随着业务发展的需要,原本单体服务器部署的系统被演化为了分布集群系统,由于分布式系统多线程、多进程而且还都分布在不同的机器上,这将使原单击部署情况下的并发控制锁策略失效,单纯的JavaAPI并不提供分布式锁的能力,为了解决这类问题就需要跨JVM的互斥机制来控制共享资源的访问。 分布式锁主流实现方案: 基于数据库实现的分布式锁 基于缓存(Redis) 基于Zookeeper 各个分布式锁的优势: 性能:redis最高 可靠性:zookeeper最高 这里,我们就基于redis实现分布式锁。 命令 压力测试通过ab测试基本没问题: ab -n 1000 -c 100 http://192.168.140.1:8080/test/testLock 问题:setnx刚好获取到锁,业务逻辑出现异常,导致锁无法释放 解决:设置过期时间,自动释放锁。 1.释放了别人锁 操作A在执行过程中先对自己的资源上了锁,但是过程中出现了卡顿,导致过一会锁自动释放了但是A的操作还未执行完毕,这是操作B抢到了锁进行操作,A又反应了过来进行了操作并手动释放了锁,这就导致A释放了B的锁。 解决方案①:优化值UUID防止误删:只可以删自己的,不可以删别人的 第一步:用UUID表示不同的操作 第二步:在释放锁的时候判断当前的UUID与要释放锁的UUID是否一致 解决方法②:用LUA脚本对Redis操作强行原子化 user:{id=1,name=zhangsan,age=20} #这是存在问题的:
#如果user的年龄每年都需要变化,那么user的数据就得都取出来,取出来之后先通过json变为对象,变为对象之后,将age值改为新的结果,然后再将对象转为JSON存入redis中
user:id 1
user:name zhangsan
user:age 20
#优点例如只修改一个属性,只需要将一段的数据取出来即可
#缺点,存储的数据太分散了,存储很混乱
user 为key,value也是映射关系
value : {id = 1,name = zhangsan, age = 20}
3.5.2常用命令
3.5.3Hash的数据结构
3.6Redis有序集合(Zset)
3.6.1有序集合简介
3.6.2常用命令
3.6.3Zset底层的数据结构
3.6.4跳跃表的介绍
3.7跳跃表面试知识点
4.Redis的配置文件详解
4.1Units单位
4.2INCLUDES包含
4.3###网络相关配置###
4.3.3Port 的端口默认是6379
4.3.4tcp - backlog
4.3.4timeout
4.3.5tcp-keepalive
4.4###GENERAL通用###
4.4.1daemonize
4.4.2datebase
4.5###secret密码###
4.5.1设置密码
4.6####LIMITS限制####
4.6.1maxclients最大客户端连接数
5.Redis的订阅与发布
5.1什么是订阅和发布
5.2Redis的发布和订阅
5.3发布订阅命令行实现
subscribe channel1
//订阅一个频道
publish channel1 hello
6.Redis的新数据类型
6.1Bitmaps(位操作记录)
6.1.2命令
setbit
getbit
bitcount
bitop and(or/not/xor)
6.1.3Bitmaps和set的对比
6.2HyperLogLog(处理基数问题)
6.2.1简介
6.2.2命令
pfadd
pfcount
pfmerge
6.3Geospatial(地理信息问题)
6.3.1简介
6.3.2命令
geoadd
geopos
geodist
georadius
7.Redis_Jedis_测试
7.1Jedis测试所需要的的jar包
7.2Jedis连接的注意事项
7.3Jedis的常用操作
7.3.1创建动态工程
7.3.2创建测试类
import redis.clients.jedis.Jedis;
public class Demo01 {
public static void main(String[] args) {
Jedis jedis = new Jedis("192.168.137.3",6379);
String pong = jedis.ping();
System.out.println("连接成功:"+pong);
jedis.close();
}
}
7.4.1测试相关数据类型
@Test//获取所有的key值
public void demo1(){
Jedis jedis = new Jedis("192.168.112.130",6379);
Set
jedis.mset("str1","v1","str2","v2","str3","v3");//创建多个
@Test
public void demo2(){
jedis.lpush("key1","lucy","mary","jack");
List
@Test
public void demo3(){
jedis.sadd("orders", "order01");
jedis.sadd("orders", "order02");
jedis.sadd("orders", "order03");
jedis.sadd("orders", "order04");
Set
jedis.hset("user","age","20");
String hget = jedis.hget("user","age");
jedis.zadd("zset01",100d,"z3");
jedis.zadd("zset01",90d,"i4");
Set
8.Redis_Jedis_实例
8.1完成一个手机验证码的功能
//1.生成六位数字验证码
public static String getCode(){
Random random = new Random();
String code = "";
for(int i = 0; i < 6; i++){
int rand = random.nextInt(10);
code += rand;
}
return code;
}
public static void putCode(String phone){
Jedis jedis = new Jedis("192.168.112.130",6379);
String countOfPut = "VerifyCode" + phone +":count";//用作后面设置key-vlaue的key值
String codeKey = "VerifyCode" + phone + "code";
String count = jedis.get(countOfPut);//获取发送次数
if(count == null){//第一次发送
jedis.setex(countOfPut,24*60*60,"1");//第一次设置这个值为1
}else if(Integer.parseInt(count) <= 2){
jedis.incr(countOfPut);//已经申请验证码的次数+1
}else if(Integer.parseInt(count) > 2){
System.out.println("发送次数已达上限");
}
String vCode = getCode();
jedis.setex(codeKey,120,vCode);
jedis.close();
}
9.SpringBoot整合Redis
9.1整合步骤
#Redis服务器地址
spring.redis.host=192.168.112.130
#Redis服务器连接端口
spring.redis.port=6379
#Redis数据库索引(默认为0)
spring.redis.database= 0
#连接超时时间(毫秒)
spring.redis.timeout=1800000
#连接池最大连接数(使用负值表示没有限制)
spring.redis.lettuce.pool.max-active=20
#最大阻塞等待时间(负数表示没限制)
spring.redis.lettuce.pool.max-wait=-1
#连接池中的最大空闲连接
spring.redis.lettuce.pool.max-idle=5
#连接池中的最小空闲连接
spring.redis.lettuce.pool.min-idle=0
@EnableCaching
@Configuration
public class RedisConfig extends CachingConfigurerSupport {
@Bean
public RedisTemplate
10.Redis事务,锁机制和秒杀的实现
10.1Redis事务定义
10.21Multi、Exec、discard(组队,执行,解散)
multi
10.3事务的错误处理
10.4产生事务的原因
10.5事务的冲突问题
10.5.1解决方法
10.5.2WATCH key [key .......]
set balance 100
watch balance
multi
incrby balance 10
exec
->ok #执行成功
watch balance
multi
incrby balance 20
exec
->nil #执行失败
10.6Redis事务的三大特性
11.Redis事务的秒杀功能案例
11.1解决计数器和人员记录的事务操作
11.2基本的前端代码和后端servlet代码
<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
iPhone 13 Pro !!! 1元秒杀!!!
public class SecKillServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
public SecKillServlet() {
super();
}
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String userid = new Random().nextInt(50000) +"" ;
String prodid =request.getParameter("prodid");
//boolean isSuccess=SecKill_redis.doSecKill(userid,prodid);
boolean isSuccess= SecKill_redisByScript.doSecKill(userid,prodid);
response.getWriter().print(isSuccess);
}
}
import java.io.IOException;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.slf4j.LoggerFactory;
import ch.qos.logback.core.rolling.helper.IntegerTokenConverter;
import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisCluster;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;
import redis.clients.jedis.ShardedJedisPool;
import redis.clients.jedis.Transaction;
/**
*
*/
public class SecKill_redis {
public static void main(String[] args) {
Jedis jedis =new Jedis("192.168.44.168",6379);
System.out.println(jedis.ping());
jedis.close();
}
//秒杀过程
public static boolean doSecKill(String uid,String prodid) throws IOException {
//1 uid和prodid非空判断
if(uid == null || prodid == null) {
return false;
}
//2 连接redis
//Jedis jedis = new Jedis("192.168.44.168",6379);
//通过连接池得到jedis对象
JedisPool jedisPoolInstance = JedisPoolUtil.getJedisPoolInstance();
Jedis jedis = jedisPoolInstance.getResource();
//3 拼接key
// 3.1 库存key
String kcKey = "sk:"+prodid+":qt";//对应在redis数据库中的key为这个,value为String类型的个数
// 3.2 秒杀成功用户key
String userKey = "sk:"+prodid+":user";//对应的redis中的key为userKey,value为用户的id——> uid
//监视库存
jedis.watch(kcKey);
//4 获取库存,如果库存null,秒杀还没有开始
String kc = jedis.get(kcKey);
if(kc == null) {
System.out.println("秒杀还没有开始,请等待");
jedis.close();
return false;
}
// 5 判断用户是否重复秒杀操作
if(jedis.sismember(userKey, uid)) {
System.out.println("已经秒杀成功了,不能重复秒杀");
jedis.close();
return false;
}
//6 判断如果商品数量,库存数量小于1,秒杀结束
if(Integer.parseInt(kc)<=0) {
System.out.println("秒杀已经结束了");
jedis.close();
return false;
}
//7 秒杀过程
//使用事务进行操作
Transaction multi = jedis.multi();
//组队操作
multi.decr(kcKey);
multi.sadd(userKey,uid);
//执行
List
#设置商品的初始数量
set sk:0101:qt 10
smembers sk:0101:user #获取set集合的内容
11.3模拟并发情况下的秒杀情况
ab -n 1000 -c 100 -p ~/postfile -t 'application/x-www-form-urlencoded' http://192.168.140.1:8080/seckill/doseckill #再加上路径
-n 1000 #表示有1000个请求
-c 100 #有100个并发
-p postfile #从postfile文件中获取post提交的参数
vi postfile #添加postfile文件,文件内写入参数并且通过&连接多个参数,最后一个后面要有一个&
prodid = 0101&
11.4多并发暴露的问
11.4.1超卖问题
jedis.watch(kcKey);//
Transaction multi = jedis.multi(); //开启一个事务的方法multi,返回的是一个事务对象
//组队操作
multi.decr(kcKey);
multi.sadd(userKey,uid);
//执行
List
package com.atguigu;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;
public class JedisPoolUtil {
private static volatile JedisPool jedisPool = null;
private JedisPoolUtil() {
}
public static JedisPool getJedisPoolInstance() {
if (null == jedisPool) {
synchronized (JedisPoolUtil.class) {
if (null == jedisPool) {
JedisPoolConfig poolConfig = new JedisPoolConfig();
poolConfig.setMaxTotal(200);//连接池最大连接数
poolConfig.setMaxIdle(32);//
poolConfig.setMaxWaitMillis(100*1000);//最大等待时间
poolConfig.setBlockWhenExhausted(true);
poolConfig.setTestOnBorrow(true); //测试连接状态 ping PONG
jedisPool = new JedisPool(poolConfig, "192.168.44.168", 6379, 60000 );
//超时时间,超过指定时间不再提供服务。
}
}
}
return jedisPool;
}
public static void release(JedisPool jedisPool, Jedis jedis) {
if (null != jedis) {
jedisPool.returnResource(jedis);
}
}
}
11.4.3解决库存遗留问题
local userid=KEYS[1];
local prodid=KEYS[2];
local qtkey="sk:"..prodid..":qt";
local usersKey="sk:"..prodid.":usr';
local userExists=redis.call("sismember",usersKey,userid);
if tonumber(userExists)==1 then
return 2; //2表示当前用户已经秒杀过了
end
local num= redis.call("get" ,qtkey);
if tonumber(num)<=0 then
return 0; //0表示秒杀已经结束了
else
redis.call("decr",qtkey);
redis.call("sadd",usersKey,userid);
end
return 1; //1表示成功
问题1:连接超时和连接数量问题
解决方法:通过redis数据库连接池来解决
问题2:卖货在多并发下的超库问题
解决办法:通过组队事务然后集体执行,(乐观锁实现)
问题3:由于乐观锁本性,导致库存还有却卖货失败问题
解决办法:用LUA脚本代码来实现局部的原子性,在redis事务执行阶段其他请求不会影响
12.Redis持久化RDB
12.1RDB
12.1.1官网介绍
12.1.2什么是RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
12.1.3RDB的过程
12.1.4RDB的持久化文件,看redis.conf配置文件
#在配置文件中设置在20s内只要有3个key发生改变就进行持久化
save 20 3
12.2RDB的备份操作
cp dump.rdb dumpCp.rdb #赋值当前rdb文件到dumCp.rdb文件
ps -ef | grep redis #查看redis进程
kill - 9 3524 #杀掉redis进程
rm -f dump.rdb #删除之前的rdb文件
#恢复dump.rdb过程
cp dumpCp.rdb dump.rdb / mv dump.rdb dumpCp.rdb
redis-server /etc/redis.conf #启动redis服务
redis-cli #后面就查看redis中的内容
12.3RDB的优缺点
12.4如何停止RDB操作
redis-cli config set save "" #save后给空值,表示禁用保存策略
13.Redis的AOF持久化操作
13.1AOF概念
13.2AOF操作
13.2.1AOF启动/修复/恢复功能
13.3AOF配置介绍
13.3.1同步频率设置
appendfsync always
#始终同步,每次Redis的写入都会立刻记入日志;性能较差但数据完整性比较好,效率低完整性更好
appendfsync everysec
#每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。
appendfsync no
#redis不主动进行同步,把同步时机交给操作系统
13.3.2Rewrite压缩
13.3.3AOF持久化流程
13.4AOF优缺点
13.5AOF和RDB的选用条件
14、Redis的主从复制
14.1主从复制的概念
14.2主从复制的作用
14.3主从复制的过程
mkdir /myredis
cd /myredis
/usr/local/bin/redis-server /etc/redis.conf
cp /etc/redis.conf /myredis/redis.conf #复制redis中的配置文件到myredis文件夹
vi redis.conf
vi redis6379.conf
include /myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
cp redis6379.conf redis6380.conf
vi redis6380.conf
include /myredis/redis.conf
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
redis-server redis6379.conf
redis-server redis6380.conf
redis-server redis6381.conf
ps -ef | grep redis
info replication #打印主从复制的相关信息
slaveof 127.0.0.1 6379
14.4主从复制的特点
14.4.1一主二仆
当从服务器重启后,从服务器并不会是之前的从服务器,而是需要通过指令再变为之前主机的从机才行。
再变为从机后,所有的数据将会和主机进行从头的同步
主服务器挂掉后,但是从服务器的角色仍然是从机,重启主机后,主机仍然是主机
14.4.2薪火相传
14.4.3反从为主
slaveof no one #将当前从机变为主机
info replication #查看当前主机从机关系
14.5主从复制的原理
14.6哨兵模式
14.6.1什么是哨兵模式?
14.6.2使用的步骤
mkdir sentinel.conf
sentinel monitor mymaster 127.0.0.1 6379 1 #为哨兵设置主机地址
#其中mymaster为监控对象起的服务器名称, 1 为至少有多少个哨兵同意迁移的数量。
redis-sentinel -> redis-server
redis-server
redis-sentinel /myredis/sentinel.conf #启动哨兵
14.6.3故障恢复方法
14.6.4Java代码实现主从复制功能
private static JedisSentinelPool jedisSentinelPool=null;
public static Jedis getJedisFromSentinel(){
if(jedisSentinelPool==null){
Set
15.Redis的集群操作
15.1什么是集群?
15.2集群模拟案例
rm -rf dump63* #表示以dump63开头的文件都删掉
include /myredis/redis.conf
开启daemonize yes
Pid文件名字
指定端口
Log文件名字
Dump.rdb名字
Appendonly 关掉或者换名字
###除此之外还需要添加这些个配置
cluster-enabled yes #打开集群模式
cluster-config-file nodes-6379.conf #设定节点配置文件名
cluster-node-timeout 15000 #设定节点失联时间,超过该时间(毫秒),集群自动进行主从切换。
cp redis6379.conf redis6380.conf
cp redis6379.conf redis6381.conf
cp redis6379.conf redis6382.conf
cp redis6379.conf redis6389.conf
cp redis6379.conf redis6390.conf
cp redis6379.conf redis6391.conf
:%s/6379/6380 #进行快速地统一替换
ps -ef | grep redis #查看当前已经启动的redis服务
redis-server redis6379.conf
redis-server redis6380.conf
redis-server redis6381.conf
redis-server redis6389.conf
redis-server redis6390.conf
redis-server redis6391.conf
cd /opt/redis-6.2.1/src
#到src目录下去进行集群操作
redis-cli --cluster create --cluster-replicas 1 192.168.11.101:6379 192.168.11.101:6380 192.168.11.101:6381 192.168.11.101:6389 192.168.11.101:6390 192.168.11.101:6391
redis-cli -c -p 6379 #就可以用集群的方式进行连接,用任何的端口都是可以的
cluster nodes 查看集群中的所有结点信息
15.3Slots
15.4在集群中录入键值
15.5查询集群中的值
cluster keyslot
15.6故障恢复
cluster nodes
15.6Jedis集群操作
public class JedisClusterTest {
public static void main(String[] args) {
Set
16.Redis应用问题的解决
16.1问题一:缓存穿透
Key对应的数据源并不存在,所以每一次针对key的请求从缓存中都获取不到,请求可能会压垮数据源,请求会先查缓存,缓存有数据则返回,没有则去数据库中查。
redis的命中率降低了,一直查询数据库而不查redis,导致数据库的压力过大,造成数据库崩溃
16.2问题二:缓存击穿
16.3问题三:缓存雪崩
16.4问题四:分布式锁
16.4.1Redis实现分布式锁
#1.手动上锁删锁
setnx users 10 #为user 这个key加了锁,没有释放都无法对其进行修改
del users #删除这个key即会释放锁
#2.设置过期时间自动删除key
setnx users 10
expire users 10 #设置过期时间,自动删除锁和key资源
#3.如果上锁后发生异常,无法设置时间
#在上锁的过程中设置一下过期时间
set users 10 nx ex 12 #表示users的value值为10,nx为上锁,ex后的数值为过期时间单位为s
set sku:1:info "OK" NX PX10000
16.4.2Jedis实现上锁删锁等过程
@GetMapping("testLock")
public void testLock(){
//获取锁
Boolean lockSucceed = redisTemplate.opsForValue().setIfAbsent("keyOfLock", "111");
//setIfAbsent 类似于 setnx
//获取如果成功查询num的值
if(lockSucced){
Object value = redisTemplate.opsForValue().get("num");
if(StringUtils.isEmpty(value)){
return;
}
int num = Integer.parseInt(value+"");
redisTemplate.opsForValue().set("num", ++num);
//释放锁
redisTemplate.delete("lock");
}else{
//3获取锁失败、每隔0.1秒再获取
try {
Thread.sleep(100);
testLock();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
Boolean lockSucceed = redisTemplate.opsForValue().setIfAbsent("keyOfLock", "111",3,TimeUnit.SECONDS);
//四个参数的方法表示获取到锁并且设置过期时间
16.4.3分布式锁的其他隐藏问题
set lock UUDI nx ex 10
String uuid = UUID.randomUUID().toString();
Boolean lockSucceed = redisTemplate.opsForValue().setIfAbsent("keyOfLock", UUID,3,TimeUnit.SECONDS);
....
if(uuid.equals((String)redisTemplate.opsForValue().get("lock"))){ //判断当前环境中的锁和最初的锁uuid是否一直
this.redisTemplate.delete("lock");
}
@GetMapping("testLockLua")
public void testLockLua() {
//1 声明一个uuid ,将做为一个value 放入我们的key所对应的值中
String uuid = UUID.randomUUID().toString();
//2 定义一个锁:lua 脚本可以使用同一把锁,来实现删除!
String skuId = "25"; // 访问skuId 为25号的商品 100008348542
String locKey = "lock:" + skuId; // 锁住的是每个商品的数据
// 3 获取锁
Boolean lock = redisTemplate.opsForValue().setIfAbsent(locKey, uuid, 3, TimeUnit.SECONDS);
// 第一种: lock 与过期时间中间不写任何的代码。
// redisTemplate.expire("lock",10, TimeUnit.SECONDS);//设置过期时间
// 如果true
if (lock) {
// 执行的业务逻辑开始
// 获取缓存中的num 数据
Object value = redisTemplate.opsForValue().get("num");
// 如果是空直接返回
if (StringUtils.isEmpty(value)) {
return;
}
// 不是空 如果说在这出现了异常! 那么delete 就删除失败! 也就是说锁永远存在!
int num = Integer.parseInt(value + "");
// 使num 每次+1 放入缓存
redisTemplate.opsForValue().set("num", String.valueOf(++num));
/*使用lua脚本来锁*/
// 定义lua 脚本
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
// 使用redis执行lua执行
DefaultRedisScript