网站卖给别人后做违法信息,电子商务专业可以从事什么工作,做产品类的工作上什么网站好,电子商务网站开发期末考试高清思维导图已同步Git#xff1a;https://github.com/SoWhat1412/xmindfile总感觉哪里不对#xff0c;但是又说不上来1、基本类型及底层实现1.1、String用途#xff1a;适用于简单key-value存储、setnx key value实现分布式锁、计数器(原子性)、分布式全局唯一ID。底层https://github.com/SoWhat1412/xmindfile总感觉哪里不对但是又说不上来1、基本类型及底层实现1.1、String用途适用于简单key-value存储、setnx key value实现分布式锁、计数器(原子性)、分布式全局唯一ID。底层C语言中String用char[]数组表示源码中用SDS(simple dynamic string)封装char[]这是是Redis存储的最小单元一个SDS最大可以存储512M信息。struct sdshdr{unsigned int len; // 标记char[]的长度unsigned int free; //标记char[]中未使用的元素个数char buf[]; // 存放元素的坑
}
Redis对SDS再次封装生成了RedisObject核心有两个作用说明是5种类型哪一种。里面有指针用来指向 SDS。当你执行set name sowhat的时候其实Redis会创建两个RedisObject对象键的RedisObject 和 值的RedisOjbect 其中它们type REDIS_STRING而SDS分别存储的就是 name 跟 sowhat 字符串咯。并且Redis底层对SDS有如下优化SDS修改后大小 1M时 系统会多分配空间来进行空间预分配。SDS是惰性释放空间的你free了空间可是系统把数据记录下来下次想用时候可直接使用。不用新申请空间。1.2、List查看源码底层 adlist.h 会发现底层就是个 双端链表该链表最大长度为2^32-1。常用就这几个组合。lpush lpop stack 先进后出的栈 lpush rpop queue 先进先出的队列 lpush ltrim capped collection 有限集合lpush brpop message queue 消息队列一般可以用来做简单的消息队列并且当数据量小的时候可能用到独有的压缩列表来提升性能。当然专业点还是要 RabbitMQ、ActiveMQ等1.3、Hash散列非常适用于将一些相关的数据存储在一起比如用户的购物车。该类型在日常用途还是挺多的。这里需要明确一点Redis中只有一个K一个V。其中 K 绝对是字符串对象而 V 可以是String、List、Hash、Set、ZSet任意一种。hash的底层主要是采用字典dict的结构整体呈现层层封装。从小到大如下1.3.1、dictEntry真正的数据节点包括key、value 和 next 节点。1.3.2、dictht1、数据 dictEntry 类型的数组每个数组的item可能都指向一个链表。2、数组长度 size。3、sizemask 等于 size - 1。4、当前 dictEntry 数组中包含总共多少节点。1.3.3、dict1、dictType 类型包括一些自定义函数这些函数使得key和value能够存储2、rehashidx 其实是一个标志量如果为-1说明当前没有扩容如果不为 -1 则记录扩容位置。3、dictht数组两个Hash表。4、iterators 记录了当前字典正在进行中的迭代器组合后结构就是如下1.3.4、渐进式扩容为什么 dictht ht[2]是两个呢目的是在扩容的同时不影响前端的CURD慢慢的把数据从ht[0]转移到ht[1]中同时rehashindex来记录转移的情况当全部转移完成将ht[1]改成ht[0]使用。rehashidx -1说明当前没有扩容rehashidx ! -1则表示扩容到数组中的第几个了。扩容之后的数组大小为大于used*2的2的n次方的最小值跟 HashMap 类似。然后挨个遍历数组同时调整rehashidx的值对每个dictEntry[i] 再挨个遍历链表将数据 Hash 后重新映射到 dictht[1]里面。并且 dictht[0].use 跟 dictht[1].use 是动态变化的。整个过程的重点在于rehashidx其为第一个数组正在移动的下标位置如果当前内存不够或者操作系统繁忙扩容的过程可以随时停止。停止之后如果对该对象进行操作那是什么样子的呢1、如果是新增则直接新增后第二个数组因为如果新增到第一个数组以后还是要移过来没必要浪费时间2、如果是删除更新查询则先查找第一个数组如果没找到则再查询第二个数组。1.4、Set如果你明白Java中HashSet是HashMap的简化版那么这个Set应该也理解了。都是一样的套路而已。这里你可以认为是没有Value的Dict。看源码 t.set.c 就可以了解本质了。int setTypeAdd(robj *subject, robj *value) {long long llval;if (subject-encoding REDIS_ENCODING_HT) {// 看到底层调用的还是dictAdd只不过第三个参数 NULLif (dictAdd(subject-ptr,value,NULL) DICT_OK) {incrRefCount(value);return 1;}....
1.5、ZSet范围查找 的天敌就是 有序集合看底层 redis.h 后就会发现 Zset用的就是可以跟二叉树媲美的跳跃表来实现有序。跳表就是多层链表的结合体跳表分为许多层(level)每一层都可以看作是数据的索引这些索引的意义就是加快跳表查找数据速度。每一层的数据都是有序的上一层数据是下一层数据的子集并且第一层(level 1)包含了全部的数据层次越高跳跃性越大包含的数据越少。并且随便插入一个数据该数据是否会是跳表索引完全随机的跟玩骰子一样。跳表包含一个表头它查找数据时是从上往下从左往右进行查找。现在找出值为37的节点为例来对比说明跳表和普遍的链表。没有跳表查询 比如我查询数据37如果没有上面的索引时候路线如下图有跳表查询 有跳表查询37的时候路线如下图应用场景积分排行榜、时间排序新闻、延时队列。1.6、Redis Geo以前写过Redis Geo核心原理解析想看的直接跳转即可。他的核心思想就是将地球近似为球体来看待然后 GEO利用 GeoHash 将二维的经纬度转换成字符串来实现位置的划分跟指定距离的查询。1.7、HyperLogLogHyperLogLog 是一种概率数据结构它使用概率算法来统计集合的近似基数。而它算法的最本源则是伯努利过程 分桶 调和平均数。具体实现可看 HyperLogLog 讲解。功能误差允许范围内做基数统计 (基数就是指一个集合中不同值的个数) 的时候非常有用每个HyperLogLog的键可以计算接近2^64不同元素的基数而大小只需要12KB。错误率大概在0.81%。所以如果用做 UV 统计很合适。HyperLogLog底层 一共分了 2^14 个桶也就是 16384 个桶。每个(registers)桶中是一个 6 bit 的数组这里有个骚操作就是一般人可能直接用一个字节当桶浪费2个bit空间但是Redis底层只用6个然后通过前后拼接实现对内存用到了极致最终就是 16384*6/8/1024 12KB。1.8、bitmapBitMap 原本的含义是用一个比特位来映射某个元素的状态。由于一个比特位只能表示 0 和 1 两种状态所以 BitMap 能映射的状态有限但是使用比特位的优势是能大量的节省内存空间。在 Redis 中BitMap 底层是基于字符串类型实现的可以把 Bitmaps 想象成一个以比特位为单位的数组数组的每个单元只能存储0和1数组的下标在 Bitmaps 中叫做偏移量BitMap 的 offset 值上限 2^32 - 1。用户签到key 年份用户id offset 今天是一年中的第几天 % 今年的天数统计活跃用户使用日期作为 key然后用户 id 为 offset 设置不同offset为0 1 即可。PS : Redis 它的通讯协议是基于TCP的应用层协议 RESP(REdis Serialization Protocol)。1.9、Bloom Filter使用布隆过滤器得到的判断结果不存在的一定不存在存在的不一定存在。布隆过滤器 原理当一个元素被加入集合时通过K个散列函数将这个元素映射成一个位数组中的K个点(有效降低冲突概率)把它们置为1。检索时我们只要看看这些点是不是都是1就知道集合中有没有它了如果这些点有任何一个为0则被检元素一定不在如果都是1则被检元素很可能在。这就是布隆过滤器的基本思想。想玩的话可以用Google的guava包玩耍一番。1.10 发布订阅redis提供了发布、订阅模式的消息机制其中消息订阅者与发布者不直接通信发布者向指定的频道channel发布消息订阅该频道的每个客户端都可以接收到消息。不过比专业的MQ(RabbitMQ RocketMQ ActiveMQ Kafka)相比不值一提这个功能就算球了。2、持久化因为Redis数据在内存断电既丢因此持久化到磁盘是必须得有的Redis提供了RDB跟AOF两种模式。2.1、RDBRDB 持久化机制是对 Redis 中的数据执行周期性的持久化。更适合做冷备。优点1、压缩后的二进制文适用于备份、全量复制用于灾难恢复加载RDB恢复数据远快于AOF方式适合大规模的数据恢复。2、如果业务对数据完整性和一致性要求不高RDB是很好的选择。数据恢复比AOF快。缺点1、RDB是周期间隔性的快照文件数据的完整性和一致性不高因为RDB可能在最后一次备份时宕机了。2、备份时占用内存因为Redis 在备份时会独立fork一个子进程将数据写入到一个临时文件此时内存中的数据是原来的两倍哦最后再将临时文件替换之前的备份文件。所以要考虑到大概两倍的数据膨胀性。注意手动触发及COW1、SAVE 直接调用 rdbSave 阻塞 Redis 主进程导致无法提供服务。2、BGSAVE 则 fork 出一个子进程子进程负责调用 rdbSave 在保存完成后向主进程发送信号告知完成。在BGSAVE 执行期间仍可以继续处理客户端的请求。3、Copy On Write 机制备份的是开始那个时刻内存中的数据只复制被修改内存页数据不是全部内存数据。4、Copy On Write 时如果父子进程大量写操作会导致分页错误。2.2、AOFAOF 机制对每条写入命令作为日志以 append-only 的模式写入一个日志文件中因为这个模式是只追加的方式所以没有任何磁盘寻址的开销所以很快有点像 Mysql 中的binlog。AOF更适合做热备。优点AOF是一秒一次去通过一个后台的线程fsync操作数据丢失不用怕。缺点1、对于相同数量的数据集而言AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。2、根据同步策略的不同AOF在运行效率上往往会慢于RDB。总之每秒同步策略的效率是比较高的。AOF整个流程分两步第一步是命令的实时写入不同级别可能有1秒数据损失。命令先追加到aof_buf然后再同步到AO磁盘如果实时写入磁盘会带来非常高的磁盘IO影响整体性能。第二步是对aof文件的重写目的是为了减少AOF文件的大小可以自动触发或者手动触发(BGREWRITEAOF)是Fork出子进程操作期间Redis服务仍可用。1、在重写期间由于主进程依然在响应命令为了保证最终备份的完整性它依然会写入旧的AOF中如果重写失败能够保证数据不丢失。2、为了把重写期间响应的写入信息也写入到新的文件中因此也会为子进程保留一个buf防止新写的file丢失数据。3、重写是直接把当前内存的数据生成对应命令并不需要读取老的AOF文件进行分析、命令合并。4、无论是 RDB 还是 AOF 都是先写入一个临时文件然后通过rename完成文件的替换工作。关于Fork的建议1、降低fork的频率比如可以手动来触发RDB生成快照、与AOF重写2、控制Redis最大使用内存防止fork耗时过长3、配置牛逼点合理配置Linux的内存分配策略避免因为物理内存不足导致fork失败。4、Redis在执行BGSAVE和BGREWRITEAOF命令时哈希表的负载因子5而未执行这两个命令时1。目的是尽量减少写操作避免不必要的内存写入操作。5、哈希表的扩展因子哈希表已保存节点数量 / 哈希表大小。因子决定了是否扩展哈希表。2.3、恢复启动时会先检查AOF(数据更完整)文件是否存在如果不存在就尝试加载RDB。2.4、建议既然单独用RDB会丢失很多数据。单独用AOF数据恢复没RDB来的快所以出现问题了第一时间用RDB恢复然后AOF做数据补全才说王道。3、Redis为什么那么快3.1、 基于内存实现数据都存储在内存里相比磁盘IO操作快百倍操作速率很快。3.2、高效的数据结构Redis底层多种数据结构支持不同的数据类型比如HyperLogLog它连2个字节都不想浪费。3.3、丰富而合理的编码Redis底层提供了 丰富而合理的编码 五种数据类型根据长度及元素的个数适配不同的编码格式。1、String自动存储int类型非int类型用raw编码。2、List字符串长度且元素个数小于一定范围使用 ziplist 编码否则转化为 linkedlist 编码。3、Hashhash 对象保存的键值对内的键和值字符串长度小于一定值及键值对。4、Set保存元素为整数及元素个数小于一定范围使用 intset 编码任意条件不满足则使用 hashtable 编码。5、Zset保存的元素个数小于定值且成员长度小于定值使用 ziplist 编码任意条件不满足则使用 skiplist 编码。3.4、合适的线程模型I/O 多路复用模型同时监听客户端连接多线程是需要上下文切换的对于内存数据库来说这点很致命。3.5、 Redis6.0后引入多线程提速要知道 读写网络的read/write系统耗时 Redis运行执行耗时Redis的瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向:1、提高网络 IO 性能典型的实现比如使用 DPDK 来替代内核网络栈的方式 2、使用多线程充分利用多核典型的实现比如 Memcached。协议栈优化的这种方式跟 Redis 关系不大支持多线程是一种最有效最便捷的操作方式。所以Redis支持多线程主要就是两个原因1、可以充分利用服务器 CPU 资源目前主线程只能利用一个核2、多线程任务可以分摊 Redis 同步 IO 读写负荷关于多线程须知:Redis 6.0 版本 默认多线程是关闭的 io-threads-do-reads noRedis 6.0 版本 开启多线程后 线程数也要 谨慎设置。多线程可以使得性能翻倍但是多线程只是用来处理网络数据的读写和协议解析执行命令仍然是单线程顺序执行。4、常见问题4.1、缓存雪崩雪崩定义Redis中大批量key在同一时间同时失效导致所有请求都打到了MySQL。而MySQL扛不住导致大面积崩塌。雪崩解决方案1、缓存数据的过期时间加上个随机值防止同一时间大量数据过期现象发生。2、如果缓存数据库是分布式部署将热点数据均匀分布在不同搞得缓存数据库中。3、设置热点数据永远不过期。4.2、缓存穿透穿透定义缓存穿透 是 指缓存和数据库中都没有的数据比如ID默认0黑客一直 请求ID -12的数据那么就会导致数据库压力过大严重会击垮数据库。穿透解决方案1、后端接口层增加 用户鉴权校验参数做校验等。2、单个IP每秒访问次数超过阈值直接拉黑IP关进小黑屋1天在获取IP代理池的时候我就被拉黑过。3、从缓存取不到的数据在数据库中也没有取到这时也可以将key-value对写为key-null 失效时间可以为15秒防止恶意攻击。4、用Redis提供的 Bloom Filter 特性也OK。4.3、缓存击穿击穿定义现象大并发集中对这一个热点key进行访问当这个Key在失效的瞬间持续的大并发就穿破缓存直接请求数据库。击穿解决设置热点数据永远不过期 加上互斥锁也能搞定了4.4、双写一致性双写缓存跟数据库均更新数据如何保证数据一致性1、先更新数据库再更新缓存安全问题线程A更新数据库-线程B更新数据库-线程B更新缓存-线程A更新缓存。导致脏读。业务场景读多写少场景频繁更新数据库而缓存根本没用。更何况如果缓存是叠加计算后结果更浪费性能。2、先删缓存再更新数据库A 请求写来更新缓存。B 发现缓存不在去数据查询旧值后写入缓存。A 将数据写入数据库此时缓存跟数据库不一致。因此 FackBook 提出了 Cache Aside Pattern失效应用程序先从cache取数据没有得到则从数据库中取数据成功后放到缓存中。命中应用程序从cache中取数据取到后返回。更新先把数据存到数据库中成功后再让缓存失效。4.5、脑裂脑裂是指因为网络原因导致master节点、slave节点 和 sentinel集群处于不用的网络分区此时因为sentinel集群无法感知到master的存在所以将slave节点提升为master节点 此时存在两个不同的master节点就像一个大脑分裂成了两个。其实在Hadoop 、Spark集群中都会出现这样的情况只是解决方法不同而已(用ZK配合强制杀死)。集群脑裂问题中如果客户端还在基于原来的master节点继续写入数据那么新的master节点将无法同步这些数据当网络问题解决后sentinel集群将原先的master节点降为slave节点此时再从新的master中同步数据将造成大量的数据丢失。Redis处理方案是redis的配置文件中存在两个参数min-replicas-to-write 3 表示连接到master的最少slave数量
min-replicas-max-lag 10 表示slave连接到master的最大延迟时间
如果连接到master的slave数量 第一个参数 且 ping的延迟时间 第二个参数那么master就会拒绝写请求配置了这两个参数后如果发生了集群脑裂则原先的master节点接收到客户端的写入请求会拒绝就可以减少数据同步之后的数据丢失。4.6、事务MySQL 中的事务还是挺多道道的还要而在Redis中的事务只要有如下三步关于事务具体结论1、redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。 2、Redis事务没有隔离级别的概念批量操作在发送 EXEC 命令前被放入队列缓存并不会被实际执行也就不存在事务内的查询要看到事务里的更新事务外查询不能看到。3、Redis不保证原子性Redis中单条命令是原子性执行的但事务不保证原子性。4、Redis编译型错误事务中所有代码均不执行指令使用错误。运行时异常是错误命令导致异常其他命令可正常执行。5、watch指令类似于乐观锁在事务提交时如果watch监控的多个KEY中任何KEY的值已经被其他客户端更改则使用EXEC执行事务时事务队列将不会被执行。4.7、正确开发步骤上线前Redis 高可用主从哨兵Redis cluster避免全盘崩溃。上线时本地 ehcache 缓存 Hystrix 限流 降级避免MySQL扛不住。上线后Redis 持久化采用 RDB AOF 来保证断点后自动从磁盘上加载数据快速恢复缓存数据。5、分布式锁日常开发中我们可以用 synchronized 、Lock 实现并发编程。但是Java中的锁只能保证在同一个JVM进程内中执行。如果在分布式集群环境下用锁呢日常一般有两种选择方案。5.1、 Zookeeper实现分布式锁你需要知道一点基本zookeeper知识1、持久节点客户端断开连接zk不删除persistent类型节点 2、临时节点客户端断开连接zk删除ephemeral类型节点 3、顺序节点节点后面会自动生成类似0000001的数字表示顺序 4、节点变化的通知客户端注册了监听节点变化的时候会调用回调方法大致流程如下其中注意每个节点只监控它前面那个节点状态从而避免羊群效应。关于模板代码百度即可。缺点频繁的创建删除节点加上注册watch事件对于zookeeper集群的压力比较大性能也比不上Redis实现的分布式锁。5.2、 Redis实现分布式锁本身原理也比较简单Redis 自身就是一个单线程处理器具备互斥的特性通过setNXexist等命令就可以完成简单的分布式锁处理好超时释放锁的逻辑即可。SETNXSETNX 是SET if Not eXists的简写日常指令是SETNX key value如果 key 不存在则set成功返回 1如果这个key已经存在了返回0。SETEXSETEX key seconds value 表达的意思是 将值 value 关联到 key 并将 key 的生存时间设为多少秒。如果 key 已经存在setex命令将覆写旧值。并且 setex是一个原子性(atomic)操作。加锁一般就是用一个标识唯一性的字符串比如UUID 配合 SETNX 实现加锁。解锁这里用到了LUA脚本LUA可以保证是原子性的思路就是判断一下Key和入参是否相等是的话就删除返回成功10就是失败。缺点这个锁是无法重入的且自己实心的话各种边边角角都要考虑到所以了解个大致思路流程即可工程化还是用开源工具包就行。5.3、 Redisson实现分布式锁Redisson 是在Redis基础上的一个服务采用了基于NIO的Netty框架不仅能作为Redis底层驱动客户端还能将原生的RedisHashListSetStringGeoHyperLogLog等数据结构封装为Java里大家最熟悉的映射Map列表List集Set通用对象桶Object Bucket地理空间对象桶Geospatial Bucket基数估计算法HyperLogLog等结构。这里我们只是用到了关于分布式锁的几个指令他的大致底层原理Redisson加锁解锁 大致流程图如下6、Redis 过期策略和内存淘汰策略6.1、Redis的过期策略Redis中 过期策略 通常有以下三种1、定时过期每个设置过期时间的key都需要创建一个定时器到过期时间就会立即对key进行清除。该策略可以立即清除过期的数据对内存很友好但是会占用大量的CPU资源去处理过期的数据从而影响缓存的响应时间和吞吐量。2、惰性过期只有当访问一个key时才会判断该key是否已过期过期则清除。该策略可以最大化地节省CPU资源却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问从而不会被清除占用大量内存。3、定期过期每隔一定的时间会扫描一定数量的数据库的expires字典中一定数量的key并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时可以在不同情况下使得CPU和内存资源达到最优的平衡效果。expires字典会保存所有设置了过期时间的key的过期时间数据其中 key 是指向键空间中的某个键的指针value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。Redis采用的过期策略惰性删除 定期删除。memcached采用的过期策略惰性删除。6.2、6种内存淘汰策略Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时怎么处理需要新写入且需要申请额外空间的数据。1、volatile-lru从已设置过期时间的数据集server.db[i].expires中挑选最近最少使用的数据淘汰 2、volatile-ttl从已设置过期时间的数据集server.db[i].expires中挑选将要过期的数据淘汰 3、volatile-random从已设置过期时间的数据集server.db[i].expires中任意选择数据淘汰 4、allkeys-lru从数据集server.db[i].dict中挑选最近最少使用的数据淘汰 5、allkeys-random从数据集server.db[i].dict中任意选择数据淘汰 6、no-enviction驱逐禁止驱逐数据不删除的意思。面试常问常考的也就是LRU了大家熟悉的LinkedHashMap中也实现了LRU算法的实现如下class SelfLRUCacheK, V extends LinkedHashMapK, V {private final int CACHE_SIZE;/*** 传递进来最多能缓存多少数据* param cacheSize 缓存大小*/public SelfLRUCache(int cacheSize) {// true 表示让 linkedHashMap 按照访问顺序来进行排序最近访问的放在头部最老访问的放在尾部。super((int) Math.ceil(cacheSize / 0.75) 1, 0.75f, true);CACHE_SIZE cacheSize;}Overrideprotected boolean removeEldestEntry(Map.EntryK, V eldest) {// 当 map中的数据量大于指定的缓存个数的时候就自动删除最老的数据。return size() CACHE_SIZE;}
}
6.2、总结Redis的内存淘汰策略的选取并不会影响过期的key的处理。内存淘汰策略用于处理内存不足时的需要申请额外空间的数据过期策略用于处理过期的缓存数据。7、Redis 集群高可用单机问题有机器故障、容量瓶颈、QPS瓶颈。在实际应用中Redis的多机部署时候会涉及到redis主从复制、Sentinel哨兵模式、Redis Cluster。模式优点缺点单机版架构简单部署方便机器故障、容量瓶颈、QPS瓶颈主从复制高可靠性读写分离故障恢复复杂主库的写跟存受单机限制Sentinel 哨兵集群部署简单HA原理繁琐slave存在资源浪费不能解决读写分离问题Redis Cluster数据动态存储solt可扩展高可用客户端动态感知后端变更批量操作支持查7.1、redis主从复制该模式下 具有高可用性且读写分离 会采用 增量同步 跟 全量同步 两种机制。7.1.1、全量同步Redis全量复制一般发生在Slave初始化阶段这时Slave需要将Master上的所有数据都复制一份1、slave连接master发送psync命令。2、master接收到psync命名后开始执行bgsave命令生成RDB文件并使用缓冲区记录此后执行的所有写命令。3、master发送快照文件到slave并在发送期间继续记录被执行的写命令。4、slave收到快照文件后丢弃所有旧数据载入收到的快照。5、master快照发送完毕后开始向slave发送缓冲区中的写命令。6、slave完成对快照的载入开始接收命令请求并执行来自master缓冲区的写命令。7.1.2、增量同步也叫指令同步就是从库重放在主库中进行的指令。Redis会把指令存放在一个环形队列当中因为内存容量有限如果备机一直起不来不可能把所有的内存都去存指令也就是说如果备机一直未同步指令可能会被覆盖掉。Redis增量复制是指Slave初始化后开始正常工作时master发生的写操作同步到slave的过程。增量复制的过程主要是master每执行一个写命令就会向slave发送相同的写命令。7.1.3、Redis主从同步策略1、主从刚刚连接的时候进行全量同步全同步结束后进行增量同步。当然如果有需要slave 在任何时候都可以发起全量同步。redis 策略是无论如何首先会尝试进行增量同步如不成功要求从机进行全量同步。2、slave在同步master数据时候如果slave丢失连接不用怕slave在重新连接之后丢失重补。3、一般通过主从来实现读写分离但是如果master挂掉后如何保证Redis的 HA呢引入Sentinel进行master的选择。7.2、高可用之哨兵模式Redis-sentinel 本身是一个独立运行的进程一般sentinel集群 节点数至少三个且奇数个它能监控多个master-slave集群sentinel节点发现master宕机后能进行自动切换。Sentinel可以监视任意多个主服务器以及主服务器属下的从服务器并在被监视的主服务器下线时自动执行故障转移操作。这里需注意sentinel也有single-point-of-failure问题。大致罗列下哨兵用途集群监控循环监控master跟slave节点。消息通知当它发现有redis实例有故障的话就会发送消息给管理员 故障转移这里分为主观下线(单独一个哨兵发现master故障了)。客观下线(多个哨兵进行抉择发现达到quorum数时候开始进行切换)。配置中心如果发生了故障转移它会通知将master的新地址写在配置中心告诉客户端。7.3、Redis ClusterRedisCluster是Redis的分布式解决方案在3.0版本后推出的方案有效地解决了Redis分布式的需求。7.3.1、分区规则常见的分区规则节点取余hash(key) % N一致性哈希一致性哈希环虚拟槽哈希CRC16[key] 16383RedisCluster采用了虚拟槽分区方式具题的实现细节如下1、采用去中心化的思想它使用虚拟槽solt分区覆盖到所有节点上取数据一样的流程节点之间使用轻量协议通信Gossip来减少带宽占用所以性能很高 2、自动实现负载均衡与高可用自动实现failover并且支持动态扩展官方已经玩到可以1000个节点 实现的复杂度低。3、每个Master也需要配置主从并且内部也是采用哨兵模式如果有半数节点发现某个异常节点会共同决定更改异常节点的状态。4、如果集群中的master没有slave节点则master挂掉后整个集群就会进入fail状态因为集群的slot映射不完整。如果集群超过半数以上的master挂掉集群都会进入fail状态。5、官方推荐 集群部署至少要3台以上的master节点。8、Redis 限流经常乘坐北京西二旗地铁或者在北京西站乘坐的时候经常会遇到一种情况就是如果人很多地铁的工作人员拿个小牌前面一档让你等会儿再检票这就是实际生活应对人流量巨大的措施。在开发高并发系统时有三把利器用来保护系统缓存、降级和限流。那么何为限流呢顾名思义限流就是限制流量就像你宽带包了1个G的流量用完了就没了。通过限流我们可以很好地控制系统的qps从而达到保护系统的目的。1、基于Redis的setnx、zset1.2、setnx比如我们需要在10秒内限定20个请求那么我们在setnx的时候可以设置过期时间10当请求的setnx数量达到20时候即达到了限流效果。缺点比如当统计1-10秒的时候无法统计2-11秒之内如果需要统计N秒内的M个请求那么我们的Redis中需要保持N个key等等问题。1.3、zset其实限流涉及的最主要的就是滑动窗口上面也提到1-10怎么变成2-11。其实也就是起始值和末端值都各1即可。我们可以将请求打造成一个zset数组当每一次请求进来的时候value保持唯一可以用UUID生成而score可以用当前时间戳表示因为score我们可以用来计算当前时间戳之内有多少的请求数量。而zset数据结构也提供了range方法让我们可以很轻易的获取到2个时间戳内有多少请求缺点就是zset的数据结构会越来越大。2、漏桶算法漏桶算法思路把水比作是请求漏桶比作是系统处理能力极限水先进入到漏桶里漏桶里的水按一定速率流出当流出的速率小于流入的速率时由于漏桶容量有限后续进入的水直接溢出拒绝请求以此实现限流。3、令牌桶算法令牌桶算法的原理可以理解成医院的挂号看病只有拿到号以后才可以进行诊病。细节流程大致1、所有的请求在处理之前都需要拿到一个可用的令牌才会被处理。2、根据限流大小设置按照一定的速率往桶里添加令牌。3、设置桶最大可容纳值当桶满时新添加的令牌就被丢弃或者拒绝。4、请求达到后首先要获取令牌桶中的令牌拿着令牌才可以进行其他的业务逻辑处理完业务逻辑之后将令牌直接删除。5、令牌桶有最低限额当桶中的令牌达到最低限额的时候请求处理完之后将不会删除令牌以此保证足够的限流。工程化1、自定义注解、aop、Redis Lua 实现限流。2、推荐 guava 的RateLimiter实现。9、常见知识点字符串模糊查询时用Keys可能导致线程阻塞尽量用scan指令进行无阻塞的取出数据然后去重下即可。多个操作的情况下记得用pipeLine把所有的命令一次发过去避免频繁的发送、接收带来的网络开销提升性能。bigkeys可以扫描redis中的大key底层是使用scan命令去遍历所有的键对每个键根据其类型执行STRLEN、LLEN、SCARD、HLEN、ZCARD这些命令获取其长度或者元素个数。缺陷是线上试用并且个数多不一定空间大线上应用记得开启Redis慢查询日志哦基本思路跟MySQL类似。Redis中因为内存分配策略跟增删数据是会导致内存碎片你可以重启服务也可以执行activedefrag yes进行内存重新整理来解决此问题。1、Ratio 1 表明有内存碎片越大表明越多严重。2、Ratio 1 表明正在使用虚拟内存虚拟内存其实就是硬盘性能比内存低得多这是应该增强机器的内存以提高性能。3、一般来说mem_fragmentation_ratio的数值在1 ~ 1.5之间是比较健康的
往期推荐
线程池的7种创建方式强烈推荐你用它...Redis的自白我为什么在单线程的这条路上越走越远Redis 6.0 正式版终于发布了除了多线程还有什么新功能关注我每天陪你进步一点点
