消息队列、redis知识

互联网面试技术点

RabbitMq :

    首先 publisher 生产者将消息（Message）发送给 Broker(rabbitmq服务器)--->  交换机 （Exchange）
	每个交换机（Exchange）可以绑定多个队列（Queue）,所以路由键（routerKey）的功能就是指定发送到匹配的队列中去；
	队列和交换机有一个绑定关系（Binding）,所以路由键实际是匹配到Binding关系对应的队列中去的；

消息队列：

传统系统的严重耦合，是非常不利于开发的，所以消息起到了很好的解耦作用

消息队列的优点： 解耦、异步、削峰
         缺点： 系统可用性降低{增加一个依赖，如果这个依赖挂掉了就降低了可用性}
                系统复杂性变高{消息重复消费、消息丢失、怎么保证消息的有序性}
                一致性的问题{A系统成功、B系统失败了}
为啥用？ 利大于弊
activemq  rabbitmq rocketmq kafka
activemq、rabbitmq 单机吞吐量是万级的消息   activemq是java语言、rabbitmq是多语言  rabbitmq （是微秒级的延迟）   高可用 基于主从架构 
rocketmq、kafka    单机吞吐量是十万级的消息   rocketmq是java语言、kafka是多语言的          非常高可用，分布式架构

中小型公司一般使用rabbitmq  kafka一般用户大数据计算、日志收集

如何保证高可用： 
		要开启镜像集群模式,需要在后台新增镜像集群模式策略. 即要求数据同步到所有的节点.也可以指定同步到指定数量的节点.

		这种方式的好处就在于, 任何一个服务宕机了,都不会影响整个集群数据的完整性, 因为其他服务中都有queue的完整数据, 当进行消息消费的时候,连接其他的服务器节点一样也能获取到数据.

		缺点:

		1: 性能开销大: 因为需要进行整个集群内部所有实例的数据同步

		2: 无法线性扩容: 因为每一个服务器中都包含整个集群服务节点中的所有数据, 这样如果一旦单个服务器节点的容量无法容纳了怎么办?.


*rabbit搭建高可用集群（没有完成）

	如何保证MQ的消费是幂等性的，需要结合具体的业务来看：
	重复消费。如何做到幂等性----考虑业务，如果消费一条数据往数据库插入一条数据，先判断数据库是否存在，存在就丢掉该消息

	如何保证数据不被丢失：
   		 数据丢失分为两种 1：mq丢失的 2：我们消费丢失的
    1）生产者弄丢了数据

		生产者将数据发送到rabbitmq的时候，可能数据就在半路给搞丢了，因为网络啥的问题，都有可能。

		此时可以选择用rabbitmq提供的事务功能，就是生产者发送数据之前开启rabbitmq事务（channel.txSelect），然后发送消息，如果消息没有成功被rabbitmq接收到，那么生产者会收到异常报错，此时就可以回滚事务（channel.txRollback），然后重试发送消息；如果收到了消息，那么可以提交事务（channel.txCommit）。但是问题是，rabbitmq事务机制一搞，基本上吞吐量会下来，因为太耗性能。

		所以一般来说，如果你要确保说写rabbitmq的消息别丢，可以开启 confirm 模式，在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq中，rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了。如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。

		事务机制和cnofirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是confirm机制是异步的，你发送个消息之后就可以发送下一个消息，然后那个消息rabbitmq接收了之后会异步回调你一个接口通知你这个消息接收到了。

		-- 所以一般在生产者这块避免数据丢失，都是用confirm机制的。

	2）rabbitmq弄丢了数据

		就是rabbitmq自己弄丢了数据，这个你必须开启rabbitmq的持久化，就是消息写入之后会持久化到磁盘，哪怕是rabbitmq自己挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢。除非极其罕见的是，rabbitmq还没持久化，自己就挂了，可能导致少量数据会丢失的，但是这个概率较小。

		设置持久化有两个步骤，第一个是创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里的数据；第二个是发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。必须要同时设置这两个持久化才行，rabbitmq哪怕是挂了，再次重启，也会从磁盘上重启恢复queue，恢复这个queue里的数据。

		而且持久化可以跟生产者那边的confirm机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者ack了，所以哪怕是在持久化到磁盘之前，rabbitmq挂了，数据丢了，生产者收不到ack，你也是可以自己重发的。

		哪怕是你给rabbitmq开启了持久化机制，也有一种可能，就是这个消息写到了rabbitmq中，但是还没来得及持久化到磁盘上，结果不巧，此时rabbitmq挂了，就会导致内存里的一点点数据会丢失。

	3）消费端弄丢了数据

		rabbitmq如果丢失了数据，主要是因为你消费的时候，刚消费到，还没处理，结果进程挂了，比如重启了，那么就尴尬了，rabbitmq认为你都消费了，这数据就丢了。

		这个时候得用rabbitmq提供的ack机制，简单来说，就是你关闭rabbitmq自动ack，可以通过一个api来调用就行，然后每次你自己代码里确保处理完的时候，再程序里ack一把。这样的话，如果你还没处理完，不就没有ack？那rabbitmq就认为你还没处理完，这个时候rabbitmq会把这个消费分配给别的consumer去处理，消息是不会丢的。



	如何保证消费的有序性：
		我举个例子，我们以前做过一个mysql binlog同步的系统，压力还是非常大的，日同步数据要达到上亿。mysql -> mysql，常见的一点在于说大数据team，就需要同步一个mysql库过来，对公司的业务系统的数据做各种复杂的操作。

		你在mysql里增删改一条数据，对应出来了增删改3条binlog，接着这三条binlog发送到MQ里面，到消费出来依次执行，起码得保证人家是按照顺序来的吧？不然本来是：增加、修改、删除；你楞是换了顺序给执行成删除、修改、增加，不全错了么。
		（1）rabbitmq：一个queue，多个consumer，这不明显乱了
		解决办法：
		（1）rabbitmq：拆分多个queue，每个queue一个consumer，就是多一些queue而已，确实是麻烦点；或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理


	如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？



	（1）大量消息在mq里积压了几个小时了还没解决

		几千万条数据在MQ里积压了七八个小时，从下午4点多，积压到了晚上很晚，10点多，11点多

		这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复consumer的问题，让他恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。

		一个消费者一秒是1000条，一秒3个消费者是3000条，一分钟是18万条，1000多万条

		所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概1小时的时间才能恢复过来

		一般这个时候，只能操作临时紧急扩容了，具体操作步骤和思路如下：

		1）先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉
		2）新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量
		3）然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue
		4）接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据
		5）这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据
		6）等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息

	（2）这里我们假设再来第二个坑
	
		假设你用的是rabbitmq，rabbitmq是可以设置过期时间的，就是TTL，如果消息在queue中积压超过一定的时间就会被rabbitmq给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢。

		这个情况下，就不是说要增加consumer消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。

		这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入mq里面去，把白天丢的数据给他补回来。也只能是这样了。

		假设1万个订单积压在mq里面，没有处理，其中1000个订单都丢了，你只能手动写程序把那1000个订单给查出来，手动发到mq里去再补一次

	（3）然后我们再来假设第三个坑

			如果走的方式是消息积压在mq里，那么如果你很长时间都没处理掉，此时导致mq都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。

