服务器教程

Redis消息队列发展历程 收藏 在数据库实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《Redis消息队列发展历程》，聊聊Redis、消息队列、数据库，希望可以帮助到正在努力赚钱的你。 作者 | 丕天 Redis是目前最受欢迎的kv类数据库，当然它的功能越来越多，早已不限定在kv场景，消息队列就是Redis中一个重要的功能。 Redis从2010年发布1.0版本就具备一个消息队列的雏形，随着10多年的迭代，其消息队列的功能也越来越完善，作为一个全内存的消息队列，适合应用与要求高吞吐、低延时的场景。 我们来盘一下Redis消息队列功能的发展历程，历史版本有哪些不足，后续版本是如何来解决这些问题的。 一、Redis 1.0 list 从广义上来讲消息队列就是一个队列的数据结构，生产者从队列一端放入消息，消费者从另一端读取消息，消息保证先入先出的顺序，一个本地的list数据结构就是一个进程维度的消息队列，它可以让模块A写入消息，模块B消费消息，做到模块A/B的解耦与异步化。但想要做到应用级别的解耦和异步还需要一个消息队列的服务。 1.list的特性 Redis 1.0发布时就具备了list数据结构，应用A可以通过lpush写入消息，应用B通过rpop从队列中读取消息，每个消息只会被读取一次，而且是按照lpush写入的顺序读到。同时Redis的接口是并发安全的，可以同时有多个生产者向一个list中生产消息，多个消费者从list中读取消息。 这里还有个问题，消费者要如何知道list中有消息了，需要不断轮询去查询吗。轮询无法保证消息被及时的处理，会增加延时，而且当list为空时，大部分轮询的请求都是无效请求，这种方式大量浪费了系统资源。好在Redis有brpop接口，该接口有一个参数是超时时间，如果list为空，那么Redis服务端不会立刻返回结果，它会等待list中有新数据后在返回或是等待最多一个超时时间后返回空。通过brpop接口实现了长轮询，该效果等同于服务端推送，消费者能立刻感知到新的消息，而且通过设置合理的超时时间，使系统资源的消耗降到很低。 #基于list完成消息的生产和消费 #生产者生产消息msg1lpush listA msg1(integer) 1 #消费者读取到消息msg1rpop listA“msg1” #消费者阻塞式读取listA，如果有数据立刻返回，否则最多等待10秒brpop listA 10 1) “listA”2)…

Redis安装使用RedisJSON模块的方法 收藏 IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《Redis安装使用RedisJSON模块的方法》，聊聊Redis安装、RedisJSON，我们一起来看看吧！ 在使用 Redis 中，我们可以使用大量的 Redis 模块来扩展 Redis 的功能，这里安装使用 ReJSON模块。 一、安装ReJSON github上下载ReJSON的源码： 官方使用文档： 1、下载好上传到Liunx [root@centos7 ~]# ll | grep *JSON* -rw-r--r-- 1 root root 4694039 5月 16…

Redis内存回收策略 收藏 本篇文章向大家介绍《Redis内存回收策略》，主要包括Redis内存回收，具有一定的参考价值，需要的朋友可以参考一下。 概述 Redis也会因为内存不足而产生错误 ， 也可能因为回收过久而导致系统长期的停顿，因此掌握执行回收策略十分有必要。在 Redis 的配置文件中，当 Redis 的内存达到规定的最大值时，允许配置 6 种策略中的一种进行淘汰键值，并且将一些键值对进行回收。 maxmemory-policy 参数 # Set a memory usage limit to the specified amount of bytes. #…

