【Redis】Redis中的大key怎么处理？

找到 /ect/redis/redis.conf 文件修改如下：注释掉 127.0.0.1 ，如果不需要远程连接redis则不需要这个操作。使用客户端向 Redis 服务器发送一个 PING ，如果服务器运作正常的话，会返回一个 PONG。默认情况下，Redis服务器不允许远程访问，只允许本机访问，所以我们需要设置打开远程访问的功能。执行sudo apt-get install redis-server 安装命令。查看 redis 是否启动，重新打开一个窗口。停止/启动/重启redis。

下载版本Redis-x64-5.0.14.1.zip。(可能需要开代理)

git config --global color.ui true //让git显示颜色//忽略特殊文件//.gitignore文件 # Windows: Thumbs.db*.egg*.egg-infodist//把该文件也提交到git$ git add -f App.class //强制添加被忽略的特殊文件。

然后A修改了，A想上传代码，发现冲突了，原因是A依靠的是1版本的代码进行了修改，而此时远程仓库的代码是2版本，这样当然会产生冲突。当从远程仓库拉取代码时，代码会直接拉取到工作区，然后我们要添加、提交，然后才可以把拉取的代码放入本地仓库，本地仓库的代码可以通过推送，推送到远程仓库，这是一个大循环。解决冲突的办法就是，先把远程仓库的2版本的代码进行拉取，然后TortoiseGit会列出冲突的文件代码，然后自己手动解决、选择自己需要的代码，右键选择解决冲突，最后再重新上传就可以了。点击拉取，可以下载文件。

上边图中，跨越了区的箭头，它中间的区数据都会同步。例如：git checkout ，它是将本地仓库数据更新到暂存区和工作区的。

防盗链是一种防止网站资源被非法下载的技术。当用户尝试直接访问一个受保护的资源时，服务器会返回一个403 Forbidden错误，提示用户该资源受到保护，不能直接访问。这样可以避免用户通过搜索引擎或其他方式获取到未经授权的资源。通过以上步骤，我们可以在Linux系统中的Nginx Web服务器中使用Shell脚本实现防盗链的配置。这种方法可以有效地保护网站资源不被非法下载，提高用户体验，同时防止恶意攻击。在实际项目中，我们可以根据实际需求灵活配置受保护资源的URL和处理方式。

也就是在设定的时间里数据没有取出来，但是锁由过期了，常见的思路是，锁过期时间值递增，但是想想不靠谱，因为第一个请求可能超时，如果后面的也超时呢，接连多次超时之后，锁过期时间值势必特别大了，这样做弊端太多。雪崩，和击穿类似，不同的是击穿是一个热点Key某时刻失效，而雪崩是大量的热点Key在一瞬间失效，网络上很多博客都在强调解决雪崩的策略是随机过期时间，这个非常不准确，举个例子，银行做活动，之前这个利息系数为2%，过了零点系数改为3%，这种情况能将用户的对应的key改为随机过期吗？如果用的过去的数据叫脏数据。

Git的基本概念、使用方式及常用命令

这是一道经典的Redis面试题，一个Redis中可能存在很多很多的key，这些key中可能有很大一部分都有过期时间，此时Redis服务器咋知道哪些key已经过期，哪些还没过期呢？如果直接遍历所有的key，这显然是行不通的，效率非常低！！Redis整体的策略是定期删除和惰性删除相结合。举个栗子：假如我去小卖铺买东西，付款的时候，发现东西过期了。就告知老板，于是老板下架此产品。消费者发现过期了，才去下架，这就叫。小卖铺老板主动定期抽取一部分商品，进行筛查，这就叫定期删除。

系统一些应用会使用到特殊权限，这时候要在系统配置一下否则系统会一直重启。出现该问题的时候，系统一直显示开机Log界面，无法正常进入Android系统界面。下面一起分析总结一下吧。本文不仅正文有学习价值，后续的延伸介绍内容也是有学习价值的。framework 定义的所有 权限都是有定义包含 protectionLevel 等级的，主要等级有：普通，运行时，权限，特殊。

注意：在执行这些命令之前，请确保你对新的远程地址已经拥有访问权限，并且确认地址正确无误。例如，要将远程仓库名为。

