LYJbao的博客

小伙伴们肯定多少对哈希表的基本思想会有一点了解的，我就不具体解释了~在这里的分片方式中，简单来说就是借助一个哈希函数把key映射到整数，再针对数组的长度求余，就可以得到一个数组下标啦~说明一：把key映射到整数因为求余中，当然是要求该数为整数，而key值不一定为整数，所以我们借助映射来得到每个不同的key所对应的整数。例如使用md5，就可以将一个字符串经过一系列的数学变换将其转换为一个整数【十六进制，并且计算出的所有字符串的长度都是固定的；

我们在前面学习中，都有了解关于线程安全的问题，那引发这个问题的关键就是，多个线程去修改了同一个公共资源引发的“一票多卖”的问题，例如Java中就可以使用synchronized来保证线程安全。但这种方法只是在同一进程下管用，当我们引入了分布式系统后，是多个进程在工作，那多个进程在多个主机下，想要同时修改数据库中的某些公共资源而引发的问题，我们该如何解决呢？这里就要使用到分布式锁了。其本质上就是使用一个公共的服务器来记录加锁状态。

缓存，其实核心实现的就是能够更快访问到数据~更快既然是一个比较级的关系，那么就是会有一个相对关系，谁对谁来说更快，谁对谁来说访问速度更快，是谁谁的缓存。举例理解：你把钱存在银行，每次买东西之前，你需要去银行取钱，然后再来付款，这个过程就会比较麻烦；这种情况下，你可以取一小部分钱放在口袋里，每次买东西付款时直接从口袋里取钱，这个过程就会相对来说更加高效了。此时口袋相对银行来说访问速度更快，就可以使用口袋作为银行的缓存，大大提高办事效率~

哨兵-监控主节点。哨兵节点通过心跳包，判定redis服务器是否正常工作。如果心跳包没有如约而至，就说明redis服务器挂了~ 但是这里不能排除是因为网络波动的影响，因此只能单方面的认为这个redis节点挂了，也就是主观下线~

心跳包机制的实现：主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通信主节点：默认，每个10s给从节点发送一个ping命令，从节点收到后返回pong从节点：默认，每隔1s就给主节点发送一个特定的请求，机会上报当前从节点的复制数据的进度（offset）默认等待响应时间：60s，超过时间，就会判定对方出事了，就会断开复制客户端连接。从节点恢复连接后，心跳机制继续进行

适合小白学习~

这里所说的持久化，其实就是将数据存储在硬盘上。我们都知道redis的特点就是快，他快就是因为他将数据存储在内存中。但是数据存储在内存中时，重启进程或者重启主机后，数据就不存在。而如果在使用Redis时，重启进程或重启主机后数据就不存在了，就太鸡肋了~

spring中是对redis的原生命令进行了封装，这里的封装和jedis封装不同，他很多封装后的命令对应的方法与原生命令有所差距，所以在使用时，大多数命令根据英文意思是可以猜到命令含义的，如果不认识的可以去官网中查看，其所指的是哪个命令~上述调用的是opsForValue就是指的是数据类型为string时的接口，后面的get就是string命令中的get命令~和原生命令有些出入，详细的可取官网看，这里只是一个简单了解举例~同上述使用flushall一样，其他原生命令都可以在这里这样写~

我们之前学习Redis命令时，直接在Linux服务器中所提供的redis客户端上使用的，也就是说Redis服务器和客户端在同一台主机上。而现在我们使用Java去操作Redis，一般Java开发都是在Windows上，也就是在自己的电脑上的，就会导致一个问题，客户端和服务器不在同一台主机上。这种情况下，切记可不敢去云服务器上把这个端口开放哈！！！因为太容易被攻击了~这个情况，我们有两个解决办法~

前面的博客中，我们有提到使用keys *来获取所有的key，但这种办法，当Redis中存储的有很多key时，实行此命令所耗费的时长就会很长，不符合使用规范，redis一般情况下，都会要求命令执行时，短平快~因此提出使用渐进式遍历，也就是说，在不能使用keys *的情况下，我又想获取redis中的所有的key，就需要使用渐进式命令，所谓渐进，就是循序渐进，我们一次取出一点，直到取完~渐进式命令，有一组命令，我们暂时只介绍一种scan，其他命令的使用都是一样的~

score member和key vlaue的区别；score有两个特殊取值：inf 无穷大 ，-inf无穷小 ---二者的绝对值都是无限大的~zset中使用的是member和score【score为一个浮点数】，而不是键值对key value；排行榜——使用redis的zset实现排行榜，能够实时的保证排行榜的更新~