Redis 缓存

	1）高性能

	假设这么个场景，你有个操作，一个请求过来，吭哧吭哧你各种乱七八糟操作mysql，半天查出来一个结果，耗时600ms。但是这个结果可能接下来几个小时都不会变了，或者变了也可以不用立即反馈给用户。那么此时咋办？

	缓存啊，折腾600ms查出来的结果，扔缓存里，一个key对应一个value，下次再有人查，别走mysql折腾600ms了。直接从缓存里，通过一个key查出来一个value，2ms搞定。性能提升300倍。

	这就是所谓的高性能。

	2）高并发

	mysql这么重的数据库，压根儿设计不是让你玩儿高并发的，虽然也可以玩儿，但是天然支持不好。mysql单机支撑到2000qps也开始容易报警了。

	所以要是你有个系统，高峰期一秒钟过来的请求有1万，那一个mysql单机绝对会死掉。你这个时候就只能上缓存，把很多数据放缓存，别放mysql。缓存功能简单，说白了就是key-value式操作，单机支撑的并发量轻松一秒几万十几万，支撑高并发so easy。单机承载并发量是mysql单机的几十倍。
	常见的缓存问题有仨（当然其实有很多，我这里就说仨，你能说出来也可以了）

	单机吞吐量  QPS 十万/秒   TPS 八万/秒
	1.QPS: 应用系统每秒钟最大能接受的用户访问量
	每秒钟处理完请求的次数，注意这里是处理完，具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。
	2.TPS： 每秒钟最大能处理的请求数
	每秒钟处理完的事务次数，一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较合理。

	1）缓存与数据库双写不一致
	2）缓存雪崩
	3）缓存穿透
	4）缓存并发竞争

	（3）为啥redis单线程模型也能效率这么高？

	1）纯内存操作
	2）核心是基于非阻塞的IO多路复用机制
	3）单线程反而避免了多线程的频繁上下文切换问题（百度）

	redis类型：

	（1）string

	这是最基本的类型了，没啥可说的，就是普通的set和get，做简单的kv缓存

	（2）hash

	这个是类似map的一种结构，这个一般就是可以将结构化的数据，比如一个对象（前提是这个对象没嵌套其他的对象）给缓存在redis里，然后每次读写缓存的时候，可以就操作hash里的某个字段。

	key=150

	value={
	  “id”: 150,
	  “name”: “zhangsan”,
	  “age”: 20
	}

	hash类的数据结构，主要是用来存放一些对象，把一些简单的对象给缓存起来，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值

	value={
	  “id”: 150,
	  “name”: “zhangsan”,
	  “age”: 21
	}


	（3）list

	有序列表，这个是可以玩儿出很多花样的

	微博，某个大v的粉丝，就可以以list的格式放在redis里去缓存

	key=某大v

	value=[zhangsan, lisi, wangwu]

	比如可以通过list存储一些列表型的数据结构，类似粉丝列表了、文章的评论列表了之类的东西

	比如可以通过lrange命令，就是从某个元素开始读取多少个元素，可以基于list实现分页查询，这个很棒的一个功能，基于redis实现简单的高性能分页，可以做类似微博那种下拉不断分页的东西，性能高，就一页一页走

	比如可以搞个简单的消息队列，从list头怼进去，从list尾巴那里弄出来

	（4）set

	无序集合，自动去重

	直接基于set将系统里需要去重的数据扔进去，自动就给去重了，如果你需要对一些数据进行快速的全局去重，你当然也可以基于jvm内存里的HashSet进行去重，但是如果你的某个系统部署在多台机器上呢？

	得基于redis进行全局的set去重

	可以基于set玩儿交集、并集、差集的操作，比如交集吧，可以把两个人的粉丝列表整一个交集，看看俩人的共同好友是谁？对吧

	把两个大v的粉丝都放在两个set中，对两个set做交集

	（5）sorted set

	排序的set，去重但是可以排序，写进去的时候给一个分数，自动根据分数排序，这个可以玩儿很多的花样，最大的特点是有个分数可以自定义排序规则

	比如说你要是想根据时间对数据排序，那么可以写入进去的时候用某个时间作为分数，人家自动给你按照时间排序了

	排行榜：将每个用户以及其对应的什么分数写入进去，
	zadd board score username，
	接着zrevrange board 0 99，
	就可以获取排名前100的用户；
	zrank board username，
	可以看到用户在排行榜里的排名

	zadd board 85 zhangsan
	zadd board 72 wangwu
	zadd board 96 lisi
	zadd board 62 zhaoliu

	96 lisi
	85 zhangsan
	72 wangwu
	62 zhaoliu

	zrevrange board 0 3

	获取排名前3的用户

	96 lisi
	85 zhangsan
	72 wangwu

	zrank board zhaoliu

	4



