redis
自学redis的过程
铁板鱿鱼140
这个作者很懒,什么都没留下…
展开
-
Session 不共享(仅供自己参考)
在有多台的Tomcat实现并发的时候,在进行轮询使用Tomcat,在一台Tomcat登录之后,这个用户的sessionID存储在第一个Tomcat,但是当再有请求,另外一个Tomcat接受,但是Tomcat没有上一个Tomcat的保存的sessionId,就又需要登录,导致用户的体验感不好。所以采用redis保存用户的信息,因为每个Tomcat都可以访问redis,就可以实现信息的共享。原创 2024-07-23 16:58:15 · 190 阅读 · 0 评论 -
feed流(投喂)
优缺点:对于普通人,因为粉丝数量比较少,我们直接给他的粉丝推到粉丝的收件箱,不需要发件箱。所以大v的就直接放一个发件箱,对于普通的用户不做任何操作,但是对于活跃粉丝就需要将博客给推到他的收件箱。那么在第二次分页的时候,角标读取的不是5-1的数据,而是随着数据多了一个,读取的是6-2,那么就会造成第二次页数据和第一页数据有一个重复的数据6;滚动分页:通过记录一页中最后一个数据的id,第二页接着从这个数据的id的后面读取下一页的数据,这样就不会造成页与页之间的数据的重复了。优缺点:延迟低,耗时少。原创 2024-07-23 16:56:41 · 143 阅读 · 0 评论 -
redis的分片集群(仅供自己参考)
前言:为什么使用分片集群:因为redis的主从和哨兵机制主要是用来解决redis的高并发读的问题,还有redis的高并发的写的问题没有解决。使用分片集群就可以很好的解决redis写的问题,有多个master就可以实现并发的写。2、分片集群的插槽:插槽的大小分为16384(2的14次方),如果有多个master,则每个集群各占这些插槽的均分。使用{}来进行分类,{it}a,{it}b都被分在同一个插槽里面,到时候不用频繁的切换master,可以减少因频繁切换带来的性能问题。还有单个节点的大小的问题。原创 2024-07-21 14:22:55 · 296 阅读 · 0 评论 -
Redis哨兵机制
如果是主节点故障之后,那么哨兵就会从从节点中选一个来当主接主节点,判断的依据有很多,主要是看offset是否是最大的最接近故障的offset的值。选出来之后,就会执行slaveof no one,使这个从节点变为主节点,同时向存活的从节点发生信息,告知从节点,主节点发生变化。它是每隔1秒钟就向主从集群中的节点发送心跳,如果节点没有回复,则这个哨兵就主观的认为这个节点发生故障,这时候其他的哨兵也就向这个节点发送心跳,当有一半的哨兵主观的认为节点故障,那么就客观的认为这个节点不能工作了,发生故障。原创 2024-07-21 11:11:26 · 241 阅读 · 0 评论 -
reids的全量同步和增量同步
(1)首先master和slave节点建立连接,连接之后,slave会向master发送增量同步(slave会携带自己的repid和offset),master接收了slave的增量同步请求之后,就会拿自身的replId和slave的replId进行判断,如果相同则进行增量同步,不相同则进行全量同步,之后master会将自己的replId和offset发送给slave。slave执行log文件,将数据补充完整,每当数据不一致的时候,都进行增量同步。原创 2024-07-21 10:09:42 · 304 阅读 · 0 评论 -
redis持久化AOF(仅供自己参考)
1、redis每处理一个命令都会在AOF中添加一条命令,如果redis不小心发生宕机,那么只需要执行这个命令文件AOF文件就可以恢复数据了。3、bgrewriteaof命令,是对AOF文件中的数据进行重写,对重复的命令执行一次,对相同的命令合并执行。减少AOF文件的大小。4、RDB和AOF结合使用,RDB主要用来异地容灾,AOF数据安全性较高。原创 2024-07-18 16:13:16 · 139 阅读 · 0 评论 -
redis持久化RDB(仅供自己参考)
冲突的解决:在进行RDB的时候,主线程和子线程的读取不受任何影响,但是如果这个时候主线程有个写操作,那么如果直接在原数据上操作,那么就会和子进程的读取有冲突,解决方法:主线程会拷贝要修改的数据,得到数据的副本,同时将自己的页表的映射进行修改。解决了冲突带来了数据的不一致。共享的方式:在fork之后,子进程跟父进程几乎一模一样,那么父进程有的页表,子进程也有。(1)save命令:是直接占用主线程来执行持久化的(因为redis是单线程的,如果执行save命令,则其他命令,无论查询还是怎么的都被阻塞了)原创 2024-07-18 15:36:08 · 252 阅读 · 0 评论 -
HyperLogLog
2、HyperLogLog(算法)(对于重复数据,只保存一个)1、uv和pv的区别。原创 2024-07-18 14:33:42 · 108 阅读 · 0 评论 -
位运算和BitMap(位图)仅供自己参考
只要有一个对应的位是 1,结果位就是 1。只有两个都是0的时候才位0。只有当两个对应的位都是 1 时,结果位才是 1。&是只有两位都是1的时候才位1,其他的情况都为0。: 将一个数的二进制位向左移动指定的位数。(<<是有符号的左移),(<<<无符号的左移)(10<<1 == 20)(-10<< = -20)(>>有符号的右移),(>>>无符号的右移)(10>>1 = 5) (-10>>1 = )当两个对应的位相同时,结果位是 0。0和1为1,0和0为0,1和1为0。将 0 变成 1,将 1 变成 0。原创 2024-07-18 14:01:39 · 259 阅读 · 0 评论 -
redis消息队列
确认消息命令:XACK key group ID [ID ...] (如果消息只是拿到,没有确认的话,消息会存放在expending-list里面)第二个sub接收的频道(order.*)接收order.后面所有的频道,使得两次pub发送的消息都接收到了。创建一个消费者组: XGROUP CREATE s1 g1 $ (s1队列名称,g1消费者组的名称)第一个sub接收的信息通道(order.p1)使得pub发送第二次消息没有接受到。$:则实时取数据,在消息存放的时候才会获取。原创 2024-07-13 23:04:34 · 467 阅读 · 0 评论 -
redis redisson(仅供自己参考)
等待也不是死等(一直while循环),因为redis在释放一个键的时候,会发布一个通知,其他线程一直等待这个通过,有了通知之后,再次判断是否已经过了等待时间(设置的一个线程最长的等待时间,如果超出则获取锁失败)。为了解决这样的问题,给每一个获取锁的线程增加一个定时的任务(TimeOut),如果key释放的时间剩余key设置的释放时间的三分之一的话,就重新给key重新设置超时释放的值(这个值一直是原本的时间)。当主节点宕机,就会出现主节点的数据还没有同步到从节点,导致的一系列的问题。原创 2024-07-11 15:11:43 · 802 阅读 · 0 评论 -
分布式锁(仅供自己参考)
分布式锁:满足分布式系统或集群式下多进程可见并且互斥的锁(使用外部的锁,因为如果是集群部署,每台服务器都有一个对应的tomcat,则每个tomcat的jvm就不同,锁对象就不同(加锁的机制,每个jvm有一个锁监听器,里面存放着是否含有所有加锁的对象。有一次线程来,首先判断该线程所具有的所要加锁的对象在锁监视器中是否有,有则让它等待,没有的话则将加锁的对象加进来,再有线程来判断,则和上面的流程一样))(自己理解的流程,可能不对,请指错)因为在加锁的时候new的不同的对象,使得每一个name都是不同的。原创 2024-07-09 21:54:18 · 1331 阅读 · 0 评论