UV:用户访问服务器，会产生一个UV，但同一个多次访问不会使UV增加，所以使用set统计UV，能够很好的做到去重~或者例如:我们博客网站常常使用到的兴趣标签，把一个个有着相同爱好，关注类似内容的用户利用一个标签把他们进行。注：当集合中存放的都是整数，且数量不是特别多的情况下，内部编码是intset,此时虽然是无序的，但我。例如最常见的“人物画像”，给相应的用户打上对应标签后，针对性给该用户推送他可能感兴趣的话题。例如QQ中有一个功能叫做你可能认识的人~可能还是有处理的，相对来说还是有序的，从小到大 排列~

但是，并不是所有的最新列表都能用list类型实现，因为对于频繁更新的列表，list类型的分页可能导致列表元素重复或漏掉，举个例子，当前列表里由表头到表尾依次有（E，D，C，B，A）五个元素，每页获取3个元素，用户第一次获取到（E，D，C）三个元素，然后表头新增了一个元素F，列表变成了（F，E，D，C，B，A），此时用户取第二页拿到（C，B，A），元素C重复了。注：lpop和rpop在redis6之后就增加参数了，可以指定删除前几个或后几个，例rpop key count。好啦，本期到这里了，下期见~

对的，这两种方法有各自的优缺点，具体使用按照具体的业务场景来选择就好，相对来说，9存储结构化的数据，使用hash其实是更加适合滴~【结构化数据-->类似于数据库表这种的】redis中存储数据本身就是以键值对的形式，而这里的hash类型，指的是redis的key value中的value是以键值对的形式存储的，也就是说，键值对中的值也是键值对~，需要我们先取出json，然后解析出内部的value值，做出修改后，再合成json，后再存入key中指定的field处~使用string来存储。好啦，我们下期见咯~

实际工作中，一个web应用可能是存在多个应用服务器的，如果说每个应用服务器都各个存储自己的session，那如果一个用户发送1个请求前，进行了登录信息验证，而后续又发送了三个请求，但这三个请求恰巧被发送到了另外3台应用服务器中，那这三个应用服务器都是没有改用户的session的，就会让用户进行登录操作，此时就是出现一个用户需要返回多次登录，用户的体验感非常不好~而在redis中，就不会存在这些问题，因为Redis中不会进行任何的编码转换，存什么就是什么，例如可以存整数，字符串，JSON等都是支持的~

我们在之前的学习中，例如在TCP的学习中，编写了一个回显服务器。在这里面，我们采用的方法就是使用一个线程来管理一个socket，并且要给每个客户端都分配一个socket，那在实际情况中，必然是会有多个客户端的，也就是会同时存在多个socket。我们仔细观察会发现，每个客户端和服务器之间并不是无时无刻的传输数据，大多数时间都是在等待中。因此就提出了IO多路复用，使用一个线程来管理多个socket。

适合小白的学习笔记~

当redis中没有这些数据，请求来了，就会去MySQL中找，请求大的话，MySQL就比较容易挂掉~ 此外如果说，直接把redis就当做数据库来用，那删数据，哪怕是删了一个，影响也很大~ 再此外，redis作为消息队列时，这种情况下，删数据影响大不大就需要看具体的业务类场景了~当redis中，有很多key设置了过期时间，那就可以将这些key加入到优先级队列中，指定优先级规则是过期时间你越早的，先出队列，例如我们可以使用小根堆作为辅助，对首元素就是最早要过期的key。

5.重新启动服务器命令：service redis-server restart无反应就是重启成功6.使用redis自带的客户端来连接服务器命令： redis-cli再输入：ping 返回PONG后，就表示成功了，按ctrl+d就是退出redis客户端了。

应用服务器复杂后，维护的人就要增多，微服务更利于给人划分领域，把这些人组织好，按照功能，拆分成多组微服务，就可以有利于人员的组织结构分配了，也就是说，微服务就是解决了人的问题系统的性能下降。为保证下降不能太多，就需要引入更多的机器，更多的硬件资源~【拆分出来的服务，多个功能之间要更依赖网络通信，而网络通信的速度很可能比硬盘还要慢】可用性受到影响。服务器多，出问题的概率增加~【需要更丰富的监控报警，以及配套的运维人员】可以给不同的额服务进行不同的部署

不使用Redis进行会话缓存之前，所有会话都是存储在应用服务器上的，那么在分布式系统中，又是引入了多台应用服务器，当用户第一次登陆时，分配到第一台，就只有第一台有该用户的信息，第二次进行访问时，由于负载均衡器的处理（尽可能让请求均匀分配到各个服务器），就会分配给第二台，第二台有没有这个用户session，因此会让用户重新登陆，那一次两次还好，那三次四次呢？会让用户的体验感很差！所以分布式系统会涉及到多个进程，而进程是具有隔离性的，每个进程的内存空间都是被隔开的，想要访问其他进程的变量，是有一定难度的。