Redis的事务处理机制详解 大家好，今天本人给大家带来文章《Redis的事务处理机制详解》，文中内容主要涉及到，如果你对数据库方面的知识点感兴趣，那就请各位朋友继续看下去吧~希望能真正帮到你们，谢谢！ Redis是一个快速的内存数据库，能够处理各种类型的数据结构。除了其高性能之外，还有一个重要特性是支持事务处理。本文将对Redis的事务处理机制进行详细讲解，包括事务的基本概念、事务的执行方式、事务的回滚机制等。 一. 事务的基本概念 Redis的事务包含多个命令，并且这些命令在同一个客户端中。事务执行完毕后，要么提交，要么回滚。Redis的事务具体包括以下几个重要概念： 多个命令构成的事务单元，称为“事务块”。 事务块内部的所有命令按照提交顺序执行，Redis保证执行的原子性。 事务块内部命令的执行顺序与提交顺序无关，即使其中的某个命令执行失败，仍然可以继续执行后续的命令。 一个客户端可以开启多个事务。 事务中命令执行时，不会被其他客户端的命令所打断。 在多个客户端之间，事务之间是互不干扰的。 执行命令时，可以调用watch命令监视一个或多个键，如果在事务执行期间有任何已监视键发生变化，事务会被中止。 二. 事务的执行方式 在Redis中，事务执行顺序与普通的命令执行流程是不同的。在普通的命令执行过程中，客户端发送一个命令到服务端，服务端执行该命令并返回结果。而在事务执行过程中，客户端并不会立即发送事务命令到服务端，而是先将该事务存入客户端的命令缓冲区，直到执行EXEC命令时才将缓冲区的事务命令一次性发送到服务端，服务端按照事务命令的提交顺序一个一个执行。 当客户端开始一个事务时，需要使用MULTI命令，MULTI命令返回“OK”表示事务开始，此时任何命令都不会被执行，事务等待被提交或者回滚。在事务过程中，可以使用Redis的所有命令，包括查询操作和修改操作，但是不能使用SUBSCRIBE和PSUBSCRIBE命令。 在Redis事务中，有三个重要的提交命令： EXEC：提交事务。当客户端发送EXEC命令时，服务端会执行客户端缓冲区的所有事务命令，按照事务命令提交的顺序执行。 DISCARD：回滚事务。当客户端发送DISCARD命令时，服务端会清空客户端缓冲区中的事务命令，并将事务状态设置为未开始。 WATCH：监控键值。客户端可以使用WATCH命令监视指定的键值，如果在事务执行期间，被监视的键值已发生变化，事务会被中止。 三. 事务的回滚机制 Redis的事务处理机制具有原子性，它可以保证在事务中所有命令的执行都是原子性的。如果事务中某个命令执行失败，则所有命令都将取消，并将引发回滚操作。事务回滚时，Redis将自动撤销事务中的所有操作并释放资源。 需要注意的是，Redis的事务处理机制只能回滚写操作，读操作无法回滚。如果事务中包含读操作，即使某个写操作执行失败，读操作的执行结果也可能会被返回。 四. 总结 Redis的事务处理机制是一种非常重要的特性，通过使用事务可以保证数据的一致性，并且可以提高Redis的性能和可靠性。在使用Redis的事务处理机制时，需要注意事务的基本概念和执行方式，以及回滚操作的具体效果。同时，在事务处理期间，需要确保监视的键值没有发生变化，以保证事务的正常执行。最后，需要注意，Redis的事务处理机制提供了一种非常强大的原子性保障，但是并不是所有数据操作都适合使用事务处理机制，需要结合实际情况进行选择。…

一文详解Redis哨兵原理及实践 收藏 学习知识要善于思考，思考，再思考！今天golang学习网小编就给大家带来《一文详解Redis哨兵原理及实践》，以下内容主要包含Redis、高可用、架构等知识点，如果你正在学习或准备学习数据库，就都不要错过本文啦~让我们一起来看看吧，能帮助到你就更好了！ 【golang学习网.com原创稿件】在上篇文章中曾提到，Redis 主从复制的作用有数据热备、负载均衡、故障恢复等；但主从复制存在的一个问题是故障恢复无法自动化。 本文将要介绍的哨兵，它基于 Redis 主从复制，主要作用便是解决主节点故障恢复的自动化问题，进一步提高系统的高可用性。 文章将首先介绍哨兵的作用和架构；然后讲述哨兵系统的部署方法，以及通过客户端访问哨兵系统的方法；然后简要说明哨兵实现的基本原理；***给出关于哨兵实践的一些建议。（注：文章内容基于 Redis 3.0 版本） 哨兵的作用和架构 哨兵的作用 在介绍哨兵之前，首先从宏观角度回顾一下 Redis 实现高可用相关的技术。 它们包括：持久化、复制、哨兵和集群，其主要作用和解决的问题是： 持久化：持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。 复制：复制是高可用 Redis 的基础，哨兵和集群都是在复制基础上实现高可用的。 复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。 哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。 集群：通过集群，Redis 解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。 下面说回哨兵，Redis Sentinel，即…