Redis 是一种内存键值数据库。它支持多种数据结构，如 String, Hash, List, Set 和 SortedSet。

将客户端公钥id_rsa.pub内容复制到服务端.ssh/下新建文件authorized_keys里，这样我们在拉取推送代码时，就不需要输入密码了。在服务器终端输入如下命令，输入两次密码后（比如密码也是：git），一路回车就创建好了。客户端：windows10_x64、Ubuntu20.04。无论是服务端还是客户端都需要先安装git。服务器：Ubuntu18.04。

XSS即Cross Site Scripting（跨站脚本攻击），攻击者通过各种方式将恶意代码注入到用户的页面中，这样就可以通过脚本进行一些操作。以后，基本就杜绝了 CSRF 攻击。当然，前提是用户浏览器支持 SameSite 属性。（1）为了防止这种攻击，表单一般都带有一个随机 token，告诉服务器这是真实请求。CSRF即Cross-site request forgery(跨站请求伪造)

这里 我就改用 sudo service redis start。然后 他会提示你要占多少磁盘空间 例如 我这里是 1.7 M。因为我们刚安装好 端口 密码都没设置过 就是。然后 我们可以根据版本选择启动命令。没问题就 y 然后回车就可以了。如下图 我们很明显就是连接到了。先打开我们的Linux服务器。这样我们 redis就起来了。终端执行 安装redis。这样 就能看到版本了。

这两段代码都是用于发送邮件的简单Python脚本，但第二段代码相对于第一段代码进行了一些优化和改进。第二段代码引入了附件的支持，使用了和模块，使得邮件可以携带更多类型的内容，包括文本和附件。引入了辅助函数，用于格式化发件人地址，支持设置发件人姓名。这样可以使邮件中的发件人信息更加友好和易读。使用Header对邮件主题进行编码，确保支持非ASCII字符的主题。同时，设置了头部，用于指定附件的处理方式，提高邮件的兼容性。第二段代码在处理附件时增加了对附件文件是否存在的检查，并在捕获异常时输出更详细的错误信息。

本章节主要讲解redis中的红锁，假设我们有个客户端要获取锁，然后向master去获取锁，然后master会把锁同步到slave节点，假设现在还没同步出去的时候,master节点挂了。然后从节点升级为主节点，然后另外一个刚刚在竞争锁失败处于阻塞状态的线程去获取锁的时候，但是新的master上，并没有锁的信息，然后就能拿到锁，此时就可能导致一些问题。此时我们就能使用红锁，来解决这个问题。一个客户端要向多个master节点发送加锁请求。只有半数的锁加锁成功，才是获取锁。

自定义目录：/myredis/redis.conf。

redis的哨兵Sentinel高可用架构,redis 哨兵集群与redis集群的关系以及故障转移，故障检测等原理

里面大致说了redis的架构演进。开始学redis架构的时候，总是感觉架构好多，迷迷糊糊的，但是你知道Redis 架构演化之路之后，就明白了前因后果，这样学习更加深入以及搞笑。这篇文章我想和你聊一聊 Redis 的架构演化之路。现如今 Redis 变得越来越流行，几乎在很多项目中都要被用到，不知道你在使用 Redis 时，有没有思考过，Redis 到底是如何稳定、高性能地提供服务的？如果你对 Redis 已经有些了解，肯定也听说过。

Redis哨兵机制和集群有什么区别？redis集群有几种实现方式，一个是主从集群，一个是redis cluster.

安装docker gitlab前确保docker环境，如果没有搭建docker请查阅“Linux docker 安装文档”可以看到在docker ps -a 打印中看到 容器ID ps 展示的容器ID只时原来的一部分。修改docker镜像的gitlab容器端口前需要把gitlab容器以及docker镜像关闭。通过容器ID就能找到containers下具体哪一个是gitlab容器的配置。修改config.v2.json、hostconfig.json文件。docker 下载 gitlab容器。