redis 删除策略：  
	      定期删除+ 惰性删除
	      每100ms 随机删除过期的key + 查询的时候才去删除过期的key


	如果redis的内存占用过多的时候，此时会进行内存淘汰，redis淘汰数据时还会同步到aof
	2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）


	redis持久化 RDB、AOF（灾难恢复、数据恢复）

	RDB持久化机制，对redis中的数据执行周期性的持久化

	AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集

	如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的持久化机制

	通过RDB或AOF，都可以将redis内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说阿里云，云服务

	如果redis挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中，然后重新启动redis，redis就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务

	如果同时使用RDB和AOF两种持久化机制，那么在redis重启的时候，会使用AOF来重新构建数据，因为AOF中的数据更加完整

	RDB 是快照 某个时间点的全部数据，产生多个文件
	AOF 是一个文件 不停的追加redis命令，比RDB效率慢
	（3）相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速

	AOF，存放的指令日志，做数据恢复的时候，其实是要回放和执行所有的指令日志，来恢复出来内存中的所有数据的
	RDB，就是一份数据文件，恢复的时候，直接加载到内存中即可

3、RDB持久化机制的缺点

	（1）如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据

	这个问题，也是rdb最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多

	（2）RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒

	一般不要让RDB的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能可能会有影响的


4、AOF持久化机制的优点

	（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据

	每隔1秒，就执行一次fsync操作，保证os cache中的数据写入磁盘中

	redis进程挂了，最多丢掉1秒钟的数据

	（2）AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复

	（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。

	（4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据


5、AOF持久化机制的缺点

	（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

	（2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

	如果你要保证一条数据都不丢，也是可以的，AOF的fsync设置成没写入一条数据，fsync一次，那就完蛋了，redis的QPS大降

	（3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

	（4）唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，还有做冷备，定期的备份，不太方便，可能要自己手写复杂的脚本去做，做冷备不太合适


	-------------------------------------------------------------------------------------
6、RDB和AOF到底该如何选择

	（1）不要仅仅使用RDB，因为那样会导致你丢失很多数据

	（2）也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug

	（3）综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复



	Redis常见性能问题和解决方案？
	(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件
	(2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次
	(3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内
	(4) 尽量避免在压力很大的主库上增加从库
	(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3…
	这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。
	Redis支持的Java客户端都有哪些？官方推荐用哪个？
	Redisson、Jedis、lettuce等等，官方推荐使用Redisson。


Redis如何做内存优化？
	尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面.


redis 高可用：
	主从方式（推荐）
	这种采取一主多从的办法，主从之间进行数据同步。 当Master宕机后，通过选举算法(Paxos、Raft)从slave中选举出新Master继续对外提供服务，主机恢复后以slave的身份重新加入。 主从另一个目的是进行读写分离，这是当单机读写压力过高的一种通用型解决方案。 其主机的角色只提供写操作或少量的读，把多余读请求通过负载均衡算法分流到单个或多个slave服务器上。

	缺点是主机宕机后，Slave虽然被选举成新Master了，但对外提供的IP服务地址却发生变化了，意味着会影响到客户端。 解决这种情况需要一些额外的工作，在当主机地址发生变化后及时通知到客户端，客户端收到新地址后，使用新地址继续发送新请求。






redis 哨兵模式 --主从
	哨兵的缺点：   master 挂了之后 请求瞬时无法服务，请求量不能满足