Redis和消息队列
Redis
一、Redis数据类型、Redis数据结构、Redis使用场景
Redis数据类型
键的类型只能是字符串
值支持5种数据类型：
字符串String，可以存储字符串、整数、浮点数
列表list
集合set
散列表hash，包含键值对的无序散列表
有序集合zset
Redis具体数据结构
字典：是集合的一种，集合中每个元素都是key-value键值对
跳跃表：是有序集合的底层实现之一，是基于多指针有序链表实现的，可以看成多个有序链表。
对于一个单链表来说，即使链表中存储的数据有序，查找数据也只能从头到尾遍历
想要提高效率，考虑在链表上建立索引，每两个节点提取一个节点到上一级。
查找时，从上层指针开始查找，找到对应区间之后再到下一层查找。
Redis的使用场景
缓存
会话缓存：存储多个应用服务器的会话信息，应用服务器无状态
消息队列：写入和读出消息
计数器
查找表：和缓存类似，如存储DNS记录；查找表内容不允许失效，缓存允许失效
分布式锁：分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步
二、Redis和Memcashed
都是非关系型内存键值数据库
- Redis支持5种不同的数据类型；Mencashed只支持字符串类型
- Redis支持两种持久化策略：RDB快照和AOF日志；而Memcashed不能持久化
- Redis支持分布式，Memcashed不支持分布式
- Redis中并不是所有数据都一直在内存中，可以将很久没用的value交换到磁盘；而Memcashed的所有数据都一直在内存中
三、Redis键的过期时间、数据淘汰策略、持久化、（事务、事件)
键的过期时间
数据淘汰策略（算法）
可以设置内存最大使用量，当内存使用量超出时就会淘汰；
从以设置过期时间的数据中选择：volatile-lru、volatile-ttl（将要过期）、volatile-random
从全部数据中选择：allkeys-lru、allkeys-random
禁止驱逐数据：noeviction
一般使用allkeys-lru算法
数据持久化：将数据从内存中持久化到磁盘上
- ROB快照：将某个时间点的所有数据，以快照形式存放到硬盘上
- AOF日志：以独立日志的方式记录“每一次的写命令”，在Redis重启时，重新执行AOF中的命令，以达到恢复数据的目的。
（事务）
一个事务包含多个命令，服务器执行事务期间，不会执行其他命令。
（事件）
Redis服务器是一个事件驱动程序
- 文本事件：服务器通过套接字与客户端或其他服务器通信，文本事件就是对套接字操作的抽象
- 时间事件：服务器有一些操作，需要在给定的事件点执行，时间事件是对这类定时操作的抽象
四、（Redis复制、sentinel、分片）
Redis主从复制
Redis主服务器，从服务器
可以设置主从链
Redis的Sentinel
哨兵，可以监听集群中的服务器，可以在主服务器下线时，自从从 从服务器中选举出新的主服务器
Redis的分片
将数据划分为多个部分，可以将数据存储到多台机器里面
缓存问题
缓存雪崩
如果缓存在某个时刻出现大规模的key失效，就会导致大量的请求直接打在数据库上，使得数据库压力巨大；如果在高并发的情况下，可能瞬间导致数据库宕机。
缓存击穿
某个热点key失效，大量并发请求集中访问，在缓存找不到；
就会引起高并发访问数据库，使得数据库压力剧增，可能导致数据库宕机；
缓存穿透
用户请求的数据在缓存中不存在，同时也在数据库中不存在；
导致用户每次请求该数据，都要去数据库中查询；
如果有恶意攻击者短时间内不断请求系统中不存在的数据，会导致短时间内有大量请求落在数据库上，从而使数据库宕机。
消息队列
消息队列介绍
消息队列是分布式系统中重要的组件；
主要解决“应用解耦”、“异步消息”，“流量削峰”等问题；实现高性能，高可用，高伸缩和最终一致性架构。
目前使用较多的消息队列有ActiveMQ、RabbitMQ、kafka、RocketMQ等。
概念：
Topic：
从逻辑上讲一个Topic就是一个队列Queue；
从存储上讲一个Topic存储了一类相关的消息，是消息的集合。
Partition：
分是存在于服务端，且内部保持顺序，顺序不可变更的一个队列，用户存储消息。
在使用消息队列时用户感觉不到分区
一个Topic存储消息时会分为多个Partition，每个Partition内部消息是有顺序的。
类似于快递网点内有多家快递公司
Productor：
生产消息，生产完决定将消息发送到哪个Topic的哪个Partition
一个MQ中可以有多个种类的Topic种类消息，Patition先理解成一个Queue的内部存储
Consumer:
订阅Topic，消费内部的消息
Group：
用来标记Consumer的身份，拥有相同Group名称的Consumer是一个类Consumer，一般消费同一类消息。
Consumer之间是需要协同工作的，Productor之间一般是不相关的，不需要Group标记身份。
协同工作：两个consumer消费Topic消息，订单消息只能消费一次；如果行为相同的consumer只存在一个，就不存在协同工作了，但是存在单点问题和性能问题，因为大多数情况下是分布式系统。
集群消费：
一个消息只被消费一次，同一个Group内有多个Consumer，共同完成对一个Topic的消费。
上面说的Consumer协同工作就默认是集群消费了。
图中Consumer0和Consumer1属于同一个Group，假设Topic中有0到5共6条消息，Consumer0消费0-2，Consumer1消费3-5，他们共同完成了Topic中消息的消费。
这存在于大量的无状态的后台系统，就如上面说的消费订单消息进行发货的例子。（一个消息只被一个Consumer消费一次）
广播消费：
Topic中的每个消息会被同一个Group里的每个Consumer都消费一次；
如图Topic有0-5共6条消息，Consumer0会消费到0-5完整的6条消息，Consumer1也会消费0-5的6条消息。
这种消费往往应用在有状态的后台系统，比如多个缓存服务器，都要去消费消息，更新自己的缓存数据。
消息模型
点对点模型
生产者向消息队列Topic中发送一个消息后，只能被一个消费者消费一次
发布订阅模型
生产者向Topic中发布了一个消息之后，所有订阅了该Topic的消费者都可以进行消费该消息，一个消息可以被消费多次。
(扩展：设计模式中“发送订阅模式”和“观察者模式”区别)
观察者模式中，Topic和观察者都知道对方的存在；而在发布订阅者模式中，生产者和消费者不知道对方的存在，它们通过Topic进行通信。
观察者模式是同步的，当事件触发，Topic会调用观察者的方法，然后等待方法的返回；
发布订阅模式是异步的，生产者向Topic发送一条消息，会立即返回，不关心消费者什么时候来消费这个消息。
使用场景
异步处理
productor将消息发送给消息队列Topic之后，不需要等待consumer的处理，而是立即返回，可以进行其他操作。consumer从Topic中接收消息后进行异步处理。
例如在注册流程中，系统需要发送邮件验证用户合法性，可以使用消息队列使得 发送邮件的操作异步处理；用户注册完后就可以完成注册，而将“发送邮件”这一消息发送给消息队列。
但只有业务流程允许异步处理的情况下才能这么做。
流量削峰
高并发场景下，如果短时间内有大量请求到达，可能会压垮服务器和数据库；
可以将请求转发到消息队列中，业务处理服务器再根据其处理能力，从消息队列中订阅消息进行处理。
因为用户请求被放入消息队列中之后，请求就立即返回了。但是在后续的业务操作和数据库操作可能失败，因此使用消息队列进行异步处理之后，需要适当修改业务流程进行配合。例如在用户提交订单之后，订单数据写入MQ，不能立即返回给用户订单结果，需要在MQ中的消息被真正处理之后，再通过email或者短信通知用户订单结果，如手机订车票。
系统解耦
传统情况下系统模块之间进行直接调用，修改或新增一个模块会直接对其他模块产生影响。
通过使用MQ，一个模块只需要向MQ中发送消息，其他模块可以选择性的从MQ中订阅消息，从而完成调用，这样降低了系统耦合性。
利用发布订阅模式；消息发送者（生产者）发布消息，一个或多个消费者订阅消息，消息发送者和消息接收者并没有直接耦合，对新增业务而言，只要对某类消息感兴趣，就可以订阅该消息，对原有的系统和业务没有任何的影响。从而实现网站业务的可拓展性设计。
消息队列的问题
- 可用性降低：引入MQ之后，需要考虑MQ服务器宕机的情况。
- 复杂性提高：需要保证消息没有被‘’重复消费“，处理”消息丢失“的情况，保证“消息传递的顺序性”
- 数据一致性：MQ异步处理可以提高系统的响应速度，但是消费者消费失败了，就会导致数据不一致的问题。
解决方案：
可用性问题：
MQ服务器使用集群，每次访问的是集群中的主服务器，当主服务器挂掉以后，备用服务器顶上。
复杂性问题
如何保证消息不被重复消费
消息被重复消费的原因大多是因为网络不通，确认消息没有传送到消息队列，导致MQ不知道自己已经消费过该消息了，再次将消息分发给其他消费者。三种解决思路：
如果消息是做数据库插入操作，给这个消息做一个唯一的主键，这样就算重复消费也会到导致主键冲突；不可取，数据库记录的主键一般是与业务无关的自增主键。
如果这个消息是做redis的set操作，那么不用解决，因为无论set几次结果都是一样的。
如果以上两种情况都不行，那么准备一个第三方来做消息记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将<id,message>以键值对的形式写入redis。那么消费者开始消费前，先去redis中查看有没有消费记录即可。
选择一个支持消息持久化的方案：如RabiitMQ，给消息一个处理状态
如何保证消息的可靠传输
保证消息的可靠传输就是防止Productor弄丢数据，MQ弄丢数据，Consumer弄丢数据。
Productor弄丢数据：事务机制，生产者发送数据之前开启RabbitMQ事务，然后发送消息，如果消息没有被MQ接收到，生产者就会报错，此时就可以进行回滚，重新发送消息。
ack机制和超时重传：当MQ收到消息以后返回ack给Productor确认，如果在超时时间内Productor没有收到MQ的确认就重发该消息；
MQ丢失数据：开启MQ的持久化，即使MQ挂了重启以后还能恢复之前的数据
Consumer丢失数据：主要是消费时刚消费到，还没处理，进程就挂了；
关闭MQ的自动ack机制，只有消息真正处理完才手动返回给MQ一个ack；
如何保证从消息队列里拿到的数据按顺序执行
将需要保持顺序的消息放到同一个Topic里面，然后只用一个消费者去消费该Topic
数据是通过push还是通过pull方式给到Consumer比较好
- push实时性好，但是consumer消费速度不一致，同时MQ也难以知道consumer消费的情况，push也会加重Consumer的负载压垮Cnosumer
- pull实现相对简单，但实时性取决于轮询的频率，在对实时性要求不高的场景可以使用
其他问题：
大量消息在MQ中积压了几个小时还没解决？
临时紧急扩容：临时将Queue资源和consumer资源扩大10倍，以正常的10倍数据来消费数据。
消息队列过期失效：批量重新导入
消息队列满了：
常见消息队列
消息队列详解_hc_ttxs的博客-CSDN博客_消息队列详解
ActiveMQ
- 单机吞吐量：万级，吞吐量比RocketMQ和Kafka低一个数量级
- Topic数量对吞吐量的影响：
- 时效性：ms级别
- 可用性：高，基于主从架构实现高可用性
- 消息可靠性：有较低的概率丢失数据
- 功能支持：MQ领域的功能极其完备
- 优劣势总结：
- 非常成熟，功能强大，在业内大量公司用
- 偶尔会有较低概率丢失消息
- 社区和国内应用越来越少，官方维护越来越少
- 主要基于异步和解耦使用，较少在大规模吞吐的场景中使用
RabbitMQ
- 单机吞吐量：万级，吞吐量比RocketMQ和Kafka低一个数量级
- Topic数量对吞吐量的影响：
- 时效性：us级别，延迟是最低的，这是RabbitMQ的一大特点
- 可用性：高，基于主从架构实现高可用性
- 消息可靠性：
- 功能支持：基于erlang开发，所以并发能力很强，性能极好，延时很低
- 优劣势总结：
- 基于erlang语言开发，性能好，延时很低
- 吞吐量到万级，MQ功能比较完备
- 开源而且提供的管理界面很好
- 社区相对活跃，几乎几个月都发布几个版本
- 国内互联网公司近几年用的相对想多
- 问题也显而易见，吞吐量确实会低一些
- erlang语言很难读懂源码以及很难定制
RocketMQ
- 单机吞吐量：10万级别，可以支撑高吞吐量
- Topic数量对吞吐量的影响：==Topic可以达到几百，几千个的级别，这是Rocket的优势。==吞吐量会有较小幅度的下降
- 时效性：ms级别
- 可用性：非常高，采用分布式架构
- 消息可靠性：经过参数优化配置，可以做到0丢失
- 功能支持：MQ功能较为完善，分布式，扩展性好
- 优劣势总结：
- 接口简单引用，阿里大规模应用过，有阿里品牌保证
- 日处理消息上百亿之多，可以做到大规模吞吐；性能也非常好，分布式扩展也方便；社区维护、可用性OK；支持大规模Topic复杂MQ业务场景
- 采用java系的，可以自己阅读源码，定制自己公司的MQ，可以掌控
- 社区活跃度相对一般，但也还可以
Kafaka——高吞吐量的分布式发布订阅MQ
单机吞吐量：10万级别，这是kafka最大的特点，吞吐量高，一般配合大数据系统来进行实时数据计算、日志采集等场景
Topic数量对吞吐量的影响：Topic从几十个到几百个的时候，吞吐量会大幅度下降；
所以在同等机器中，kafka尽量保证topic数量不要过多；如果需要大规模topic，需要增加更多机器资源
时效性：ms级别
可用性：非常高，kafka是分布式的，一个数据多个副本，少数机器宕机不会导致数据不可用
消息可靠性：经过参数优化配置，可以做到0丢失
功能支持：功能较为简单，主要支持简单的MQ功能；在大数据领域的实时计算和日志采集被大规模使用，是事实上的标准。
优劣势总结：
- kafka特点明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量；ms级的延时，极高的可用性，分布式可以任意扩展
- kafka为了保证其超高的吞吐量，支持尽量较少的topic
- 唯一缺点：消息有可能重复消费，那么对数据的准确性会造成轻微的影响；在大数据领域实时计算和数据采集中，这点轻微影响可以忽略。
Redis和消息队列相关推荐
- Redis做消息队列，香吗？
来自:架构师修行之路 菜菜哥,我刚做完了一个订单系统,感觉很简单呀 说说看,大量的订单状态怎么处理的? 我设计的时候可是考虑了这一点,所以用了异步处理,采用了MQ 那用的什么MQ呢,透露一下呗 我用的 ...
- 【springboot】【redis】springboot+redis实现发布订阅功能，实现redis的消息队列的功能...
springboot+redis实现发布订阅功能,实现redis的消息队列的功能 参考:https://www.cnblogs.com/cx987514451/p/9529611.html 思考一个问 ...
- PHP + Redis 实现消息队列
Redis做消息队列的好处在于它的轻量级,高并发,延迟敏感,应用场景有 即时数据分析.秒杀计数器.缓存等 Redis做消息队列待解决的问题: 1.消息的可靠性: 没有相应的机制保证消息的消费,当消费者 ...
- redis实现消息队列
redis是一个开源的key-value存储系统.与Memcached类似,Redis将大部分数据存储在内存中,支持的数据类型包括:字符串.哈希表.链表.集合.有序集合以及基于这些数据类型的相关操作. ...
- 用redis实现消息队列（实时消费+ack机制）【转】
用redis实现消息队列(实时消费+ack机制) java queue 消息队列 redis 消息队列 首先做简单的引入. MQ主要是用来: 解耦应用. 异步化消息 流量削峰填谷 目前使用的较多的有A ...
- 使用Redis 实现消息队列
一 .为什么要用Redis实现轻量级MQ? MQ的主要作用: 应用解耦 异步化消息 流量削峰填谷 目前使用比较多的是ActiveMQ . RabbitMQ . ZeroMQ . Kafka . Met ...
- 【BCVP】实现基于 Redis 的消息队列
聆听自己的声音 如果自己学不动了,或者感觉没有动力的时候,看看书,听听音乐,跑跑步,休息两天,重新出发,偷懒虽好,可不要贪杯. 话说上回书我们说到了,Redis的使用修改<[BCVP更新]Sta ...
- 程序员过关斩将--redis做消息队列，香吗？
菜菜哥,我刚做完了一个订单系统,感觉很简单呀 说说看,大量的订单状态怎么处理的? 我设计的时候可是考虑了这一点,所以用了异步处理,采用了MQ 那用的什么MQ呢,透露一下呗 我用的redis做的MQ,很 ...
- c#进阶（4）—— Redis 用于消息队列的存储
1.参考的博文 a : http://www.cnblogs.com/lori/archive/2012/04/12/2443708.html -- 主要的实现思路 b: http://www.cn ...
- Redis异步消息队列
一.异步消息队列介绍 个人认为消息队列的主要特点是异步处理,主要目的是减少请求响应时间和解耦.所以主要的使用场景就是将比较耗时而且不需要即时(同步)返回结果的操作作为消息放入消息队列.同时由于使用了消 ...
最新文章
- Java Optional类源码解析和用法
- NSIS来自己设定快捷方式的图标
- 为 Jupyter Notebook指定虚拟环境的 Python 解释器
- 3D图形图像处理软件HOOPS介绍及下载
- GSON反序列化时，字符串被转换成科学记数法的问题处理
- 数据结构--图(Graph)详解(一)
- Hadoop 01_基础知识
- P2485-[SDOI2011]计算器【BSGS,exgcd,快速幂】
- bootstrap插件（对话框）bootbox参数和自定义弹出框宽度设置
- 时至 2018 年，还有必要学 Vim 吗？
- [Bzoj2120]数颜色
- android 感应器
- 理解LP Simplex
- 基于Matlab App Designer的语音信号分析与处理（二）：IIR和FIR滤波器的设计，语音信号的滤波
- Agent with Tangent-based Formulation and Anatomical Perception for Standard Plane Localization in 3D
- 没有植入的内容就是TM在逗我
- wex5 实战 单页模式下的多页面数据同步
- linux查看邮件服务状态,利用mail实时监测服务器程序状态
- hurtworld正版社区服务器,《伤害世界hurtworld》正版盗版GM权限获取方法图文详解...
- sys.types详解