如何高效使用Redis作为LRU缓存 收藏 本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《如何高效使用Redis作为LRU缓存》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~ 当用Redis作为一个LRU存储时，有些时候是比较方便的，在你增添新的数据时会自动驱逐旧的数据。这种行为在开发者论坛是非常有名的，因为这是流行的memcached系统的默认行为。 LRU实际上只是支持驱逐的方式之一。这页包含更多一般的Redis maxmemory指令的话题用于限制内存使用到一个定额，同时它也深入的涵盖了Redis所使用的LRU算法，实际上是精确LRU的近似值。 一、Maxmemory设置指令 Maxmemory设置指令用于配置Redis的数据集使用指定量的内存。可以用redis conf.file设置指令,或者可以在稍晚的时候在运行时间用config set命令。 例如，为了设置内存局限于100百万字节，下列指令可在redis.conf file内使用。设置maxmemory到零使得没有内存限制。这是64位系统的默认行为，而32位系统使用3GB内隐记忆极限。 maxmemory 100mb 当达到指定量的内存后，就可以选择不同的行为，称为策略。Redis可以返回错误的指令，导致使用更多的内存，或者为了每次增加新的数据后返回指定的内存，它可以驱逐一些旧的数据。 二、驱逐策略 当到达maxmemory极限时，使用maxmemory-策略配置指令来执行具体的Redis动作。 以下策略可以使用： 1、noeviction：达到内存限额后返回错误，客户尝试可以导致更多内存使用的命令（大部分写命令，但DEL和一些例外） 2、allkeys-lru：为了给新增加的数据腾出空间，驱逐键先试图移除一部分最近使用较少的（LRC）。 3、volatile-lru：为了给新增加的数据腾出空间，驱逐键先试图移除一部分最近使用较少的（LRC），但只限于过期设置键。 4、allkeys-random: 为了给新增加的数据腾出空间，驱逐任意键。 5、volatile-random: 为了给新增加的数据腾出空间，驱逐任意键，但只限于有过期设置的驱逐键。 6、volatile-ttl: 为了给新增加的数据腾出空间，驱逐键只有秘钥过期设置，并且首先尝试缩短存活时间的驱逐键。 如果没有秘钥去驱逐匹配先决条件，策略volatile-lru,…

redis适合场景八点总结 收藏 本篇文章向大家介绍《redis适合场景八点总结》，主要包括redis场景，具有一定的参考价值，需要的朋友可以参考一下。 redis适合什么场景？ 1、缓存 缓存现在几乎是所有中大型网站都在用的必杀技，合理的利用缓存不仅能够提升网站访问速度，还能大大降低数据库的压力。Redis提供了键过期功能，也提供了灵活的键淘汰策略，所以，现在Redis用在缓存的场合非常多。 2、排行榜 很多网站都有排行榜应用的，如京东的月度销量榜单、商品按时间的上新排行榜等。Redis提供的有序集合数据类构能实现各种复杂的排行榜应用。 3、计数器 什么是计数器，如电商网站商品的浏览量、视频网站视频的播放数等。为了保证数据实时效，每次浏览都得给+1，并发量高时如果每次都请求数据库操作无疑是种挑战和压力。Redis提供的incr命令来实现计数器功能，内存操作，性能非常好，非常适用于这些计数场景。 4、分布式会话 集群模式下，在应用不多的情况下一般使用容器自带的session复制功能就能满足，当应用增多相对复杂的系统中，一般都会搭建以Redis等内存数据库为中心的session服务，session不再由容器管理，而是由session服务及内存数据库管理。 5、分布式锁 在很多互联网公司中都使用了分布式技术，分布式技术带来的技术挑战是对同一个资源的并发访问，如全局ID、减库存、秒杀等场景，并发量不大的场景可以使用数据库的悲观锁、乐观锁来实现，但在并发量高的场合中，利用数据库锁来控制资源的并发访问是不太理想的，大大影响了数据库的性能。可以利用Redis的setnx功能来编写分布式的锁，如果设置返回1说明获取锁成功，否则获取锁失败，实际应用中要考虑的细节要更多。 6、 社交网络 点赞、踩、关注/被关注、共同好友等是社交网站的基本功能，社交网站的访问量通常来说比较大，而且传统的关系数据库类型不适合存储这种类型的数据，Redis提供的哈希、集合等数据结构能很方便的的实现这些功能。 7、最新列表 Redis列表结构，LPUSH可以在列表头部插入一个内容ID作为关键字，LTRIM可用来限制列表的数量，这样列表永远为N个ID，无需查询最新的列表，直接根据ID去到对应的内容页即可。 8、消息系统 消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