如果需要根据某种模式来获取键，更好的选择是使用更高效的命令，如SCAN命令，它使用游标方式迭代返回匹配的键，避免了遍历整个键空间的性能问题，并且可以逐步处理数据。KEYS命令用于检索匹配指定模式的所有键。如果匹配的键非常多，返回的结果列表可能巨大无比，占用大量的内存。在极端情况下，如果执行KEYS命令返回的结果集非常大，并且内存不足以容纳整个结果集，Redis服务器可能会发生内存溢出错误。如果KEYS命令运行时间较长或遇到大量匹配的键，会导致服务器长时间无法响应其他请求，从而对系统的可用性产生负面影响。

putIfAbsent 指的是如果传入key对应的value已经存在，就返回存在的value，不进行替换。如果不存在，就添加key和value，返回null。如果传入key对应的value已经存在，就返回存在的value，不进行替换。如果不存在，就添加key和value，返回null。下面这两句话，可以实现向Redis插入Hash数据，并且设置整个Hash的过期时间。TimeUnit.MILLISECONDS：毫秒。TimeUnit.MILLISECONDS：微秒。TimeUnit.MINUTES：分。

该模板的序列化机制改变起来也很容易，并且Redis模块在org.springframework.data.redis.serializer包中提供了多种可用的实现，详情请参考Serializers。大部分的用户都喜欢用RedisTemplate，它相应的包是org.springframework.data.redis.core。虽然RedisConnection提供接受和返回二进制值（字节数组）的低级方法，但该模板可以处理序列化和连接管理，使得用户不需要处理太多的细节。如果 两者是实现的效果是相同的。

对于上面这种情况，对于第一次查询，请求 B 查询的数据是 10，但是 MySQL 的数据是 11，只存在这一次不一致的情况，对于不是强一致性要求的业务，可以容忍。这个图已经画的很清晰了，我就不用再去啰嗦了吧，不过这里有个前提，就是对于读请求，先去读 Redis，如果没有，再去读 DB，但是读请求不会再回写 Redis。请求 A、B 都是先写 MySQL，然后再写 Redis，在高并发情况下，如果请求 A 在写 Redis 时卡了一会，请求 B 已经依次完成数据的更新，就会出现图中的问题。

对网络同学开销的平衡：redis集群中的每个节点，会发送心跳消息，而心跳包中会携带节点的完整配置，他能够以幂等的方式来实现配置的更新。但是修改集群的槽位数量需要进行数据迁移和重新均衡，会对集群产生较大的影响，因此一般情况下建议使用默认的 16384 个槽位。可用性和容错性：16384 是一个较大的数字，可以提供足够的槽位数量来分布数据，从而提高集群的可用性和容错性。应用程序去存储一个key的时候会通过，对key进行一个CRC16去计算，再取模，然后路由到hash slot所在的节点。

为了避免子进程在重写过程过程中，主进程中的数据发生变化，导致AOF文件里面的数据和redis内存中的数据不一致，redis中还做了一个优化，也就是说在子进程在做这个重写的过程中，主进程中的数据变更，需要追加到AOF的重写缓冲区中，等到AOF重写完成以后，再把AOF重写缓冲区的数据，追加到新的AOF文件里面，这样意料就能保证新的AOF文件里面的数据和当前Redis中的数据保持一致。子进程在进行重写的过程中，主进程依然可以去处理客户端的一个请求，这样一来子进程在重写的过程中，不耽误客户端的使用。

建议大家去看原文，这里是学到了，记录一下。最近项目的生产环境遇到一个奇怪的问题：现象 ：每天早上客服人员在后台创建客服事件时，都会创建失败。当我们重启 这个微服务后，后台就可以正常创建了客服事件了。到第二天早上又会创建失败，又得重启这个微服务才行。初步排查 ：创建一个客服事件时，会用到 Redis 的递增操作来生成一个唯一的分布式 ID 作为事件 id。而恰巧每天早上这个递增操作都会返回 null，进而导致后面的一系列逻辑出错，保存客服事件失败。当重启微服务后，这个递增操作又正常了。

然后再看这个好理解一些。bitmap的表象意义是，使用一个01标识位来表示是否的状态，可以达到节省空间和高效判定的效果。在我们的实际工作中，也有着许多的应用场景，相信了解bitmap定会给你带来一些额外的收获。