Redis在高可用中的应用实战 从现在开始，我们要努力学习啦！今天我给大家带来《Redis在高可用中的应用实战》，感兴趣的朋友请继续看下去吧！下文中的内容我们主要会涉及到等等知识点，如果在阅读本文过程中有遇到不清楚的地方，欢迎留言呀！我们一起讨论，一起学习！ Redis是一个流行的开源非关系型数据库系统，它提供了快速的内存缓存和持久化功能，也是当今互联网世界中应用最广泛的缓存组件之一。在互联网应用中，Redis通常被用来加快数据读取速度和提高数据写入效率，因此在高可用性的应用中，Redis也扮演着重要的角色。 本文将介绍Redis在高可用中的应用实战，包括Redis的多节点架构、主从同步、哨兵模式和集群模式。我们将介绍各种架构的优缺点，以及在实际应用中如何选取Redis高可用方案。 Redis多节点架构 在高可用性应用中，单一节点往往无法满足大量数据存储和高并发读取的需求。为了解决这个问题，我们可以通过构建多节点架构来提高系统的可用性和性能。在Redis中，多节点架构的方式包括主从同步、哨兵模式和集群模式。 主从同步 主从同步是Redis的最基本的多节点复制模式。主从同步架构包括一个主节点和多个从节点。主节点是数据的主要写入者和读取者，而从节点则是数据的备份副本。 主节点负责将数据同步到从节点，从节点则定期从主节点获取新的数据。这种方式能提高系统的可读性能和可用性，尤其是在读取操作方面。 主从同步的缺点是，在主节点宕机或者网络出现故障时，从节点无法提供数据服务，处理读请求的能力也会受到影响。因此，主从同步更适合于读写比较平衡、从节点数量不多的场景。 哨兵模式 哨兵模式是基于主从同步的一种故障转移方案。在哨兵模式中，增加一个哨兵节点来监控主节点和从节点的状态，当发现主节点宕机时，在从节点中选择一个新的主节点来提供服务。 在哨兵模式中，哨兵节点定期向主节点和从节点发送心跳包，检测它们的存活状态。当发现主节点宕机时，哨兵节点领导从节点进行投票，找出新的主节点。新的主节点被选出后，其他从节点则向新的主节点同步数据。 哨兵模式的优点是，能够快速切换到新的主节点，从而保证了应用系统的高可用性。缺点是，哨兵节点也会成为硬件单点故障，如果哨兵节点宕机，会导致整个系统无法正常运行。 集群模式 集群模式是Redis分布式缓存中的一种构架，能够实现容错和灾备。集群模式分为内置集群和外部集群两种方式。 内置集群是通过在Redis网络中通过Hash槽将数据分配到多个Redis节点上，在多个节点之间实现数据分片和负载均衡。 外部集群则需要使用如Kafka, Zookeeper等分布式协调工具来管理集群，通过预先定义Hash槽将数据分配到不同的节点上。 集群模式的优点是，能够扩展读写性能，增加了系统的可扩展性和可用性。缺点是需要更复杂的配置，实现集群模式也会增加系统的管理成本，同时也会增加数据一致性的问题。 Redis高可用性方案选择 在实际应用中，如何选择最适合自己系统的Redis高可用性方案呢？以下是一些具体的建议： 如果读写比较平衡，从节点数量不多，可以选择主从同步模式。 如果需要快速切换到新的主节点而不影响系统正常运行，可以考虑使用哨兵模式。 如果需要扩展读写性能并增加系统的可扩展性和可用性，则可以选择集群模式。 在选择高可用性方案时，我们还需要考虑性能、容错和成本等因素的综合考虑。我们可以通过性能测试、容灾测试和成本分析等手段来评估不同方案的优缺点，从而选择最适合自己系统的Redis高可用性方案。 结论 Redis作为一款高性能的缓存组件，在互联网应用中扮演着越来越重要的角色。在高可用性的应用中，构建多节点架构能够提高数据的读取性能和写入效率，保证了系统的稳定性和可用性。在不同的高可用性方案中，我们可以根据系统的需求和场景来选择最适合自己的方案，从而在保证系统稳定性和高可用性的同时，也能够提高读写性能并降低系统成本。…

redis数据倾斜处理方法 收藏 学习数据库要努力，但是不要急！今天的这篇文章《redis数据倾斜处理方法》将会介绍到redis数据倾斜等等知识点，如果你想深入学习数据库，可以关注我！我会持续更新相关文章的，希望对大家都能有所帮助！ 写在前面 我们在使用Redis分片集群时，集群最好的状态就是每个实例可以处理相同或相近比例的请求，但如果不是这样，则会出现某些实例压力特别大，而某些实例特别空闲的情况发生，本文就一起来看下这种情况是如何发生的以及如何处理。 1：什么是数据倾斜 数据倾斜分为两种，第一种是数据量倾斜，第二种是数据访问倾斜，定义如下： 数据量倾斜：数据分布的不均匀，导致某些实例数据特别多，进而导致处理的请求量大 数据访问倾斜：数据分布均匀，但是某些实例存在热点数据，进而导致处理的请求量大 可以看到不管是数据量倾斜，还是数据访问倾斜，最终导致的结果都是发生倾斜的实例处理了更多的数据请求，压力增大。 2：数据量倾斜 数据量倾斜最常见的原因就是在手动划分slot时，分配不均匀，除此之外，还有big key，hash tag，分别来看下。 2.1：slot分配不均匀 slot分配不均匀一般是由于手动分配造成，或者是因为某个实例节点配置较高，为了更加充分的利用其计算机资源，有意的给其分配更多的slot，但是这个多出的量其实是不好预估的，所以对于因为计算机性能差异有意分配的造成的slot不均匀还是要尽量避免，即保证所有的实例节点都具有相同的配置，然后将slot进行均匀分配。如果是已经发生了slot分配不均匀，我们可以通过迁移slot的方式来处理，首先通过cluster slots命令查看当前slot的分配情况： 上图slot0~4095分配到了实例192.168.10.3:6379,slot12288~16383分配到了实例192.168.10.5:6379。如下是一个slot迁移的例子。 假设我们要把 Slot 300 从源实例（ID 为 3）迁移到目标实例（ID 为 5），那要怎么做呢？ 第1步，我们先在目标实例5上执行下面的命令，将Slot 300的源实例设置为实例…

基于redis.properties文件的配置及说明介绍 收藏 亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《基于redis.properties文件的配置及说明介绍》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下配置、redisproperties，希望所有认真读完的童鞋们，都有实质性的提高。 在使用到redis连接池时，需要进行一些redis相关配置，redis.properties文件是由编程者自己在项目classpath路径（如eclipse的src）下建立的，并非从redis安装包中获取的。 1.redis.properties文件的建立 在eclipse中找到相应的项目，选择File–>New–>File，选中项目中的src目录，填入文件名称redis.properties,然后Finish就可以了。 2.redis.properties文件的配置与说明 redis.timeout=3000 #超时时间：单位ms redis.password=123456 #授权密码 redis.pool.maxActive=200 #最大连接数：能够同时建立的“最大链接个数” redis.pool.maxIdle=20 #最大空闲数：空闲链接数大于maxIdle时，将进行回收 redis.pool.minIdle=5 #最小空闲数：低于minIdle时，将创建新的链接 redis.pool.maxWait=3000 #最大等待时间：单位ms redis.pool.testOnBorrow=true #使用连接时，检测连接是否成功 redis.pool.testOnReturn=true #返回连接时，检测连接是否成功 以上这篇基于redis.properties文件的配置及说明介绍就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持golang学习网。